EP2594046A1 - Method and apparatus for implementing p2mp path computation - Google Patents

Method and apparatus for implementing p2mp path computation

Info

Publication number
EP2594046A1
EP2594046A1 EP10854578.1A EP10854578A EP2594046A1 EP 2594046 A1 EP2594046 A1 EP 2594046A1 EP 10854578 A EP10854578 A EP 10854578A EP 2594046 A1 EP2594046 A1 EP 2594046A1
Authority
EP
European Patent Office
Prior art keywords
list
path computation
rro
iro
xro
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP10854578.1A
Other languages
German (de)
French (fr)
Other versions
EP2594046A4 (en
Inventor
Dhruv Dhody
Suresh Babu Kesava Reddy
Qianglin Quintin Zhao
Udayasree Palle
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of EP2594046A4 publication Critical patent/EP2594046A4/en
Publication of EP2594046A1 publication Critical patent/EP2594046A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/16—Multipoint routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/42—Centralised routing

Definitions

  • the present invention relates to communication network, and particularly to a method and apparatus for implementing Point-to-Multipoint (P2MP) path computation.
  • P2MP Point-to-Multipoint
  • Path Computation Element is an entity, component, application or network node that is capable of computing a network path or route based on a network graph and applying computational constraints.
  • Path Computation Client is a client application requesting a path computation to be performed by the PCE.
  • MPLS Multiprotocol Label Switching
  • GPLS Generalized Multiprotocol Label Switching
  • TE Traffic Engineering
  • LSPs Label Switched Paths
  • PCEP Path Computation Element Communication Protocol
  • the PCEP supports the capability of requiring computation of more than one path (e.g., computation of a set of link-diverse paths) by a single request.
  • the PCC may use the PCEP to transmit a path computation request for one or more TE LSPs to the PCE, and the PCE may reply with a set of computed paths if one or more paths can be found that satisfies a set of constraints in the request.
  • PCEP Path Computation Element Communication Protocol
  • P2MP Point-to-Multipoint
  • PCC Point-to-Multipoint
  • the Draft specifies a Path Computation Request (PCReq) message which is used by the PCC to request a P2MP path computation for multiple destinations.
  • the PCReq message includes constraints that are applied to all the destinations.
  • the PCReq message specified in the Draft could not define constraints separately for each destination, that is, could not support constraints per destination.
  • the PCReq message provides no flexibility in applying explicit-path per destination, applying domain-sequence per destination, and carrying metric value of each calculated path.
  • the problem to be solved by the embodiments of the disclosure is to implement P2MP path computation which could provide flexibility in applying explicit-path per destination, applying domain-sequence per destination, and carrying metric value of each calculated path.
  • a method for requesting P2MP path computation by a PCC includes: generating a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and transmitting the PCReq message to a PCE for performing the path computation according to the PCReq message.
  • a method for performing P2MP path computation by a PCE includes: receiving from a PCC a PCReq message for requesting path computation for multiple destinations; extracting constraints per destination from the PCReq message; performing the path computation according to the extracted constraints per destination; and returning a result of the path computation to the PCC.
  • an apparatus for requesting P2MP path computation includes: a PCReq message generating unit, configured to generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and a PCReq message transmitting unit, configured to transmit the PCReq message to a PCE for performing the path computation according to the PCReq message.
  • an apparatus for performing P2MP path computation includes: a PCReq message receiving unit, configured to receive from a PCC a PCReq message for requesting path computation for multiple destinations; a constraints per destination extracting unit, configured to extract constraints per destination from the PCReq message; a path computation performing unit, configured to perform the path computation according to the extracted constraints per destination; and a result returning unit, configured to return a result of the path computation to the PCC.
  • an apparatus for requesting P2MP path computation includes a memory and a processor.
  • the processor is coupled to the memory and configured to: generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and transmit the PCReq message to a PCE for performing the path computation according to the PCReq message.
  • an apparatus for performing P2MP path computation includes a memory and a processor.
  • the processor is coupled to the memory and configured to: receive from a PCC a PCReq message for requesting path computation for multiple destinations; extract constraints per destination from the PCReq message; perform the path computation according to the extracted constraints per destination; and return a result of the path computation to the PCC.
  • the present invention could carry explicit-path per destination, domain-sequence per destination and metric value of each calculated path in a P2MP PCReq message, and thus could support constraints per destination.
  • Fig.l illustrates general operations of a PCC in a path computation process according to the related art.
  • Fig.2 illustrates general operations of a PCE in a path computation process according to the related art.
  • Fig.3 illustrates the format of an END-POINTS object.
  • Fig.4 illustrates a mapping relationship among different objects according to an embodiment of the present invention.
  • Figs.5A and 5B illustrate a mapping relationship among different objects according to another embodiment of the present invention.
  • Fig.6 is a flow chart of a method for requesting P2MP path computation by a PCC according to the present invention.
  • Fig.7 is a flow chart of a method for performing P2MP path computation by a PCE according to the present invention.
  • Fig.8 is an apparatus for requesting P2MP path computation according to the present invention.
  • Fig.9 is an apparatus for performing P2MP path computation according to the present invention.
  • Fig. l illustrates general operations of a PCC in a path computation process according to the related art.
  • step 1 10 once the PCC has successfully established a PCEP session with one or more PCEs, the PCC detects a path computation event which may trigger the request of computation of a set of paths.
  • the PCC selects a PCE from the one or more PCEs. Note that the selection of the PCE may have taken place prior to the establishment of the PCEP session.
  • the PCC generates a PCReq message for requesting path computation for multiple destinations.
  • the PCReq message contains a variety of objects that specify a set of constraints and attributes for the path to be computed.
  • the PCC may specify the urgency of such a request by assigning a request priority in the request. Each request is uniquely identified by a request ID number and a PCC-PCE address pair.
  • the PCC transmits the PCReq message to the selected PCE.
  • the PCC receives a Path Computation Reply (PCRep) message from the PCC.
  • PCep Path Computation Reply
  • Fig.2 illustrates general operations of a PCE in a path computation process according to the related art.
  • the PCE receives the PCReq message from the PCC.
  • the PCE triggers and performs path computation according to the PCReq message.
  • the PCE determines whether the path computation is successful.
  • step 240 if it is determined that the path computation is successful, that is, the PCE finds a set of paths that satisfy the set of constraints in the PCReq message, the PCE returns to the requesting PCC a positive reply in a PCRep message which contains the set of computed paths.
  • step 250 if it is determined that the path computation is unsuccessful, that is, the PCE finds no path that satisfies the set of constraints in the PCReq message, the PCE returns to the requesting PCC a negative reply in a PCRep message which may optionally contain various additional information, such as the set of constraints that lead to the failure of path computation. Alternatively, upon receiving the negative reply, the PCC may further decide to resend a modified request to the PCE or take any other appropriate actions.
  • ⁇ request> specifies the objects to be included in the request message, and this phrase is replaced by:
  • ⁇ RP> specifies a Request Parameters (RP) object which carries a unique request ID.
  • RP Request Parameters
  • END-PONITS object is mandatory and can be followed by a Reported Route Object (RRO)-List and a BANDWIDTH object which are optional.
  • RRO Reported Route Object
  • BANDWIDTH object which are optional.
  • the END-PONITS object carries one source and multiple destinations for which an end-to-end path needs to be computed. The format of the END-PONITS object will be described with reference to Fig.3 below.
  • the RRO-List is replaced by:
  • RRO object is mandatory and can be followed by a BANDWIDTH object which is optional. These fields can be repeated multiple times, so it is considered as a list.
  • the RRO object carries the last calculated path.
  • [ ⁇ LSPA>] specifies a LSP Attributes (LSPA) object.
  • [LOAD-BALANCING>] specifies a LOAD-BALANCING object.
  • the existing PCReq message has only one IRO object.
  • This IRO object is used to carry explicit-path constraint in the PCReq message for the path to be computed, which means that when computing the path from the source to each destination, the same explicit-path is applied as a constraint.
  • the existing PCReq message is applicable.
  • the existing PCReq message could not provide flexibility in applying different explicit-path for each destination.
  • the ⁇ metric-list> in the existing PCReq message can only have two objects, i.e. metric-type and hoplimit, which are applied for all the destinations. This is already defined in RFC 5440. Thus, the ⁇ metric-list> could not be included for each RRO object and could not be mapped for each destination carried in the END-POINTS object.
  • the embodiments of the present invention replace the ⁇ end-point-rro-pair-list> in the above existing PCReq message by ⁇ end-point-iro-xro-rro-metric-pair-list>.
  • IRO-List, XRO-List and METRIC-List are introduced.
  • the IRO-List and the XRO-List could be used to carry explicit-path per destination, the IRO-List could be used to carry domain-sequence per destination, and the METRIC-List could be used to carry metric value of each calculated path encoded in the RRO-List.
  • the format of the PCReq message according to the present invention may be as follows:
  • the END-POINTS object in the PCReq message needs to be ordered and grouped in a way such that the IRO object, XRO object, RRO object and METRIC object are associated with each destination.
  • the END-POINTS object is used in the PCReq message to specify an IP address of a source and IP addresses of all the destinations for which path computation is requested.
  • the END-POINTS object is used in the PCReq message to specify an IP address of a source and IP addresses of all the destinations for which path computation is requested.
  • two new types of END-POINTS objects for the P2MP path are defined: old leaves (destinations) whose path can be modified/reoptimized; and old leaves whose path must be left unchanged.
  • the PCReq message is expanded in a way which allows a single request message to list multiple destinations.
  • a given END-POINTS object gathers the leaves of a given type.
  • the type of leaf in a given END-POINTS object is identified by a Leaf Type field in the END-POINTS object.
  • the format of the new END-POINTS object body for IPv4 (Object-Type 3) is shown in Fig.3.
  • the multiple destinations indicated by the END- POINTS object can be mapped to their own constraints of the objects in the IRO-List, XRO-List, RRO-List and METRIC-List respectively, thus supporting constraints per destination.
  • Fig.4 illustrates a mapping relationship among different objects in a PCReq message according to an embodiment of the present invention. Specifically, it is shown in Fig.4 how the multiple destinations that exist in the END-POINTS object can be mapped to the constraints of IROs, XROs in the IRO-List, XRO-List, etc.
  • each of the multiple destinations may have different constraints. For example, as shown in Fig.4,
  • Destination 1 has the constraints of IROl , XROl , RROl , METRIC 1 ;
  • Destination 2 has the constraints of IROl , XROl ;
  • Destination 3 has the constraint of XR03;
  • ⁇ END-POINTS> is followed by ⁇ IRO-List>, then ⁇ XRO- List>, then ⁇ RRO-List>, then ⁇ METRIC-List>.
  • One destination in the ⁇ END-POINTS> must be mapped to the objects in the ⁇ IRO-List>, ⁇ XRO-List>, ⁇ RRO-List> and ⁇ METRIC-List>.
  • the number of the objects inside the lists can be different.
  • the rule for mapping a destination to the objects inside the lists is: the first object in the lists belongs to the first destination in the ⁇ END-POINTS>; the second object in the lists belongs to the second destination in the ⁇ END-POINTS>; and so on. That is, the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the ⁇ IRO-List>, ⁇ XRO-List>, ⁇ RRO-List> and ⁇ METRIC-List> in a sequential one-to-one correspondence.
  • Destination 1 has the constraints of IROl , XROl ;
  • Destination 2 has the constraint of IR02;
  • Destination 3 has the constraint of XR03;
  • Destination 4 has the constraint of XR04; and Destination 5 has no constraint.
  • Figs.5A and 5B illustrate such two endpoints, ENDPOINT- 1 and ENDPOINT-2, in which all Destinations 1-5 are mapped to their own constrains properly.
  • the ENDPOINT- 1 carries Destinations 1 , 2 and 5 and corresponding ⁇ IRO-List> and ⁇ XRO-List>.
  • the ENDPOINT-2 carries Destinations 3 and 4 and corresponding ⁇ XRO-List> only.
  • ENDPOINT- 1 sequentially indicates all destinations subjected to the constraints in both the ⁇ IRO-List> and the ⁇ XRO-List>, all destinations just subjected to the constraints in the ⁇ IRO-List>, and all destinations without any constraint; and ENDPOINT-2 sequentially indicates all destinations just subjected to the constraints in the ⁇ XRO-List>.
  • Fig.6 is a flow chart of a method for requesting P2MP path computation by a PCC according to the present invention.
  • the PCC generates a PCReq message for requesting path computation for multiple destinations.
  • the PCC includes constraints per destination in the PCReq message.
  • the PCC may include the constraints per destination in the PCReq message through including an IRO list in the PCReq message.
  • Each IRO in the IRO list defines inclusive hops for one of the multiple destinations.
  • the PCC may include the constraints per destination in the PCReq message through including an XRO list in the PCReq message.
  • Each XRO in the XRO list defines exclusive hops for one of the multiple destinations.
  • the PCC may include the constraints per destination in the PCReq message through including a RRO list and a METRIC list in the PCReq message.
  • the RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
  • the PCC may include at least one of the IRO list, the XRO list, and both the RRO list and the METRIC list in the PCReq message, so as to include the constraints per destination in the PCReq.
  • the PCC when generating the PCReq message, may further generate an END-POINTS object which specifies an IP address of a source and IP addresses of the multiple destinations.
  • the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
  • the PCC includes the END-POINTS object in the PCReq message.
  • the PCC breaks the END-POINTS object into two END-POINTS objects so as to map destinations indicated by each of the two END-POINTS objects to their own constraints respectively. And then the PCC may include the two END-POINTS objects in the PCReq message.
  • breaking the END-POINTS object into two END-POINTS objects is based on the following rule: the first END-POINTS object of the two END-POINTS objects sequentially indicates all destinations subjected to the constraints in both the IRO list and the XRO list, all destinations just subjected to the constraints in the IRO list, and all destinations without any constraint; and the second END-POINTS object of the two END-POINTS objects indicates all destinations just subjected to the constraints in the XRO list.
  • the PCC transmits the PCReq message to a PCE for performing the path computation according to the PCReq message.
  • the PCC may further detect a reply message returned from the PCE.
  • Fig.7 is a flow chart of a method for performing P2MP path computation by a PCE according to the present invention.
  • the PCE receives, from the PCC, the PCReq message for requesting path computation for multiple destinations.
  • the PCE extracts constraints per destination from the PCReq message.
  • the PCE might try to extract at least one of an IRO list, an XRO list, and both an RRO list and a METRIC list from the PCReq message.
  • the objects in these lists define constraints for each destination respectively.
  • the PCE might try to extract an END-POINTS object from the PCReq message.
  • the END-POINTS object is included by the PCC in the PCReq message; otherwise, the END-POINTS object is broken by the PCC into two END- POINTS objects which are included in the PCReq message.
  • the rule for breaking the END- POINTS object into two END-POINTS objects is the same as that discussed above with respect to Fig.6.
  • the PCE performs the path computation according to the extracted constraints per destination.
  • the PCE returns a result of the path computation to the PCC.
  • Fig.8 is an apparatus for requesting P2MP path computation according to the present invention, which might refer to the PCC as discussed in the above embodiments of the present invention.
  • the apparatus 800 includes: a PCReq message generating unit 810, configured to generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and a PCReq message transmitting unit 820, configured to transmit the PCReq message to a PCE for performing the path computation according to the PCReq message.
  • the PCReq message generating unit 810 may include an IRO list including unit which is configured to include an IRO list in the PCReq message. Each IRO in the IRO list defines inclusive hops for one of the multiple destinations.
  • the PCReq message generating unit 810 may include an XRO list including unit which is configured to include an XRO list in the PCReq message. Each XRO in the XRO list defines exclusive hops for one of the multiple destinations.
  • the PCReq message generating unit 810 may include a RRO list and METRIC list including unit which is configured to include a RRO list and a METRIC list in the PCReq message.
  • the RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
  • the PCReq message generating unit 810 may include at least one of the IRO list including unit, the XRO list including unit, and the RRO list and METRIC list including unit.
  • the PCReq message generating unit 810 may include an END-POINTS object generating unit which is configured to generate an END-POINTS object which specifies an IP address of a source and IP addresses of the multiple destinations.
  • the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
  • Fig.9 is an apparatus for performing P2MP path computation according to the present invention, which might refer to the PCE as discussed in the above embodiments of the present invention.
  • the apparatus 900 includes: a PCReq message receiving unit 910, configured to receive from a PCC a PCReq message for requesting path computation for multiple destinations; a constraints per destination extracting unit 920, configured to extract constraints per destination from the PCReq message; a path computation performing unit 930, configured to perform the path computation according to the extracted constraints per destination; and a result returning unit 940, configured to return a result of the path computation to the PCC.
  • the constraints per destination extracting unit 920 may include an IRO list extracting unit which is configured to extract an IRO list from the PCReq message.
  • Each IRO in the IRO list defines inclusive hops for one of the multiple destinations.
  • constraints per destination extracting unit 920 may include an XRO list extracting unit which is configured to extract an XRO list from the PCReq message.
  • XRO in the XRO list defines exclusive hops for one of the multiple destinations.
  • the constraints per destination extracting unit 920 may include a RRO list and METRIC list extracting unit which is configured to extract a RRO list and a METRIC list from the PCReq message.
  • the RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
  • the 920 may include at least one of the IRO list extracting unit, the XRO list extracting unit, and the
  • the apparatus 900 may further include an END-POINTS object extracting unit which is configured to extract an END-POINTS object from the PCReq message, which specifies an IP address of a source and IP addresses of the multiple destinations.
  • the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
  • the PCC and the PCE could also be implemented by a combination of a memory and a processor respectively.
  • the PCC may be implemented in an apparatus which includes: a memory which stores executable instructions; and a processor, coupled to the memory and configured to generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message, and transmit the PCReq message to a PCE for performing the path computation according to the PCReq message.
  • the PCE may be implemented in an apparatus which includes: a memory which stores executable instructions; and a processor, coupled to the memory and configured to receive, from a PCC, a PCReq message for requesting path computation for multiple destinations, extract constraints per destination from the PCReq message, perform the path computation according to the extracted constraints per destination, and return a result of the path computation to the PCC.

Landscapes

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

Abstract

The disclosure provides a method and apparatus for implementing Point-to-Multipoint (P2MP) path computation. The method for requesting P2MP path computation by a Path Computation Client (PCC) includes: generating a path computation request (PCReq) message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and transmitting the PCReq message to a Path Computation Element (PCE) for performing the path computation according to the PCReq message. The embodiments in the disclosure implement P2MP path computation which could support constraints per destination.

Description

METHOD AND APPARATUS FOR IMPLEMENTING P2MP PATH COMPUTATION
FIELD OF THE INVENTION
[0001] The present invention relates to communication network, and particularly to a method and apparatus for implementing Point-to-Multipoint (P2MP) path computation.
BACKGROUND
[0002] Path Computation Element (PCE) is an entity, component, application or network node that is capable of computing a network path or route based on a network graph and applying computational constraints. Path Computation Client (PCC) is a client application requesting a path computation to be performed by the PCE. A PCE-based architecture used for path computation for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) is described in RFC4655.
[0003] When the PCC and the PCE are not collocated, a communication protocol between the PCC and the PCE is needed. Path Computation Element Communication Protocol (PCEP) is such a protocol designed specifically for communications between the PCC and the PCE or between two PCEs in compliance with RFC4657. The PCEP supports the capability of requiring computation of more than one path (e.g., computation of a set of link-diverse paths) by a single request. For example, the PCC may use the PCEP to transmit a path computation request for one or more TE LSPs to the PCE, and the PCE may reply with a set of computed paths if one or more paths can be found that satisfies a set of constraints in the request.
[0004] Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint (P2MP) Traffic Engineering Label Switched Paths (hereinafter referred to as the Draft) specifies a Path Computation Request (PCReq) message which is used by the PCC to request a P2MP path computation for multiple destinations. The PCReq message includes constraints that are applied to all the destinations.
[0005] However, the PCReq message specified in the Draft could not define constraints separately for each destination, that is, could not support constraints per destination. Specifically, the PCReq message provides no flexibility in applying explicit-path per destination, applying domain-sequence per destination, and carrying metric value of each calculated path.
[0006] Therefore, there is a need in the art to provide a scheme for implementing P2MP path computation which could support constraints per destination.
SUMMARY
[0007] The problem to be solved by the embodiments of the disclosure is to implement P2MP path computation which could provide flexibility in applying explicit-path per destination, applying domain-sequence per destination, and carrying metric value of each calculated path.
[0008] According to an embodiment, a method for requesting P2MP path computation by a PCC includes: generating a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and transmitting the PCReq message to a PCE for performing the path computation according to the PCReq message.
[0009] According to another embodiment, a method for performing P2MP path computation by a PCE includes: receiving from a PCC a PCReq message for requesting path computation for multiple destinations; extracting constraints per destination from the PCReq message; performing the path computation according to the extracted constraints per destination; and returning a result of the path computation to the PCC.
[0010] According to another embodiment, an apparatus for requesting P2MP path computation includes: a PCReq message generating unit, configured to generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and a PCReq message transmitting unit, configured to transmit the PCReq message to a PCE for performing the path computation according to the PCReq message.
[0011] According to another embodiment, an apparatus for performing P2MP path computation includes: a PCReq message receiving unit, configured to receive from a PCC a PCReq message for requesting path computation for multiple destinations; a constraints per destination extracting unit, configured to extract constraints per destination from the PCReq message; a path computation performing unit, configured to perform the path computation according to the extracted constraints per destination; and a result returning unit, configured to return a result of the path computation to the PCC.
[0012] According to another embodiment, an apparatus for requesting P2MP path computation includes a memory and a processor. The processor is coupled to the memory and configured to: generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and transmit the PCReq message to a PCE for performing the path computation according to the PCReq message.
[0013] According to another embodiment, an apparatus for performing P2MP path computation includes a memory and a processor. The processor is coupled to the memory and configured to: receive from a PCC a PCReq message for requesting path computation for multiple destinations; extract constraints per destination from the PCReq message; perform the path computation according to the extracted constraints per destination; and return a result of the path computation to the PCC.
[0014] Through the above method and apparatus for implementing P2MP path computation, the present invention could carry explicit-path per destination, domain-sequence per destination and metric value of each calculated path in a P2MP PCReq message, and thus could support constraints per destination.
BRIEF DESCRIPTION OF THE DRAWINGS
[0015] Fig.l illustrates general operations of a PCC in a path computation process according to the related art.
[0016] Fig.2 illustrates general operations of a PCE in a path computation process according to the related art.
[0017] Fig.3 illustrates the format of an END-POINTS object.
[0018] Fig.4 illustrates a mapping relationship among different objects according to an embodiment of the present invention.
[0019] Figs.5A and 5B illustrate a mapping relationship among different objects according to another embodiment of the present invention.
[0020] Fig.6 is a flow chart of a method for requesting P2MP path computation by a PCC according to the present invention.
[0021] Fig.7 is a flow chart of a method for performing P2MP path computation by a PCE according to the present invention.
[0022] Fig.8 is an apparatus for requesting P2MP path computation according to the present invention.
[0023] Fig.9 is an apparatus for performing P2MP path computation according to the present invention.
DETAILED DESCRIPTION
[0024] In order to make the objects, technical solutions and advantages of the disclosure clearer, the disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It is understood that specific embodiments described here are only for illustrating the disclosure but not for limiting the disclosure.
[0025] Fig. l illustrates general operations of a PCC in a path computation process according to the related art.
[0026] At step 1 10, once the PCC has successfully established a PCEP session with one or more PCEs, the PCC detects a path computation event which may trigger the request of computation of a set of paths.
[0027] At step 120, the PCC selects a PCE from the one or more PCEs. Note that the selection of the PCE may have taken place prior to the establishment of the PCEP session.
[0028] At step 130, the PCC generates a PCReq message for requesting path computation for multiple destinations. The PCReq message contains a variety of objects that specify a set of constraints and attributes for the path to be computed. For example, the PCReq message may request to compute a TE LSP path with source IP address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B Mbit/s, Setup/Holding priority=P, etc. Additionally, the PCC may specify the urgency of such a request by assigning a request priority in the request. Each request is uniquely identified by a request ID number and a PCC-PCE address pair.
[0029] At step 140, the PCC transmits the PCReq message to the selected PCE.
[0030] At step 150, the PCC receives a Path Computation Reply (PCRep) message from the
PCE which carries a result of the path computation.
[0031] Fig.2 illustrates general operations of a PCE in a path computation process according to the related art.
[0032] At step 210, the PCE receives the PCReq message from the PCC.
[0033] At step 220, the PCE triggers and performs path computation according to the PCReq message.
[0034] At step 230, the PCE determines whether the path computation is successful.
[0035] At step 240, if it is determined that the path computation is successful, that is, the PCE finds a set of paths that satisfy the set of constraints in the PCReq message, the PCE returns to the requesting PCC a positive reply in a PCRep message which contains the set of computed paths.
[0036] At step 250, if it is determined that the path computation is unsuccessful, that is, the PCE finds no path that satisfies the set of constraints in the PCReq message, the PCE returns to the requesting PCC a negative reply in a PCRep message which may optionally contain various additional information, such as the set of constraints that lead to the failure of path computation. Alternatively, upon receiving the negative reply, the PCC may further decide to resend a modified request to the PCE or take any other appropriate actions.
[0037] In the Draft, the contents of which are herein incorporated in their entirety by reference for all purposes, the format of the PCReq message, which is transmitted from the PCC to the PCE, is specified as follows:
<PCReq Message>::= <Common Header>
<request>
where:
<request>::= <RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
where:
<end-point-rro-pair-list>: :=
<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>]
<RRO-List>: := <RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>: := <METRIC>[<metric-list>]
where the phrase mentioned between "< >" is considered as a mandatory field to support, and the phrase mentioned between "[ ]" is considered as an optional field.
[0038] <Common Header> specifies Message Header.
[0039] <request> specifies the objects to be included in the request message, and this phrase is replaced by:
<RP>
<end-point-rro-pair-list>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
[<LOAD-BALANCING>]
[0040] <RP> specifies a Request Parameters (RP) object which carries a unique request ID. [0041] <end-point-rro-pair-list> is replaced by:
<END-POINTS>[<RRO-List>][<BANDWIDTH>]
[<end-point-rro-pair-list>] where the END-PONITS object is mandatory and can be followed by a Reported Route Object (RRO)-List and a BANDWIDTH object which are optional. The END-PONITS object carries one source and multiple destinations for which an end-to-end path needs to be computed. The format of the END-PONITS object will be described with reference to Fig.3 below.
[0042] If the RRO-List exists, the RRO-List is replaced by:
<RRO[<BANDWIDTH>] [<RRO-List>]
where the RRO object is mandatory and can be followed by a BANDWIDTH object which is optional. These fields can be repeated multiple times, so it is considered as a list. The RRO object carries the last calculated path.
[0043] [<OF>] specifies an Objective Function (OF) object.
[0044] [<LSPA>] specifies a LSP Attributes (LSPA) object.
[0045] [<BANDWIDTH>] specifies a BANDWIDTH object.
[0046] [<metric-list>] is replaced by:
<METRIC>[<metric-list>] where <METRIC> means a METRIC object. This field is repeated multiple times if more than one metric constraint exists.
[0047] [<IRO>] specifies an Include Route Object (IRO) object.
[0048] [LOAD-BALANCING>] specifies a LOAD-BALANCING object.
[0049] As shown in the following Table 1 , except the RP object and the END-POINTS object, all the other objects are used to carry constraints for the path to be computed.
Table 1
[0050] As specified in the Draft, the existing PCReq message has only one IRO object. This IRO object is used to carry explicit-path constraint in the PCReq message for the path to be computed, which means that when computing the path from the source to each destination, the same explicit-path is applied as a constraint. In the case of P2MP, if the explicit-path constraint is same for all the destinations encoded in the END-POINTS object, the existing PCReq message is applicable. However, if the explicit-path constraint is different for each destination, the existing PCReq message could not provide flexibility in applying different explicit-path for each destination.
[0051] Moreover, according to the Draft, the <metric-list> in the existing PCReq message can only have two objects, i.e. metric-type and hoplimit, which are applied for all the destinations. This is already defined in RFC 5440. Thus, the <metric-list> could not be included for each RRO object and could not be mapped for each destination carried in the END-POINTS object.
[0052] It is apparent that the existing PCReq message specified in the Draft could not support constraints per destination. In fact, the related art does not provide any mechanism to apply constraints separately for each destination.
[0053] In order to support constraints per destination in a PCReq message, the embodiments of the present invention replace the <end-point-rro-pair-list> in the above existing PCReq message by <end-point-iro-xro-rro-metric-pair-list>. In the <end-point-iro-xro-rro-metric-pair-list>, IRO-List, XRO-List and METRIC-List are introduced. For example, the IRO-List and the XRO-List could be used to carry explicit-path per destination, the IRO-List could be used to carry domain-sequence per destination, and the METRIC-List could be used to carry metric value of each calculated path encoded in the RRO-List.
[0054] For example, the format of the PCReq message according to the present invention may be as follows:
<PCReq Message>::= <Common Header>
<request>
where:
<request>::= <RP>
<end-point-iro-xro-rro-metric-pair4ist>
[<OF>]
[<LSPA>]
[<BANDWIDTH>]
[<metric4ist>]
[<LOAD-BALANCING>]
where:
<end-point-iro-xro-rro-metric-pair4ist>::=
<END-POINTS>
[<IRO-List>]
[<XRO-List>]
[<RRO-List>] [<B AND WIDTH>]
[<METRIC-List>] < end-point-iro-xro-rro-metric-pair-list>
<IRO-list>: := <IRO>[<IRO-List>]
<XRO-list>: := <XRO>[<XRO-List>]
<RRO-List>::= <RRO>[<BANDWIDTH>][<RRO-List>]
<metric-list>: := <METRIC>[<metric-list>]
[0055] To carry constraints for each destination, the END-POINTS object in the PCReq message needs to be ordered and grouped in a way such that the IRO object, XRO object, RRO object and METRIC object are associated with each destination.
[0056] The END-POINTS object is used in the PCReq message to specify an IP address of a source and IP addresses of all the destinations for which path computation is requested. To represent the endpoints for a P2MP path efficiently, two new types of END-POINTS objects for the P2MP path are defined: old leaves (destinations) whose path can be modified/reoptimized; and old leaves whose path must be left unchanged.
[0057] With the new END-POINTS objects, the PCReq message is expanded in a way which allows a single request message to list multiple destinations.
[0058] In total, there are now 4 possible types of leaves in a P2MP request:
• New leaves to add (leaf type = 1)
• Old leaves to remove (leaf type = 2)
• Old leaves whose path can be modified/reoptimized (leaf type = 3)
• Old leaves whose path must be left unchanged (leaf type = 4)
[0059] A given END-POINTS object gathers the leaves of a given type. The type of leaf in a given END-POINTS object is identified by a Leaf Type field in the END-POINTS object. The format of the new END-POINTS object body for IPv4 (Object-Type 3) is shown in Fig.3.
[0060] According to the present invention, the multiple destinations indicated by the END- POINTS object can be mapped to their own constraints of the objects in the IRO-List, XRO-List, RRO-List and METRIC-List respectively, thus supporting constraints per destination.
[0061] Fig.4 illustrates a mapping relationship among different objects in a PCReq message according to an embodiment of the present invention. Specifically, it is shown in Fig.4 how the multiple destinations that exist in the END-POINTS object can be mapped to the constraints of IROs, XROs in the IRO-List, XRO-List, etc.
[0062] In the case of P2MP, each of the multiple destinations may have different constraints. For example, as shown in Fig.4,
Destination 1 has the constraints of IROl , XROl , RROl , METRIC 1 ;
Destination 2 has the constraints of IROl , XROl ;
Destination 3 has the constraint of XR03;
Destination 4 has no constraint; and
Destination 5 has no constraint.
[0063] When a P2MP tunnel is configured at a PCC, all the P2MP leaves (destinations) can be packed in one END-POINTS object. But sometimes it is unable to map constraints properly because they can be optional.
[0064] As shown in the Figure, <END-POINTS> is followed by <IRO-List>, then <XRO- List>, then <RRO-List>, then <METRIC-List>. One destination in the <END-POINTS> must be mapped to the objects in the <IRO-List>, <XRO-List>, <RRO-List> and <METRIC-List>.
[0065] Since all the lists are optional, the number of the objects inside the lists can be different. The rule for mapping a destination to the objects inside the lists is: the first object in the lists belongs to the first destination in the <END-POINTS>; the second object in the lists belongs to the second destination in the <END-POINTS>; and so on. That is, the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the <IRO-List>, <XRO-List>, <RRO-List> and <METRIC-List> in a sequential one-to-one correspondence.
[0066] To follow this rule properly, it is needed to order the multiple destinations in the <END-POINTS> properly.
[0067] In the case shown in Fig.4, all of the multiple destinations can be carried in the same endpoint along with the <IRO-List>, <XRO-List>, <RRO-List> and <METRIC-List>, in which the multiple destinations indicated by the END-POINTS object can be mapped to their own constraints in the <IRO-List>, <XRO-List>, <RRO-List> and <METRIC-List> respectively.
[0068] However, in some cases, it may not be possible to put all the destinations in the same endpoint. Some destinations may have all constraints such as IRO, XRO and RRO, while some destinations may have just constraints such as XRO. An exemplary case is as follows:
Destination 1 has the constraints of IROl , XROl ;
Destination 2 has the constraint of IR02;
Destination 3 has the constraint of XR03;
Destination 4 has the constraint of XR04; and Destination 5 has no constraint.
[0069] In this case, it is difficult to map XR03 to Destination 3 because the rule is to map sequentially. Specifically, following the above rule, XROl belongs to Destination 1 , and XR03 which is next in the <XRO-List> will belong to Destination2. This is incorrect because XR03 should belong to Destination 3. So, it is impossible to order all the destinations in one endpoint in this case.
[0070] Therefore, it is needed to break one endpoint into two endpoints and use their separate lists so as to map all the destinations to their own constraints in the lists properly. Figs.5A and 5B illustrate such two endpoints, ENDPOINT- 1 and ENDPOINT-2, in which all Destinations 1-5 are mapped to their own constrains properly. The ENDPOINT- 1 carries Destinations 1 , 2 and 5 and corresponding <IRO-List> and <XRO-List>. The ENDPOINT-2 carries Destinations 3 and 4 and corresponding <XRO-List> only.
[0071] Referring to Figs.5A and 5B, the rule for breaking one endpoint into the two endpoints is as follows:
ENDPOINT- 1 sequentially indicates all destinations subjected to the constraints in both the <IRO-List> and the <XRO-List>, all destinations just subjected to the constraints in the <IRO-List>, and all destinations without any constraint; and ENDPOINT-2 sequentially indicates all destinations just subjected to the constraints in the <XRO-List>.
[0072] Therefore, both in the case that all the destinations could be carried in the same endpoint (such as the case shown in Fig.4) and in the case that the destinations should be carried in different endpoints (such as the case shown in Figs.5A and 5B), the present invention could map all the destinations to their own constraints properly.
[0073] The following embodiments exemplarily illustrate how to implement P2MP path computation by utilizing the PCReq message according to the present invention.
[0074] Fig.6 is a flow chart of a method for requesting P2MP path computation by a PCC according to the present invention.
[0075] At step 610, the PCC generates a PCReq message for requesting path computation for multiple destinations. When generating the PCReq message, the PCC includes constraints per destination in the PCReq message.
[0076] The PCC may include the constraints per destination in the PCReq message through including an IRO list in the PCReq message. Each IRO in the IRO list defines inclusive hops for one of the multiple destinations.
[0077] Alternatively, the PCC may include the constraints per destination in the PCReq message through including an XRO list in the PCReq message. Each XRO in the XRO list defines exclusive hops for one of the multiple destinations.
[0078] Alternatively, the PCC may include the constraints per destination in the PCReq message through including a RRO list and a METRIC list in the PCReq message. The RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
[0079] Under specific application environments, the PCC may include at least one of the IRO list, the XRO list, and both the RRO list and the METRIC list in the PCReq message, so as to include the constraints per destination in the PCReq.
[0080] According to an embodiment of the present invention, when generating the PCReq message, the PCC may further generate an END-POINTS object which specifies an IP address of a source and IP addresses of the multiple destinations. The multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
[0081] If the multiple destinations indicated by the END-POINTS object can be mapped to their own constraints in the IRO list, the XRO list or both the RRO list and the METRIC list respectively, the PCC includes the END-POINTS object in the PCReq message.
[0082] However, if the multiple destinations indicated by the END-POINTS object can not be mapped to their own constraints in the IRO list, the XRO list or both the RRO list and the METRIC list respectively, the PCC breaks the END-POINTS object into two END-POINTS objects so as to map destinations indicated by each of the two END-POINTS objects to their own constraints respectively. And then the PCC may include the two END-POINTS objects in the PCReq message.
[0083] According to an embodiment of the present invention, breaking the END-POINTS object into two END-POINTS objects is based on the following rule: the first END-POINTS object of the two END-POINTS objects sequentially indicates all destinations subjected to the constraints in both the IRO list and the XRO list, all destinations just subjected to the constraints in the IRO list, and all destinations without any constraint; and the second END-POINTS object of the two END-POINTS objects indicates all destinations just subjected to the constraints in the XRO list.
[0084] At step 620, after generating the PCReq message with constraints per destination, the PCC transmits the PCReq message to a PCE for performing the path computation according to the PCReq message.
[0085] Alternatively, after the PCReq message is transmitted, the PCC may further detect a reply message returned from the PCE.
[0086] Fig.7 is a flow chart of a method for performing P2MP path computation by a PCE according to the present invention.
[0087] At step 710, the PCE receives, from the PCC, the PCReq message for requesting path computation for multiple destinations.
[0088] At step 720, the PCE extracts constraints per destination from the PCReq message.
[0089] Specifically, the PCE might try to extract at least one of an IRO list, an XRO list, and both an RRO list and a METRIC list from the PCReq message. As discussed above with respect to Fig.6, the objects in these lists define constraints for each destination respectively.
[0090] Moreover, the PCE might try to extract an END-POINTS object from the PCReq message. As discussed above with respect to Fig.6, if the multiple destinations indicated by the END-POINTS object can be mapped to their own constraints in the IRO list, the XRO list or both the RRO list and the METRIC list respectively, the END-POINTS object is included by the PCC in the PCReq message; otherwise, the END-POINTS object is broken by the PCC into two END- POINTS objects which are included in the PCReq message. The rule for breaking the END- POINTS object into two END-POINTS objects is the same as that discussed above with respect to Fig.6.
[0091] At step 730, the PCE performs the path computation according to the extracted constraints per destination.
[0092] At step 740, the PCE returns a result of the path computation to the PCC.
[0093] Through the methods shown in Figs. 6 and 7, the PCC and the PCE could cooperate to implement P2MP path computation which could support constraints per destination.
[0094] Fig.8 is an apparatus for requesting P2MP path computation according to the present invention, which might refer to the PCC as discussed in the above embodiments of the present invention. The apparatus 800 includes: a PCReq message generating unit 810, configured to generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and a PCReq message transmitting unit 820, configured to transmit the PCReq message to a PCE for performing the path computation according to the PCReq message.
[0095] Alternatively, the PCReq message generating unit 810 may include an IRO list including unit which is configured to include an IRO list in the PCReq message. Each IRO in the IRO list defines inclusive hops for one of the multiple destinations.
[0096] Alternatively, the PCReq message generating unit 810 may include an XRO list including unit which is configured to include an XRO list in the PCReq message. Each XRO in the XRO list defines exclusive hops for one of the multiple destinations.
[0097] Alternatively, the PCReq message generating unit 810 may include a RRO list and METRIC list including unit which is configured to include a RRO list and a METRIC list in the PCReq message. The RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
[0098] Under specific application environments, the PCReq message generating unit 810 may include at least one of the IRO list including unit, the XRO list including unit, and the RRO list and METRIC list including unit.
[0099] Alternatively, the PCReq message generating unit 810 may include an END-POINTS object generating unit which is configured to generate an END-POINTS object which specifies an IP address of a source and IP addresses of the multiple destinations. The multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
[00100] Fig.9 is an apparatus for performing P2MP path computation according to the present invention, which might refer to the PCE as discussed in the above embodiments of the present invention. The apparatus 900 includes: a PCReq message receiving unit 910, configured to receive from a PCC a PCReq message for requesting path computation for multiple destinations; a constraints per destination extracting unit 920, configured to extract constraints per destination from the PCReq message; a path computation performing unit 930, configured to perform the path computation according to the extracted constraints per destination; and a result returning unit 940, configured to return a result of the path computation to the PCC.
[00101] Alternatively, the constraints per destination extracting unit 920 may include an IRO list extracting unit which is configured to extract an IRO list from the PCReq message. Each IRO in the IRO list defines inclusive hops for one of the multiple destinations.
[00102] Alternatively, the constraints per destination extracting unit 920 may include an XRO list extracting unit which is configured to extract an XRO list from the PCReq message. Each
XRO in the XRO list defines exclusive hops for one of the multiple destinations.
[00103] Alternatively, the constraints per destination extracting unit 920 may include a RRO list and METRIC list extracting unit which is configured to extract a RRO list and a METRIC list from the PCReq message. The RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
[00104] Under specific application environments, the constraints per destination extracting unit
920 may include at least one of the IRO list extracting unit, the XRO list extracting unit, and the
RRO list and METRIC list extracting unit.
[00105] Alternatively, the apparatus 900 may further include an END-POINTS object extracting unit which is configured to extract an END-POINTS object from the PCReq message, which specifies an IP address of a source and IP addresses of the multiple destinations. The multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
[00106] In addition, according to the present invention, the PCC and the PCE could also be implemented by a combination of a memory and a processor respectively. For example, the PCC may be implemented in an apparatus which includes: a memory which stores executable instructions; and a processor, coupled to the memory and configured to generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message, and transmit the PCReq message to a PCE for performing the path computation according to the PCReq message. The PCE may be implemented in an apparatus which includes: a memory which stores executable instructions; and a processor, coupled to the memory and configured to receive, from a PCC, a PCReq message for requesting path computation for multiple destinations, extract constraints per destination from the PCReq message, perform the path computation according to the extracted constraints per destination, and return a result of the path computation to the PCC.
[00107] The previous description of the disclosure is provided to enable those skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art and generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

