WO2016095699A1 - 一种标签交换路径状态的获取方法及装置 - Google Patents

一种标签交换路径状态的获取方法及装置 Download PDF

Info

Publication number
WO2016095699A1
WO2016095699A1 PCT/CN2015/096031 CN2015096031W WO2016095699A1 WO 2016095699 A1 WO2016095699 A1 WO 2016095699A1 CN 2015096031 W CN2015096031 W CN 2015096031W WO 2016095699 A1 WO2016095699 A1 WO 2016095699A1
Authority
WO
WIPO (PCT)
Prior art keywords
pcc
path
lsp
pcc node
node
Prior art date
Application number
PCT/CN2015/096031
Other languages
English (en)
French (fr)
Inventor
卢刚
王志宏
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2016095699A1 publication Critical patent/WO2016095699A1/zh

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols

Definitions

  • the present invention relates to the field of routing technologies, and in particular, to a method and an apparatus for acquiring a label switched path state.
  • PCE Path Computation Unit
  • the PCE is also referred to as a path computation server, wherein a path computation client (PCC) sends a path computation request to the PCE, and the PCE and PCC interact using a Path Computation Unit Protocol (PCEP).
  • PCC path computation client
  • PCEP Path Computation Unit Protocol
  • the PCC sends a path calculation request (PCReq) to the PCE.
  • PCE performs the calculation of the constraint path according to its own Traffic Engineering Database (TED). After completion, the path result is returned to the PCC through the path calculation response (PCRep), thereby completing a path calculation.
  • PCE can be divided into stateless and stateful.
  • the stateless PCE is only synchronized with the TED in the topology, and does not know the state of the existing traffic engineering label switching path (TE LSP) in the network.
  • the stateful PCE in addition to synchronizing with the TED, can also synchronize with the label switched path database (LSP DB) to grasp the state of the existing TE LSP.
  • LSP DB label switched path database
  • stateful PCE The implementation architecture of stateful PCE is described in the draft IETF standard (draft-ietf-pce-stateful-pce). Among them, it is defined that the PCC and the PCE end negotiate the capability of the stateful PCE support through the OPEN message when the PCEP session is initialized. The synchronization function of the stateful PCE can only be used if the negotiation is successful. Otherwise, it cannot be used. As shown in FIG. 1, when the PCC requests the stateful PCE to perform path calculation, the stateful PCE receives the PCReq, performs path calculation, and finally sends the path to the PCC through the PCRep. When the LSP state changes on the PCC side, the state change of the LSP is continuously reported through the proxy message (PCRpt). This is the process of general LSP synchronization.
  • PCRpt proxy message
  • the embodiment of the present invention provides a method and a device for acquiring a label switching path state, by selecting a downstream PCC node with state reporting capability in the LSP in the calculated LSP path, instead of not supporting the The first PCC node of the protocol extension of the state PCE reports the status of the LSP to the PCE.
  • a method for obtaining a label switched path state includes:
  • Stateful PCE acquires path computation initiated by the first PCC node from multiple PCCs a request, wherein the first PCC node does not support protocol extension of a stateful PCE;
  • the stateful PCE obtains the path calculation request initiated by the first PCC node from the plurality of PCCs, and further includes:
  • the stateful PCE negotiates with each PCC node of the plurality of PCCs to obtain a negotiation result between the stateful PCE and each PCC node, and the negotiation result records information about whether each PCC node supports protocol extension of the PCE.
  • the step of selecting a second PCC node supported by the protocol extension of the stateful PCE in each of the downstream PCC nodes in the calculated path includes:
  • the step of selecting a second PCC node supported by the protocol extension of the stateful PCE includes:
  • the step of sending a proxy message to the second PCC node, and obtaining the status information of the LSP reported by the second PCC node according to the proxy message to the first PCC node includes:
  • the path of the LSP issued by the PCC node calculates the full path information of the LSP and the LSP object of the calculated path;
  • the status update report of the LSP is an LSP status update report generated by the second PCC node for the path calculated by the first PCC node according to the proxy message.
  • the method further includes:
  • the second PCC node compares the full path information of the LSP in the proxy message with the full path information obtained on the second PCC node, and if the comparison result is consistent, determining that the second PCC node needs to be a proxy
  • the first PCC node reports the LSP status update report of the path, where the LSP status update report includes at least the LSP status proxy report identifier generated by the second PCC node, the generated LSP full path information, and the generated LSP object.
  • a device for acquiring a label switched path state including:
  • An acquisition module configured to acquire, by the stateful PCE, a path calculation request initiated by a first PCC node from the plurality of PCCs, wherein the first PCC node does not support protocol extension of the stateful PCE;
  • Selecting a module configured to: according to the path calculation request, select, in each of the calculated downstream path PCC nodes, a second PCC node supported by the protocol extension of the stateful PCE;
  • the processing module is configured to send a proxy message to the second PCC node, and obtain status information of the LSP reported by the second PCC node by the second PCC node according to the proxy message.
  • the device further comprises:
  • the negotiation module sets the stateful PCE to negotiate with each PCC node of the plurality of PCCs to obtain a negotiation result between the stateful PCE and each PCC node, and the negotiation result records information about whether each PCC node supports the protocol extension of the PCE. .
  • the selection module is further configured to:
  • the selection module is further configured to:
  • the processing module includes:
  • a sending unit configured to send a proxy message to the second PCC node, where the proxy message includes: an LSP state proxy reporting identifier used to notify the second PCC node that the other PCC node is required to report the LSP status information, and is used to indicate
  • the PCE calculates the full path information of the LSP and the LSP object of the path calculated by the path sent by the first PCC node;
  • a receiving unit configured to obtain a status update report of the LSP reported by the first PCC node by the second PCC node, where the status update report of the LSP is that the second PCC node is the first PCC node according to the proxy message
  • the calculated LSP status update report generated by the path.
  • the processing module further includes:
  • a comparison unit configured to compare, by the second PCC node, the full path information of the LSP in the proxy message with the full path information obtained on the second PCC node, and if the comparison result is consistent, determine the first
  • the second PCC node needs to proxy the LSP status update report of the path to the first PCC node, where the LSP status update report includes at least: an LSP state proxy report identifier generated by the second PCC node, the generated LSP full path information, and The generated LSP object.
  • the method for obtaining the label switching path state in the embodiment of the present invention by selecting the downstream PCC node having the status reporting capability in the LSP in the calculated LSP path, instead of the protocol not supporting the stateful PCE
  • the extended first PCC node reports the status of the LSP to the PCE, which can greatly reduce the impact of the LSP state on the stateful PCE when the first PCC node does not have the ability to report the LSP status. Therefore, the LSP state information of the stateful PCE is maximized and the LSP state information maintained on each PCC node in the network is consistent.
  • FIG. 2 is a schematic diagram showing the principle of acquiring a label switching path state according to an embodiment of the present invention
  • FIG. 3 is a flowchart of a method for acquiring a label switching path state according to an embodiment of the present invention
  • FIG. 4 is a schematic diagram showing an implementation process of a method for acquiring a label switching path state according to an embodiment of the present invention
  • FIG. 5 is a schematic structural diagram of an apparatus for acquiring a label switching path state according to an embodiment of the present invention
  • Figure 6 shows a schematic structural view of a processing module.
  • a method for obtaining a label switching path state includes:
  • Step S33 The stateful path calculation server PCE acquires a path calculation request initiated by the first PCC node in the plurality of path calculation client PCCs.
  • the first PCC node does not support the protocol extension of the stateful PCE, and the node is responsible for sending a path calculation request to the PCE, and initiates a signaling establishment process of the LSP according to the path calculation result, where the path calculation request does not Includes LSP objects.
  • the LSP object may specifically include a PLSP-ID, Flag, and TLVs fields.
  • the method further includes:
  • Step S31 The stateful PCE negotiates with each PCC node of the plurality of PCCs to obtain a negotiation result between the stateful PCE and each PCC node.
  • the negotiation result records information about whether each PCC node supports protocol extension of the PCE.
  • the result of the stateful capability negotiation between the PCE and each PCC needs to be saved in the PCE.
  • the specific negotiation mode may carry the STATEFUL-PCE-CAPABILITY TLV in the OPEN message to indicate the protocol extension support of the stateful PCE on the PCC or PCE side.
  • the PCE saves the result of the negotiation and can be recorded as:
  • Step S35 Select, according to the path calculation request, a second PCC node supported by the protocol extension of the stateful PCE among each of the downstream PCC nodes in the calculated path.
  • the first PCC node that initiates the path computation request supports the protocol extension of the stateful PCE
  • the first PCC node directly reports the state change of the LSP to the PCE.
  • not all first PCC nodes that initiate path computation requests support protocol extensions for stateful PCEs.
  • the method for obtaining the status of the label switched path in the embodiment of the present invention needs to be based on the path calculation request, in each downstream PCC node in the calculated path, for the status update of the subsequent LSP is still collected by the PCR pt message. Select a second PCC node that is supported for protocol extension of the stateful PCE.
  • step S35 includes:
  • a second PCC node supporting the protocol extension of the stateful PCE may be selected according to the negotiation result instead of not supporting the stateful PCE.
  • the first PCC node of the protocol extension reports the status change of the LSP to the PCE.
  • a second PCC node supported by the protocol extension of the stateful PCE may be arbitrarily selected among the downstream PCC nodes of the calculated path or the first one may be selected in order for the stateful
  • the PCE protocol extension supports the second PCC node.
  • Step S37 Send a proxy message to the second PCC node, and obtain status information of the LSP reported by the second PCC node according to the proxy message.
  • step S37 includes:
  • the proxy message includes at least: an LSP state proxy report identifier for informing the second PCC node that the other PCC node is required to report the LSP state information, and is used to indicate that the PCE calculates the path calculation request sent by the first PCC node. Full path information of the LSP of the path and the LSP object;
  • the status update report of the LSP is an LSP status update report generated by the second PCC node for the path calculated by the first PCC node according to the proxy message.
  • the method further includes:
  • the second PCC node compares the full path information of the LSP in the proxy message with the full path information obtained on the second PCC node, and if the comparison result is consistent, determining that the second PCC node needs to be a proxy
  • the first PCC node reports an LSP status update report of the path.
  • the full path information on the second node can be obtained through a record routing (RRO) object.
  • the LSP status update report includes at least: an LSP generated by the second PCC node.
  • the status agent reports the identifier, the generated LSP full path information, and the generated LSP object.
  • PCC1 and PCC2 do not support protocol extension of stateful PCE, and PCC3, PCC4, and PCC5 support it.
  • first, PCC1, PCC2, PCC3, PCC4, and PCC5 respectively negotiate the capability of the stateful PCE in the initialization of the PCEP session.
  • the specific way is to carry the STATEFUL-PCE-CAPABILITY TLV in the OPEN message to indicate the protocol extension support for the stateful PCE on the PCC or PCE side.
  • the negotiation result is searched for from the R set in sequence according to each node starting from PCC1 in L. Find the first PCC node that negotiated successfully as PCC3.
  • one node may be arbitrarily selected from the three nodes of the successful PCC3, PCC4, and PCC5 as the proxy node of the first PCC node, that is, the second PCC node.
  • the PCE sends a PCUpt message to the PCC3, and requests the PCC3 to send a status update report LSP corresponding to the LSP of the path L instead of the PCC1.
  • the PCUpt includes: an SRP, an LSP, and a path object.
  • the SRP object is:
  • the LSP object is:
  • PLSP-ID 0
  • Flag 0
  • TLVs 0
  • the Path object carries the path PCC1-PCC2-PCC3-PCC4-PCC5, including detailed path information or labels.
  • the PCC3 judges that the PCC3 needs to proxy other PCCs to report the LSP status according to the D bit of the Flags in the SRP and the LSP all zeros.
  • the path is compared with the path in the local node. When the comparison result is consistent, the LSP that needs to report information is determined.
  • the first node of the LSP is not the PCC3 node.
  • the PCC3 node generates a unique label path name (Symbolic path name) for the LSP, and the corresponding PLSP-ID field, and uses the PCR pt to report the status information of the LSP to the PCE.
  • PCRpt includes SRP, LSP, and path objects.
  • the PLSP-ID in the LSP object is the newly generated PLSP-ID, and the newly generated Symbolic path name is also in the Symbolic Path name TLV.
  • the PCC3 reports the status report of the LSP through the PCR pt message proxy PCC1.
  • the device 500 includes:
  • the obtaining module 502 is set to be a stateful path computing server PCE to obtain multiple paths
  • the path calculation request initiated by the first PCC node in the client PCC is calculated, wherein the first PCC node does not support the protocol extension of the stateful PCE;
  • the selecting module 503 is configured to: according to the path calculation request, select, in each of the calculated downstream path PCC nodes, a second PCC node supported by the protocol extension of the stateful PCE;
  • the processing module 504 is configured to send a proxy message to the second PCC node, and obtain status information of the LSP reported by the first PCC node by the second PCC node according to the proxy message.
  • the device further includes:
  • the negotiation module 501 sets the stateful PCE to negotiate with each PCC node of the plurality of PCCs to obtain a negotiation result between the stateful PCE and each PCC node, and the negotiation result records whether each PCC node supports the protocol extension of the PCE. information.
  • the selecting module 503 is further configured to:
  • the selecting module 503 is further configured to:
  • the processing module 504 includes:
  • the sending unit 5041 is configured to send a proxy message to the second PCC node, where the proxy message includes: an LSP state proxy report identifier used to notify the second PCC node that the other PCC node is required to report the LSP state information, and is used for Indicates the full path information of the LSP and the LSP object of the path calculated by the PCE for the path calculation request sent by the first PCC node;
  • the receiving unit 5043 is configured to obtain a status update report of the LSP reported by the first PCC node by the second PCC node, where the status update report of the LSP is that the second PCC node is the first PCC according to the proxy message.
  • the LSP status generated by the path calculated by the node is more New report.
  • processing module 504 further includes:
  • the comparing unit 5042 is configured to compare, by the second PCC node, the full path information of the LSP in the proxy message with the full path information obtained on the second PCC node, and if the comparison result is consistent, determine the The second PCC node needs to proxy the LSP status update report of the path reported by the first PCC node, where the LSP status update report includes at least: an LSP state proxy report identifier generated by the second PCC node, and the generated LSP full path information. And the generated LSP object.
  • modules or steps of the present invention described above can be implemented by a general-purpose computing device that can be centralized on a single computing device or distributed across a network of multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from the order herein.
  • the steps shown or described are performed, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated as a single integrated circuit module.
  • the invention is not limited to any specific combination of hardware and software.
  • the method and apparatus for acquiring the state of the label switched path provided by the embodiment of the present invention have the following beneficial effects: the LSP state cannot be reported to the stateful PCE when the first PCC node does not have the capability of reporting the LSP state. The impact. Thus, the LSP state information of the stateful PCE is maximized and maintained on each PCC node in the network. Consistency of LSP status information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种标签交换路径状态的获取方法及装置，该方法包括：有状态的路径计算服务端PCE获取来自多个路径计算客户端PCC中的第一PCC节点发起的路径计算请求，其中，第一PCC节点不支持有状态的PCE的协议扩展；根据路径计算请求，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点；向第二PCC节点下发代理消息，并获得第二PCC节点根据代理消息代理第一PCC节点上报的LSP的状态信息。本发明的方案使得在第一PCC节点和PCE的有状态能力协商失败时，仍然能够上报该LSP状态，进而保证了有状态PCE中的LSP状态数据库和实际网络中能够最大程度地保持一致。

