Internet Engineering Task Force Q. Zhao, Ed. Internet-Draft Huawei Technology Intended Status: Standards Track Fabien Verhaeghe Created: March 8, 2009 Marben Products Expires: September 8, 2009 Daniel King Old Dog Consulting Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths draft-ietf-pce-pcep-p2mp-extensions-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract Point-to-point Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) may be established using signaling techniques, but their paths may first be determined. The Path Computation Element (PCE) has been identified as an appropriate technology for the determination of the paths of P2MP TE LSPs. This document describes extensions to the PCE communication Protocol (PCEP) to handle requests and responses for the computation of paths for P2MP TE LSPs. Zhao, et al. [Page 1] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3. Protocol Procedures and Extensions . . . . . . . . . . . . . . 3.1. P2MP Capability Advertisement . . . . . . . . . . . . . . 3.1.1. Extend the TLV in the Existing PCE Discovery Protocol . . . . . . . . . . . . . . . . . . . . . . . 3.1.2. Open Message Extension . . . . . . . . . . . . . . . . 3.2. P2MP LSPs Efficient Presentation . . . . . . . . . . . . . 3.3. Indication of P2MP Path Computation Request/Reply . . . . 3.3.1. The Extension of RP Object . . . . . . . . . . . . . . 3.3.2. The New P2MP END-POINTS Object . . . . . . . . . . . . 3.4. Request Message Formats . . . . . . . . . . . . . . . . . 3.5. Reply Message Formats . . . . . . . . . . . . . . . . . . 3.6. P2MP Objective Functions and Metric Types . . . . . . . . 3.6.1. New Object Functions . . . . . . . . . . . . . . . . . 3.6.2. New Metric Object Types . . . . . . . . . . . . . . . 3.7. Non-Support of P2MP Path Computation. . . . . . . . . . . 3.8. Non-Support by Back-Level PCE Implementations. . . . . . . 3.9. P2MP TE Path Re-optimization Request . . . . . . . . . . . 3.10. Adding/pruning Leaves . . . . . . . . . . . . . . . . . . 3.11. Branch Nodes . . . . . . . . . . . . . . . . . . . . . . . 3.12. Synchronization of P2MP TE Path Computation Requests . . . 3.13. Multi-Message Support . . . . . . . . . . . . . . . . . . 3.14. UNREACH_DESTINATION object . . . . . . . . . . . . . . . . 3.15. P2MP PCEP Error Object . . . . . . . . . . . . . . . . . . 3.16. PCEP NO-PATH Indicator . . . . . . . . . . . . . . . . . . 4. Manageability Considerations . . . . . . . . . . . . . . . . . 4.1. Control of Function and Policy . . . . . . . . . . . . . . 4.2. Information and Data Models . . . . . . . . . . . . . . . 4.3. Liveness Detection and Monitoring . . . . . . . . . . . . 4.4. Verifying Correct Operation . . . . . . . . . . . . . . . 4.5. Requirements on Other Protocols and Functional Components . . . . . . . . . . . . . . . . . . . . . . . . 4.6. Impact on Network Operation . . . . . . . . . . . . . . . 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8.2. Informative References . . . . . . . . . . . . . . . . . . 9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10. Intellectual Property Consideration. . . . . . . . . . . . . . 11. Disclaimer of Validity . . . . . . . . . . . . . . . . . . . . 12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . Zhao, et al. [Page 2] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 1. Introduction The Path Computation Element (PCE) defined in [RFC4655] is an entity that is capable of computing a network path or route based on a network graph, and applying computational constraints. A Path Computation Client (PCC) may make requests to a PCE for paths to be computed. [RFC4875] describes how to set up point-to-multipoint (P2MP) Traffic Engineering Label Switched Paths (TE LSPs) for use in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The PCE is identified as a suitable application for the computation of paths for P2MP TE LSPs [PCE-P2MP-APP]. The PCE communication protocol (PCEP) is designed as a communication protocol between PCCs and PCEs for point-to-point (P2P) path computations and is defined in [RFC5440]. However, that specification does not provide a mechanism to request path computation of P2MP TE LSPs. This document presents extensions to PCEP to support P2MP path computation satisfying the set of requirements described in [PCE- P2MP-REQ]. This document relies on the semantics of PCEP for requesting path computation for P2MP TE LSPs. A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. These S2L sub-LSPs are set up between ingress and egress LSRs and are appropriately combined by the branch LSRs using computation result from PCE to result in a P2MP TE LSP. One request message from a PCC may signal one or more S2L sub-LSP path computation requests to the PCE for a single P2MP LSP with certain constraints. Hence the S2L sub-LSPs belonging to a P2MP LSP can use one path computation request message or be split across multiple path computation messages. 1.1 Terminology Terminology used in this document TE LSP: Traffic Engineered Label Switched Path. LSR: Label Switch Router. OF: Objective Function: A set of one or more optimization criterion (criteria) used for the computation of a single path (e.g. path cost minimization), or the synchronized computation of a set of paths (e.g. aggregate bandwidth consumption minimization, etc.). P2MP: Point-to-Multipoint. P2P: Point-to-Point. Zhao, et al. [Page 3] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 This document also uses the terminology defined in [RFC4655], [RFC4875], and [RFC5440]. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Requirements This section summarizes the PCEP requirements specific to Point to Multipoint as described in [PCE-P2MP-REQ]. R1: Indication of P2MP Path Computation Request. R2: Indication of P2MP Objective Functions. R3: Non-Support of P2MP Path Computation. R4: Non-Support by Back-Level PCE Implementations. R5: Specification of Destinations. R6: Indication of P2MP Paths. R7: Multi-Message Requests and Responses. R8: Non-Specification of Per-Destination Constraints and Parameters. R9: Path Modification and Path Diversity. R10: Reoptimization of P2MP TE LSPs. R11: Addition and Removal of Destinations from Existing Paths. R12: Specification of Applicable Branch Nodes. R13: Capabilities Exchange. R14: The PCC should be able to request a PCE to compute secondary P2MP path tree with partial path diversity for specific leaves or a specific S2L sub-path. R15: Sender of the request message can specify if the return result from the PCE need to be represented in the compressed format or not. Zhao, et al. [Page 4] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 3. Protocol Procedures and Extensions The following sections describe the protocol extensions to satisfy the requirements specified in the previous section. 3.1. P2MP Capability Advertisement 3.1.1. Extend the TLV in the Existing PCE Discovery Protocol Since the [RFC5088] has specified that we can not add additional sub- TLV to the PCED TLV, we will define new bits to go in the existing 32 bits PCE Caps Flags to indicate the capability of P2MP for the PCC and PCE. 3.1.2. Open Message Extension Based on the Capabilities Exchange requirement described in [PCE- P2MP-REQ], if a PCE does not advertise its P2MP capability through discovery and the capability is not configured to the PCC, we need to use PCEP to allow a PCC to discover which PCEs with which it communicates support P2MP path computation. To satisfy this requirement, we extend the OPEN object format by including a new defined TLV for the capability of P2MP in the optional field. The new defined capability TLV allows the PCE to advertise its path computation capabilities. The TLV type number will be assigned by IANA, the LENGTH value is 2 bytes. The value field is set to default value 0. Note that the capability TLV is meaningful only for a PCE so it will typically appear only in one of the two Open messages during PCE session establishment. However, in case of PCE cooperation (e.g., inter-domain), when a PCE behaving as a PCC initiates a PCE session it SHOULD also indicate its Path Computation capability. 3.2. P2MP LSPs Efficient Presentation In the request message of the adding of leaves, optimization of P2MP TE LSPs as specified in [PCE-P2MP-REQ], and in the reply message, we need to pass an existing P2MP LSP between the PCC and PCE. In these cases, we need new path objects for efficiently passing the existing P2MP LSP between PCE to PCC. We suggest to using the ERO/SERO and RRO/SRRO to represent each individual S2L sub-LSP. The contents of ERO/RRO are same as defined in the [RFC5440] and the contents of SERO and SRRO are same as defined in RFC4875 for the RSVP extension of P2MP except we need assign the new class and type for all of them. Zhao, et al. [Page 5] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 3.3. Indication of P2MP Path Computation Request/Reply The existing P2P RP object is extended so that it can signal to the receiver of the request or reply message that it is for P2P or P2MP path computation. Also the END-POINT object is extended to improve the efficiency of the message exchange between PCC and PCE in the case of P2MP path computation. 3.3.1. The Extension of RP Object The PCE path computation request/reply message adds an explicit parameter to allow a receiving PCE to identify that the request/reply is for a P2MP path and also to specify if the route is represented in the compress format or not. The M bit is added in the flag bits field of the RP object to signal the receiver of the message that the request/reply is for P2MP or not. The E bit is added in the flag bits field of the RP object to signal the receiver of the message that the route is in the compress format or not. The extended format of the RP object body to include the M bit and the E bit is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |E|M| O|B|R| Pri | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request-ID-number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: RP Object Body Format The following flags are added in this draft: o M ( P2MP bit - 1 bit): 0: This indicates that this is not PCReq/PCRrep for P2MP. 1: This indicates that this is PCReq or PCRep message for P2MP. o E ( ERO-compression bit - 1 bit): Zhao, et al. [Page 6] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 0: This indicates that the route is not in the compressed format. 1: This indicates that the route is in the compressed format. 3.3.2. The New P2MP END-POINTS Object To represent the end points for a P2MP path efficiently, we define a new type of end-points object for P2MP path. With this new END-POINTS object, the PCE path computation request message is expanded in a way such that it allows a single request message to list multiple destinations. There are 4 types of leaves in a P2MP request: o New leaves to add; o Old leaves to remove; o Old leaves whose path can be modified/reoptimized; o Old leaves whose path must be left unchanged. 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 the END- POINTS object leaf type field. So four values are possible for the leaf type field: 1. New leaves to add; 2. Old leaves to remove; 3. Old leaves whose path can be modified/reoptimized; 4. Old leaves whose path must be left unchanged. With this new END-POINTS object, the END-POINTS portions of a request message for the multiple destinations can be roughly reduced up to 50% for a P2MP path where a single source address has a very large number of destinations. Note that A P2MP path computation request can mix the different type of leaves by including several END-POINTS object per RP object as shown in PCReq BNF format in next section. The format of the new END-POINTS object body for IPv4 (Object-Type 3) is as follows: Zhao, et al. [Page 7] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: The New P2MP END-POINTS Object Body Format for IPv4 The format of the END-POINTS object body for IPv6 (Object-Type 4) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Leaf type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: The New P2MP END-POINTS Object Body Format for IPv6 The END-POINTS object body has a variable length of multiple of 4 bytes for IPv4 and multiple of 16 bytes for IPv6. Zhao, et al. [Page 8] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 3.4. Request Message Formats Below is the message format for the request message: ::= where: ::= [] [] [] [] [] [] where: ::= [][] [] RRO-List::=[BANDWIDTH][] ::=[] Figure 4: The Message Format for the Request Message 3.5. Reply Message Formats Below is the message format for the reply message: ::= ::= [] [] [] where: ::= [][] ::= |[] ::=[] [] [] [] [] Figure 5: The Message Format for the Reply Message Zhao, et al. [Page 9] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 The optional END-POINTS in the reply message is used to specify which paths are removed, changed, not changed, or added for the request. The path is only needed for the end points which are added or changed. If the ERO-Compress bit was set to 1 in request then the path will be formed by an ERO followed by a list of SERO. Otherwise it is a list of ERO. 3.6. P2MP Objective Functions and Metric Types 3.6.1. New Object Functions Six objective functions have been defined in [PCE-OF] for P2P path computation. This document defines two additional objective functions, namely SPT (Shortest Path Tree) and MCT (Minimum Cost Tree) that apply to P2MP path computation. Hence two new objective function codes have to be defined. The description of the two new objective functions is as follows. Objective Function Code: 7 (suggested value, to be assigned by IANA) Name: Shortest Path Tree (SPT) Description: Minimize the maximum source-to-leaf cost with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified. (e.g. TE or IGP metric) Objective Function Code: 8 (suggested value, to be assigned by IANA) Name: Minimum Cost Tree (MCT) Description: Minimize the total cost of the tree, that is the sum of the costs of tree links, with respect to a specific metric or to the TE metric used as the default metric when the metric is not specified.. Processing these two new objective functions is subject to the rules defined in [PCE-OF]. Zhao, et al. [Page 10] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 3.6.2. New Metric Object Types There are three types defined for the object in [RFC5440], namely, the IGP metric, the TE metric and the hop count metric. This document defines three other types for the object: the P2MP IGP metric, the P2MP TE metric, and the P2MP Hop Count metric. They encode the sum of the metrics of all links of the tree. We propose the following values for these new metric types (to be assigned by IANA): o P2MP IGP metric: T=4 o P2MP TE metric: T=5 o P2MP hop count metric: T=6 3.7. Non-Support of P2MP Path Computation. o if a PCE receives a P2MP path request and it understands the P2MP flag in RP object, but the PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with a PCEP-ERROR Object and an Error-Value. The corresponding P2MP path computation request MUST be cancelled. (Error-Type and Error-Value are defined in this document). o If the PCE does not understand the P2MP flag in the RP object, then the PCE MUST send a PCErr message with a new error type "Unknown RP flag". 3.8. Non-Support by Back-Level PCE Implementations. If we accidentally send the P2MP request to a PCE which does not support the PCEP P2MP extensions yet, then it will reject the request because it cannot understand the new END-POINTS object. 3.9. P2MP TE Path Re-optimization Request The re-optimization request for a P2MP TE path is specified by R bit in the RP object similarly to the re-optimization request for a P2P TE path. The only difference is that the user must insert the list of RRO after each type of END-POINTS as described in the PCReq message format section. Zhao, et al. [Page 11] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 So the PCReq message would look like this: ::= where: ::= [OF] Figure 6: PCReq Message Example 1 for Optimization In this example, we request re-optimization of path to all leaves without adding or pruning leaves. That is only one END-POINT of type 3. The RRO list is representing the P2MP LSP before the optimization and the modifiable path leaves are indicated in the END-POINTS object. Optionally it is possible to specify some leaves whose path cannot be modified. The PCReq message would then look like this: ::= where: ::= [OF] Figure 7: PCReq Message Example 2 for Optimization 3.10. Adding/pruning Leaves When adding new leaves or removing old leaves to the existing P2MP tree, by supplying a list of existing leaves, one may be able to optimize the new P2MP tree. This section explains ways to add new leaves or remove old leaves to the existing P2MP tree. To add new leaves the user must build a P2MP request with an END- POINTS with leaf type 1. To Remove old leaves the user must build a P2MP request with an END- POINTS with leaf type 2. Zhao, et al. [Page 12] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 In any case it must also provides the list of old leaves and indicate if they must be reoptimized or not by including END-POINTS with leaf type 3 or 4 or both. In the future version, we may want to consider to define error values when the condition is not satisfied (i.e., when there is no END-POINTS with leaf type 3 or 4, in the presence of END-POINTS with leaf type 1 or 2). For old leaves the user must provide the old path as list of RROs that immediately follows each END-POINTS object. In the future version, we may want to consider to define error values when the condition is not satisfied. So eventually the following cases are possible when modifying an existing P2MP LSP: Case 1: Adding leaves with full reoptimization of existing paths ::= where: ::= [OF] Figure 8: Adding Leaves with Full Reoptimization Case 2: Adding leaves with partial reoptimization of existing paths ::= where: ::= [OF] Figure 9: Adding Leaves with Partial Reoptimization Zhao, et al. [Page 13] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 Case 3: Adding leaves without reoptimization of existing paths ::= where: ::= [OF] Figure 10: Adding Leaves without Reoptimization ::= where: ::= [OF] Figure 11: Pruning Leaves with Full Reoptimization Case 5: Pruning leaves with partial reoptimization of existing paths ::= where: ::= [OF] Figure 12: Pruning Leaves with Partial Reoptimization Zhao, et al. [Page 14] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 Case 6: Pruning leaves without reoptimization of existing paths ::= where: ::= [OF] Figure 13: Pruning Leaves without Reoptimization Case 7: Adding and pruning leaves full reoptimization of existing paths ::= where: ::= [OF] Figure 14: Adding and Pruning Leaves full Reoptimization Case 8: Adding and pruning leaves with partial reoptimization of existing paths ::= where: ::= [OF] Figure 15: Adding and Pruning Leaves with Partial Reoptimization Zhao, et al. [Page 15] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 Case 9: Adding and pruning leaves without reoptimization of existing paths ::= where: ::= [OF] Figure 16: Adding and Pruning Leaves without Reoptimization 3.11. Branch Nodes Before computing the P2MP path, a PCE must be provided means to know which nodes in the network are capable of acting as branch LSRs. A PCE can discover such capability by using the mechanisms defined in [NODE-CAP]. 3.12. Synchronization of P2MP TE Path Computation Requests There are cases when multiple P2MP LSPs' computations need to be synchronized. For example, one P2MP LSP is the backup of another P2MP LSP. In this case, the path diversity for these two LSPs need to be considered during the path computation. The synchronization can be done by just using the existing SVEC functionality. Example of synchronizing two P2MP LSPs, each has two leaves for Path Computation Request Messages is illustrated as below: ::= [OF] where: ::= ::= [] ::= [] Figure 17: PCReq Message Example for Synchronization Zhao, et al. [Page 16] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 We propose that two new flags are also added to the SVEC object for path dependent computation requests. The first new flag is to allow the PCC to request that the PCE should compute a secondary P2MP path tree with partial path diversity for specific leaves or a specific S2L sub- path to the primary P2MP path tree. The second flag, would allow the PCC to request that partial paths should be link direction diverse. 3.13. Multi-Message Support The solution follows synchronization procedures defined in [RFC5440]. If the P2MP request (i.e. ) is too large to fit into a single message it is permitted to divide it into multiple requests that would be carried in different messages. That means that a P2MP request would then contain multiple requests with RP objects that have the same request IDs. Here is an example of such P2MP request that is divided in 2 request messages: ::= where: ::=< RP with Req-ID1 > ::= where: ::=< RP with Req-ID1> Figure 18: PCReq Message Example for Message Fragmentation Note that the SVEC object contains the same request Id repeated N times where N is the total number of RP objects included in all messages. This is to be able to detect that the whole P2MP request has been received. Note that this assumes that the transmission of the messages is performed reliably and in consistent order, which is not a problem since PCEP relies on TCP. Zhao, et al. [Page 17] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 To avoid the backward compatible problem when a PCE that does not support P2MP extensions receives an SVEC with same request Id twice, such message MUST NOT be sent to a non P2MP capable PCE. Thanks to the OPEN message discovery mechanism this is possible to known. We propose to use the SVEC/synctimer mechanism also for PCRep message (in case of too large response message). This was not defined in The PCEP base draft. We propose that this feature should be defined in The future version of the PCEP draft. 3.14. UNREACH_DESTINATION object The PCE path computation request may fail because all or a subset of the destinations are unreachable. In such a case, the UNREACH-DESTINATION object allows the PCE to optionally specify the list of unreachable destinations. This object can be present in PCRep messages. There can be up to one such object per RP. UNREACH_DESTINATION Object-Class is to be assigned by IANA. UNREACH_DESTINATION Object-Type for IPv4 is to be assigned by IANA UNREACH_DESTINATION Object-Type for IPv6 is to be assigned by IANA. The format of the UNREACH_DESTINATION object body for IPv4 (Object- Type=1) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IPv4 address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 19: UNREACH_DESTINATION Object Body for IPv4 Zhao, et al. [Page 18] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 The format of the UNREACH_DESTINATION object body for IPv6 (Object- Type=2) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination IPv6 address (16 bytes) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 20: UNREACH_DESTINATION Object Body for IPv6 3.15. P2MP PCEP Error Object To indicate errors associated with the P2MP path request, a new Error-Type (16) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR object: A new Error-Type (16) and subsequent error-values are defined as follows: Error-Type=16 and Error-Value=1: if a PCE receives a P2MP path request and the PCE is not capable to satisfy the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP ERROR object (Error-Type=16) and an Error-Value(Error-Value=1). The corresponding P2MP path computation request MUST be cancelled. Error-Type=16; Error-Value=2: if a PCE receives a P2MP path request and the PCE is not capable of P2MP computation, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=16) and an Error- Value (Error-Value=2). The corresponding P2MP path computation request MUST be cancelled. To indicate an error associated with policy violation, a new error value "P2MP Path computation not allowed" should be added to an existing error code for policy violation (Error-Type=5) as defined in [RFC5440]. Error-Type=5; Error-Value=4: if a PCE receives a P2MP path computation request which is not compliant with administrative privileges (i.e., the PCE policy does not support P2MP path computation), the PCE sends a PCErr message with a PCEP-ERROR Object (Error-Type=5) and an Error-Value (Error-Value=4). The corresponding P2MP path computation request MUST be cancelled. Zhao, et al. [Page 19] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 3.16. PCEP NO-PATH Indicator To communicate the reason(s) for not being able to find P2MP path computation, the NO-PATH object can be used in the PCRep message. The format of the NO-PATH object body is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C| Flags | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // Optional TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 21: The Format of the NO-PATH Object Body One new bit flags are defined in the NO-PATH-VECTOR TLV carried in the NO-PATH Object: 0x20: when set, the PCE indicates that there is a reachability problem with all or a subset of the P2MP destinations. Optionally the PCE can specify the list of destination(s) that are not reachable using the new UNREACH_DESTINATION object defined in section 3.6. 4. Manageability Considerations [PCE-P2MP-REQ] describes various manageability requirements in support of P2MP path computation when applying PCEP. This section describes how manageability requirements mentioned in [PCE-P2MP-REQ] are supported in the context of PCEP extensions specified in this document. Note that [RFC5440] describes various manageability considerations in PCEP, and most of manageability requirements mentioned in [PCE-P2MP P2MP] are already covered there. 4.1. Control of Function and Policy In addition to configuration parameters listed in [RFC5440], the following parameters MAY be required. o P2MP path computations enabled or disabled. o Advertisement of P2MP path computation capability enabled or disabled (discovery protocol, capability exchange). Zhao, et al. [Page 20] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 4.2. Information and Data Models As described in [PCE-P2MP-REQ], MIB objects MUST be supported for PCEP extensions specified in this document. 4.3. Liveness Detection and Monitoring There are no additional considerations beyond those expressed in [RFC5440], since [PCE-P2MP-REQ] does not address any additional requirements. 4.4. Verifying Correct Operation There are no additional considerations beyond those expressed in [PCEP], since [PCE-P2MP-REQ] does not address any additional requirements. 4.5. Requirements on Other Protocols and Functional Components As described in [PCE-P2MP-REQ], the PCE MUST obtain information about the P2MP signaling and branching capabilities of each LSR in the network. Protocol extensions specified in this document does not provide such capability. Other mechanisms MUST be present. 4.6. Impact on Network Operation It is expected that use of PCEP extensions specified in this document does not have significant impact on network operations. 5. Security Considerations As described in [PCE-P2MP-REQ], P2MP path computation requests are more CPU-intensive and also use more link bandwidth. Therefore, it may be more vulnerable to denial of service attacks. [PCEP] describes various mechanisms for denial of service attacks, and these tools MAY be advantageously used. 6. IANA Considerations A number of IANA considerations have been highlighted in the relevant sections of this document. Further clarifications of these requests will be made in a future version of this document. Zhao, et al. [Page 21] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 7. Acknowledgements The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan,Autumn Liu and Huaimo Chen, and Eiji Oki for their valuable comments on this draft. 8. References 8.1. Normative References [RFC5440] Ayyangar, A., Farrel, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, Y., Kumaki, K., Vasseur, J., and J. Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007. [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008. [PCE-P2MP-REQ] Yasukawa, S. and A. Farrel, "PCC-PCE Communication Requirements for Point to Multipoint Multiprotocol Label Switching Traffic Engineering (MPLS-TE)", draft-ietf-pce-p2mp-req-01 (work in progress), February 2008. Zhao, et al. [Page 22] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 [PCE-OF] Roux, J., Vasseur, J., and Y. Lee, "Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)", draft-ietf-pce-of-06 (work in progress), December 2008. 8.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [PCE-P2MP-APP] Yasukawa, S. and A. Farrel, "draft-ietf-pce-p2mp-app-01.txt", draft-ietf-pce-p2mp-app-01 (work in progress), February 2009. 9. Authors' Addresses Quintin Zhao (editor) Huawei Technology 125 Nagog Technology Park Acton, MA 01719 US Email: qzhao@huawei.com Daniel King Old Dog Consulting UK Email: daniel@olddog.co.uk Fabien Verhaeghe Marben Products 176 avenue Jean Jaures 92800 Puteaux, France Email: fabien.verhaeghe@marben-products.com Tomonori Takeda NTT Corporation 3-9-11, Midori-Cho Musashino-Shi, Tokyo 180-8585 Japan Email: takeda.tomonori@lab.ntt.co.jp Mohamad Chaitou (editor) France Email: Mohamad. mohamad.chaitou@gmail.com Zhao, et al. [Page 23] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex, France Email: Jeanlouis.Leroux@orange-ftgroup.com Zafar Ali Cisco systems, Inc. 2000 Innovation Drive Kanata, Ontario K2K 3E8 Canada Email: zali@cisco.com 10. Intellectual Property Consideration The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. Zhao, et al. [Page 24] draft-ietf-pce-pcep-p2mp-extensions-02.txt March 2009 For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. 11. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 12. Full Copyright Statement Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Zhao, et al. [Page 25]