diff options
Diffstat (limited to 'doc/rfc/rfc6006.txt')
| -rw-r--r-- | doc/rfc/rfc6006.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc6006.txt b/doc/rfc/rfc6006.txt new file mode 100644 index 0000000..04e438c --- /dev/null +++ b/doc/rfc/rfc6006.txt @@ -0,0 +1,1851 @@ + + + + + + +Internet Engineering Task Force (IETF) Q. Zhao, Ed. +Request for Comments: 6006 Huawei Technology +Category: Standards Track D. King, Ed. +ISSN: 2070-1721 Old Dog Consulting + F. Verhaeghe + Thales Communication France + T. Takeda + NTT Corporation + Z. Ali + Cisco Systems, Inc. + J. Meuric + France Telecom + September 2010 + + + Extensions to + the Path Computation Element Communication Protocol (PCEP) + for Point-to-Multipoint Traffic Engineering Label Switched Paths + +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 + need to be determined. The Path Computation Element (PCE) has been + identified as an appropriate technology for the determination of the + paths of point-to-multipoint (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. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6006. + + + + + + +Zhao, et al. Standards Track [Page 1] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +Copyright Notice + + Copyright (c) 2010 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 + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction ....................................................3 + 1.1. Terminology ................................................4 + 1.2. Requirements Language ......................................5 + 2. PCC-PCE Communication Requirements ..............................5 + 3. Protocol Procedures and Extensions ..............................6 + 3.1. P2MP Capability Advertisement ..............................6 + 3.1.1. P2MP Computation TLV in the Existing PCE + Discovery Protocol ..................................6 + 3.1.2. Open Message Extension ..............................7 + 3.2. Efficient Presentation of P2MP LSPs ........................7 + 3.3. P2MP Path Computation Request/Reply Message Extensions .....8 + 3.3.1. The Extension of the RP Object ......................8 + 3.3.2. The New P2MP END-POINTS Object ......................9 + 3.4. Request Message Format ....................................12 + 3.5. Reply Message Format ......................................12 + 3.6. P2MP Objective Functions and Metric Types .................13 + 3.6.1. New Objective Functions ............................13 + 3.6.2. New Metric Object Types ............................14 + 3.7. Non-Support of P2MP Path Computation ......................14 + + + +Zhao, et al. Standards Track [Page 2] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + 3.8. Non-Support by Back-Level PCE Implementations .............15 + 3.9. P2MP TE Path Reoptimization Request .......................15 + 3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........16 + 3.11. Discovering Branch Nodes .................................19 + 3.11.1. Branch Node Object ................................19 + 3.12. Synchronization of P2MP TE Path Computation Requests .....19 + 3.13. Request and Response Fragmentation .......................20 + 3.13.1. Request Fragmentation Procedure ...................21 + 3.13.2. Response Fragmentation Procedure ..................21 + 3.13.3. Fragmentation Examples ............................21 + 3.14. UNREACH-DESTINATION Object ...............................22 + 3.15. P2MP PCEP-ERROR Objects and Types ........................23 + 3.16. PCEP NO-PATH Indicator ...................................24 + 4. Manageability Considerations ...................................25 + 4.1. Control of Function and Policy ............................25 + 4.2. Information and Data Models ...............................25 + 4.3. Liveness Detection and Monitoring .........................25 + 4.4. Verifying Correct Operation ...............................25 + 4.5. Requirements for Other Protocols and Functional + Components ................................................26 + 4.6. Impact on Network Operation ...............................26 + 5. Security Considerations ........................................26 + 6. IANA Considerations ............................................27 + 6.1. PCEP TLV Type Indicators ..................................27 + 6.2. Request Parameter Bit Flags ...............................27 + 6.3. Objective Functions .......................................27 + 6.4. Metric Object Types .......................................27 + 6.5. PCEP Objects ..............................................28 + 6.6. PCEP-ERROR Objects and Types ..............................29 + 6.7. PCEP NO-PATH Indicator ....................................30 + 6.8. SVEC Object Flag ..........................................30 + 6.9. OSPF PCE Capability Flag ..................................30 + 7. Acknowledgements ...............................................30 + 8. References .....................................................30 + 8.1. Normative References ......................................30 + 8.2. Informative References ....................................32 + +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. + + + +Zhao, et al. Standards Track [Page 3] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + The PCE has been identified as a suitable application for the + computation of paths for P2MP TE LSPs [RFC5671]. + + 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. + + A P2MP LSP is comprised of multiple source-to-leaf (S2L) sub-LSPs. + These S2L sub-LSPs are set up between ingress and egress Label + Switching Routers (LSRs) and are appropriately overlaid to construct + a P2MP TE LSP. During path computation, the P2MP TE LSP may be + determined as a set of S2L sub-LSPs that are computed separately and + combined to give the path of the P2MP LSP, or the entire P2MP TE LSP + may be determined as a P2MP tree in a single computation. + + This document relies on the mechanisms of PCEP to request path + computation for P2MP TE LSPs. One path computation request message + from a PCC may request the computation of the whole P2MP TE LSP, or + the request may be limited to a sub-set of the S2L sub-LSPs. In the + extreme case, the PCC may request the S2L sub-LSPs to be computed + individually with it being the PCC's responsibility to decide whether + to signal individual S2L sub-LSPs or combine the computation results + to signal the entire P2MP TE LSP. Hence the PCC may use one path + computation request message or may split the request across multiple + path computation messages. + +1.1. Terminology + + Terminology used in this document: + + TE LSP: Traffic Engineering Label Switched Path. + + LSR: Label Switching Router. + + OF: Objective Function: A set of one or more optimization criteria + used for the computation of a single path (e.g., path cost + minimization), or for the synchronized computation of a set of + paths (e.g., aggregate bandwidth consumption minimization). + + P2MP: Point-to-Multipoint. + + P2P: Point-to-Point. + + This document also uses the terminology defined in [RFC4655], + [RFC4875], and [RFC5440]. + + + + +Zhao, et al. Standards Track [Page 4] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +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. PCC-PCE Communication Requirements + + This section summarizes the PCC-PCE communication requirements for + P2MP MPLS-TE LSPs described in [RFC5862]. The numbering system + corresponds to the requirement numbers used in [RFC5862]. + + 1. The PCC MUST be able to specify that the request is a P2MP path + computation request. + + 2. The PCC MUST be able to specify that objective functions are to + be applied to the P2MP path computation request. + + 3. The PCE MUST have the capability to reject a P2MP path request + and indicate non-support of P2MP path computation. + + 4. The PCE MUST provide an indication of non-support of P2MP path + computation by back-level PCE implementations. + + 5. A P2MP path computation request MUST be able to list multiple + destinations. + + 6. A P2MP path computation response MUST be able to carry the path + of a P2MP LSP. + + 7. By default, the path returned by the PCE SHOULD use the + compressed format. + + 8. It MUST be possible for a single P2MP path computation request or + response to be conveyed by a sequence of messages. + + 9. It MUST NOT be possible for a single P2MP path computation + request to specify a set of different constraints, traffic + parameters, or quality-of-service requirements for different + destinations of a P2MP LSP. + + 10. P2MP path modification and P2MP path diversity MUST be supported. + + 11. It MUST be possible to reoptimize existing P2MP TE LSPs. + + 12. It MUST be possible to add and remove P2MP destinations from + existing paths. + + + + +Zhao, et al. Standards Track [Page 5] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + 13. It MUST be possible to specify a list of applicable branch nodes + to use when computing the P2MP path. + + 14. It MUST be possible for a PCC to discover P2MP path computation + capability. + + 15. The PCC MUST be able to request diverse paths when requesting a + P2MP path. + +3. Protocol Procedures and Extensions + + The following section describes the protocol extensions required to + satisfy the requirements specified in Section 2 ("PCC-PCE + Communication Requirements") of this document. + +3.1. P2MP Capability Advertisement + +3.1.1. P2MP Computation TLV in the Existing PCE Discovery Protocol + + [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF + Router Information Link State Advertisement (LSA) defined in + [RFC4970] to facilitate PCE discovery using OSPF. [RFC5088] + specifies that no new sub-TLVs may be added to the PCED TLV. This + document defines a new flag in the OSPF PCE Capability Flags to + indicate the capability of P2MP computation. + + Similarly, [RFC5089] defines the PCED sub-TLV for use in PCE + Discovery using IS-IS. This document will use the same flag + requested for the OSPF PCE Capability Flags sub-TLV to allow IS-IS to + indicate the capability of P2MP computation. + + The IANA assignment for a shared OSPF and IS-IS P2MP Capability Flag + is documented in Section 6.9 ("OSPF PCE Capability Flag") of this + document. + + PCEs wishing to advertise that they support P2MP path computation + would set the bit (10) accordingly. PCCs that do not understand this + bit will ignore it (per [RFC5088] and [RFC5089]). PCEs that do not + support P2MP will leave the bit clear (per the default behavior + defined in [RFC5088] and [RFC5089]). + + PCEs that set the bit to indicate support of P2MP path computation + MUST follow the procedures in Section 3.3.2 ("The New P2MP END-POINTS + Object") to further qualify the level of support. + + + + + + + +Zhao, et al. Standards Track [Page 6] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +3.1.2. Open Message Extension + + Based on the Capabilities Exchange requirement described in + [RFC5862], if a PCE does not advertise its P2MP capability during + discovery, PCEP should be used to allow a PCC to discover, during the + Open Message Exchange, which PCEs are capable of supporting P2MP path + computation. + + To satisfy this requirement, we extend the PCEP OPEN object by + defining a new optional TLV to indicate the PCE's capability to + perform P2MP path computations. + + IANA has allocated value 6 from the "PCEP TLV Type Indicators" sub- + registry, as documented in Section 6.1 ("PCEP TLV Type Indicators"). + The description is "P2MP capable", and the length value is 2 bytes. + The value field is set to default value 0. + + The inclusion of this TLV in an OPEN object indicates that the sender + can perform P2MP path computations. + + 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 capabilities. + +3.2. Efficient Presentation of P2MP LSPs + + When specifying additional leaves, or optimizing existing P2MP TE + LSPs as specified in [RFC5862], it may be necessary to pass existing + P2MP LSP route information between the PCC and PCE in the request and + reply messages. In each of these scenarios, we need new path objects + for efficiently passing the existing P2MP LSP between the PCE and + PCC. + + We specify the use of the Resource Reservation Protocol Traffic + Engineering (RSVP-TE) extensions Explicit Route Object (ERO) to + encode the explicit route of a TE LSP through the network. PCEP ERO + sub-object types correspond to RSVP-TE ERO sub-object types. The + format and content of the ERO object are defined in [RFC3209] and + [RFC3473]. + + The Secondary Explicit Route Object (SERO) is used to specify the + explicit route of a S2L sub-LSP. The path of each subsequent S2L + sub-LSP is encoded in a P2MP_SECONDARY_EXPLICIT_ROUTE object SERO. + The format of the SERO is the same as an ERO defined in [RFC3209] and + [RFC3473]. + + + + +Zhao, et al. Standards Track [Page 7] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + The Secondary Record Route Object (SRRO) is used to record the + explicit route of the S2L sub-LSP. The class of the P2MP SRRO is the + same as the SRRO defined in [RFC4873]. + + The SERO and SRRO are used to report the route of an existing TE LSP + for which a reoptimization is desired. The format and content of the + SERO and SRRO are defined in [RFC4875]. + + A new PCEP object class and type are requested for SERO and SRRO. + + Object-Class Value 29 + Name SERO + Object-Type 1: SERO + 2-15: Unassigned + Reference RFC 6006 + + Object-Class Value 30 + Name SRRO + Object-Type 1: SRRO + 2-15: Unassigned + Reference RFC 6006 + + The IANA assignment is documented in Section 6.5 ("PCEP Objects"). + + Since the explicit path is available for immediate signaling by the + MPLS or GMPLS control plane, the meanings of all of the sub-objects + and fields in this object are identical to those defined for the ERO. + +3.3. P2MP Path Computation Request/Reply Message Extensions + + This document extends the existing P2P RP (Request Parameters) object + so that a PCC can signal a P2MP path computation request to the PCE + receiving the PCEP request. The END-POINTS object is also 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 the RP Object + + The PCE path computation request and reply messages will need the + following additional parameters to indicate to the receiving PCE that + the request and reply messages have been fragmented across multiple + messages, that they have been requested for a P2MP path, and whether + the route is represented in the compressed or uncompressed format. + + This document adds the following flags to the RP Object: + + + + + + +Zhao, et al. Standards Track [Page 8] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + The F-bit is added to the flag bits of the RP object to indicate to + the receiver that the request is part of a fragmented request, or is + not a fragmented request. + + o F (RP fragmentation bit - 1 bit): + + 0: This indicates that the RP is not fragmented or it is the last + piece of the fragmented RP. + + 1: This indicates that the RP is fragmented and this is not the + last piece of the fragmented RP. The receiver needs to wait + for additional fragments until it receives an RP with the same + RP-ID and with the F-bit set to 0. + + The N-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 is + not for P2MP. + + o N (P2MP bit - 1 bit): + + 0: This indicates that this is not a PCReq or PCRep message for + P2MP. + + 1: This indicates that this is a PCReq or PCRep message for P2MP. + + 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 compressed + format or is not in the compressed format. By default, the path + returned by the PCE SHOULD use the compressed format. + + o E (ERO-compression bit - 1 bit): + + 0: This indicates that the route is not in the compressed format. + + 1: This indicates that the route is in the compressed format. + + The IANA assignment is documented in Section 6.2 ("Request Parameter + Bit Flags") of this document. + +3.3.2. The New P2MP END-POINTS Object + + The END-POINTS object is used in a PCReq message to specify the + source IP address and the destination IP address of the path for + which a path computation is requested. To represent the end points + for a P2MP path efficiently, we define two new types of END-POINTS + objects for the P2MP path: + + + + + +Zhao, et al. Standards Track [Page 9] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + o Old leaves whose path can be modified/reoptimized; + + o Old leaves whose path must be left unchanged. + + With the new END-POINTS object, the PCE path computation request + message is expanded in a way that allows a single request message to + list multiple destinations. + + In total, there are now 4 possible types of leaves in a P2MP request: + + o New leaves to add (leaf type = 1) + + o Old leaves to remove (leaf type = 2) + + o Old leaves whose path can be modified/reoptimized (leaf type = 3) + + o Old leaves whose path must be left unchanged (leaf type = 4) + + 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. + + Using the new END-POINTS object, the END-POINTS portion of a request + message for the multiple destinations can be reduced by 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 types + of leaves by including several END-POINTS objects per RP object as + shown in the PCReq Routing Backus-Naur Form (RBNF) [RFC5511] format + in Section 3.4 ("Request Message Format"). + + + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 10] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + The format of the new END-POINTS object body for IPv4 (Object-Type 3) + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Leaf type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Source IPv4 address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination IPv4 address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination IPv4 address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1. 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Leaf type | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Source IPv6 address (16 bytes) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Destination IPv6 address (16 bytes) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Destination IPv6 address (16 bytes) | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2. The New P2MP END-POINTS Object Body Format for IPv6 + + The END-POINTS object body has a variable length. These are + multiples of 4 bytes for IPv4, and multiples of 16 bytes, plus 4 + bytes, for IPv6. + + + + +Zhao, et al. Standards Track [Page 11] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +3.4. Request Message Format + + The PCReq message is encoded as follows using RBNF as defined in + [RFC5511]. + + Below is the message format for the request message: + + <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>] + + Figure 3. The Message Format for the Request Message + + Note that we preserve compatibility with the [RFC5440] definition of + <request>. At least one instance of <endpoints> MUST be present in + this message. + + We have documented the IANA assignment of additional END-POINTS + Object-Types in Section 6.5 ("PCEP Objects") of this document. + +3.5. Reply Message Format + + The PCRep message is encoded as follows using RBNF as defined in + [RFC5511]. + + + + + + + + + + +Zhao, et al. Standards Track [Page 12] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + Below is the message format for the reply message: + + <PCRep Message>::= <Common Header> + <response> + <response>::=<RP> + [<end-point-path-pair-list>] + [<NO-PATH>] + [<attribute-list>] + + where: + + <end-point-path-pair-list>::= + [<END-POINTS>]<path>[<end-point-path-pair-list>] + + <path> ::= (<ERO>|<SERO>) [<path>] + + <attribute-list>::=[<OF>] + [<LSPA>] + [<BANDWIDTH>] + [<metric-list>] + [<IRO>] + + Figure 4. The Message Format for the Reply Message + + The optional END-POINTS object 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 that are + added or changed. + + If the E-bit (ERO-Compress bit) was set to 1 in the request, then the + path will be formed by an ERO followed by a list of SEROs. + + Note that we preserve compatibility with the [RFC5440] definition of + <response> and the optional <end-point-path-pair-list> and <path>. + +3.6. P2MP Objective Functions and Metric Types + +3.6.1. New Objective Functions + + Six objective functions have been defined in [RFC5541] 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. + + + +Zhao, et al. Standards Track [Page 13] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + Objective Function Code: 7 + + 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 + + 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 [RFC5541]. + +3.6.2. New Metric Object Types + + There are three types defined for the <METRIC> object in [RFC5440] -- + namely, the IGP metric, the TE metric, and the hop count metric. + This document defines three additional types for the <METRIC> 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: + + o P2MP IGP metric: T=8 + + o P2MP TE metric: T=9 + + o P2MP hop count metric: T=10 + +3.7. Non-Support of P2MP Path Computation + + o If a PCE receives a P2MP path request and it understands the P2MP + flag in the RP object, but the PCE is not capable of P2MP + computation, the PCE MUST send a PCErr message with a PCEP-ERROR + object and corresponding Error-Value. The request MUST then be + cancelled at the PCC. New Error-Types and Error-Values are + requested in Section 6 ("IANA Considerations") of 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 Error-value=2 + (capability not supported). + + + + +Zhao, et al. Standards Track [Page 14] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +3.8. Non-Support by Back-Level PCE Implementations + + If a PCE receives a P2MP request and the PCE does not understand the + P2MP flag in the RP object, and therefore the PCEP P2MP extensions, + then the PCE SHOULD reject the request. + +3.9. P2MP TE Path Reoptimization Request + + A reoptimization request for a P2MP TE path is specified by the use + of the R-bit within the RP object as defined in [RFC5440] and is + similar to the reoptimization request for a P2P TE path. The only + difference is that the user MUST insert the list of RROs and SRROs + after each type of END-POINTS in the PCReq message, as described in + the "Request Message Format" section (Section 3.4) of this document. + + An example of a reoptimization request and subsequent PCReq message + is described below: + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 3 + RRO list + OF (optional) + + Figure 5. PCReq Message Example 1 for Optimization + + In this example, we request reoptimization of the path to all leaves + without adding or pruning leaves. The reoptimization request would + use an END-POINT type 3. The RRO list would represent the P2MP LSP + before the optimization, and the modifiable path leaves would be + indicated in the END-POINTS object. + + It is also possible to specify distinct leaves whose path cannot be + modified. An example of the PCReq message in this scenario would be: + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 3 + RRO list + END-POINTS for leaf type 4 + RRO list + OF (optional) + + Figure 6. PCReq Message Example 2 for Optimization + + + + + + + +Zhao, et al. Standards Track [Page 15] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +3.10. Adding and Pruning Leaves to/from the P2MP Tree + + When adding new leaves to or removing old leaves from the existing + P2MP tree, by supplying a list of existing leaves, it SHOULD be + possible to optimize the existing P2MP tree. This section explains + the methods for adding new leaves to or removing old leaves from the + existing P2MP tree. + + To add new leaves, the user MUST build a P2MP request using END- + POINTS with leaf type 1. + + To remove old leaves, the user must build a P2MP request using END- + POINTS with leaf type 2. If no type-2 END-POINTS exist, then the PCE + MUST send an error type 17, value=1: The PCE is not capable of + satisfying the request due to no END-POINTS with leaf type 2. + + When adding new leaves to or removing old leaves from the existing + P2MP tree, the PCC must also provide the list of old leaves, if any, + including END-POINTS with leaf type 3, leaf type 4, or both. New + PCEP-ERROR objects and types are necessary for reporting when certain + conditions are not satisfied (i.e., when there are no END-POINTS with + leaf type 3 or 4, or in the presence of END-POINTS with leaf type 1 + or 2). A generic "Inconsistent END-POINT" error will be used if a + PCC receives a request that has an inconsistent END-POINT (i.e., if a + leaf specified as type 1 already exists). These IANA assignments are + documented in Section 6.6 ("PCEP-ERROR Objects and Types") of this + document. + + For old leaves, the user MUST provide the old path as a list of RROs + that immediately follows each END-POINTS object. This document + specifies error values when specific conditions are not satisfied. + + The following examples demonstrate full and partial reoptimization of + existing P2MP LSPs: + + Case 1: Adding leaves with full reoptimization of existing paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 1 + RRO list + END-POINTS for leaf type 3 + RRO list + OF (optional) + + + + + + + +Zhao, et al. Standards Track [Page 16] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + Case 2: Adding leaves with partial reoptimization of existing paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 1 + END-POINTS for leaf type 3 + RRO list + END-POINTS for leaf type 4 + RRO list + OF (optional) + + Case 3: Adding leaves without reoptimization of existing paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 1 + RRO list + END-POINTS for leaf type 4 + RRO list + OF (optional) + + Case 4: Pruning Leaves with full reoptimization of existing paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 2 + RRO list + END-POINTS for leaf type 3 + RRO list + OF (optional) + + Case 5: Pruning leaves with partial reoptimization of existing paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 2 + RRO list + END-POINTS for leaf type 3 + RRO list + END-POINTS for leaf type 4 + RRO list + OF (optional) + + + + + + + + + +Zhao, et al. Standards Track [Page 17] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + Case 6: Pruning leaves without reoptimization of existing paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 2 + RRO list + END-POINTS for leaf type 4 + RRO list + OF (optional) + + Case 7: Adding and pruning leaves with full reoptimization of + existing paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 1 + END-POINTS for leaf type 2 + RRO list + END-POINTS for leaf type 3 + RRO list + OF (optional) + + Case 8: Adding and pruning leaves with partial reoptimization of + existing paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 1 + END-POINTS for leaf type 2 + RRO list + END-POINTS for leaf type 3 + RRO list + END-POINTS for leaf type 4 + RRO list + OF (optional) + + Case 9: Adding and pruning leaves without reoptimization of existing + paths + + Common Header + RP with P2MP flag/R-bit set + END-POINTS for leaf type 1 + END-POINTS for leaf type 2 + RRO list + END-POINTS for leaf type 4 + RRO list + OF (optional) + + + + +Zhao, et al. Standards Track [Page 18] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +3.11. Discovering Branch Nodes + + Before computing the P2MP path, a PCE may need to be provided means + to know which nodes in the network are capable of acting as branch + LSRs. A PCE can discover such capabilities by using the mechanisms + defined in [RFC5073]. + +3.11.1. Branch Node Object + + The PCC can specify a list of nodes that can be used as branch nodes + or a list of nodes that cannot be used as branch nodes by using the + Branch Node Capability (BNC) Object. The BNC Object has the same + format as the Include Route Object (IRO) defined in [RFC5440], except + that it only supports IPv4 and IPv6 prefix sub-objects. Two Object- + types are also defined: + + o Branch node list: List of nodes that can be used as branch nodes. + + o Non-branch node list: List of nodes that cannot be used as branch + nodes. + + The object can only be carried in a PCReq message. A Path Request + may carry at most one Branch Node Object. + + The Object-Class and Object-types have been allocated by IANA. The + IANA assignment is documented in Section 6.5 ("PCEP Objects"). + +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 designated backup of + another P2MP LSP. In this case, path diversity for these dependent + LSPs may need to be considered during the path computation. + + The synchronization can be done by using the existing Synchronization + VECtor (SVEC) functionality defined in [RFC5440]. + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 19] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + An example of synchronizing two P2MP LSPs, each having two leaves for + Path Computation Request Messages, is illustrated below: + + Common Header + SVEC for sync of LSP1 and LSP2 + OF (optional) + END-POINTS1 for P2MP + RRO1 list + END-POINTS2 for P2MP + RRO2 list + + Figure 7. PCReq Message Example for Synchronization + + This specification also defines two new flags to the SVEC Object Flag + Field for P2MP 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. + + The following flags are added to the SVEC object body in this + document: + + o P (Partial Path Diverse bit - 1 bit): + + When set, this would indicate a request for path diversity for a + specific leaf, a set of leaves, or all leaves. + + o D (Link Direction Diverse bit - 1 bit): + + When set, this would indicate a request that a partial path or + paths should be link direction diverse. + + The IANA assignment is referenced in Section 6.8 of this document. + +3.13. Request and Response Fragmentation + + The total PCEP message length, including the common header, is + 16 bytes. In certain scenarios the P2MP computation request may not + fit into a single request or response message. For example, if a + tree has many hundreds or thousands of leaves, then the request or + response may need to be fragmented into multiple messages. + + + + + + + + +Zhao, et al. Standards Track [Page 20] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + The F-bit has been outlined in "The Extension of the RP Object" + (Section 3.3.1) of this document. The F-bit is used in the RP object + header to signal that the initial request or response was too large + to fit into a single message and will be fragmented into multiple + messages. In order to identify the single request or response, each + message will use the same request ID. + +3.13.1. Request Fragmentation Procedure + + If the initial request is too large to fit into a single request + message, the PCC will split the request over multiple messages. Each + message sent to the PCE, except the last one, will have the F-bit set + in the RP object to signify that the request has been fragmented into + multiple messages. In order to identify that a series of request + messages represents a single request, each message will use the same + request ID. + + The assumption is that request messages are reliably delivered and in + sequence, since PCEP relies on TCP. + +3.13.2. Response Fragmentation Procedure + + Once the PCE computes a path based on the initial request, a response + is sent back to the PCC. If the response is too large to fit into a + single response message, the PCE will split the response over + multiple messages. Each message sent to the PCE, except the last + one, will have the F-bit set in the RP object to signify that the + response has been fragmented into multiple messages. In order to + identify that a series of response messages represents a single + response, each message will use the same response ID. + + Again, the assumption is that response messages are reliably + delivered and in sequence, since PCEP relies on TCP. + +3.13.3. Fragmentation Examples + + The following example illustrates the PCC sending a request message + with Req-ID1 to the PCE, in order to add one leaf to an existing tree + with 1200 leaves. The assumption used for this example is that one + request message can hold up to 800 leaves. In this scenario, the + original single message needs to be fragmented and sent using two + smaller messages, which have the Req-ID1 specified in the RP object, + and with the F-bit set on the first message, and cleared on the + second message. + + + + + + + +Zhao, et al. Standards Track [Page 21] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + Common Header + RP1 with Req-ID1 and P2MP=1 and F-bit=1 + OF (optional) + END-POINTS1 for P2MP + RRO1 list + + Common Header + RP2 with Req-ID1 and P2MP=1 and F-bit=0 + OF (optional) + END-POINTS1 for P2MP + RRO1 list + + Figure 8. PCReq Message Fragmentation Example + + To handle a scenario where the last fragmented message piece is lost, + the receiver side of the fragmented message may start a timer once it + receives the first piece of the fragmented message. When the timer + expires and it has not received the last piece of the fragmented + message, it should send an error message to the sender to signal that + it has received an incomplete message. The relevant error message is + documented in Section 3.15 ("P2MP PCEP-ERROR Objects and Types"). + +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. + + The following UNREACH-DESTINATION objects will be required: + + UNREACH-DESTINATION Object-Class is 28. + UNREACH-DESTINATION Object-Type for IPv4 is 1. + UNREACH-DESTINATION Object-Type for IPv6 is 2. + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 22] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination IPv4 address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Destination IPv4 address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9. UNREACH-DESTINATION Object Body for IPv4 + + 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 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Destination IPv6 address (16 bytes) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + | Destination IPv6 address (16 bytes) | + | | + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10. UNREACH-DESTINATION Object Body for IPv6 + +3.15. P2MP PCEP-ERROR Objects and Types + + To indicate an error associated with policy violation, a new error + value "P2MP Path computation not allowed" should be added to the + existing error code for policy violation (Error-Type=5) as defined in + [RFC5440]: + + + + + + + + + +Zhao, et al. Standards Track [Page 23] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + Error-Type=5; Error-Value=7: if a PCE receives a P2MP path + computation request that is not compliant with administrative + privileges (i.e., "The PCE policy does not support P2MP path + computation"), the PCE MUST send a PCErr message with a PCEP-ERROR + object (Error-Type=5) and an Error-Value (Error-Value=7). The + corresponding P2MP path computation request MUST also be cancelled. + + To indicate capability 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: + + Error-Type=16; Error-Value=1: if a PCE receives a P2MP path request + and the PCE is not capable of satisfying 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 also 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 also be cancelled. + + To indicate P2MP message fragmentation errors associated with a P2MP + path request, a new Error-Type (17) and subsequent error-values are + defined as follows for inclusion in the PCEP-ERROR object: + + Error-Type=18; Error-Value=1: if a PCE has not received the last + piece of the fragmented message, it should send an error message to + the sender to signal that it has received an incomplete message + (i.e., "Fragmented request failure"). The PCE MUST send a PCErr + message with a PCEP-ERROR object (Error-Type=18) and an Error-Value + (Error-Value=1). + +3.16. PCEP NO-PATH Indicator + + To communicate the reasons for not being able to find P2MP path + computation, the NO-PATH object can be used in the PCRep message. + + One new bit is defined in the NO-PATH-VECTOR TLV carried in the + NO-PATH Object: + + bit 24: 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 destination or list of destinations that are + not reachable using the new UNREACH-DESTINATION object defined in + Section 3.14. + + + + +Zhao, et al. Standards Track [Page 24] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +4. Manageability Considerations + + [RFC5862] describes various manageability requirements in support of + P2MP path computation when applying PCEP. This section describes how + manageability requirements mentioned in [RFC5862] are supported in + the context of PCEP extensions specified in this document. + + Note that [RFC5440] describes various manageability considerations in + PCEP, and most of the manageability requirements mentioned in + [RFC5862] are already covered there. + +4.1. Control of Function and Policy + + In addition to PCE configuration parameters listed in [RFC5440], the + following additional parameters might be required: + + o The ability to enable or disable P2MP path computations on the + PCE. + + o The PCE may be configured to enable or disable the advertisement + of its P2MP path computation capability. A PCE can advertise its + P2MP capability via the IGP discovery mechanism discussed in + Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery + Protocol"), or during the Open Message Exchange discussed in + Section 3.1.2 ("Open Message Extension"). + +4.2. Information and Data Models + + A number of MIB objects have been defined for general PCEP control + and monitoring of P2P computations in [PCEP-MIB]. [RFC5862] + specifies that MIB objects will be required to support the control + and monitoring of the protocol extensions defined in this document. + A new document will be required to define MIB objects for PCEP + control and monitoring of P2MP computations. + +4.3. Liveness Detection and Monitoring + + There are no additional considerations beyond those expressed in + [RFC5440], since [RFC5862] does not address any additional + requirements. + +4.4. Verifying Correct Operation + + There are no additional requirements beyond those expressed in + [RFC4657] for verifying the correct operation of the PCEP sessions. + It is expected that future MIB objects will facilitate verification + of correct operation and reporting of P2MP PCEP requests, responses, + and errors. + + + +Zhao, et al. Standards Track [Page 25] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +4.5. Requirements for Other Protocols and Functional Components + + The method for the PCE to obtain information about a PCE capable of + P2MP path computations via OSPF and IS-IS is discussed in + Section 3.1.1 ("P2MP Computation TLV in the Existing PCE Discovery + Protocol") of this document. + + The subsequent IANA assignments are documented in Section 6.9 ("OSPF + PCE Capability Flag") of this document. + +4.6. Impact on Network Operation + + It is expected that the use of PCEP extensions specified in this + document will not significantly increase the level of operational + traffic. However, computing a P2MP tree may require more PCE state + compared to a P2P computation. In the event of a major network + failure and multiple recovery P2MP tree computation requests being + sent to the PCE, the load on the PCE may also be significantly + increased. + +5. Security Considerations + + As described in [RFC5862], P2MP path computation requests are more + CPU-intensive and also utilize more link bandwidth. In the event of + an unauthorized P2MP path computation request, or a denial of service + attack, the subsequent PCEP requests and processing may be disruptive + to the network. Consequently, it is important that implementations + conform to the relevant security requirements of [RFC5440] that + specifically help to minimize or negate unauthorized P2MP path + computation requests and denial of service attacks. These mechanisms + include: + + o Securing the PCEP session requests and responses using TCP + security techniques (Section 10.2 of [RFC5440]). + + o Authenticating the PCEP requests and responses to ensure the + message is intact and sent from an authorized node (Section 10.3 + of [RFC5440]). + + o Providing policy control by explicitly defining which PCCs, via IP + access-lists, are allowed to send P2MP path requests to the PCE + (Section 10.6 of [RFC5440]). + + PCEP operates over TCP, so it is also important to secure the PCE and + PCC against TCP denial of service attacks. Section 10.7.1 of + [RFC5440] outlines a number of mechanisms for minimizing the risk of + TCP based denial of service attacks against PCEs and PCCs. + + + + +Zhao, et al. Standards Track [Page 26] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + PCEP implementations SHOULD consider the additional security provided + by the TCP Authentication Option (TCP-AO) [RFC5925]. + +6. IANA Considerations + + IANA maintains a registry of PCEP parameters. A number of IANA + considerations have been highlighted in previous sections of this + document. IANA has made the following allocations. + +6.1. PCEP TLV Type Indicators + + As described in Section 3.1.2., the newly defined P2MP capability TLV + allows the PCE to advertise its P2MP path computation capability. + IANA has made the following allocation from the "PCEP TLV Type + Indicators" sub-registry. + + Value Description Reference + 6 P2MP capable RFC 6006 + +6.2. Request Parameter Bit Flags + + As described in Section 3.3.1, three new RP Object Flags have been + defined. IANA has made the following allocations from the PCEP "RP + Object Flag Field" sub-registry: + + Bit Description Reference + + 18 Fragmentation (F-bit) RFC 6006 + 19 P2MP (N-bit) RFC 6006 + 20 ERO-compression (E-bit) RFC 6006 + +6.3. Objective Functions + + As described in Section 3.6.1, two new Objective Functions have been + defined. IANA has made the following allocations from the PCEP + "Objective Function" sub-registry: + + Code Point Name Reference + + 7 SPT RFC 6006 + 8 MCT RFC 6006 + +6.4. Metric Object Types + + As described in Section 3.6.2, three new metric object T fields have + been defined. IANA has made the following allocations from the PCEP + "METRIC Object T Field" sub-registry: + + + + +Zhao, et al. Standards Track [Page 27] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + Value Description Reference + + 8 P2MP IGP metric RFC 6006 + 9 P2MP TE metric RFC 6006 + 10 P2MP hop count metric RFC 6006 + +6.5. PCEP Objects + + As discussed in Section 3.3.2, two new END-POINTS Object-Types are + defined. IANA has made the following Object-Type allocations from + the "PCEP Objects" sub-registry: + + Object-Class Value 4 + Name END-POINTS + Object-Type 3: IPv4 + 4: IPv6 + 5-15: Unassigned + Reference RFC 6006 + + As described in Section 3.2, Section 3.11.1, and Section 3.14, four + PCEP Object-Classes and six PCEP Object-Types have been defined. + IANA has made the following allocations from the "PCEP Objects" sub- + registry: + + Object-Class Value 28 + Name UNREACH-DESTINATION + Object-Type 1: IPv4 + 2: IPv6 + 3-15: Unassigned + Reference RFC 6006 + + Object-Class Value 29 + Name SERO + Object-Type 1: SERO + 2-15: Unassigned + Reference RFC 6006 + + Object-Class Value 30 + Name SRRO + Object-Type 1: SRRO + 2-15: Unassigned + Reference RFC 6006 + + + + + + + + + +Zhao, et al. Standards Track [Page 28] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + Object-Class Value 31 + Name Branch Node Capability Object + Object-Type 1: Branch node list + 2: Non-branch node list + 3-15: Unassigned + Reference RFC 6006 + +6.6. PCEP-ERROR Objects and Types + + As described in Section 3.15, a number of new PCEP-ERROR Object Error + Types and Values have been defined. IANA has made the following + allocations from the PCEP "PCEP-ERROR Object Error Types and Values" + sub-registry: + + Error + Type Meaning Reference + + 5 Policy violation + Error-value=7: RFC 6006 + P2MP Path computation is not allowed + + 16 P2MP Capability Error + Error-Value=0: Unassigned RFC 6006 + Error-Value=1: RFC 6006 + The PCE is not capable to satisfy the request + due to insufficient memory + Error-Value=2: RFC 6006 + The PCE is not capable of P2MP computation + + 17 P2MP END-POINTS Error + Error-Value=0: Unassigned RFC 6006 + Error-Value=1: RFC 6006 + The PCE is not capable to satisfy the request + due to no END-POINTS with leaf type 2 + Error-Value=2: RFC 6006 + The PCE is not capable to satisfy the request + due to no END-POINTS with leaf type 3 + Error-Value=3: RFC 6006 + The PCE is not capable to satisfy the request + due to no END-POINTS with leaf type 4 + Error-Value=4: RFC 6006 + The PCE is not capable to satisfy the request + due to inconsistent END-POINTS + + 18 P2MP Fragmentation Error + Error-Value=0: Unassigned RFC 6006 + Error-Value=1: RFC 6006 + Fragmented request failure + + + +Zhao, et al. Standards Track [Page 29] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +6.7. PCEP NO-PATH Indicator + + As discussed in Section 3.16, a new NO-PATH-VECTOR TLV Flag Field has + been defined. IANA has made the following allocation from the PCEP + "NO-PATH-VECTOR TLV Flag Field" sub-registry: + + Bit Description Reference + + 24 P2MP Reachability Problem RFC 6006 + +6.8. SVEC Object Flag + + As discussed in Section 3.12, two new SVEC Object Flags are defined. + IANA has made the following allocation from the PCEP "SVEC Object + Flag Field" sub-registry: + + Bit Description Reference + + 19 Partial Path Diverse RFC 6006 + 20 Link Direction Diverse RFC 6006 + +6.9. OSPF PCE Capability Flag + + As discussed in Section 3.1.1, a new OSPF Capability Flag is defined + to indicate P2MP path computation capability. IANA has made the + following assignment from the OSPF Parameters "Path Computation + Element (PCE) Capability Flags" registry: + + Bit Description Reference + + 10 P2MP path computation RFC 6006 + +7. Acknowledgements + + The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, + Autumn Liu, Huaimo Chen, Eiji Okim, Nick Neate, Suresh Babu K, Dhruv + Dhody, Udayasree Palle, Gaurav Agrawal, Vishwas Manral, Dan + Romascanu, Tim Polk, Stewart Bryant, David Harrington, and Sean + Turner for their valuable comments and input on this document. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + + + + +Zhao, et al. Standards Track [Page 30] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, December 2001. + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", + RFC 3473, January 2003. + + [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. + Farrel, "GMPLS Segment Recovery", RFC 4873, May 2007. + + [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. + Yasukawa, Ed., "Extensions to Resource Reservation + Protocol - Traffic Engineering (RSVP-TE) for Point-to- + Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May + 2007. + + [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., + and S. Shaffer, "Extensions to OSPF for Advertising + Optional Router Capabilities", RFC 4970, July 2007. + + [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing + Protocol Extensions for Discovery of Traffic Engineering + Node Capabilities", RFC 5073, December 2007. + + [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "OSPF Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5088, January 2008. + + [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. + Zhang, "IS-IS Protocol Extensions for Path Computation + Element (PCE) Discovery", RFC 5089, January 2008. + + [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax + Used to Form Encoding Rules in Various Routing Protocol + Specifications", RFC 5511, April 2009. + + [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path + Computation Element (PCE) Communication Protocol (PCEP)", + RFC 5440, March 2009. + + [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of + Objective Functions in the Path Computation Element + Communication Protocol (PCEP)", RFC 5541, June 2009. + + + + + + +Zhao, et al. Standards Track [Page 31] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +8.2. Informative References + + [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path + Computation Element (PCE)-Based Architecture", RFC 4655, + August 2006. + + [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol Generic + Requirements", RFC 4657, September 2006. + + [RFC5671] Yasukawa, S. and A. Farrel, Ed., "Applicability of the + Path Computation Element (PCE) to Point-to-Multipoint + (P2MP) MPLS and GMPLS Traffic Engineering (TE)", + RFC 5671, October 2009. + + [RFC5862] Yasukawa, S. and A. Farrel, "Path Computation Clients + (PCC) - Path Computation Element (PCE) Requirements for + Point-to-Multipoint MPLS-TE", RFC 5862, June 2010. + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, June 2010. + + [PCEP-MIB] Koushik, K., Stephan, E., Zhao, Q., and D. King, "PCE + communication protocol (PCEP) Management Information + Base", Work in Progress, July 2010. + +Contributors + + Jean-Louis Le Roux + France Telecom + 2, Avenue Pierre-Marzin + 22307 Lannion Cedex + France + EMail: jeanlouis.leroux@orange-ftgroup.com + + + Mohamad Chaitou + France + EMail: mohamad.chaitou@gmail.com + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 32] + +RFC 6006 Extensions to PCEP for P2MP TE LSPs September 2010 + + +Authors' Addresses + + Quintin Zhao (editor) + Huawei Technology + 125 Nagog Technology Park + Acton, MA 01719 + US + EMail: qzhao@huawei.com + + + Daniel King (editor) + Old Dog Consulting + UK + EMail: daniel@olddog.co.uk + + + Fabien Verhaeghe + Thales Communication France + 160 Bd Valmy 92700 Colombes + France + EMail: fabien.verhaeghe@gmail.com + + + Tomonori Takeda + NTT Corporation + 3-9-11, Midori-Cho + Musashino-Shi, Tokyo 180-8585 + Japan + EMail: takeda.tomonori@lab.ntt.co.jp + + + Zafar Ali + Cisco Systems, Inc. + 2000 Innovation Drive + Kanata, Ontario K2K 3E8 + Canada + EMail: zali@cisco.com + + + Julien Meuric + France Telecom + 2, Avenue Pierre-Marzin + 22307 Lannion Cedex + France + EMail: julien.meuric@orange-ftgroup.com + + + + + + +Zhao, et al. Standards Track [Page 33] + |