Description

一种标签交换路径状态的获取方法及装置 技术领域
本发明涉及路由技术领域，尤其涉及一种标签交换路径状态的获取方法及装置。
背景技术
在传送网中，为了实现流量工程，往往需要根据带宽、代价、标签资源等进行约束路径计算。为了实现这样的路径计算，互联网工程任务组(IETF)提出了路径计算单元(PCE)，用来处理一个路由域中的所有路径计算请求，或协调多个域的PCE处理跨域多个路由域的路径计算请求。
一般地，PCE也称为路径计算服务端，其中，路径计算客户端(PCC)向PCE发送路径计算请求，且PCE和PCC采用路径计算单元协议(PCEP)进行交互。PCC将路径计算请求(PCReq)发送给PCE，PCE根据自身的流量工程数据库(TED)进行约束路径的计算，完成后将路径结果通过路径计算响应(PCRep)返回给PCC，从而完成一次路径计算。
根据网络基准测试(RFC4655)的描述，PCE可以分为无状态(stateless)方式和有状态(stateful)方式。其中无状态的PCE，只与拓扑中的TED同步，不了解网络中已有的流量工程标签交换路径(TE LSP)的状态。而有状态的PCE，则除和TED同步以外，还能和标签交换路径数据库(LSP DB)同步，从而掌握已有的TE LSP的状态。这样，对于有状态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-CAPABILITY TLV，以表示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-CAPABILITY TLV，以表示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对象为：
Figure PCTCN2015096031-appb-000001
Figure PCTCN2015096031-appb-000002
其中Flags的D(delegate)位为1，表示需PCC3代理上报LSP状态，其他为0；SRP-ID-number＝0x00000001；Optional TLVs为空。
LSP对象为：
Figure PCTCN2015096031-appb-000003
其中，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生成唯一的标签路径名称(Symbolic path name)，以及相应的PLSP-ID字段，使用PCRpt向PCE上报该LSP的状态信息。
其中，PCRpt中包括SRP、LSP、path对象。其中LSP对象中PLSP-ID为新生成的PLSP-ID，Symbolic Path name TLV中也为新生成的Symbolic path name。
此外，若后续该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对象。
显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
工业实用性
如上所述，本发明实施例提供的一种标签交换路径状态的获取方法及装置具有以下有益效果：可以大大降低当首PCC节点不具备上报LSP状态能力时，无法上报该LSP状态给有状态PCE所造成的影响。从而使得有状态PCE的LSP状态信息最大程度的和网络中各PCC节点上维护的 LSP状态信息的一致性。

