A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
Extracted elements (31)
General and specific monitoring request types are distinguished because general requests collect PCE-wide aggregate metrics (e.g., average CPU load), while specific requests are tied to a particular TE LSP path computation, requiring distinct object semantics (e.g., Current-processing-time only meaningful for specific requests).
Two monitoring modes are defined — in-band (monitoring coupled to a path computation PCReq) and out-of-band (standalone PCMonReq) — because different operational scenarios require either attaching metrics to a specific request or collecting general PCE-wide statistics independently.
If a PCE does not support the PCMonReq message or in-band monitoring, it MUST send a PCErr with Error-value=2 (capability not supported); if unrecognized messages arrive at excessive rates, the PCE must send a PCEP CLOSE and terminate the TCP session per RFC 5440 Section 6.9.
The P and I flags of all PCEP objects defined in this document SHOULD always be set to 0 on transmission and MUST be ignored on receipt, since these flags are exclusively related to path computation requests and have no meaning in monitoring objects.
A PCC MUST use the PCE-ADDRESS sub-TLV address (advertised via IGP discovery per RFC5088/RFC5089) in PCReq and PCMonReq messages; a PCE MUST also use this address in PCRep and PCMonRep messages.
An implementation MUST form PCEP messages using the object ordering specified in this document.
For general monitoring requests, the Current-processing-time field of the PROC-TIME object MUST be cleared; when the E (Estimated) bit is set, Min/Max/Average/Variance-processing-time MUST be set to 0x00000000.
If a PCE receives a monitoring request that specifies a next-hop PCE in the PCE list that is unreachable, the request MUST be silently discarded.
If the path computation chain was statically specified via PCE-ID objects in the monitoring request, the monitoring reply MUST use the same path computation chain in the reverse order.
It is RECOMMENDED that a PCC not cancel a queued PCReq and reissue it to another PCE solely because the PCE is overloaded, to avoid overload thrashing where multiple PCCs shift load simultaneously and compound delays across the network.
It MUST be possible to configure the activation/deactivation of PCEP monitoring on a PCEP speaker.
Receipt of a PCMonReq message that triggers a policy violation: the PCE MUST send a PCErr message with Error-type=5 and Error-value=6.
The I (Incomplete) bit: if a PCE supports a PCMonReq message and it does not trigger a policy violation but the PCE cannot provide requested metrics, the PCE MUST set the I bit. Once set, the I bit MUST NOT be changed by a receiving PCE.
The monitoring-id-number MUST start at a non-zero value and MUST be incremented each time a new monitoring request is sent to a PCE. If no reply is received and the PCC resends, the same monitoring-id-number MUST be used; a different one MUST be used for distinct requests.
The MONITORING object MUST be present in PCMonReq and PCMonRep messages. If missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=4.
The P flag (path computation request flag) MUST be cleared in PCMonReq and PCMonRep messages, since these flags are exclusively related to path computation requests.
When the C (Overload) bit is set in the MONITORING object of a request, an OVERLOAD object MUST be inserted in the corresponding PCMonRep or PCRep message if the PCE is experiencing a congested state.
The MONITORING object (Object-Class 19, Object-Type 1) specifies the set of requested PCE state metrics via flags: L (Liveness), G (General), P (Processing Time), C (Overload), I (Incomplete), plus a 32-bit Monitoring-id-number.
The OVERLOAD object (Object-Class 27, Object-Type 1) reports a PCE's processing congestion state, including a 16-bit Overload Duration field (in seconds) representing the estimated time until the PCE can immediately process new requests.
The PCC-ID-REQ object (Object-Class 20, Object-Type 1 for IPv4, 2 for IPv6) specifies the IP address of the requesting PCC; it MUST be inserted in PCReq or PCMonReq messages.
The PCE-ID object (Object-Class 25, Object-Type 1 for IPv4, 2 for IPv6) specifies a PCE's IP address. It is used in requests to identify PCEs for monitoring and in replies to record IP addresses of PCEs involved in the computation chain.
The PROC-TIME object (Object-Class 26, Object-Type 1) reports processing time metrics including Current, Min, Max, Average, and Variance fields (all in milliseconds), plus an E (Estimated) flag.
Five new PCEP objects assigned by IANA: Object-Class 19 (MONITORING), 20 (PCC-REQ-ID with IPv4/IPv6 types), 25 (PCE-ID with IPv4/IPv6 types), 26 (PROC-TIME), and 27 (OVERLOAD).
IANA registries created for flag fields of the MONITORING object (bits 19-23 assigned), PROC-TIME object (bit 15 assigned for Estimated), and OVERLOAD object (no bits currently assigned); new allocations require IETF Review.
New Error-values registered: Error-type=5 Error-value=6 (monitoring message rejected due to policy violation) and Error-type=6 Error-value=4 (MONITORING object missing).
Two new PCEP message types assigned by IANA: value 8 for PCMonReq (Path Computation Monitoring Request) and value 9 for PCMonRep (Path Computation Monitoring Reply).
Monitoring data can be exploited for DoS attacks, e.g., by manipulating the C bit and Overload Duration to prevent PCCs from using a PCE. It is recommended to apply the security mechanisms of RFC 5440 (authenticity, integrity, privacy, DoS protection) to PCMonReq/PCMonRep messages and to implement input rate shaping for monitoring requests from specific peers.
MONITORING object body: 8-bit Reserved, 24-bit Flags (bits 19-23 defined: I, C, P, G, L), 32-bit Monitoring-id-number, followed by optional TLVs. Total fixed portion is 8 bytes.
OVERLOAD object body: 8-bit Flags (none currently defined), 8-bit Reserved, 16-bit Overload Duration (in seconds). Total 4 bytes.
PCC-ID-REQ object body: 32-bit IPv4 address (4 octets fixed) or 128-bit IPv6 address (16 octets fixed).
PROC-TIME object body: 16-bit Reserved, 16-bit Flags (bit 15 = E/Estimated), then five 32-bit fields: Current-processing-time, Min-processing-time, Max-processing-time, Average-processing-time, Variance-processing-time (all in milliseconds).