From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8306.txt | 2411 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2411 insertions(+) create mode 100644 doc/rfc/rfc8306.txt (limited to 'doc/rfc/rfc8306.txt') diff --git a/doc/rfc/rfc8306.txt b/doc/rfc/rfc8306.txt new file mode 100644 index 0000000..dd8902e --- /dev/null +++ b/doc/rfc/rfc8306.txt @@ -0,0 +1,2411 @@ + + + + + + +Internet Engineering Task Force (IETF) Q. Zhao +Request for Comments: 8306 D. Dhody, Ed. +Obsoletes: 6006 R. Palleti +Category: Standards Track Huawei Technologies +ISSN: 2070-1721 D. King + Old Dog Consulting + November 2017 + + + 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. + + This document obsoletes RFC 6006. + +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 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8306. + + + + + + + + + + +Zhao, et al. Standards Track [Page 1] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +Copyright Notice + + Copyright (c) 2017 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 + (https://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 ....................................................4 + 1.1. Terminology ................................................5 + 1.2. Requirements Language ......................................5 + 2. PCC-PCE Communication Requirements ..............................5 + 3. Protocol Procedures and Extensions ..............................6 + 3.1. P2MP Capability Advertisement ..............................7 + 3.1.1. IGP Extensions for P2MP Capability Advertisement ....7 + 3.1.2. Open Message Extension ..............................7 + 3.2. Efficient Presentation of P2MP LSPs ........................8 + 3.3. P2MP Path Computation Request/Reply Message Extensions .....9 + 3.3.1. The Extension of the RP Object ......................9 + 3.3.2. The P2MP END-POINTS Object .........................11 + 3.4. Request Message Format ....................................13 + 3.5. Reply Message Format ......................................15 + + + + + + + + +Zhao, et al. Standards Track [Page 2] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 3.6. P2MP Objective Functions and Metric Types .................16 + 3.6.1. Objective Functions ................................16 + 3.6.2. METRIC Object-Type Values ..........................17 + 3.7. Non-Support of P2MP Path Computation ......................17 + 3.8. Non-Support by Back-Level PCE Implementations .............17 + 3.9. P2MP TE Path Reoptimization Request .......................17 + 3.10. Adding and Pruning Leaves to/from the P2MP Tree ..........18 + 3.11. Discovering Branch Nodes .................................22 + 3.11.1. Branch Node Object ................................22 + 3.12. Synchronization of P2MP TE Path Computation Requests .....22 + 3.13. Request and Response Fragmentation .......................23 + 3.13.1. Request Fragmentation Procedure ...................24 + 3.13.2. Response Fragmentation Procedure ..................24 + 3.13.3. Fragmentation Example .............................24 + 3.14. UNREACH-DESTINATION Object ...............................25 + 3.15. P2MP PCEP-ERROR Objects and Types ........................27 + 3.16. PCEP NO-PATH Indicator ...................................28 + 4. Manageability Considerations ...................................28 + 4.1. Control of Function and Policy ............................28 + 4.2. Information and Data Models ...............................28 + 4.3. Liveness Detection and Monitoring .........................29 + 4.4. Verifying Correct Operation ...............................29 + 4.5. Requirements for Other Protocols and Functional + Components ................................................29 + 4.6. Impact on Network Operation ...............................29 + 5. Security Considerations ........................................30 + 6. IANA Considerations ............................................31 + 6.1. PCEP TLV Type Indicators ..................................31 + 6.2. Request Parameter Bit Flags ...............................31 + 6.3. Objective Functions .......................................31 + 6.4. METRIC Object-Type Values .................................32 + 6.5. PCEP Objects ..............................................32 + 6.6. PCEP-ERROR Objects and Types ..............................34 + 6.7. PCEP NO-PATH Indicator ....................................35 + 6.8. SVEC Object Flag ..........................................35 + 6.9. OSPF PCE Capability Flag ..................................35 + 7. References .....................................................36 + 7.1. Normative References ......................................36 + 7.2. Informative References ....................................37 + Appendix A. Summary of Changes from RFC 6006 ......................39 + Appendix A.1. RBNF Changes from RFC 6006 ..........................39 + Acknowledgements ..................................................41 + Contributors ......................................................42 + Authors' Addresses ................................................43 + + + + + + + +Zhao, et al. Standards Track [Page 3] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +1. Introduction + + The Path Computation Element (PCE) as 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 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 subset of the S2L sub-LSPs. In the + extreme case, the PCC may request the S2L sub-LSPs to be computed + individually; the PCC is responsible for deciding 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. + + This document obsoletes [RFC6006] and incorporates the following + errata: + + o Erratum IDs 3819, 3830, 3836, 4867, and 4868 for [RFC6006] + + o Erratum ID 4956 for [RFC5440] + + All changes from [RFC6006] are listed in Appendix A. + + + +Zhao, et al. Standards Track [Page 4] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +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]. + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in + BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. PCC-PCE Communication Requirements + + This section summarizes the PCC-PCE communication requirements as met + by the protocol extension specified in this document for P2MP MPLS-TE + LSPs. The numbering system in the list below corresponds to the + requirement numbers (e.g., R1, R2) 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 + computation 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. + + + + +Zhao, et al. Standards Track [Page 5] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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. + + 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. + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 6] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +3.1. P2MP Capability Advertisement + +3.1.1. IGP Extensions for P2MP Capability Advertisement + + [RFC5088] defines a PCE Discovery (PCED) TLV carried in an OSPF + Router Information Link State Advertisement (LSA) as defined in + [RFC7770] to facilitate PCE discovery using OSPF. [RFC5088] + specifies that no new sub-TLVs may be added to the PCED TLV. This + document defines a 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 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 P2MP END-POINTS + Object") to further qualify the level of support. + +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 an optional TLV to indicate the PCE's capability to perform + P2MP path computations. + + IANA has allocated value 6 from the "PCEP TLV Type Indicators" + subregistry, 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. + + + + + +Zhao, et al. Standards Track [Page 7] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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 the 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 when 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 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 are defined in [RFC3209] and [RFC3473]. + + The Secondary Explicit Route Object (SERO) is used to specify the + explicit route of an 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 the format of an ERO as defined + in [RFC3209] and [RFC3473]. + + 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 class of the SRRO as 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]. + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 8] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + PCEP Object-Class and Object-Type values for the SERO and SRRO have + been assigned: + + Object-Class Value 29 + Name SERO + Object-Type 0: Reserved + 1: SERO + 2-15: Unassigned + Reference RFC 8306 + + Object-Class Value 30 + Name SRRO + Object-Type 0: Reserved + 1: SRRO + 2-15: Unassigned + Reference RFC 8306 + + The IANA assignments are 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 the 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 + (1) that the request and reply messages have been fragmented across + multiple messages, (2) that they have been requested for a P2MP path, + and (3) whether the route is represented in the compressed or + uncompressed format. + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 9] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + This document adds the following flags to the RP object: + + 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 Path Computation Request + (PCReq) or Path Computation Reply (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 assignments are documented in Section 6.2 ("Request + Parameter Bit Flags") of this document. + + + + + + + + + + + +Zhao, et al. Standards Track [Page 10] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +3.3.2. The 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 types of END-POINTS + objects for the P2MP path: + + o Old leaves whose path can be modified/reoptimized. + + o Old leaves whose path must be left unchanged. + + With the P2MP 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 four 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 P2MP 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 11] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + The format of the P2MP 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 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 P2MP END-POINTS Object Body Format for IPv6 + + + + + + + + +Zhao, et al. Standards Track [Page 12] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + The END-POINTS object body has a variable length. These are + + o multiples of 4 bytes for IPv4 + + o multiples of 16 bytes, plus 4 bytes, for IPv6 + +3.4. Request Message Format + + As per [RFC5440], a Path Computation Request message (also referred + to as a PCReq message) is a PCEP message sent by a PCC to a PCE to + request a path computation. A PCReq message may carry more than one + path computation request. + + As per [RFC5541], the OF object MAY be carried within a PCReq + message. If an objective function is to be applied to a set of + synchronized path computation requests, the OF object MUST be carried + just after the corresponding SVEC (Synchronization Vector) object and + MUST NOT be repeated for each elementary request. + + The PCReq message is encoded as follows using RBNF as defined in + [RFC5511]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 13] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + Below is the message format for the request message: + + ::= + [] + + + where: + + ::= + [] + [] + [] + + ::= [] + + ::= + + [] + [] + [] + [] + [|] + [] + + where: + + ::= + [[]] + [] + + ::= (|)[] + ::= [] + + Figure 3: The Message Format for the Request Message + + Note that we preserve compatibility with the definition of + provided in [RFC5440]. At least one instance of MUST be + present in this message. + + We have documented the IANA assignment of additional END-POINTS + Object-Type values in Section 6.5 ("PCEP Objects") of this document. + + + + + + + + + + +Zhao, et al. Standards Track [Page 14] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +3.5. Reply Message Format + + The PCEP Path Computation Reply message (also referred to as a + PCRep message) is a PCEP message sent by a PCE to a requesting PCC in + response to a previously received PCReq message. PCEP supports the + bundling of multiple replies to a set of path computation requests + within a single PCRep message. + + The PCRep message is encoded as follows using RBNF as defined in + [RFC5511]. + + Below is the message format for the reply message: + + ::= + + + where: + + ::= [] + + ::= + [] + [] + [] + [] + + ::= + [] + [] + + ::= (|) [] + + where: + + ::= [] + [] + [] + [] + [] + + 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. + + + + + +Zhao, et al. Standards Track [Page 15] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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 definition of + provided in [RFC5440] and with the optional + and . + +3.6. P2MP Objective Functions and Metric Types + +3.6.1. 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 objective function codes are + defined as follows: + + 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 (i.e., 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 objective functions is subject to the rules + defined in [RFC5541]. + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 16] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +3.6.2. METRIC Object-Type Values + + There are three types defined for the METRIC object in [RFC5440] -- + namely, the IGP metric, the TE metric, and Hop Counts. 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. The + following values for these metric types have been assigned; see + Section 6.4. + + 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 computation 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. The Error-Types and + Error-values have been assigned; see Section 6 ("IANA + Considerations") of this document. + + o If the PCE does not understand the P2MP flag in the RP object, + then the PCE would send a PCErr message with Error-Type=2 + (Capability not supported) as per [RFC5440]. + +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 PCC MUST insert the list of Record Route + Objects (RROs) and SRROs after each instance of the END-POINTS object + in the PCReq message, as described in Section 3.4 ("Request Message + Format") of this document. + + + + + + +Zhao, et al. Standards Track [Page 17] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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-POINTS object with leaf 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 + +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 is 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 PCC MUST build a P2MP request using END-POINTS + with leaf type 1. + + To remove old leaves, the PCC MUST build a P2MP request using + END-POINTS with leaf type 2. If no type-2 END-POINTS exist, then the + PCE MUST send Error-Type 17, Error-value 1: the PCE cannot satisfy + the request due to no END-POINTS with leaf type 2. + + + + + + +Zhao, et al. Standards Track [Page 18] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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. + Specific PCEP-ERROR objects and types are used 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-POINTS" error will be used if a + PCC receives a request that has an inconsistent END-POINTS setting + (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 PCC 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) + + 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) + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 19] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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) + + 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) + + + + + + + + + + +Zhao, et al. Standards Track [Page 20] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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 21] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +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) as defined in [RFC5440], + except that it only supports IPv4 and IPv6 prefix sub-objects. Two + Object-Type parameters 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 + computation request may carry at most one Branch Node object. + + The Object-Class and Object-Type values have been allocated by IANA. + The IANA assignments are 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 SVEC + functionality as defined in [RFC5440]. + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 22] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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) + RP for LSP1 + END-POINTS1 for LSP1 + RRO1 list + RP for LSP2 + END-POINTS2 for LSP2 + RRO2 list + + Figure 7: PCReq Message Example for Synchronization + + This specification also defines two flags for the SVEC Object Flag + Field for P2MP path-dependent computation requests. The first flag + allows 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 + allows 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 assignments are 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 23] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + The F-bit is outlined in Section 3.3.1 ("The Extension of the RP + Object") of this document. The F-bit is used in the RP object 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 by 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 Example + + 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 Req-ID1 specified in the RP object, and + with the F-bit set on the first message and the F-bit cleared on the + second message. + + + + + + + +Zhao, et al. Standards Track [Page 24] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + 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. If the timer + expires and it still 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. + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 25] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + The following UNREACH-DESTINATION objects (for IPv4 and IPv6) are + defined: + + UNREACH-DESTINATION Object-Class is 28. + UNREACH-DESTINATION Object-Type for IPv4 is 1. + UNREACH-DESTINATION Object-Type for IPv6 is 2. + + 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 + + + + + + + + + +Zhao, et al. Standards Track [Page 26] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +3.15. P2MP PCEP-ERROR Objects and Types + + To indicate an error associated with a policy violation, the + Error-value "P2MP Path computation is not allowed" has been added to + the existing error code for Error-Type 5 ("Policy violation") as + defined in [RFC5440] (see also Section 6.6 of this document): + + 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 of 7. The corresponding + P2MP path computation request MUST also be cancelled. + + To indicate capability errors associated with the P2MP path + computation request, 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 + computation 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 of 1. The corresponding P2MP path computation request + MUST also be cancelled. + + Error-Type=16; Error-value=2: if a PCE receives a P2MP path + computation 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 of 2. The corresponding + P2MP path computation request MUST also be cancelled. + + To indicate P2MP message fragmentation errors associated with a P2MP + path computation request, Error-Type (18) 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 of 1. + + + + + + + + + + +Zhao, et al. Standards Track [Page 27] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +3.16. PCEP NO-PATH Indicator + + To communicate the reasons for not being able to find a P2MP path + computation, the NO-PATH object can be used in the PCRep message. + + One 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 UNREACH-DESTINATION + object defined in Section 3.14. + +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 + for 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 PCE may be configured to enable or disable P2MP path + computations. + + 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 ("IGP Extensions for P2MP Capability Advertisement") + 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 in [RFC7420] for general + PCEP control and monitoring of P2P computations. [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. + + + +Zhao, et al. Standards Track [Page 28] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + The "ietf-pcep" PCEP YANG module is specified in [PCEP-YANG]. The + P2MP capability of a PCEP entity or a configured peer can be set + using this YANG module. Also, support for P2MP path computation can + be learned using this module. The statistics are maintained in the + "ietf-pcep-stats" YANG module as specified in [PCEP-YANG]. This YANG + module will be required to be augmented to also include the + P2MP-related statistics. + +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. + +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 ("IGP Extensions for P2MP Capability Advertisement") of + this document. + + The relevant IANA assignment is 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. + + + + + + + + + + +Zhao, et al. Standards Track [Page 29] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +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 that specifically help + to minimize or negate unauthorized P2MP path computation requests and + denial-of-service attacks. These mechanisms include the following: + + o Securing the PCEP session requests and responses is RECOMMENDED + using TCP security techniques such as the TCP Authentication + Option (TCP-AO) [RFC5925] or using Transport Layer Security (TLS) + [RFC8253], as per the recommendations and best current practices + in [RFC7525]. + + o Authenticating the PCEP requests and responses to ensure that the + message is intact and sent from an authorized node using the + TCP-AO or TLS is RECOMMENDED. + + o Policy control could be provided by explicitly defining which PCCs + are allowed to send P2MP path computation requests to the PCE via + IP access lists. + + PCEP operates over TCP, so it is also important to secure the PCE and + PCC against TCP denial-of-service attacks. + + As stated in [RFC6952], PCEP implementations SHOULD support the + TCP-AO [RFC5925] and not use TCP MD5 because of TCP MD5's known + vulnerabilities and weakness. + + + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 30] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +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 made the allocations as per [RFC6006]. + +6.1. PCEP TLV Type Indicators + + As described in Section 3.1.2, the P2MP capability TLV allows the PCE + to advertise its P2MP path computation capability. + + IANA had previously made an allocation from the "PCEP TLV Type + Indicators" subregistry, where RFC 6006 was the reference. IANA has + updated the reference as follows to point to this document. + + Value Description Reference + + 6 P2MP capable RFC 8306 + +6.2. Request Parameter Bit Flags + + As described in Section 3.3.1, three RP Object Flags have been + defined. + + IANA had previously made allocations from the PCEP "RP Object Flag + Field" subregistry, where RFC 6006 was the reference. IANA has + updated the reference as follows to point to this document. + + Bit Description Reference + + 18 Fragmentation (F-bit) RFC 8306 + 19 P2MP (N-bit) RFC 8306 + 20 ERO-compression (E-bit) RFC 8306 + +6.3. Objective Functions + + As described in Section 3.6.1, this document defines two objective + functions. + + IANA had previously made allocations from the PCEP "Objective + Function" subregistry, where RFC 6006 was the reference. IANA has + updated the reference as follows to point to this document. + + Code Point Name Reference + + 7 SPT RFC 8306 + 8 MCT RFC 8306 + + + + +Zhao, et al. Standards Track [Page 31] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +6.4. METRIC Object-Type Values + + As described in Section 3.6.2, three METRIC object T fields have been + defined. + + IANA had previously made allocations from the PCEP "METRIC Object + T Field" subregistry, where RFC 6006 was the reference. IANA has + updated the reference as follows to point to this document. + + Value Description Reference + + 8 P2MP IGP metric RFC 8306 + 9 P2MP TE metric RFC 8306 + 10 P2MP hop count metric RFC 8306 + +6.5. PCEP Objects + + As discussed in Section 3.3.2, two END-POINTS Object-Type values are + defined. + + IANA had previously made the Object-Type allocations from the "PCEP + Objects" subregistry, where RFC 6006 was the reference. IANA has + updated the reference as follows to point to this document. + + Object-Class Value 4 + Name END-POINTS + Object-Type 3: IPv4 + 4: IPv6 + 5-15: Unassigned + Reference RFC 8306 + + As described in Sections 3.2, 3.11.1, and 3.14, four PCEP + Object-Class values and six PCEP Object-Type values have been + defined. + + IANA had previously made allocations from the "PCEP Objects" + subregistry, where RFC 6006 was the reference. IANA has updated the + reference to point to this document. + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 32] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + Also, for the following four PCEP objects, codepoint 0 for the + Object-Type field is marked "Reserved", as per Erratum ID 4956 for + RFC 5440. IANA has updated the reference to point to this document. + + Object-Class Value 28 + Name UNREACH-DESTINATION + Object-Type 0: Reserved + 1: IPv4 + 2: IPv6 + 3-15: Unassigned + Reference RFC 8306 + + Object-Class Value 29 + Name SERO + Object-Type 0: Reserved + 1: SERO + 2-15: Unassigned + Reference RFC 8306 + + Object-Class Value 30 + Name SRRO + Object-Type 0: Reserved + 1: SRRO + 2-15: Unassigned + Reference RFC 8306 + + Object-Class Value 31 + Name BNC + Object-Type 0: Reserved + 1: Branch node list + 2: Non-branch node list + 3-15: Unassigned + Reference RFC 8306 + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 33] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +6.6. PCEP-ERROR Objects and Types + + As described in Section 3.15, a number of PCEP-ERROR Object + Error-Types and Error-values have been defined. + + IANA had previously made allocations from the PCEP "PCEP-ERROR Object + Error Types and Values" subregistry, where RFC 6006 was the + reference. IANA has updated the reference as follows to point to + this document. + + Error + Type Meaning Reference + + 5 Policy violation + Error-value=7: RFC 8306 + P2MP Path computation is not allowed + + 16 P2MP Capability Error + Error-value=0: Unassigned RFC 8306 + Error-value=1: RFC 8306 + The PCE cannot satisfy the request + due to insufficient memory + Error-value=2: RFC 8306 + The PCE is not capable of P2MP computation + + 17 P2MP END-POINTS Error + Error-value=0: Unassigned RFC 8306 + Error-value=1: RFC 8306 + The PCE cannot satisfy the request + due to no END-POINTS with leaf type 2 + Error-value=2: RFC 8306 + The PCE cannot satisfy the request + due to no END-POINTS with leaf type 3 + Error-value=3: RFC 8306 + The PCE cannot satisfy the request + due to no END-POINTS with leaf type 4 + Error-value=4: RFC 8306 + The PCE cannot satisfy the request + due to inconsistent END-POINTS + + 18 P2MP Fragmentation Error + Error-value=0: Unassigned RFC 8306 + Error-value=1: RFC 8306 + Fragmented request failure + + + + + + + +Zhao, et al. Standards Track [Page 34] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +6.7. PCEP NO-PATH Indicator + + As discussed in Section 3.16, the NO-PATH-VECTOR TLV Flag Field has + been defined. + + IANA had previously made an allocation from the PCEP "NO-PATH-VECTOR + TLV Flag Field" subregistry, where RFC 6006 was the reference. IANA + has updated the reference as follows to point to this document. + + Bit Description Reference + + 24 P2MP Reachability Problem RFC 8306 + +6.8. SVEC Object Flag + + As discussed in Section 3.12, two SVEC Object Flags are defined. + + IANA had previously made allocations from the PCEP "SVEC Object Flag + Field" subregistry, where RFC 6006 was the reference. IANA has + updated the reference as follows to point to this document. + + Bit Description Reference + + 19 Partial Path Diverse RFC 8306 + 20 Link Direction Diverse RFC 8306 + +6.9. OSPF PCE Capability Flag + + As discussed in Section 3.1.1, the OSPF Capability Flag is defined to + indicate P2MP path computation capability. + + IANA had previously made an assignment from the OSPF Parameters "Path + Computation Element (PCE) Capability Flags" registry, where RFC 6006 + was the reference. IANA has updated the reference as follows to + point to this document. + + Bit Description Reference + + 10 P2MP path computation RFC 8306 + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 35] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., + and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP + Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, + . + + [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label + Switching (GMPLS) Signaling Resource ReserVation + Protocol-Traffic Engineering (RSVP-TE) Extensions", + RFC 3473, DOI 10.17487/RFC3473, January 2003, + . + + [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, + "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, + 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, DOI 10.17487/RFC4875, May 2007, + . + + [RFC5073] Vasseur, J., Ed., and J. Le Roux, Ed., "IGP Routing + Protocol Extensions for Discovery of Traffic Engineering + Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, + 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, DOI 10.17487/RFC5088, + 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, DOI 10.17487/RFC5089, + January 2008, . + + + + + + +Zhao, et al. Standards Track [Page 36] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol (PCEP)", RFC 5440, + DOI 10.17487/RFC5440, March 2009, + . + + [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax + Used to Form Encoding Rules in Various Routing Protocol + Specifications", RFC 5511, DOI 10.17487/RFC5511, + April 2009, . + + [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of + Objective Functions in the Path Computation Element + Communication Protocol (PCEP)", RFC 5541, + DOI 10.17487/RFC5541, June 2009, + . + + [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and + S. Shaffer, "Extensions to OSPF for Advertising Optional + Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, + February 2016, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in + RFC 2119 Key Words", BCP 14, RFC 8174, + DOI 10.17487/RFC8174, May 2017, + . + +7.2. Informative References + + [PCEP-YANG] + Dhody, D., Ed., Hardwick, J., Beeram, V., and J. Tantsura, + "A YANG Data Model for Path Computation Element + Communications Protocol (PCEP)", Work in Progress, + draft-ietf-pce-pcep-yang-05, July 2017. + + [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path + Computation Element (PCE)-Based Architecture", RFC 4655, + DOI 10.17487/RFC4655, August 2006, + . + + [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation + Element (PCE) Communication Protocol Generic + Requirements", RFC 4657, DOI 10.17487/RFC4657, + September 2006, . + + + + + + + + +Zhao, et al. Standards Track [Page 37] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + [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, + DOI 10.17487/RFC5671, 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, + DOI 10.17487/RFC5862, June 2010, + . + + [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP + Authentication Option", RFC 5925, DOI 10.17487/RFC5925, + June 2010, . + + [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., + Ali, Z., and J. Meuric, "Extensions to the Path + Computation Element Communication Protocol (PCEP) for + Point-to-Multipoint Traffic Engineering Label Switched + Paths", RFC 6006, DOI 10.17487/RFC6006, September 2010, + . + + [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of + BGP, LDP, PCEP, and MSDP Issues According to the Keying + and Authentication for Routing Protocols (KARP) Design + Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, + . + + [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. + Hardwick, "Path Computation Element Communication Protocol + (PCEP) Management Information Base (MIB) Module", + RFC 7420, DOI 10.17487/RFC7420, December 2014, + . + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, + May 2015, . + + [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, + "PCEPS: Usage of TLS to Provide a Secure Transport for the + Path Computation Element Communication Protocol (PCEP)", + RFC 8253, DOI 10.17487/RFC8253, October 2017, + . + + + + + +Zhao, et al. Standards Track [Page 38] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +Appendix A. Summary of Changes from RFC 6006 + + o Updated the text to use the term "PCC" instead of "user" while + describing the encoding rules in Section 3.10. + + o Updated the example in Figure 7 to explicitly include the + RP object. + + o Corrected the description of the F-bit in the RP object in + Section 3.13, as per Erratum ID 3836. + + o Corrected the description of the fragmentation procedure for the + response in Section 3.13.2, as per Erratum ID 3819. + + o Corrected the Error-Type for fragmentation in Section 3.15, as per + Erratum ID 3830. + + o Updated the references for the OSPF Router Information Link State + Advertisement (LSA) [RFC7770] and the PCEP MIB [RFC7420]. + + o Added current information and references for PCEP YANG [PCEP-YANG] + and PCEPS [RFC8253]. + + o Updated the Security Considerations section to include the TCP-AO + and TLS. + + o Updated the IANA Considerations section (Section 6.5) to mark + codepoint 0 as "Reserved" for the Object-Type defined in this + document, as per Erratum ID 4956 for [RFC5440]. IANA references + have also been updated to point to this document. + +Appendix A.1. RBNF Changes from RFC 6006 + + o Updates to the RBNF for the request message format, per + Erratum ID 4867: + + * Updated the request message to allow for the bundling of + multiple path computation requests within a single PCReq + message. + + * Added in PCReq messages. This object was missed in + [RFC6006]. + + * Added the BNC object in PCReq messages. This object is + required to support P2MP. The BNC object shares the same + format as the IRO, but it only supports IPv4 and IPv6 prefix + sub-objects. + + + + +Zhao, et al. Standards Track [Page 39] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + + * Updated the format to also allow the SRRO. This + object was missed in [RFC6006]. + + * Removed the BANDWIDTH object followed by the RRO from + . The BANDWIDTH object was included twice in + RFC 6006 -- once as part of and also + as part of . The latter has been removed, and the + RBNF is backward compatible with [RFC5440]. + + * Updated the to allow an optional + BANDWIDTH object only if is included. + + o Updates to the RBNF for the reply message format, per + Erratum ID 4868: + + * Updated the reply message to allow for bundling of multiple + path computation replies within a single PCRep message. + + * Added the UNREACH-DESTINATION object in PCRep messages. This + object was missed in [RFC6006]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 40] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +Acknowledgements + + The authors would like to thank Adrian Farrel, Young Lee, Dan Tappan, + Autumn Liu, Huaimo Chen, Eiji Oki, Nic Neate, Suresh Babu K, Gaurav + Agrawal, Vishwas Manral, Dan Romascanu, Tim Polk, Stewart Bryant, + David Harrington, and Sean Turner for their valuable comments and + input on this document. + + Thanks to Deborah Brungard for handling related errata for RFC 6006. + + The authors would like to thank Jonathan Hardwick and Adrian Farrel + for providing review comments with suggested text for this document. + + Thanks to Jonathan Hardwick for being the document shepherd and for + providing comments and guidance. + + Thanks to Ben Niven-Jenkins for RTGDIR reviews. + + Thanks to Roni Even for GENART reviews. + + Thanks to Fred Baker for the OPSDIR review. + + Thanks to Deborah Brungard for being the responsible AD and guiding + the authors. + + Thanks to Mirja Kuehlewind, Alvaro Retana, Ben Campbell, Adam Roach, + Benoit Claise, Suresh Krishnan, and Eric Rescorla for their IESG + review and comments. + + + + + + + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 41] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +Contributors + + Fabien Verhaeghe + Thales Communication France + 160 boulevard 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: tomonori.takeda@ntt.com + + Zafar Ali + Cisco Systems, Inc. + 2000 Innovation Drive + Kanata, Ontario K2K 3E8 + Canada + Email: zali@cisco.com + + Julien Meuric + Orange + 2, Avenue Pierre Marzin + 22307 Lannion Cedex + France + Email: julien.meuric@orange.com + + Jean-Louis Le Roux + Orange + 2, Avenue Pierre Marzin + 22307 Lannion Cedex + France + Email: jeanlouis.leroux@orange.com + + Mohamad Chaitou + France + Email: mohamad.chaitou@gmail.com + + Udayasree Palle + Huawei Technologies + Divyashree Techno Park, Whitefield + Bangalore, Karnataka 560066 + India + Email: udayasreereddy@gmail.com + + + + +Zhao, et al. Standards Track [Page 42] + +RFC 8306 Extensions to PCEP for P2MP TE LSPs November 2017 + + +Authors' Addresses + + Quintin Zhao + Huawei Technologies + 125 Nagog Technology Park + Acton, MA 01719 + United States of America + + Email: quintin.zhao@huawei.com + + + Dhruv Dhody (editor) + Huawei Technologies + Divyashree Techno Park, Whitefield + Bangalore, Karnataka 560066 + India + + Email: dhruv.ietf@gmail.com + + + Ramanjaneya Reddy Palleti + Huawei Technologies + Divyashree Techno Park, Whitefield + Bangalore, Karnataka 560066 + India + + Email: ramanjaneya.palleti@huawei.com + + + Daniel King + Old Dog Consulting + United Kingdom + + Email: daniel@olddog.co.uk + + + + + + + + + + + + + + + + + +Zhao, et al. Standards Track [Page 43] + -- cgit v1.2.3