Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
obsoletes
- rfc-6006 — Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
updated by
- rfc-9353 — IGP Extension for Path Computation Element Communication Protocol (PCEP) Security Capability Support in PCE Discovery (PCED)
Extracted elements (27)
A P2MP LSP is modeled as a set of source-to-leaf (S2L) sub-LSPs. The protocol deliberately allows a PCC to request computation of the entire P2MP tree in one message or split the request across multiple messages per sub-LSP, giving the PCC flexibility to decide whether to signal individual S2L sub-LSPs or combine results into a full P2MP LSP signal.
RFC 8306 obsoletes RFC 6006 and incorporates errata IDs 3819, 3830, 3836, 4867, and 4868 against RFC 6006 (fixing fragmentation description, error-type for fragmentation, F-bit description, and RBNF for request/reply messages) plus errata ID 4956 for RFC 5440 (marking Object-Type 0 as Reserved in four PCEP Object-Class definitions).
A single P2MP path computation request MUST NOT specify different constraints, traffic parameters, or QoS requirements for different destinations of the same P2MP LSP; constraints apply uniformly across all leaves.
By default, the path returned by the PCE SHOULD use the compressed format; the E-bit in the RP object signals whether the route is in compressed (E=1) or uncompressed (E=0) format.
For a P2MP reoptimization request, the PCC MUST set the R-bit in the RP object and MUST insert the list of RROs and SRROs immediately after each END-POINTS object in the PCReq message.
If a PCE understands the P2MP N-bit but cannot perform P2MP computation, it MUST send a PCErr with Error-Type=16, Error-value=2, and the request MUST be cancelled at the PCC. If the PCE does not understand the N-bit at all, it sends Error-Type=2 (Capability not supported) per RFC 5440.
To add new leaves the PCC MUST use END-POINTS with leaf type 1; to remove leaves it MUST use leaf type 2. When adding or removing leaves, the PCC MUST also provide old leaves as END-POINTS with leaf type 3, 4, or both, and MUST supply the old path as RROs following each END-POINTS object.
When a P2MP request or response exceeds the PCEP message size limit, it MUST be split across multiple messages all carrying the same request ID; every fragment except the last MUST set the F-bit in the RP object. If the last fragment is not received, the PCE MUST send PCErr Error-Type=18, Error-value=1 (Fragmented request failure).
Bit 10 is defined in the OSPF PCE Capability Flags sub-TLV (shared with IS-IS) to indicate P2MP computation capability. PCEs supporting P2MP set the bit; PCEs that do not support P2MP leave it clear; PCCs that do not understand the bit ignore it.
Bit 24 of the NO-PATH-VECTOR TLV (carried in the NO-PATH object) is defined as 'P2MP Reachability Problem'; when set it indicates that all or a subset of P2MP destinations are unreachable. The PCE may optionally enumerate unreachable destinations in an UNREACH-DESTINATION object.
P2MP PCEP-ERROR types: Error-Type 16 covers P2MP capability errors (value 1: insufficient memory; value 2: incapable of P2MP); Error-Type 17 covers END-POINTS errors (values 1-4: missing leaf type 2/3/4 or inconsistent END-POINTS); Error-Type 18 covers fragmentation errors (value 1: fragmented request failure); Error-Type 5, value 7: P2MP computation policy violation.
SERO (Secondary Explicit Route Object, Object-Class 29, Object-Type 1) encodes the explicit route of an individual S2L sub-LSP using the same format as the ERO. SRRO (Secondary Record Route Object, Object-Class 30, Object-Type 1) records the actual route of an S2L sub-LSP and is used when reporting an existing P2MP LSP for reoptimization.
The Branch Node Capability (BNC) object (Object-Class 31) uses the same format as the IRO but supports only IPv4 and IPv6 prefix sub-objects. Object-Type 1 specifies a list of allowed branch nodes; Object-Type 2 specifies a list of disallowed branch nodes. At most one BNC object may appear per path computation request.
The P2MP END-POINTS object defines four leaf types: 1 (new leaves to add), 2 (old leaves to remove), 3 (old leaves whose path may be modified/reoptimized), 4 (old leaves whose path must remain unchanged). A single END-POINTS object carries only one leaf type; multiple END-POINTS objects per RP are allowed to mix types.
The PCEP OPEN object is extended with an optional P2MP-capable TLV (type 6, length 2 bytes, default value 0) to let a PCE advertise P2MP path computation capability during session establishment. A PCE behaving as a PCC in inter-domain cooperation SHOULD also include this TLV.
Three new METRIC object T-field values are defined for P2MP: P2MP IGP metric (T=8), P2MP TE metric (T=9), and P2MP hop count metric (T=10), each encoding the sum of the respective metric across all links of the P2MP tree.
Two new P2MP objective functions are defined: SPT (Shortest-Path Tree, code 7) minimizes the maximum source-to-leaf cost, and MCT (Minimum-Cost Tree, code 8) minimizes the total cost of all tree links; processing is subject to the rules in RFC 5541.
Two new SVEC Object Flag Field bits are defined: P-bit (bit 19, Partial Path Diverse) requests path diversity for specific leaves or all leaves of a P2MP tree; D-bit (bit 20, Link Direction Diverse) requests that partial paths be link direction diverse.
This document updates nine IANA PCEP registries (originally allocated by RFC 6006): PCEP TLV Type Indicators (value 6, P2MP capable), RP Object Flag Field (bits 18-20), Objective Function codes (7 SPT, 8 MCT), METRIC Object T Field (8-10), PCEP Objects (END-POINTS types 3-4; Object-Classes 28 UNREACH-DESTINATION, 29 SERO, 30 SRRO, 31 BNC), PCEP-ERROR types (5/7, 16, 17, 18), NO-PATH-VECTOR TLV Flag Field (bit 24), SVEC Object Flag Field (bits 19-20), and OSPF PCE Capability Flags (bit 10).
P2MP path computation requests are more CPU-intensive and consume more link bandwidth than P2P requests. Unauthorized requests or DoS attacks can be disruptive; securing and authenticating PCEP sessions using TCP-AO (RFC 5925) or TLS (RFC 8253) is RECOMMENDED, and implementations SHOULD support TCP-AO rather than TCP MD5 due to TCP MD5's known vulnerabilities.
Policy control for P2MP path computation requests may be enforced via IP access lists that explicitly define which PCCs are permitted to send P2MP requests to the PCE. PCEP operates over TCP, so PCE and PCC implementations must also be protected against TCP-level denial-of-service attacks.
P2MP END-POINTS Object for IPv4 (Object-Class 4, Object-Type 3): 4-byte Leaf type field, one 4-byte source IPv4 address, followed by one or more 4-byte destination IPv4 addresses; total body length is a multiple of 4 bytes.
P2MP END-POINTS Object for IPv6 (Object-Class 4, Object-Type 4): 4-byte Leaf type field, one 16-byte source IPv6 address, followed by one or more 16-byte destination IPv6 addresses; total body length is a multiple of 16 bytes plus 4 bytes.
The P2MP PCRep message RBNF extends the base reply with an optional <end-point-path-pair-list> where each path is an ERO or SERO; an optional UNREACH-DESTINATION object may also appear per response. If the E-bit was set in the request, the path is formed by an ERO followed by a list of SEROs.
The P2MP PCReq message RBNF requires at least one END-POINTS object per request; it extends the base format with <end-point-rro-pair-list> (END-POINTS optionally followed by RRO/SRRO list and BANDWIDTH) and replaces IRO with IRO|BNC for P2MP branch-node constraints.
Three new 1-bit flags are added to the RP object: F-bit (bit 18) signals message fragmentation; N-bit (bit 19) signals a P2MP PCReq or PCRep; E-bit (bit 20) signals ERO-compressed format. All three share the existing RP object flag field.
UNREACH-DESTINATION Object (Object-Class 28): Object-Type 1 for IPv4 carries a variable-length list of 4-byte destination IPv4 addresses; Object-Type 2 for IPv6 carries a list of 16-byte destination IPv6 addresses. At most one such object per RP may appear in a PCRep message.