Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
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 (23)
If the Path Protection Association TLV is missing in the PPAG ASSOCIATION object, the LSP is considered a working LSP (as if the P bit is unset). This provides a safe default interpretation for backward compatibility.
LSPs are associated by group membership rather than by listing peer LSPs, using the generic ASSOCIATION object from RFC 8697. This allows both PCC- and PCE-initiated associations and supports passive, active stateful, and PCE-initiated modes uniformly.
Both working and protection LSPs are expected to be delegated together to the same PCE to avoid race conditions. The Path Protection Association Flags in PCEP map to corresponding fields in the RSVP-TE PROTECTION object for signaling.
Disjoint path requirements (node, SRLG disjoint) for working and protection LSPs are handled via a separate Disjointness Association type, which can coexist with PPAG by including both ASSOCIATION objects.
All LSPs within a PPAG MUST have the same source, destination, Tunnel ID (as carried in LSP-IDENTIFIERS TLV), and Protection Type (PT) in the Path Protection Association TLV.
An LSP-IDENTIFIERS TLV SHOULD be included for all LSPs (including Segment Routing LSPs) in a Path Protection Association.
During make-before-break (MBB) procedure, the error handling related to the number of LSPs allowed in a PPAG MUST NOT be applied.
If a PCEP speaker attempts to add or update an LSP to a PPAG and the Tunnel ID, source, or destination differs from existing LSPs in the PPAG, the PCEP speaker MUST send PCErr with Error-Type 26 and Error-Value 9 (Tunnel ID or endpoints mismatch for Path Protection Association).
If a PCEP speaker does not support the Path Protection Association Type, it MUST return a PCErr message with Error-Type 26 (Association Error) and Error-Value 1 (Association type is not supported).
If the Protection Type (PT) in the Path Protection Association TLV differs from that of existing LSPs in the PPAG, the PCEP speaker MUST send PCErr with Error-Type 26 and Error-Value 6 (Association information mismatch).
Operator-configured Association Range MUST NOT be set for the Path Protection Association type and MUST be ignored if present.
The Path Protection Association TLV MUST NOT be present more than once in the ASSOCIATION object; if it appears more than once, only the first occurrence is processed and any others MUST be ignored.
Unassigned bits in the Path Protection Association TLV flags MUST be set to 0 on transmission and MUST be ignored on receipt.
When protection type is set to 1+1 (type=0x08 or 0x10), there MUST be at maximum only one working LSP and one protection LSP within a PPAG; attempts to add another MUST result in PCErr Error-Type 26, Error-Value 10.
When protection type is set to 1:N (type=0x04), there MUST be at maximum only one protection LSP, and working LSPs MUST NOT exceed N within a PPAG; violations MUST result in PCErr Error-Type 26, Error-Value 10.
When the PCEP peer does not support the protection type set in PPAG, it MUST send PCErr with Error-Type 26 and Error-Value 11 (Protection type is not supported).
Defines the Path Protection Association Type (value 1) and Path Protection Association Group (PPAG), a new association type allowing one working LSP to be associated with one or more protection LSPs using the generic ASSOCIATION object from RFC 8697.
The Protecting (P) flag (1 bit) indicates if the LSP is a working (0) or protection (1) LSP. The Secondary (S) flag (1 bit) indicates primary (0) or secondary (1) LSP, and is ignored if P is not set. The Protection Type (PT) field (6 bits) indicates the LSP protection type per RFC 4872.
IANA allocated three new Error-Values under Error-Type 26 (Association Error): 9 (Tunnel ID or endpoints mismatch for Path Protection Association), 10 (Attempt to add another working/protection LSP for Path Protection Association), and 11 (Protection type is not supported).
IANA assigned Association Type value 1 ('Path Protection Association') in the 'ASSOCIATION Type Field' subregistry created by RFC 8697.
IANA assigned TLV Type value 38 ('Path Protection Association Group TLV') in the 'PCEP TLV Type Indicators' subregistry, and created a new subregistry 'Path protection Association Group TLV Flag Field' with Standards Action policy for flag assignments.
A malicious PCEP speaker could be spoofed and used as an attack vector by creating spurious associations; adding a false protection LSP to a PPAG could give a misleading sense of network reliability, causing failures when the working LSP goes down. Securing the PCEP session using TLS (RFC 8253) per BCP 195 (RFC 7525) is RECOMMENDED.
The Path Protection Association TLV has Type=38, Length=4 (fixed), and a 32-bit flags field containing: PT (Protection Type, 6 bits), unassigned flags, S (Secondary, 1 bit), and P (Protecting, 1 bit).