Stateful Path Computation Element (PCE) Protocol Extensions for Usage with Point-to-Multipoint TE Label Switched Paths (LSPs)
updated by
- rfc-9756 — Update to the IANA Path Communication Element Protocol (PCEP) Numbers Registration Procedures and the Allowance of Experimental Error Codes
Extracted elements (27)
Stateful PCE significantly reduces message size for P2MP operations by using PLSP-ID to reference previously exchanged LSP information. For a stateless PCE, modifying an existing P2MP tree requires sending all leaves and full path information, whereas a stateful PCE only needs to encode the modifications (new or removed leaf nodes).
PCEP speakers that wish to use stateful PCEP for P2MP TE LSPs MUST advertise stateful PCEP capabilities during PCEP session setup even if active, passive, or initiation capabilities were previously advertised via IGP discovery. A PCC MAY initiate stateful PCEP P2MP capability advertisement at session setup even without receiving IGP PCE capability advertisements.
The PCRpt and PCUpd message formats preserve compatibility with RFC 8231 definitions. The ordering of end-point-intended-path-pair-list, actual-attribute-list, end-point-actual-path-pair-list, and intended-attribute-list retains compatibility with state reports for P2P LSPs.
Adding new leaves and pruning old leaves for PCE-initiated P2MP TE LSPs MUST be carried in a PCUpd message. Leaf type=1 is used for adding new leaves and leaf type=2 for pruning old leaves of P2MP END-POINTS objects.
PCEP extensions for stateful PCE with P2MP capability MUST NOT be used if the PCE has not advertised its stateful capability with P2MP. If a PCC receives a PCUpd without having advertised capability, it SHOULD generate a PCErr with error-type 19 and error-value 12 and terminate the session.
The END-POINTS object MUST be carried in a PCInitiate message when the N flag is set in an LSP object for a P2MP TE LSP. If the END-POINTS object is missing, the receiving PCC MUST send a PCErr with Error-type=6 and Error-value=3.
The N (P2MP) flag MUST be set in the LSP object in the PCInitiate message by the PCE to specify that the instantiation is for P2MP TE LSPs. The P2MP-LSP-IDENTIFIERS TLV SHOULD NOT be included in the LSP object in PCInitiate messages and MUST be ignored on receipt.
The P2MP-CAPABILITY flag (N) MUST be advertised by both PCC and PCE for P2MP extensions of PCRpt messages to be allowed on a PCEP session. Similarly, P2MP-LSP-UPDATE-CAPABILITY (M) must be advertised by both for PCUpd, and P2MP-LSP-INSTANTIATION-CAPABILITY (P) must be set by both to support PCE-initiated P2MP LSP instantiation.
The P2MP-LSP-IDENTIFIERS TLV MUST be included in the LSP object in a PCRpt message for P2MP TE LSPs. If the N bit is set but the TLV is absent, the PCE MUST respond with a PCErr carrying error-type 6 and error-value 14 and close the PCEP session.
The S2LS object MUST be carried in a PCRpt message along with the END-POINTS object when the N (P2MP) flag is set in the LSP object. If the S2LS object is missing, the receiving PCE MUST send a PCErr with Error-type=6 and Error-value=13 ('S2LS object missing').
When there is a conflict between the O field in the LSP object and the O field in the S2LS object, the PCEP speaker MUST generate an error with error-type 10 and error-value 22 ('Mismatch of O field in S2LS and LSP object').
Error-Type 18 ('P2MP Fragmentation Error') is defined with three new error values: 2 (Fragmented report failure), 3 (Fragmented update failure), and 4 (Fragmented instantiation failure), used when a receiver does not receive the last fragment of a fragmented message.
Message fragmentation is supported via the F flag in the LSP object when P2MP report, update, or initiate requests exceed the maximum PCEP message length of (2^16)-1 bytes. Fragmented messages use the same PLSP-ID to identify the series; PCInitiate fragments also share the same SRP-ID-number.
The PCInitiate message is extended for P2MP TE LSPs. An instantiation request includes SRP, LSP (with N flag), and an end-point-path-pair list; a deletion request includes only SRP and LSP with the R flag set in SRP.
The PCRpt message is extended to support P2MP TE LSPs, incorporating END-POINTS and S2LS objects in end-point-path-pair lists. At least one END-POINTS instance MUST be present for P2MP LSP; destinations are grouped by operational status and leaf type.
The PCUpd message is extended for P2MP TE LSPs with an end-point-path-pair list containing optional END-POINTS and intended-path (ERO/SERO) pairs. The PCC SHOULD use make-before-break or sub-group-based procedures from RFC 4875 based on local policy.
The S2LS (Source-to-Leaves) Object (Object-Class 41, Object-Type 1) is a new PCEP object used to report the operational status of one or more destinations encoded in END-POINTS for a P2MP TE LSP. It contains a 32-bit Flags field with a 3-bit O (Operational) field.
Three new flags are added to the LSP Object: N (P2MP flag, bit 3) indicating a P2MP TE LSP message, F (Fragmentation flag, bit 2) indicating fragmented LSP messages, and E (ERO-compression flag, bit 1) indicating compressed route format using SERO/SRRO objects.
Three new flags are added to the STATEFUL-PCE-CAPABILITY TLV: N (P2MP-CAPABILITY, bit 25), M (P2MP-LSP-UPDATE-CAPABILITY, bit 24), and P (P2MP-LSP-INSTANTIATION-CAPABILITY, bit 23). These are advertised during PCEP session establishment in the OPEN object.
A new 'S2LS Object Flag Field' subregistry is created within the PCEP Numbers registry to manage the 32-bit flag field of the S2LS object. New values are assigned by Standards Action. Bits 29-31 are defined as Operational (3 bits); bits 0-28 are unassigned.
Three new flags registered in the LSP Object Flag Field subregistry: bit 1 (ERO-compression), bit 2 (Fragmentation), and bit 3 (P2MP). New S2LS Object registered with Object-Class 41, Object-Type 1. New TLV types 32 (P2MP-IPV4-LSP-IDENTIFIERS) and 33 (P2MP-IPV6-LSP-IDENTIFIERS) registered.
Three new flags registered in the STATEFUL-PCE-CAPABILITY TLV Flag Field subregistry: bit 23 (P2MP-LSP-INSTANTIATION-CAPABILITY), bit 24 (P2MP-LSP-UPDATE-CAPABILITY), and bit 25 (P2MP-CAPABILITY).
Three new PCE capability bits registered in the OSPF 'Path Computation Element (PCE) Capability Flags' registry: bit 13 (Active Stateful PCE with P2MP), bit 14 (Passive Stateful PCE with P2MP), and bit 15 (Stateful PCE Initiation with P2MP).
Stateful operations on P2MP TE LSPs are more CPU-intensive and bandwidth-consuming than P2P TE LSPs. A rogue PCC requesting unauthorized stateful PCE operations could mount a DoS attack against a PCE, disrupting the network. An attacker may also flood a PCC with PCUpd messages by spoofing messages or compromising the PCE itself. It is RECOMMENDED that PCEP extensions only be activated on authenticated and encrypted sessions using TLS (RFC 8253).
The IPV4-P2MP-LSP-IDENTIFIERS TLV (Type=32, Length=16 octets) contains: IPv4 Tunnel Sender Address (32 bits), LSP ID (16 bits), Tunnel ID (16 bits), Extended Tunnel ID (32 bits), and P2MP ID (32 bits).
The IPV6-P2MP-LSP-IDENTIFIERS TLV (Type=33, Length=40 octets) contains: IPv6 Tunnel Sender Address (128 bits), LSP ID (16 bits), Tunnel ID (16 bits), Extended Tunnel ID (128 bits), and P2MP ID (32 bits).
The S2LS Object format contains a 32-bit Flags field with bits 29-31 used as the O (Operational) 3-bit field representing the operational status of the group of destinations. Bits 0-28 are unassigned and must be set to 0 on transmission and ignored on receipt.