Claims (12)

  1. 一种标签交换路径状态的获取方法，包括：
    有状态的路径计算服务端PCE获取来自多个路径计算客户端PCC中的第一PCC节点发起的路径计算请求，其中，所述第一PCC节点不支持有状态的PCE的协议扩展；
    根据所述路径计算请求，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点；
    向所述第二PCC节点下发代理消息，并获得所述第二PCC节点根据所述代理消息代理第一PCC节点上报的标签交换路径LSP的状态信息。
  2. 如权利要求1所述的标签交换路径状态的获取方法，其中，有状态的路径计算服务端PCE获取来自多个路径计算客户端PCC中的第一PCC节点发起的路径计算请求前还包括：
    有状态的PCE与多个PCC的各PCC节点进行协商，获得有状态的PCE与各PCC节点的协商结果，所述协商结果记录有各PCC节点是否支持PCE的协议扩展的信息。
  3. 如权利要求2所述的标签交换路径状态的获取方法，其中，所述在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点的步骤包括：
    根据所述协商结果，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点。
  4. 如权利要求3所述的标签交换路径状态的获取方法，其中，根据所述协商结果，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点的步骤包括：
    根据所述协商结果，在计算出的路径的各下游PCC节点中，任意选择一个对于有状态的PCE的协议扩展支持的第二PCC节点，或者按顺序选择第一个对于有状态的PCE的协议扩展支持的第二PCC节点。
  5. 如权利要求1所述的标签交换路径状态的获取方法，其中，向所述第二PCC节点下发代理消息，并获得所述第二PCC节点根据所述代理消 息代理第一PCC节点上报的LSP的状态信息的步骤包括：
    向所述第二PCC节点下发代理消息，所述代理消息至少包括：用于告知第二PCC节点需代理其他PCC节点上报LSP状态信息的LSP状态代理上报标识、用于表示该PCE针对第一PCC节点发出的路径计算请求所计算出的路径的LSP的全路径信息以及LSP对象；
    获得所述第二PCC节点代理第一PCC节点上报的LSP的状态更新报告，所述LSP的状态更新报告是第二PCC节点根据所述代理消息，为所述第一PCC节点计算出的路径生成的LSP状态更新报告。
  6. 如权利要求5所述的标签交换路径状态的获取方法，其中，向所述第二PCC节点下发代理消息之后，所述方法还包括：
    所述第二PCC节点将该代理消息中的LSP的全路径信息和该第二PCC节点上获得的全路径信息进行比对，如果比对结果一致，则确定出所述第二PCC节点需代理第一PCC节点上报所述路径的LSP状态更新报告，其中，所述LSP状态更新报告中至少包括：第二PCC节点生成的LSP状态代理上报标识、生成的LSP全路径信息以及生成的LSP对象。
  7. 一种标签交换路径状态的获取装置，包括：
    获取模块，设置为有状态的路径计算服务端PCE获取来自多个路径计算客户端PCC中的第一PCC节点发起的路径计算请求，其中，所述第一PCC节点不支持有状态的PCE的协议扩展；
    选择模块，设置为根据所述路径计算请求，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点；
    处理模块，设置为向所述第二PCC节点下发代理消息，并获得所述第二PCC节点根据所述代理消息代理第一PCC节点上报的LSP的状态信息。
  8. 如权利要求7所述的标签交换路径状态的获取装置，其中，还包括：
    协商模块，设置为有状态的PCE与多个PCC的各PCC节点进行协商， 获得有状态的PCE与各PCC节点的协商结果，所述协商结果记录有各PCC节点是否支持PCE的协议扩展的信息。
  9. 如权利要求8所述的标签交换路径状态的获取装置，其中，所述选择模块还设置为：
    根据所述协商结果，在计算出的路径中的各下游PCC节点中，选择一个对于有状态的PCE的协议扩展支持的第二PCC节点。
  10. 如权利要求9所述的标签交换路径状态的获取装置，其中，所述选择模块还设置为：
    根据所述协商结果，在计算出的路径的各下游PCC节点中，任意选择一个对于有状态的PCE的协议扩展支持的第二PCC节点或者按顺序选择第一个对于有状态的PCE的协议扩展支持的第二PCC节点。
  11. 如权利要求7所述的标签交换路径状态的获取装置，其中，所述处理模块包括：
    发送单元，设置为向所述第二PCC节点下发代理消息，所述代理消息至少包括：用于告知第二PCC节点需代理其他PCC节点上报LSP状态信息的LSP状态代理上报标识、用于表示该PCE针对第一PCC节点发出的路径计算请求所计算出的路径的LSP的全路径信息以及LSP对象；
    接收单元，设置为获得所述第二PCC节点代理第一PCC节点上报的LSP的状态更新报告，所述LSP的状态更新报告是第二PCC节点根据所述代理消息，为所述第一PCC节点计算出的路径生成的LSP状态更新报告。
  12. 如权利要求11所述的标签交换路径状态的获取装置，其中，所述处理模块还包括：
    对比单元，设置为所述第二PCC节点将该代理消息中的LSP的全路径信息和该第二PCC节点上获得的全路径信息进行比对，如果比对结果一致，则确定出所述第二PCC节点需代理第一PCC节点上报所述路径的LSP状态更新报告，其中，所述LSP状态更新报告中至少包括：第二PCC 节点生成的LSP状态代理上报标识、生成的LSP全路径信息以及生成的LSP对象。
