Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware 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 (29)
Metric values are encoded in 32-bit IEEE 754 floating point (inherited from the METRIC object definition in RFC 5440) even though IGP advertisements use 24-bit integers. This conversion may introduce slight precision loss but maintains consistency with existing PCEP metric encoding.
P2MP path metrics are defined as the maximum (worst-case) metric across all destinations in the P2MP tree rather than an average or sum, because SLA compliance requires that all destinations meet the performance bound, making the worst-case destination the binding constraint.
Path Delay and Path Delay Variation metrics reuse the existing Minimum Cost Path (MCP) objective function from RFC 5541 rather than defining new ones, since minimizing cost already applies to these metrics. New objective functions (MPLP, MUP, MRUP) are defined only where existing OFs are insufficient.
If a PCE receives a METRIC object with a new type defined in this document, the P bit is clear, and the PCE does not understand or support that type, it SHOULD simply ignore the METRIC object per RFC 5440 processing rules, ensuring backward compatibility with legacy PCEs.
The new metric types and BU object are compatible with stateful PCE extensions (RFC 8231) and PCE-initiated LSPs. The updated PCReq/PCRep attribute-list (Section 5.2) is used to include service-aware parameters in stateful operations; passive stateful PCEs MAY use these extensions.
A PCE that supports the BU object MUST ensure that no link on the computed path has LBU or LRBU percentage exceeding the value specified in the BU object.
For inter-domain path computation, if all domains do not share the same understanding of the METRIC and BU object, some form of metric normalization as described in RFC 5441 MUST be applied.
If a message contains more than one BU object with the same bandwidth utilization type, the first MUST be processed by the receiver and subsequent instances MUST be ignored.
If a PCE does not understand a new METRIC type and the P bit is set in the METRIC object header, the PCE MUST send a PCErr message with Error-Type=4 (Not supported object) and Error-value=4 (Unsupported parameter).
If a PCE's local policy prohibits network performance constraints and the P bit is set, the PCE MUST send a PCErr with Error-Type=5 (Policy violation) and Error-value=8 (Not allowed network performance constraint), and the path computation request MUST be canceled.
If a PCE understands but does not support the new METRIC type and the P bit is set, the PCE MUST send a PCErr with Error-Type=4 and Error-value=5 (Unsupported network performance constraint), and the path computation request MUST be canceled.
If the BU object is unsupported/unknown and the P bit is set, the PCE MUST send a PCErr with Error-Type=4 and Error-value=5 (Unsupported network performance constraint), and the related path computation request MUST be discarded.
When a PCC uses the Path Delay metric in a PCReq message with a bound constraint, the B bit MUST be set to indicate a maximum for the Path Delay metric that must not be exceeded. When used to optimize path delay, the B bit MUST be cleared.
P2MP metric types (T=15, T=16, T=17) encode the worst-case metric among all destinations of the P2MP tree — i.e., Maximum {PDM(Dest_j)} for delay, Maximum {PDVM(Dest_j)} for delay variation, and Maximum {PLM(Dest_j)} for loss.
Six new METRIC object types are defined: T=12 (Path Delay), T=13 (Path Delay Variation), T=14 (Path Loss), T=15 (P2MP Path Delay), T=16 (P2MP Path Delay Variation), T=17 (P2MP Path Loss). These extend the METRIC object defined in RFC 5440 Section 7.8.
The BU object MAY be carried in PCReq and PCRep messages to specify an upper limit on acceptable link bandwidth utilization percentage. A PCRep message MAY also carry a BU object along with a NO-PATH object to indicate which bandwidth constraint could not be satisfied.
The Link Bandwidth Utilization (LBU) is defined as (utilized bandwidth / maximum bandwidth) * 100 in percentage, where utilized bandwidth includes both RSVP-TE and non-RSVP-TE LSP traffic.
The Link Reserved Bandwidth Utilization (LRBU) is defined as (reserved bandwidth utilization / maximum reservable bandwidth) * 100, where reserved bandwidth utilization = utilized bandwidth - (residual bandwidth - available bandwidth).
The Path Delay metric (T=12) represents the sum of Unidirectional Link Delay metrics of all links along a P2P path, computed using the sum of means composition function per RFC 6049 Section 4.2.5.
The Path Loss metric (T=14) encodes end-to-end packet loss as a percentage using the composition function: PL(P) = (1 - product of (1-FL(Lpi)) for all links) * 100, per RFC 6049 Section 5.1.5.
The PCRpt message (stateful PCE) can include the BU object via the updated attribute-list defined in Section 5.2, specifying the upper limit set at the PCC at the time of LSP delegation to an active stateful PCE.
Three new Objective Function codes are defined: OF Code 9 (MPLP — Minimum Packet Loss Path), OF Code 10 (MUP — Maximum Under-Utilized Path, maximizing minimum slack bandwidth ratio), and OF Code 11 (MRUP — Maximum Reserved Under-Utilized Path, maximizing minimum reserved bandwidth slack ratio).
IANA added two new Error-values: Error-Type 4 (Not supported object), Error-value 5 (Unsupported network performance constraint); and Error-Type 5 (Policy violation), Error-value 8 (Not allowed network performance constraint).
IANA allocated six new values in the PCEP 'METRIC Object T Field' subregistry: values 12-17 for Path Delay, Path Delay Variation, Path Loss, P2MP Path Delay, P2MP Path Delay Variation, and P2MP Path Loss metrics.
IANA allocated three new Objective Function codes in the PCEP 'Objective Function' subregistry: Code 9 (MPLP), Code 10 (MUP), Code 11 (MRUP).
IANA created a new 'BU Object Type Field' subregistry within the PCEP Numbers registry, with values assigned by Standards Action. Currently defined: 0 (Reserved), 1 (LBU), 2 (LRBU). BU object allocated Object-Class=35, Object-Type=1.
Service-aware information such as delay and packet loss is sensitive; snooping PCEP messages carrying these metrics or using them for network reconnaissance may expose operational details to attackers. Deployments should use TCP-AO (RFC 5925) or PCEPS (TLS-based) for PCEP security, with TLS considered the preferred option for sensitive service-aware data.
Path Delay and Path Delay Variation metric values are quantified in units of microseconds and encoded in 32-bit IEEE 754 floating point format, converted from the 24-bit integer used in IGP advertisements; this conversion may introduce some loss of precision.
The BU object body is 8 bytes: a 24-bit Reserved field (MUST be zero on transmission, ignored on receipt), an 8-bit Type field (1=LBU, 2=LRBU), and a 32-bit Bandwidth Utilization field encoded as a percentage in IEEE 754 floating point format. Object-Class=35, Object-Type=1.