Encoding of Objective Functions in the Path Computation Element Communication Protocol (PCEP)
Extracted elements (21)
Objective function discovery is handled via PCEP rather than OSPF/IS-IS PCE discovery extensions (RFC 5088/5089) because those IGP mechanisms are intended for a few generic parameters, while detailed PCE parameters such as supported objective functions belong in the PCEP session-setup exchange.
A legacy PCE that does not recognize the OF flag in the RP object will ignore it and send a PCRep without an OF object. The PCC's behavior in this case is an implementation choice: it may discard the reply or accept it without knowledge of the applied objective function.
An OF object specifying an objective function for an individual path computation request (non-synchronized case) MUST follow the RP object for which it applies.
If the objective function is supported but policy does not permit applying it and the P bit is set, the PCE MUST send a PCErr with error type 5 (policy-violation) and error value 3 (objective function not allowed).
If the objective function is unknown/unsupported and the P bit is set, the PCE MUST send a PCErr with error type 3 or 4 and error value 4 (Unrecognized/Unsupported parameter), and the related path computation request MUST be discarded.
If the OF flag is set in the RP object and policy permits, the PCE MUST include an OF object in the PCRep indicating the objective function used. If policy does not permit, it MUST send a PCErr with error type 5 and error value 4 (OF bit of the RP object set, request rejected).
If the P bit is set in the OF object, the PCE MUST use the specified objective function during path computation. If the P bit is clear, the PCE SHOULD apply the function if supported but MAY choose a different objective function per local policy.
It MUST be possible to configure the activation/deactivation of objective function discovery in PCEP, and it MUST be possible to configure a default objective function for path computation when a request specifies an optional objective function.
The absence of the OF-List TLV in an OPEN object MUST be interpreted as an absence of information on the list of supported objective functions by the PCE.
The OF-List TLV MUST NOT appear more than once in an OPEN object. If it appears more than once, the PCEP session MUST be rejected with error type 1, error value 1 (PCEP session establishment failure / Reception of an invalid Open message).
When an objective function applies to a set of synchronized path computation requests, the OF object MUST be carried just after the corresponding SVEC object and MUST NOT be repeated for each elementary request.
A new 'Supply OF on response' flag is defined at bit 24 of the RP object. When set in a PCReq, it instructs the PCE to include the applied objective function in the PCRep. When set in a PCRep, it indicates the OF used during computation is included.
Four new METRIC object types for synchronized requests are defined: Type 4 (aggregate bandwidth consumption), Type 5 (load of most loaded link), Type 6 (cumulative IGP cost), Type 7 (cumulative TE cost). These follow the SVEC object to which they apply.
Six mandatory objective functions are defined: MCP (code 1, minimize cost), MLP (code 2, minimize load), MBP (code 3, maximize residual bandwidth) for individual requests; MBC (code 4, minimize aggregate bandwidth consumption), MLL (code 5, minimize load of most loaded link), MCC (code 6, minimize cumulative cost) for synchronized request sets.
The OF-List TLV (type 4) is an optional TLV carried within the PCEP OPEN object, allowing a PCE to advertise the list of objective functions it supports during session setup. The value field contains a list of 2-byte objective function code points; length is N*2 where N is the number of objective functions.
The OF (Objective Function) object (Object-Class 21, Object-Type 1) is an optional PCEP object carried in PCReq messages to indicate the required/desired objective function, or in PCRep messages to report the objective function used during path computation. The body contains a 2-byte OF Code, a 2-byte Reserved field, and optional TLVs.
IANA allocated OF object (Object-Class 21, Object-Type 1) in the PCEP Objects registry, OF-List TLV (Type 4) in the PCEP TLV Type Indicators registry, two new PCEP error values under error-type 5 (policy violation), RP object flag bit 24, and four new METRIC object T-field types (4–7).
IANA created a 16-bit 'PCE Objective Function' code point registry. Values 0 is reserved; 1–1023 require IETF Review; 1024–32767 are First Come First Served; 32768–65535 are for Private Use. Six initial code points (1–6) are assigned by this document.
PCEP security mechanisms from RFC 5440 secure entire PCEP messages and continue to apply without change. The OF object is automatically secured by those mechanisms; if those mechanisms are not used, the OF object could participate in attacks against a PCE or PCC, though other objects present more significant attack vectors.
The OF-List TLV value field is a sequence of 2-byte OF Code identifiers padded to 4-octet alignment. The LENGTH field = N * 2 (N = number of objective functions); padding is not included in the length.
The OF object body encodes a 2-byte OF Code identifying the objective function, followed by 2 bytes Reserved (MUST be set to zero on transmission, MUST be ignored on receipt), followed by optional TLVs for objective function parameters.