CLAIMS What is claimed is:
1. A method for requesting Point-to-Multipoint (P2MP) path computation by a Path Computation Client (PCC), comprising:
generating a path computation request (PCReq) message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and transmitting the PCReq message to a Path Computation Element (PCE) for performing the path computation according to the PCReq message.
2. The method of claim 1, wherein including constraints per destination in the PCReq message comprises:
including at least one of an Include Route Object (IRO) list, an Exclude Route Object (XRO) list, and both a Reported Route Object (RRO) list and a METRIC list in the PCReq message,
wherein each IRO in the IRO list defines inclusive hops for one of the multiple destinations, each XRO in the XRO list defines exclusive hops for one of the multiple destinations, the RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
3. The method of claim 2, wherein generating a PCReq message comprising:
generating an END-POINTS object which specifies an IP address of a source and IP addresses of the multiple destinations,
wherein the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
4. The method of claim 3, further comprising:
including the END-POINTS object in the PCReq message if the multiple destinations indicated by the END-POINTS object can be mapped to their own constraints in the IRO list, the XRO list or both the RRO list and the METRIC list respectively.
5. The method of claim 3, further comprising:
breaking the END-POINTS object into two END-POINTS objects, if the multiple destinations indicated by the END-POINTS object can not be mapped to their own constraints in the IRO list, the XRO list or both the RRO list and the METRIC list respectively, so as to map destinations indicated by each of the two END-POINTS objects to their own constraints respectively; and
including the two END-POINTS objects in the PCReq message.
6. The method of claim 5, wherein breaking the END-POINTS object into two END-POINTS objects is based on the following rule:
the first END-POINTS object of the two END-POINTS objects sequentially indicates all destinations subjected to the constraints in both the IRO list and the XRO list, all destinations just subjected to the constraints in the IRO list, and all destinations without any constraint; and
the second END-POINTS object of the two END-POINTS objects indicates all destinations just subjected to the constraints in the XRO list.
7. A method for performing Point-to-Multipoint (P2MP) path computation by a Path Computation Element (PCE), comprising:
receiving from a Path Computation Client (PCC) a path computation request (PCReq) message for requesting path computation for multiple destinations;
extracting constraints per destination from the PCReq message;
performing the path computation according to the extracted constraints per destination; and returning a result of the path computation to the PCC.
8. The method of claim 7, wherein extracting constraints per destination from the PCReq message comprises:
extracting at least one of an Include Route Object (IRO) list, an Exclude Route Object (XRO) list, and both a Reported Route Object (RRO) list and a METRIC list from the PCReq message, wherein each IRO in the IRO list defines inclusive hops for one of the multiple destinations, each XRO in the XRO list defines exclusive hops for one of the multiple destinations, the RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
9. The method of claim 8, further comprising:
extracting an END-POINTS object from the PCReq message, which specifies an IP address of a source and IP addresses of the multiple destinations,
wherein the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
10. The method of claim 9, wherein
the END-POINTS object is included in the PCReq message if the multiple destinations indicated by the END-POINTS object can be mapped to their own constraints in the IRO list, the XRO list or both the RRO list and the METRIC list respectively.
11. The method of claim 9, wherein
the END-POINTS object is broken into two END-POINTS objects, if the multiple destinations indicated by the END-POINTS object can not be mapped to their own constraints in the IRO list, the XRO list or both the RRO list and the METRIC list respectively, so as to map destinations indicated by each of the two END-POINTS objects to their own constraints respectively; and
the two END-POINTS objects are included in the PCReq message.
12. The method of claim 11 , wherein the END-POINTS object is broken into two END-POINTS objects based on the following rule:
the first END-POINTS object of the two END-POINTS objects sequentially indicates all destinations subjected to the constraints in both the IRO list and the XRO list, all destinations just subjected to the constraints in the IRO list, and all destinations without any constraint; and
the second END-POINTS object of the two END-POINTS objects indicates all destinations just subjected to the constraints in the XRO list.
13. An apparatus for requesting Point-to-Multipoint (P2MP) path computation, comprising: a path computation request (PCReq) message generating unit, configured to generate a PCReq message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and
a PCReq message transmitting unit, configured to transmit the PCReq message to a Path Computation Element (PCE) for performing the path computation according to the PCReq message.
14. The apparatus of claim 13, wherein the PCReq message generating unit comprises at least one of an Include Route Object (IRO) list including unit, an Exclude Route Object (XRO) list including unit, and a Reported Route Object (RRO) list and METRIC list including unit, and wherein:
the IRO list including unit is configured to include an IRO list in the PCReq message, wherein each IRO in the IRO list defines inclusive hops for one of the multiple destinations,
the XRO list including unit is configured to include an XRO list in the PCReq message, wherein each XRO in the XRO list defines exclusive hops for one of the multiple destinations, and the RRO list and METRIC list including unit is configured to include a RRO list and a METRIC list in the PCReq message, wherein the RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
15. The apparatus of claim 14, wherein the PCReq message generating unit comprises:
an END-POINTS object generating unit, configured to generate an END-POINTS object which specifies an IP address of a source and IP addresses of the multiple destinations,
wherein the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
16. An apparatus for performing Point-to-Multipoint (P2MP) path computation, comprising: a path computation request (PCReq) message receiving unit, configured to receive from a Path Computation Client (PCC) a PCReq message for requesting path computation for multiple destinations; a constraints per destination extracting unit, configured to extract constraints per destination from the PCReq message;
a path computation performing unit, configured to perform the path computation according to the extracted constraints per destination; and
a result returning unit, configured to return a result of the path computation to the PCC.
17. The apparatus of claim 16, wherein the constraints per destination extracting unit comprises at least one of an Include Route Object (IRO) list extracting unit, an Exclude Route Object (XRO) list extracting unit, and a Reported Route Object (RRO) list and METRIC list extracting unit, and wherein:
the IRO list extracting unit is configured to extract an IRO list from the PCReq message, wherein each IRO in the IRO list defines inclusive hops for one of the multiple destinations,
the XRO list extracting unit is configured to extract an XRO list from the PCReq message, wherein each XRO in the XRO list defines exclusive hops for one of the multiple destinations, and the RRO list and METRIC list extracting unit is configured to extract a RRO list and a METRIC list from the PCReq message, wherein the RRO list carries calculated paths, and each metric in the METRIC list defines metric constraint for each RRO in the RRO list encoded per destination.
18. The apparatus of claim 17, further comprising:
an END-POINTS object extracting unit, configured to extract an END-POINTS object from the PCReq message, which specifies an IP address of a source and IP addresses of the multiple destinations,
wherein the multiple destinations indicated by the END-POINTS object are mapped to the constraints in the IRO list, the XRO list or both the RRO list and the METRIC list in a sequential one-to-one correspondence.
19. An apparatus for requesting Point-to-Multipoint (P2MP) path computation, comprising: a memory; and
a processor, coupled to the memory and configured to:
generate a path computation request (PCReq) message for requesting path computation for multiple destinations through including constraints per destination in the PCReq message; and
transmit the PCReq message to a Path Computation Element (PCE) for performing the path computation according to the PCReq message.
20. An apparatus for performing Point-to-Multipoint (P2MP) path computation, comprising: a memory; and
a processor, coupled to the memory and configured to:
receive from a Path Computation Client (PCC) a path computation request (PCReq) message for requesting path computation for multiple destinations;
extract constraints per destination from the PCReq message;
perform the path computation according to the extracted constraints per destination; and return a result of the path computation to the PCC.
EP10854578.1A 2010-07-15 2010-07-15 Method and apparatus for implementing p2mp path computation Withdrawn EP2594046A1 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2010/075185 WO2012006785A1 (en) 2010-07-15 2010-07-15 Method and apparatus for implementing p2mp path computation

