Path Computation Element Communication Protocol (PCEP) Requirements and Protocol Extensions in Support of Global Concurrent Optimization
Extracted elements (29)
Link utilization values in the GC object are specified as integer percentages (0–100) to avoid floating-point numbers in the wire format, as noted explicitly in the requirements section for the max and min utilization constraints.
The delete order SHOULD NOT equal the setup order. If the delete order is higher than the setup order, make-before-break is possible; if the delete order is lower, make-before-break cannot be performed. This encoding allows the PCE to communicate migration feasibility implicitly through the relative ordering values.
The document explicitly limits its scope to PCC-PCE communication requirements and protocol extensions; specific GCO computation algorithms and techniques are declared out of scope. This separation allows algorithm innovation without protocol changes.
The GCO application is primarily an NMS- or PCE-Server-based solution. The management-based PCE architecture (Section 5.5 of RFC 4655) is considered most suitable; other architectural alternatives such as distributed LSRs performing GCO via complex synchronization are NOT RECOMMENDED due to synchronization overhead and potential network stability issues.
The Global Concurrent Vector (GCV) requirement is fully satisfied by the existing SVEC object defined in RFC 5440. The SVEC object identifies a set of concurrent path requests, so it is reused without modification for GCO rather than defining a new object.
When an XRO (eXclude Route Object) is global to an SVEC (i.e., placed after the SVEC in the svec-list) and the F-bit is set, specifying multiple Record Route Objects in the PCReq message SHOULD be allowed, enabling per-LSP route recording alongside global exclusion constraints.
Applying global concurrent reoptimization in a network with a high rate of change of TE LSPs (churn) is NOT RECOMMENDED because TE LSPs would likely change before they could be globally reoptimized.
Global concurrent reoptimization is NOT RECOMMENDED for networks containing a very large number of very low bandwidth or zero bandwidth TE LSPs, because the large scope of the problem relative to the small benefit makes the process unlikely to be worthwhile.
If a PCE receives a GCO request and cannot process it due to insufficient memory, the PCE MUST send a PCErr message with PCEP-ERROR Object Error-Type=15, Error-value=1, and MUST stop processing the request. The PCC MUST cancel the corresponding GCO request.
If a PCE receives a GCO request but is not capable of global concurrent optimization, the PCE MUST send a PCErr message with Error-Type=15, Error-value=2, stop processing the request, and the PCC MUST cancel the corresponding GCO request.
If a PCE receives a GCO request that violates administrative privileges (PCE policy does not allow GCO), it sends a PCErr with Error-Type=5, Error-value=5 and stops processing. The PCC MUST cancel the corresponding GCO request.
The M-bit in the RP object can be set only if the R (Reoptimization) flag is also set. When the M-bit is not set, break-before-make reoptimization is allowed for that request.
The Order TLV MUST be included in the RP object of the PCRep message if the D-bit is set in the RP object of the corresponding PCReq message. The PCE MUST specify the order number in response to such an Order Request.
The PCEP SHOULD support a Global Objective Function (GOF) field, a Global Constraints (GC) field, and a Global Concurrent Vector (GCV) field. The list of available global objective functions SHOULD include at minimum MBC, MLL, and MCC, and SHOULD be expandable for future addition.
The PCReq request message MUST allow requesting the PCE to provide the order in which TE LSPs should be reoptimized (migration path) to minimize traffic disruption, and in response the PCE MUST be able to indicate that order in the PCRep message.
The request message MUST allow indicating per-request whether make-before-break is required (e.g., for voice traffic) or break-before-make is acceptable (e.g., for Internet traffic). The response must allow indicating TE LSPs for which make-before-break reoptimization is not possible.
GCO indication is conveyed implicitly: if any of the GCO-related objects (OF, GC, or XRO) follows the SVEC object in the PCReq message, all requested path computations specified in that SVEC are subject to those global constraints and objective functions. No separate explicit indicator field is needed.
The GLOBAL CONSTRAINTS (GC) Object (Object-Class 24, Object-Type 1) is used in PCReq messages to specify global constraints applied to all individual path computations in a GCO request. It carries MH (Max Hop), MU (Max Utilization), mU (min Utilization), and OB (Overbooking factor) fields, plus optional TLVs.
The Global Objective Function (GOF) for GCO is specified using the existing OF object (RFC 5541). Three function codes apply to GCO: code 4 (Minimize aggregate Bandwidth Consumption, MBC), code 5 (Minimize load of the Most Loaded Link, MLL), and code 6 (Minimize Cumulative Cost of a set of paths, MCC).
Two new bit flags are added to the Flags field of the RP object: Bit 21 (M-bit, Make-before-break) — when set, make-before-break reoptimization is required for that request; Bit 22 (D-bit, orDer) — when set, the PCC requires the PCE to specify in the PCRep the order in which this path request is to be provisioned.
Two new bit flags are defined in the NO-PATH-VECTOR TLV of the NO-PATH object: Bit 6 (no migration path found) and Bit 7 (no feasible solution found meeting all GCO constraints). These allow the PCE to communicate specific GCO failure reasons in the PCRep message.
IANA allocated a new Error-Type 15 ('Global Concurrent Optimization Error') with Error-value=1 (Insufficient memory) and Error-value=2 (Global concurrent optimization not supported) in the 'PCEP-ERROR Object Error Types and Values' sub-registry. Additionally, Error-value=5 was added to the existing Error-Type=5 (Policy violation) for 'Global concurrent optimization not allowed'.
IANA allocated Flag 9 ('Global Concurrent Optimization (GCO)') in the 'Path Computation Element (PCE) Capability Flags' sub-registry (OSPF PCE-CAP-FLAGS Sub-TLV, created by RFC 5088) to allow PCEs to advertise GCO capability.
IANA allocated Object-Class 24 ('GLOBAL-CONSTRAINTS', Object-Type 1: Global Constraints) in the 'PCEP Objects' sub-registry for the new GC object defined in this document.
IANA allocated TLV Type 5 ('Order TLV') in the 'PCEP TLV Type Indicators' sub-registry for use in the RP object to indicate TE LSP setup and delete ordering in GCO responses.
IANA allocated two new bit flags in the 'NO-PATH-VECTOR TLV Flag Field' sub-registry: Bit 25 ('No GCO solution found') and Bit 26 ('No GCO migration path found'), both assigned to RFC 5557.
When global reoptimization is applied to an active network it could be extremely disruptive. It is critical that the operator issuing commands has sufficient authority and is authenticated, and that computation requests are subject to appropriate policy. The RFC 5440 PCEP session security mechanisms SHOULD be used to secure GCO requests and responses.
The GC object body contains four 8-bit integer fields packed consecutively: MH (maximum hop count for all TE LSPs), MU (upper-bound link utilization percentage, 0-100), mU (lower-bound link utilization percentage, 0-100), and OB (overbooking factor percentage). Optional TLVs may follow.
The Order TLV (Type=5) is carried in the RP object of the PCRep message. It contains two 32-bit integer fields: Delete Order (the sequence number for removing the old TE LSP) and Setup Order (the sequence number for establishing the new TE LSP). A Delete Order value of 0 indicates a new TE LSP with no prior path to remove.