PCT/CN2015/096031 2014-12-16 2015-11-30 一种标签交换路径状态的获取方法及装置 WO2016095699A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201410784084.2 2014-12-16
CN201410784084.2A CN105763447B (zh) 2014-12-16 2014-12-16 一种标签交换路径状态的获取方法及装置

Publications (1)

Publication Number Publication Date
WO2016095699A1 true WO2016095699A1 (zh) 2016-06-23

Family

ID=56125884

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2015/096031 WO2016095699A1 (zh) 2014-12-16 2015-11-30 一种标签交换路径状态的获取方法及装置

Country Status (2)

Country Link
CN (1) CN105763447B (zh)
WO (1) WO2016095699A1 (zh)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108023810A (zh) * 2016-10-31 2018-05-11 中兴通讯股份有限公司 连接能力的通告方法及装置
CN108075976A (zh) * 2016-11-11 2018-05-25 中兴通讯股份有限公司 一种进行计划带宽调整的方法及装置
CN108235378A (zh) * 2016-12-15 2018-06-29 中兴通讯股份有限公司 一种实现pcep的通信方法和装置
CN109428865B (zh) * 2017-08-30 2021-12-07 中兴通讯股份有限公司 一种切换标签交换路径更新权限的方法及相关设备

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101001200A (zh) * 2006-01-13 2007-07-18 华为技术有限公司 一种区域间流量工程全网计算方法及系统
CN101237399A (zh) * 2007-09-28 2008-08-06 华为技术有限公司 获取标签交换路径的方法、系统和设备
CN101335692A (zh) * 2007-06-27 2008-12-31 华为技术有限公司 协商pcc和pce之间安全能力的方法及其网络系统
US20130336107A1 (en) * 2012-06-15 2013-12-19 Cisco Technology, Inc. Dynamically triggered traffic engineering routing advertisements in stateful path computation element environments
US8885463B1 (en) * 2011-10-17 2014-11-11 Juniper Networks, Inc. Path computation element communication protocol (PCEP) extensions for stateful label switched path management

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100546259C (zh) * 2006-07-12 2009-09-30 华为技术有限公司 一种发现路径计算元件的方法、系统及该系统中的服务端
CN102469009B (zh) * 2010-11-09 2015-06-03 中兴通讯股份有限公司 有状态路径计算单元的处理方法及有状态路径计算单元
US8817591B2 (en) * 2012-06-15 2014-08-26 Cisco Technology, Inc. Inter-domain signaling to update remote path computation elements after a call set-up failure

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101001200A (zh) * 2006-01-13 2007-07-18 华为技术有限公司 一种区域间流量工程全网计算方法及系统
CN101335692A (zh) * 2007-06-27 2008-12-31 华为技术有限公司 协商pcc和pce之间安全能力的方法及其网络系统
CN101237399A (zh) * 2007-09-28 2008-08-06 华为技术有限公司 获取标签交换路径的方法、系统和设备
US8885463B1 (en) * 2011-10-17 2014-11-11 Juniper Networks, Inc. Path computation element communication protocol (PCEP) extensions for stateful label switched path management
US20130336107A1 (en) * 2012-06-15 2013-12-19 Cisco Technology, Inc. Dynamically triggered traffic engineering routing advertisements in stateful path computation element environments

