WO2012006785A1

WO2012006785A1 - Method and apparatus for implementing p2mp path computation

Info

Publication number: WO2012006785A1
Application number: PCT/CN2010/075185
Authority: WO
Inventors: Dhruv Dhody; Suresh Babu Kesava Reddy; Qianglin Quintin Zhao; Udayasree Palle
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2010-07-15
Filing date: 2010-07-15
Publication date: 2012-01-19
Also published as: EP2594046A1; CN103155498A; EP2594046A4

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:

where:

<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:

where:

<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,

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:

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,

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,

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.