Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
obsoleted by
- rfc-8306 — Extensions to the Path Computation Element Communication Protocol (PCEP) for Point-to-Multipoint Traffic Engineering Label Switched Paths
Extracted elements (30)
Fragmentation relies on TCP's reliable, in-order delivery so no sequence numbering beyond the shared request ID is needed. A receiver may start a timer upon receiving the first fragment and send an error (Error-Type=18, Error-Value=1) if the final fragment does not arrive before expiry.
The new P2MP END-POINTS object groups multiple destinations of the same leaf type under a single source address, reducing END-POINTS overhead by up to 50% for large P2MP trees compared to individual per-destination END-POINTS objects.
If a PCE does not understand the P2MP N-bit in the RP object (back-level implementation), it MUST send a PCErr with Error-Value=2 (capability not supported) and SHOULD reject the request. The request message format preserves backward compatibility with RFC 5440.
A PCC MUST be able to specify that the request is a P2MP path computation request, and a PCE MUST have the capability to reject a P2MP path request and indicate non-support of P2MP path computation.
By default, the path returned by the PCE SHOULD use the compressed format (E-bit = 1 in RP object). A single P2MP path computation request or response MUST be able to be conveyed by a sequence of messages.
For P2MP path reoptimization, the user MUST insert the list of RROs and SRROs after each END-POINTS object (using the R-bit in the RP object). END-POINTS type 3 is used for leaves whose path can be modified.
If a P2MP path computation request violates PCE policy, the PCE MUST send a PCErr with Error-Type=5, Error-Value=7 ('P2MP Path computation not allowed'), and the corresponding request MUST be cancelled.
If a PCE understands the P2MP flag but is not capable of P2MP computation, it MUST send a PCErr message with Error-Type=16, Error-Value=2, and the corresponding request MUST be cancelled at the PCC.
If the PCE cannot satisfy a P2MP request due to insufficient memory, it MUST send a PCErr with Error-Type=16, Error-Value=1 and cancel the request. Error-Type=16 covers all P2MP capability errors.
It MUST NOT be possible for a single P2MP path computation request to specify different constraints, traffic parameters, or QoS requirements for different destinations of a P2MP LSP.
When a P2MP request or response must be fragmented across multiple messages, each message except the last MUST have the F-bit set in the RP object. All fragments of a single request/response MUST use the same request ID.
When removing old leaves, END-POINTS with leaf type 2 must be present; if no type-2 END-POINTS exist in a pruning request, the PCE MUST send Error-Type=17, Error-Value=1. Old leaves must be provided as RRO lists following their END-POINTS objects.
A new optional TLV (type 6, length 2 bytes, value 0) is defined for the PCEP OPEN object to indicate the PCE's capability to perform P2MP path computations. Its inclusion indicates the sender can perform P2MP computations.
Bit 24 of the NO-PATH-VECTOR TLV is defined to indicate a P2MP reachability problem. When set, the PCE optionally specifies the unreachable destinations using the UNREACH-DESTINATION object.
Four leaf types are defined for the P2MP END-POINTS object: type 1 (new leaves to add), type 2 (old leaves to remove), type 3 (old leaves whose path can be modified/reoptimized), and type 4 (old leaves whose path must remain unchanged).
P2MP capability is advertised via a new flag (bit 10) in the OSPF PCE Capability Flags sub-TLV defined in RFC 5088, shared with IS-IS PCE discovery. PCEs supporting P2MP computation set this bit; PCCs that do not understand it ignore it.
The Branch Node Capability (BNC) Object (Object-Class 31) has the same format as the IRO (RFC 5440), supports only IPv4/IPv6 prefix sub-objects, and has two types: branch node list (type 1) and non-branch node list (type 2). At most one BNC object per PCReq.
The Secondary Explicit Route Object (SERO, Object-Class 29, Object-Type 1) encodes the explicit route of each S2L sub-LSP of a P2MP TE LSP, using the same format as the ERO defined in RFC 3209 and RFC 3473.
The Secondary Record Route Object (SRRO, Object-Class 30, Object-Type 1) records the explicit route of an S2L sub-LSP, using the same class as the SRRO defined in RFC 4873. SERO and SRRO are used for reoptimization reporting.
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 encodes the sum of the metrics of all links of the P2MP tree.
Two new flags are added to the SVEC object for P2MP diversity: P-bit (bit 19, Partial Path Diverse) requests path diversity for specific leaves or S2L sub-paths; D-bit (bit 20, Link Direction Diverse) requests link direction diversity for partial paths.
Two new P2MP objective functions are defined: SPT (Shortest Path Tree, code 7) minimizes the maximum source-to-leaf cost; MCT (Minimum Cost Tree, code 8) minimizes the total sum of tree link costs. Both apply the rules of RFC 5541.
IANA allocations from multiple PCEP sub-registries: TLV type 6 (P2MP capable); RP Object Flag bits 18-20 (F, N, E); Objective Function codes 7 (SPT) and 8 (MCT); METRIC Object T-field values 8-10 (P2MP IGP, TE, hop count); NO-PATH-VECTOR bit 24; SVEC Object Flag bits 19-20; OSPF PCE Capability Flag bit 10.
IANA allocations from the PCEP 'PCEP Objects' sub-registry: END-POINTS Object-Types 3 (IPv4) and 4 (IPv6); UNREACH-DESTINATION (class 28, types 1-2); SERO (class 29, type 1); SRRO (class 30, type 1); Branch Node Capability (class 31, types 1-2).
New PCEP-ERROR types and values: Error-Type 16 (P2MP Capability Error, values 1-2); Error-Type 17 (P2MP END-POINTS Error, values 1-4 covering missing or inconsistent leaf type 2/3/4 END-POINTS); Error-Type 18 (P2MP Fragmentation Error, value 1 for fragmented request failure).
P2MP path computation requests are more CPU-intensive and consume more link bandwidth than P2P, making them a higher-risk target for unauthorized requests and denial-of-service attacks. Implementations MUST conform to RFC 5440 security requirements including TCP security, PCEP authentication, and IP access-list policy controls.
PCEP implementations SHOULD consider the additional security provided by the TCP Authentication Option (TCP-AO) defined in RFC 5925 to protect against TCP-based denial of service attacks against PCEs and PCCs.
The new P2MP END-POINTS object for IPv4 (Object-Type 3) contains a 4-byte Leaf type field, a 4-byte Source IPv4 address, and one or more 4-byte Destination IPv4 addresses. The IPv6 variant (Object-Type 4) uses 16-byte addresses with a 4-byte Leaf type prefix.
The UNREACH-DESTINATION object (Object-Class 28) carries a list of unreachable destination addresses in a PCRep message: Object-Type 1 for IPv4 (4 bytes each) or Object-Type 2 for IPv6 (16 bytes each). At most one such object per RP.
Three new flag bits are added to the RP object: F-bit (bit 18) indicates message fragmentation; N-bit (bit 19) signals P2MP request/reply; E-bit (bit 20) indicates ERO-compressed format. Each is 1 bit.