summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8306.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8306.txt')
-rw-r--r--doc/rfc/rfc8306.txt2411
1 files changed, 2411 insertions, 0 deletions
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:
+
+ <PCReq Message> ::= <Common Header>
+ [<svec-list>]
+ <request-list>
+
+ where:
+
+ <svec-list> ::= <SVEC>
+ [<OF>]
+ [<metric-list>]
+ [<svec-list>]
+
+ <request-list> ::= <request>[<request-list>]
+
+ <request> ::= <RP>
+ <end-point-rro-pair-list>
+ [<OF>]
+ [<LSPA>]
+ [<BANDWIDTH>]
+ [<metric-list>]
+ [<IRO>|<BNC>]
+ [<LOAD-BALANCING>]
+
+ where:
+
+ <end-point-rro-pair-list> ::=
+ <END-POINTS>[<RRO-List>[<BANDWIDTH>]]
+ [<end-point-rro-pair-list>]
+
+ <RRO-List> ::= (<RRO>|<SRRO>)[<RRO-List>]
+ <metric-list> ::= <METRIC>[<metric-list>]
+
+ Figure 3: The Message Format for the Request Message
+
+ Note that we preserve compatibility with the definition of <request>
+ provided in [RFC5440]. At least one instance of <END-POINTS> 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:
+
+ <PCRep Message> ::= <Common Header>
+ <response-list>
+
+ where:
+
+ <response-list> ::= <response>[<response-list>]
+
+ <response> ::= <RP>
+ [<end-point-path-pair-list>]
+ [<NO-PATH>]
+ [<UNREACH-DESTINATION>]
+ [<attribute-list>]
+
+ <end-point-path-pair-list> ::=
+ [<END-POINTS>]<path>
+ [<end-point-path-pair-list>]
+
+ <path> ::= (<ERO>|<SERO>) [<path>]
+
+ where:
+
+ <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.
+
+
+
+
+
+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 <response>
+ provided in [RFC5440] and with the optional
+ <end-point-path-pair-list> and <path>.
+
+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,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc3209>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc3473>.
+
+ [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
+ "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873,
+ May 2007, <https://www.rfc-editor.org/info/rfc4873>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc4875>.
+
+ [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, <https://www.rfc-editor.org/info/rfc5073>.
+
+ [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, <https://www.rfc-editor.org/info/rfc5088>.
+
+ [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, <https://www.rfc-editor.org/info/rfc5089>.
+
+
+
+
+
+
+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,
+ <https://www.rfc-editor.org/info/rfc5440>.
+
+ [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, <https://www.rfc-editor.org/info/rfc5511>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc5541>.
+
+ [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, <https://www.rfc-editor.org/info/rfc7770>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
+ RFC 2119 Key Words", BCP 14, RFC 8174,
+ DOI 10.17487/RFC8174, May 2017,
+ <https://www.rfc-editor.org/info/rfc8174>.
+
+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,
+ <https://www.rfc-editor.org/info/rfc4655>.
+
+ [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, <https://www.rfc-editor.org/info/rfc4657>.
+
+
+
+
+
+
+
+
+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,
+ <https://www.rfc-editor.org/info/rfc5671>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc5862>.
+
+ [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
+ Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
+ June 2010, <https://www.rfc-editor.org/info/rfc5925>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc6006>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc6952>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc7420>.
+
+ [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, <https://www.rfc-editor.org/info/rfc7525>.
+
+ [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,
+ <https://www.rfc-editor.org/info/rfc8253>.
+
+
+
+
+
+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 <svec-list> 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 <RRO-List> format to also allow the SRRO. This
+ object was missed in [RFC6006].
+
+ * Removed the BANDWIDTH object followed by the RRO from
+ <RRO-List>. The BANDWIDTH object was included twice in
+ RFC 6006 -- once as part of <end-point-path-pair-list> and also
+ as part of <RRO-List>. The latter has been removed, and the
+ RBNF is backward compatible with [RFC5440].
+
+ * Updated the <end-point-rro-pair-list> to allow an optional
+ BANDWIDTH object only if <RRO-List> 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]
+