Publications (2)

Publication Number Publication Date
EP2594046A4 EP2594046A4 (en) 2013-05-22
EP2594046A1 true EP2594046A1 (en) 2013-05-22

Family

ID=45468884

Family Applications (1)

Application Number Title Priority Date Filing Date
EP10854578.1A Withdrawn EP2594046A1 (en) 2010-07-15 2010-07-15 Method and apparatus for implementing p2mp path computation

Country Status (3)

Country Link
EP (1) EP2594046A1 (en)
CN (1) CN103155498A (en)
WO (1) WO2012006785A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9537753B2 (en) * 2014-03-03 2017-01-03 Cisco Technology, Inc. Opaque profile identifiers for path computation element protocol
CN106574187A (en) 2014-06-13 2017-04-19 Csir公司 Liquid flame retardant composition

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7319700B1 (en) * 2000-12-29 2008-01-15 Juniper Networks, Inc. Communicating constraint information for determining a path subject to such constraints
CN101350761B (en) * 2007-07-18 2011-12-28 华为技术有限公司 Method, apparatus and system for establishing and calculating path
CN101237399A (en) * 2007-09-28 2008-08-06 华为技术有限公司 Method, system and device for getting label switching path

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
DHODY U PALLE HUAWEI TECHNOLOGIES INDIA PVT LTD D: "Supporting explicit-path per destination in Path Computation Element Communication Protocol (PCEP) - P2MP Path Request.; draft-dhody-pce-pcep-p2mp-per-destination- 00.txt", SUPPORTING EXPLICIT-PATH PER DESTINATION IN PATH COMPUTATION ELEMENT COMMUNICATION PROTOCOL (PCEP) - P2MP PATH REQUEST.; DRAFT-DHODY-PCE-PCEP-P2MP-PER-DESTINATION- 00.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (, 29 June 2011 (2011-06-29), pages 1-11, XP015076676, [retrieved on 2011-06-29] *
MARGARIA C C ET AL: "PCEP extensions for GMPLS; draft-margaria-pce-gmpls-pcep-extensions-0 1.txt", PCEP EXTENSIONS FOR GMPLS; DRAFT-MARGARIA-PCE-GMPLS-PCEP-EXTENSIONS-0 1.TXT, INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERNET SOCIETY (ISOC) 4, RUE DES FALAISES CH- 1205 GENEVA, SWITZERLAND, no. 1, 1 July 2010 (2010-07-01), pages 1-29, XP015069232, [retrieved on 2010-07-01] *
MICHAEL BAHR: "Proposed Routing for IEEE 802.11s WLAN Mesh Networks", ACM, 2 PENN PLAZA, SUITE 701 - NEW YORK USA, 2 August 2006 (2006-08-02), - 5 August 2006 (2006-08-05), pages 1-10, XP040058821, *
See also references of WO2012006785A1 *
ZHAO Q ET AL: "Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths; draft-ietf-pce-pcep-p2mp-extensions-10.txt ", EXTENSIONS TO THE PATH COMPUTATION ELEMENT COMMUNICATION PROTOCOL (PCEP) FOR POINT-TO-MULTIPOINT TRAFFIC ENGINEERING LABEL SWITCHED PATHS; DRAFT-IETF-PCE-PCEP-P2MP-EXTENSIONS-10.TXT , INTERNET ENGINEERING TASK FORCE, IETF; STANDARDWORKINGDRAFT, INTERN, no. 10, 19 April 2010 (2010-04-19), pages 1-31, XP015068092, [retrieved on 2010-04-19] *

Also Published As

Publication number Publication date
CN103155498A (en) 2013-06-12
EP2594046A4 (en) 2013-05-22
WO2012006785A1 (en) 2012-01-19

Similar Documents

Publication Publication Date Title
JP7412469B2 (en) Method for establishing segment routing for IPV6 tunnels
US9716648B2 (en) System and method for computing point-to-point label switched path crossing multiple domains
US9088485B2 (en) System, method and apparatus for signaling and responding to ERO expansion failure in inter-domain TE LSP
US8848705B2 (en) System and method for finding point-to-multipoint label switched path crossing multiple domains
US10021023B2 (en) Packet forwarding method, controller, forwarding device, and network system
US8693471B2 (en) Graceful restart for use in nodes employing label switched path signaling protocols
US7684420B2 (en) Method for implementing cross-domain constraint routing
EP3214795B1 (en) Cross-domain clock synchronization method, apparatus and system, and computer storage medium
EP2663040A1 (en) Fast reroute using loop free alternate next hops for multipoint label switched paths
EP2299637A1 (en) Pseudo wire establishing method, device and system
KR101050681B1 (en) Method and apparatus for calculating route in label switched network
CN103650453B (en) The method communicated in path computation element communication protocol and network equipment
EP2594046A1 (en) Method and apparatus for implementing p2mp path computation
CN105743787B (en) Control method and system for label request information and up-down cursor label exchange router

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20130122

A4 Supplementary search report drawn up and despatched

Effective date: 20130319

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO SE SI SK SM TR

RIN1 Information on inventor provided before grant (corrected)

Inventor name: PALLE, UDAYASREE

Inventor name: ZHAO, QIANGLIN QUINTIN

Inventor name: DHODY, DHRUV

Inventor name: KESAVA REDDY, SURESH BABU

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20130917

DAX Request for extension of the european patent (deleted)