本发明涉及路由技术领域，尤其涉及一种标签交换路径状态的获取方法及装置。
背景技术：
在传送网中，为了实现流量工程，往往需要根据带宽、代价、标签资源等进行约束路径计算。为了实现这样的路径计算，互联网工程任务组(IETF)提出了路径计算单元(PCE)，用来处理一个路由域中的所有路径计算请求，或协调多个域的PCE处理跨域多个路由域的路径计算请求。
一般地，PCE也称为路径计算服务端，其中，路径计算客户端(PCC)向PCE发送路径计算请求，且PCE和PCC采用路径计算单元协议(PCEP)进行交互。PCC将路径计算请求(PCReq)发送给PCE，PCE根据自身的流量工程数据库(TED)进行约束路径的计算，完成后将路径结果通过路径计算响应(PCRep)返回给PCC，从而完成一次路径计算。
根据网络基准测试(RFC4655)的描述，PCE可以分为无状态(stateless)方式和有状态(stateful)方式。其中无状态的PCE，只与拓扑中的TED同步，不了解网络中已有的流量工程标签交换路径(TELSP)的状态。而有状态的PCE，则除和TED同步以外，还能和标签交换路径数据库(LSPDB)同步，从而掌握已有的TELSP的状态。这样，对于有状态PCE而言，就获得了一个标签交换路径(LSP)路径的全生命周期的信息，与各控制平面节点一样，其也具备了LSP的管理能力，并且是基于全局视野的LSP的管理能力，这种能力可为PCE的路径计算和管理提供更加灵活和有效的帮助。
IETF标准草案(draft-ietf-pce-stateful-pce)中对于有状态PCE的实现架构进行了描述。其中，定义了PCC和PCE端在PCEP会话初始化时，通过OPEN消息对有状态PCE支持的能力进行协商。只有协商成功，才能使用有状态PCE的同步功能，否则，不能使用。如图1所示，当PCC请求有状态PCE进行路径计算时，有状态PCE接收PCReq，并进行路径计算，最后将路径通过PCRep发送给PCC。当该PCC侧该LSP状态发生改变时，则不断地通过代理消息(PCRpt)报告LSP的状态变更。这是一般LSP同步的过程。
然而，在实际应用中，由于每次PCC和PCE在会话初始化时都需要协商对于有状态PCE扩展的支持能力。当两端的能力均支持时，才能由PCC向PCE上报LSP的状态，并且，当PCC请求PCE计算路径时，需携带LSP对象。既然是需要协商，那么就有可能存在失败的情况，如图2所示，当该路径计算的首PCC节点和PCE的有状态能力协商失败时，比如该PCC节点不支持有状态PCE的协议扩展，那么，即使PCE可以完成对该路径计算请求的处理，但由于该首PCC节点不支持有状态PCE的扩展，后续的该LSP的状态更新则无法通过PCRpt收集上来，会使得有状态PCE中的LSP状态数据库与实际网络中存在不一致的情况，从而影响有状态PCE的路径计算效果。
技术实现要素：
本发明要解决的技术问题是提供一种标签交换路径状态的获取方法及装置，通过在计算出的LSP路径的各PCC节点中，选择该LSP中的具备状态上报能力的下游PCC节点，代替该不支持有状态的PCE的协议扩展的首PCC节点向PCE上报该LSP的状态。
依据本发明的一个方面，提供了一种标签交换路径状态的获取方法，包括：
有状态的PCE获取来自多个PCC中的第一PCC节点发起的路径计算请求，其中，所述第一PCC节点不支持有状态的PCE的协议扩展；
根据所述路径计算请求，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点；
向所述第二PCC节点下发代理消息，并获得所述第二PCC节点根据所述代理消息代理第一PCC节点上报的LSP的状态信息。
其中，有状态的PCE获取来自多个PCC中的第一PCC节点发起的路径计算请求前还包括：
有状态的PCE与多个PCC的各PCC节点进行协商，获得有状态的PCE与各PCC节点的协商结果，所述协商结果记录有各PCC节点是否支持PCE的协议扩展的信息。
其中，所述在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点的步骤包括：
根据所述协商结果，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点。
其中，根据所述协商结果，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点的步骤包括：
根据所述协商结果，在计算出的路径的各下游PCC节点中，任意选择一个对于有状态的PCE的协议扩展支持的第二PCC节点或者按顺序选择第一个对于有状态的PCE的协议扩展支持的第二PCC节点。
其中，向所述第二PCC节点下发代理消息，并获得所述第二PCC节点根据所述代理消息代理第一PCC节点上报的LSP的状态信息的步骤包括：
向所述第二PCC节点下发代理消息，所述代理消息至少包括：用于告知第二PCC节点需代理其他PCC节点上报LSP状态信息的LSP状态代理上报标识、用于表示该PCE针对第一PCC节点发出的路径计算请求所计算出的路径的LSP的全路径信息以及LSP对象；
获得所述第二PCC节点代理第一PCC节点上报的LSP的状态更新报告，所述LSP的状态更新报告是第二PCC节点根据所述代理消息，为所述第一PCC节点计算出的路径生成的LSP状态更新报告。
其中，向所述第二PCC节点下发代理消息之后，所述方法还包括：
所述第二PCC节点将该代理消息中的LSP的全路径信息和该第二PCC节点上获得的全路径信息进行比对，如果比对结果一致，则确定出所述第二PCC节点需代理第一PCC节点上报所述路径的LSP状态更新报告，其中，所述LSP状态更新报告中至少包括：第二PCC节点生成的LSP状态代理上报标识、生成的LSP全路径信息以及生成的LSP对象。
依据本发明的另一个方面，还提供了一种标签交换路径状态的获取装置，包括：
获取模块，用于有状态的PCE获取来自多个PCC中的第一PCC节点发起的路径计算请求，其中，所述第一PCC节点不支持有状态的PCE的协议扩展；
选择模块，用于根据所述路径计算请求，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点；
处理模块，用于向所述第二PCC节点下发代理消息，并获得所述第二PCC节点根据所述代理消息代理第一PCC节点上报的LSP的状态信息。
其中，该装置还包括：
协商模块，用于有状态的PCE与多个PCC的各PCC节点进行协商，获得有状态的PCE与各PCC节点的协商结果，所述协商结果记录有各PCC节点是否支持PCE的协议扩展的信息。
其中，所述选择模块进一步用于：
根据所述协商结果，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点。
其中，所述选择模块进一步用于：
根据所述协商结果，在计算出的路径的各下游PCC节点中，任意选择一个对于有状态的PCE的协议扩展支持的第二PCC节点或者按顺序选择第一个对于有状态的PCE的协议扩展支持的第二PCC节点。
其中，所述处理模块包括：
发送单元，用于向所述第二PCC节点下发代理消息，所述代理消息至少包括：用于告知第二PCC节点需代理其他PCC节点上报LSP状态信息的LSP状态代理上报标识、用于表示该PCE针对第一PCC节点发出的路径计算请求所计算出的路径的LSP的全路径信息以及LSP对象；
接收单元，用于获得所述第二PCC节点代理第一PCC节点上报的LSP的状态更新报告，所述LSP的状态更新报告是第二PCC节点根据所述代理消息，为所述第一PCC节点计算出的路径生成的LSP状态更新报告。
其中，所述处理模块还包括：
对比单元，用于所述第二PCC节点将该代理消息中的LSP的全路径信息和该第二PCC节点上获得的全路径信息进行比对，如果比对结果一致，则确定出所述第二PCC节点需代理第一PCC节点上报所述路径的LSP状态更新报告，其中，所述LSP状态更新报告中至少包括：第二PCC节点生成的LSP状态代理上报标识、生成的LSP全路径信息以及生成的LSP对象。
本发明的有益效果是：
本发明实施例的标签交换路径状态的获取方法，通过在计算出的LSP路径的各PCC节点中，选择该LSP中的具备状态上报能力的下游PCC节点，代替该不支持有状态的PCE的协议扩展的首PCC节点向PCE上报该LSP的状态，可以大大降低当首PCC节点不具备上报LSP状态能力时，无法上报该LSP状态给有状态PCE所造成的影响。从而使得有状态PCE的LSP状态信息最大程度的和网络中各PCC节点上维护的LSP状态信息的一致性。
附图说明
图1表示现有技术中有状态PCE状态同步示意图；
图2表示本发明实施例的标签交换路径状态的获取方法原理示意图；
图3表示本发明实施例的标签交换路径状态的获取方法的流程图；
图4表示本发明实施例的标签交换路径状态的获取方法的实施过程示意图；
图5表示本发明实施例的标签交换路径状态的获取装置的结构示意图；
图6表示处理模块的结构示意图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
实施例一
依据本发明实施例的一个方面，提供了一种标签交换路径状态的获取方法，如图3所示，该方法包括：
步骤S33、有状态的路径计算服务端PCE获取来自多个路径计算客户端PCC中的第一PCC节点发起的路径计算请求。
其中，所述第一PCC节点不支持有状态的PCE的协议扩展，且该节点负责向PCE发送路径计算请求，并根据路径计算的结果发起LSP的信令建立过程，其中该路径计算请求中不包括LSP对象。
LSP对象，具体可包括PLSP-ID、Flag、TLVs字段。
可选地，在步骤S33之前，该方法还包括：
步骤S31、有状态的PCE与多个PCC的各PCC节点进行协商，获得有状态的PCE与各PCC节点的协商结果。
其中，所述协商结果记录有各PCC节点是否支持PCE的协议扩展的信息。
假设网络中PCE为有状态PCE，且一共有10个PCC节点，则在本发明实施例的标签交换路径状态的获取方法中，PCE和每个PCC的有状态能力协商的结果都需要保存在PCE中，并且当PCEP会话初始化每次重新完成时都需要进行相应的更新。其中，具体的协商方式，可在OPEN消息中携带STATEFUL-PCE-CAPABILITYTLV，以表示PCC或PCE侧对于有状态PCE的协议扩展支持。
当协商完毕后，PCE将协商的结果保存下来，可记为：
R＝{(PCC1,0),(PCC2，0),(PCC3,1),(PCC4,1),(PCC5,1),…,(PCC10,1)}，其中0表示协商失败，1表示协商成功。当然，可以理解的是，在本发明实施例的标签交换路径状态的获取方法中，并不具体限定协商结果的表示形式。
步骤S35、根据所述路径计算请求，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点。
一般地，若发起路径计算请求的第一PCC节点，支持有状态PCE的协议扩展，则该第一PCC节点会直接向PCE报告LSP的状态变更情况。然而，在实际应用中，并不是所有发起路径计算请求的第一PCC节点都支持有状态PCE的协议扩展。为了后续的LSP的状态更新依然能够通过PCRpt消息收集上来，所以，本发明实施例的标签交换路径状态的获取方法，需要根据所述路径计算请求，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点。
可选地，步骤S35包括：
根据所述协商结果，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点。
因为协商结果中记录有每一个PCC节点是否支持PCE的协议扩展的信息，所以，可依据协商结果，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点，来代替不支持有状态PCE的协议扩展的第一PCC节点，向PCE报告LSP的状态变更情况。
其中，在选择第二节点PCC时，可在计算出的路径的各下游PCC节点中，任意选择一个对于有状态的PCE的协议扩展支持的第二PCC节点或者按顺序选择第一个对于有状态的PCE的协议扩展支持的第二PCC节点。
步骤S37、向所述第二PCC节点下发代理消息，并获得所述第二PCC节点根据所述代理消息代理第一PCC节点上报的LSP的状态信息。
可选地，步骤S37包括：
向所述第二PCC节点下发代理消息；
获得所述第二PCC节点代理第一PCC节点上报的LSP的状态更新报告。
其中，所述代理消息至少包括：用于告知第二PCC节点需代理其他PCC节点上报LSP状态信息的LSP状态代理上报标识、用于表示该PCE针对第一PCC节点发出的路径计算请求所计算出的路径的LSP的全路径信息以及LSP对象；
所述LSP的状态更新报告是第二PCC节点根据所述代理消息，为所述第一PCC节点计算出的路径生成的LSP状态更新报告。
可选地，向所述第二PCC节点下发代理消息步骤之后，该方法还包括：
所述第二PCC节点将该代理消息中的LSP的全路径信息和该第二PCC节点上获得的全路径信息进行比对，如果比对结果一致，则确定出所述第二PCC节点需代理第一PCC节点上报所述路径的LSP状态更新报告。其中，第二节点上的全路径信息可通过记录路由(RRO)对象获得。
其中，所述LSP状态更新报告中至少包括：第二PCC节点生成的LSP状态代理上报标识、生成的LSP全路径信息以及生成的LSP对象。
具体地，如图4所示：
假设网络中PCE为有状态PCE，一共有10个PCC节点，分别为从PCC1～PCC10。PCC1发起的一条路径计算，计算得出的路径为PCC1～PCC5的5个节点。其中PCC1，PCC2不支持有状态PCE的协议扩展，PCC3、PCC4、PCC5均支持。
依据本发明实施例的标签交换路径状态的获取方法，首先，PCC1、PCC2、PCC3、PCC4、PCC5分别在PCEP会话的初始化中协商有状态PCE的能力。具体方式为在OPEN消息中携带STATEFUL-PCE-CAPABILITYTLV，以表示PCC或PCE侧对于有状态PCE的协议扩展支持。
接着，PCE将协商的结果保存下来，记为R＝{(PCC1,0),(PCC2，0),(PCC3,1),(PCC4,1),(PCC5,1),…,(PCC10,1)}，其中0表示协商失败，1表示协商成功。
再次，当PCE收到PCC1的PCReq后，会依据PCReq完成路径计算，得到路径为L＝PCC1-PCC2-PCC3-PCC4-PCC5，并将该路径L通过PCRep返回给PCC1。
再次，当PCE从上述协商结果中获取到PCC1协商失败的结果时，会根据L中从PCC1开始的每个节点顺序依次从R集合中寻找其协商结果。找到第一个协商成功的PCC节点为PCC3。当然，也可从协商成功的PCC3、PCC4、PCC5这三个节点中任意选择一个节点，作为第一PCC节点的代理节点，即第二PCC节点。
再次，PCE向PCC3发送PCUpt消息，请求PCC3代替PCC1发送该路径L的LSP相应的状态更新报告LSP，其中PCUpt中包括：SRP、LSP、path对象。
其中SRP对象为：
其中Flags的D(delegate)位为1，表示需PCC3代理上报LSP状态，其他为0；SRP-ID-number＝0x00000001；OptionalTLVs为空。
LSP对象为：
其中，PLSP-ID、Flag、TLVs均为0；
Path对象中携带路径为PCC1-PCC2-PCC3-PCC4-PCC5，包括详细的路径信息或标签等。
最后，PCC3收到来自PCE的PCUpt后，根据SRP中的Flags的D位，LSP全0，判断出PCC3需代理其他PCC上报LSP状态。根据path和本节点中路径进行比对，当对比结果一致时，确定出需上报信息的LSP，该LSP的首节点并不是本PCC3节点。PCC3节点为该LSP生成唯一的标签路径名称(Symbolicpathname)，以及相应的PLSP-ID字段，使用PCRpt向PCE上报该LSP的状态信息。
其中，PCRpt中包括SRP、LSP、path对象。其中LSP对象中PLSP-ID为新生成的PLSP-ID，SymbolicPathnameTLV中也为新生成的Symbolicpathname。
此外，若后续该LSP再次发生变更，则PCC3均通过PCRpt消息代理PCC1上报该LSP的状态报告。
实施例二
依据本发明实施例的另一个方面，还提供了一种标签交换路径状态的获取装置，如图5所示，该装置500包括：
获取模块502，用于有状态的路径计算服务端PCE获取来自多个路径计算客户端PCC中的第一PCC节点发起的路径计算请求，其中，所述第一PCC节点不支持有状态的PCE的协议扩展；
选择模块503，用于根据所述路径计算请求，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点；
处理模块504，用于向所述第二PCC节点下发代理消息，并获得所述第二PCC节点根据所述代理消息代理第一PCC节点上报的LSP的状态信息。
可选地，该装置还包括：
协商模块501，用于有状态的PCE与多个PCC的各PCC节点进行协商，获得有状态的PCE与各PCC节点的协商结果，所述协商结果记录有各PCC节点是否支持PCE的协议扩展的信息。
可选地，所述选择模块503进一步用于：
根据所述协商结果，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点。
可选地，所述选择模块503进一步用于：
根据所述协商结果，在计算出的路径的各下游PCC节点中，任意选择一个对于有状态的PCE的协议扩展支持的第二PCC节点或者按顺序选择第一个对于有状态的PCE的协议扩展支持的第二PCC节点。
可选地，如图6所示，所述处理模块504包括：
发送单元5041，用于向所述第二PCC节点下发代理消息，所述代理消息至少包括：用于告知第二PCC节点需代理其他PCC节点上报LSP状态信息的LSP状态代理上报标识、用于表示该PCE针对第一PCC节点发出的路径计算请求所计算出的路径的LSP的全路径信息以及LSP对象；
接收单元5043，用于获得所述第二PCC节点代理第一PCC节点上报的LSP的状态更新报告，所述LSP的状态更新报告是第二PCC节点根据所述代理消息，为所述第一PCC节点计算出的路径生成的LSP状态更新报告。
可选地，所述处理模块504还包括：
对比单元5042，用于所述第二PCC节点将该代理消息中的LSP的全路径信息和该第二PCC节点上获得的全路径信息进行比对，如果比对结果一致，则确定出所述第二PCC节点需代理第一PCC节点上报所述路径的LSP状态更新报告，其中，所述LSP状态更新报告中至少包括：第二PCC节点生成的LSP状态代理上报标识、生成的LSP全路径信息以及生成的LSP对象。
以上所述是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明所述原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。