Also Published As

Publication number Publication date
CN105763447A (zh) 2016-07-13
CN105763447B (zh) 2020-04-24

Similar Documents

Publication Publication Date Title
WO2016095699A1 (zh) 一种标签交换路径状态的获取方法及装置
US10084558B2 (en) Cross-domain clock synchronization method, device and system and computer storage medium
US20150372905A1 (en) DHT-based control network implementation method and system, and network controller
KR102158654B1 (ko) 자원 구독 방법, 자원 구독 장치, 및 자원 구독 시스템
WO2017133531A1 (zh) 异步服务处理方法及服务器
US20160043934A1 (en) Routing Of Point-to-Multipoint Services in a Multi-Domain Network
CN109076014A (zh) 分组交换通信网络中的标签数据库同步
EP3016328B1 (en) Path acquisition method, path computation element, path computation client and system
CN110300061A (zh) 一种通告绑定信息的方法、设备及存储介质
CN110740355A (zh) 设备监测方法、装置、电子设备及存储介质
WO2016161918A1 (zh) 一种状态上报控制方法和装置
EP3139552B1 (en) Virtual shortest path tree establishment and processing method, and path computation element
WO2015117365A1 (zh) Hello报文交互的方法、设备和系统
WO2018113793A1 (zh) 路径计算方法和装置、pcc、pce及路径计算系统
JP4664258B2 (ja) 経路状態管理システム、制御装置、ネットワーク管理装置、通信装置および経路状態管理方法
WO2016141653A1 (zh) 一种sctp连接重建立方法和装置、存储介质
WO2014166453A1 (zh) 路径计算单元、路径计算客户端、负荷分担方法及系统
CN104348744B (zh) 一种路径计算方法及路径计算单元
WO2018086552A1 (zh) 一种进行计划带宽调整的方法及装置
WO2015117402A1 (zh) 基于软件定义网络的数据管理方法、系统及存储介质
JP6816511B2 (ja) セッション管理プログラム、セッション管理方法、情報処理装置、及び情報処理システム
US11563692B2 (en) Communication methods, apparatuses and system for sharing network resources
CN108243104B (zh) 一种多层lsp控制方法和装置
WO2018153314A1 (zh) 一种对出现错误的lsp定位的方法及pcc和pce
JP5658621B2 (ja) 信号振分複製先決定システム、信号振分複製先決定方法およびプログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15869207

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15869207

Country of ref document: EP

Kind code of ref document: A1