RFC 5886
A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture
RFC 5886: A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture 🦋
okay bestie, this is RFC 5886 ✨ It's a Standards Track doc from the IETF, dated June 2010, with ISSN 2070-1721. The authors are JP. Vasseur, Ed. from Cisco Systems, Inc., JL. Le Roux from France Telecom, and Y. Ikejiri from NTT Communications Corporation. Its header doesn't list any RFCs that it obsoletes or updates, so it doesn't replace or change anything else 💅
Abstract 🌸
okay so the Path Computation Element (PCE)-based architecture is the setup for working out Traffic Engineering (TE) Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. It works whether you're dealing with one domain or several. A domain is just a group of network elements that share an address-management or path-computation responsibility, like Interior Gateway Protocol (IGP) areas and Autonomous Systems 🧚 Path Computation Clients (PCCs) send computation requests to PCEs, and those PCEs can pass the requests along and team up with other PCEs to form a "path computation chain" 🫶
Monitoring the path computation chain is a huge deal, ngl. It helps with troubleshooting and performance checks. You want to know if each PCE in the chain is alive, whether there's any sign of resource contention, and how long path computations take. This document lays out the procedures and PCEP extensions for gathering that info 💜
Status of This Memo 🎀
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
For the current status of this document, any errata, and how to send feedback, check out http://www.rfc-editor.org/info/rfc5886 🔥
Copyright Notice 🦋
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🙈
Table of Contents 🌈
1. Introduction ....................................................4
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Path Computation Monitoring Messages ............................6
3.1. Path Computation Monitoring Request (PCMonReq) Message .....6
3.2. Path Monitoring Reply (PCMonRep) Message ...................9
4. Path Computation Monitoring Objects ............................11
4.1. MONITORING Object .........................................11
4.2. PCC-ID-REQ Object .........................................13
4.3. PCE-ID Object .............................................14
4.4. PROC-TIME Object ..........................................15
4.5. OVERLOAD Object ...........................................17
5. Policy .........................................................18
6. Elements of Procedure ..........................................18
7. Manageability Considerations ...................................20
7.1. Control of Function and Policy ............................20
7.2. Information and Data Models ...............................20
7.3. Liveness Detection and Monitoring .........................20
7.4. Verify Correct Operations .................................20
7.5. Requirements on Other Protocols ...........................21
7.6. Impact on Network Operations ..............................21
8. Guidelines to Avoid Overload Thrashing .........................21
9. IANA Considerations ............................................22
9.1. New PCEP Message ..........................................22
9.2. New PCEP Objects ..........................................22
9.3. New Error-Values ..........................................23
9.4. MONITORING Object Flag Field ..............................23
9.5. PROC-TIME Object Flag Field ...............................24
9.6. OVERLOAD Object Flag Field ................................24
10. Security Considerations .......................................24
11. Acknowledgments ...............................................25
12. References ....................................................25
12.1. Normative References .....................................25
12.2. Informative References ...................................251. Introduction ✨
okay so the PCE-based architecture was specified in [RFC4655] for working out TE LSPs in MPLS and GMPLS networks, whether that's within one domain or across several. Like before, a domain is a group of network elements with a shared sphere of address management or path computation responsibility, such as IGP areas and Autonomous Systems 💖
PCCs send computation requests to PCEs using PCReq messages. Those PCEs can forward the requests and cooperate with other PCEs to form a "path computation chain". When path computation succeeds, the computed paths go back to the requesting PCC in PCRep messages. PCReq and PCRep are defined in [RFC5440] 🦋
Monitoring is critical here, bestie. You need it for troubleshooting and performance monitoring. Liveness of each PCE in the chain, detection of potential resource contention states, and path computation time statistics are all examples of the metrics that matter 🌸
As defined in [RFC4655], more than one PCE can be involved in computing a TE LSP. A typical case is when the head-end and tail-end of the TE LSP sit in non-adjacent domains and no single PCE can see both the head-end and tail-end domains. The set of PCEs involved in that computation is what we call a "path computation chain". As Section 3.1 explains further, the chain can be static (pre-configured) or dynamically determined during the path computation process 🧚
As discussed in [RFC4655], a TE LSP can be computed by one PCE (called single PCE path computation) or by several PCEs (called multiple PCE path computation). With a single PCE, the PCC may be able to check the PCE's liveness using IGP extensions (see [RFC5088] and [RFC5089]), or using Keepalive messages in PCEP. With multiple PCEs in the chain, though, the PCC's visibility may be limited to the first PCE. One example is the Backward Recursive PCE-based Computation (BRPC) procedure defined in [RFC5441]. So it's super important to have mechanisms for monitoring the state of the path computation chain 👑
This document extends PCEP so you can gather various state metrics along the path computation chain. We call a "state metric" any metric that characterizes a PCE's state. A state metric can be a boolean, like whether a PCE is alive or congested, or a performance metric, like the path computation time at each PCE 💅
PCE state metrics can be gathered in two contexts: in band or out of band. In band means a PCC asks for metrics as part of a path computation request. For example, a PCC might send a path computation request and want to know how long that request took to process, in addition to the computed path. Out of band means the metric collection is a standalone request. Examples include checking the liveness of a specific path computation chain, or collecting the average processing time over the last 5-minute period on one or more PCEs 🎀
There are two monitoring request types in this document: general and specific. A general monitoring request collects PCE state metrics that aren't tied to any particular path computation request, like average CPU load on a PCE. A specific monitoring request is tied to a particular path computation request, like the processing time needed to complete the path computation for a TE LSP 🍓
This document specifies procedures and extensions to the Path Computation Element Protocol (PCEP) ([RFC5440]), including new objects and new PCEP messages. The goal is to monitor the path computation chain and gather various performance metrics 💜
The message formats in this document are specified using Backus Naur Format (BNF) encoding, as specified in [RFC5511] 🌈
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶
2. Terminology 🧚
PCC (Path Computation Client): any client application that requests a path computation to be performed by a Path Computation Element 💖
PCE (Path Computation Element): an entity (component, application, or network node) that can compute a network path or route based on a network graph and apply computational constraints 🦋
TE LSP: Traffic Engineering Label Switched Path 👑
3. Path Computation Monitoring Messages ✨
Okay so PCEP messages are basically little packages 📦. Every one has a common header up top, then a body full of objects. Some objects are mandatory, which means the message isn't valid without them, and the rest are optional 💅. The P flag lives in the common header of each PCEP object, and a PCEP peer can set it to ask a PCE to actually take that info into account during path computation. BUT the P flag is all about path computation requests, so it MUST be cleared in the two PCEP messages defined here (PCMonReq and PCMonRep) 🙅♀️
Every PCEP message type has its own rules about which objects it can carry. An implementation MUST form PCEP messages using the object ordering in this document, so don't get creative with the order 😭
This doc defines two new messages, the Path Computation Monitoring Request (PCMonReq) and the Path Computation Monitoring Reply (PCMonRep), for handling out-of-band monitoring requests. The PCMonReq is sent by a PCC to a PCE to gather one or more PCE state metrics from a set of PCEs in a path computation chain. The PCMonRep is the PCE sending that data back to the PCC 🎀
3.1. Path Computation Monitoring Request (PCMonReq) Message
The Message-Type field of the PCEP common header is set to 8 for the PCMonReq message 🦋
There's one mandatory object that MUST be included in a PCMonReq message: the MONITORING object (see Section 4.1). If it's missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING object missing). Everything else is optional 🌸
Here's the out-of-band request format:
<PCMonReq Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<pce-list>]
[<svec-list>]
[<request-list>]
where:
<pce-list>::=<PCE-ID>[<pce-list>]
<svec-list>::=<SVEC>
[<OF>]
[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
[<XRO>]
<metric-list>::=<METRIC>[<metric-list>]And here's the in-band request format, for a PCReq message with monitoring data requested:
<PCReq Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<pce-list>]
[<svec-list>]
<request-list>
where:
<pce-list>::=<PCE-ID>[<pce-list>]
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
where:
<metric-list>::=<METRIC>[<metric-list>]The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and LOAD-BALANCING objects come from [RFC5440]. The XRO object comes from [RFC5521], and the OF object comes from [RFC5541]. The PCC-ID-REQ object is defined in Section 4.2 📚
So what's the PCMonReq actually for? It's for grabbing various PCE state metrics along a path computation chain. That chain can be decided by the PCC, as a series of a series of PCE-ID objects (defined in Section 4.3), based on policy set on the PCC. Or it can be figured out by the path computation procedure itself. For example, if the BRPC procedure ([RFC5441]) is used to compute an inter-domain TE LSP, the chain might be worked out on the fly 🧩 In that case the PCC sends a PCMonReq holding the PCEP objects that describe the TE LSP attributes, plus the MONITORING object (see Section 4.1) listing the metrics it cares about. If a PCE list is in the monitoring request, it takes precedence over whatever mechanism is used to dynamically work out the chain. And if a PCE gets a monitoring request naming a next-hop PCE in the PCE list that it can't reach, the request MUST be silently discarded 🙈
Several PCE state metrics can be requested, each specified by a set of objects defined in Section 4. This set of objects might get extended in the future, so keep an eye out 👀
As [RFC5440] points out, a few situations can come up:
- a bundle of independent and non-synchronized path computation requests,
- a bundle of independent and synchronized path computation requests (the SVEC object, defined below, is required), or
- a bundle of dependent and synchronized path computation requests (the SVEC object, defined below, is required).
For a bundle of requests, the MONITORING object SHOULD only be present in the first PCReq or PCMonReq message. The monitoring request applies to every request in the bundle, even when the dependent and/or synchronized requests are sent across more than one PCReq or PCMonReq message 💖
Let's look at some examples, because examples are everything 🍓
Example 1 (out-of-band request): PCC1 wants to check the path computation chain it would use if it asked for a path computation for a specific TE LSP called T1. It sends a PCMonReq with a MONITORING object that specifies a path computation check, along with the same set of objects (for example RP, END-POINTS, and so on) that would go in a PCReq for T1 ✨
Example 2 (in-band request): PCC1 asks for a path computation for a TE LSP and also wants to know the processing time along the chain selected to compute T1. It sends a PCReq that also carries a MONITORING object specifying the performance metrics it's after 🔥
Example 3 (out-of-band request): PCC2 wants performance metrics along the specific path computation chain <pce1, pce2, pce3, pce7>. It sends a PCMonReq to PCE1, containing a MONITORING object and a sequence of PCE-ID objects that identify PCE1, PCE2, PCE3, and PCE7, in that order 🧚
In every one of these examples, the reply is a PCRep message (for an in-band request) or a PCMonRep message (for an out-of-band request), and it reports the computed metrics 💜
3.2. Path Monitoring Reply (PCMonRep) Message
The PCMonRep message is how PCE state metrics get sent back to the requester for out-of-band monitoring requests. The Message-Type field of the PCEP common header is set to 9 for this one 🦋
Just like the request, there's one mandatory object that MUST be included in a PCMonRep message: the MONITORING object (see Section 4.1). If it's missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=4 (MONITORING object missing).
Everything else is optional 🌸
Here's the out-of-band reply format:
<PCMonRep Message>::= <Common Header>
<MONITORING>
<PCC-ID-REQ>
[<RP>]
[<metric-pce-list>]
where:
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=<PCE-ID>
[<PROC-TIME>]
[<OVERLOAD>]And the in-band format, for a PCRep message carrying monitoring data:
<PCRep Message> ::= <Common Header>
<response-list>
where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
<MONITORING>
<PCC-ID-REQ>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
[<metric-pce-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>
where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]
<metric-pce-list>::=<metric-pce>[<metric-pce-list>]
<metric-pce>::=<PCE-ID>
[<PROC-TIME>]
[<OVERLOAD>]The RP and NO-PATH objects come from [RFC5440]. The PCC-ID-REQ object is defined in Section 4.2 📚
Quick one, but it matters 🚨 If the path computation chain was statically specified in the monitoring request, using a series of a series of PCE-ID objects defined in Section 4.3, then the monitoring request MUST use the same path computation chain, just with the PCE list in reverse order 🔄
4. Path Computation Monitoring Objects ✨
The PCEP objects defined in this document follow the PCEP object format from [RFC5440], so they're totally compatible 🫶 The P flag and the I flag of the PCEP objects defined here SHOULD always be set to 0 on transmission, and they MUST be ignored on receipt. Why? Because both flags only relate to path computation requests 💅
Several objects defined in this section can ride along inside the PCEP PCReq or PCRep messages from [RFC5440] for in-band monitoring requests. That's when the PCC wants a TE LSP computed AND wants PCE state metrics gathered at the same time. For out-of-band monitoring requests, the objects in this section are carried inside PCMonReq and PCMonRep messages instead 🦋
Every TLV carried in an object defined in this document uses the TLV format from [RFC5440], which has these three parts:
- Type: 2 bytes
- Length: 2 bytes
- Value: variable
So a PCEP object TLV is 2 bytes of type, 2 bytes of length, and then a value field. The Length field tells you how long the value portion is, in bytes. The TLV gets padded to 4-byte alignment, but that padding does NOT count toward the Length field. For example, a 3-byte value would have a Length of 3, but the whole TLV would take up 8 bytes in total 🧮 And one more important bit: unrecognized TLVs MUST be ignored 🙈✨
4.1. MONITORING Object 💖
Okay bestie, the MONITORING object is the main event here 🦋. It MUST be present in PCMonReq and PCMonRep messages (that's the out-of-band monitoring requests), and it MAY ride along in PCRep and PCReq messages (the in-band ones) ✨. There SHOULD NOT be more than one MONITORING object in a PCMonReq or PCMonRep message. If there's more than one anyway, the recipient MUST process the first instance and MUST ignore the rest 🙈. Not the vibe, but it's the rule.
The MONITORING object is how you say which PCE state metrics you want, so it's basically your shopping list 🛍️.
The MONITORING Object-Class (19) has been assigned by IANA 🌸. The MONITORING Object-Type (1) has been assigned by IANA too 🎀.
The body is laid out like this 👑:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |I|C|P|G|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Monitoring-id-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLV(s) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags: 24 bits 💅. These flags are currently defined:
- L (Liveness) - 1 bit: when this is set, it means the state metric you care about is the PCE's liveness 🫶. So the PCE MUST include a PCE-ID object in the reply. The L bit MUST always be ignored in a PCMonRep or PCRep message, so don't panic if it shows up there 💀.
- G (General) - 1 bit: when this is set, it's a general monitoring request ✨. When the performance metric you asked for is specific, the G bit MUST be cleared. The G bit MUST always be ignored in a PCMonRep or PCRep message.
- P (Processing Time) - 1 bit: a PCMonReq or PCReq carrying the P bit is saying processing time is a metric of interest 🧚. If policy allows it, a PROC-TIME object MUST be inserted in the matching PCMonRep or PCRep message. The P bit MUST always be ignored in a PCMonRep or PCRep message.
- C (Overload) - 1 bit: same energy, but for overload status 🔥. If the C bit is set in a PCMonReq or PCReq, an OVERLOAD object MUST be inserted in the matching PCMonRep or PCRep message. The C bit MUST always be ignored in a PCMonRep or PCRep message.
- I (Incomplete) - 1 bit: this one's for the PCE 🌈. If a PCE supports a PCMonReq it received, and the request doesn't trigger any policy violation, but the PCE still can't provide any of the requested metrics for unspecified reasons, the PCE MUST set the I bit. The I bit has no meaning in a request and SHOULD be ignored on receipt.
Monitoring-id-number (32 bits) 🍓: this value plus the PCC-REQ-ID of the requesting PCC uniquely identifies the monitoring request context, which is the bit that keeps everything from getting tangled 🧶. The monitoring-id-number MUST start at a non-zero value and MUST be incremented every time a new monitoring request goes out to a PCE. Each increment SHOULD be 1, and it's allowed to wrap back to zero 🔄. If no reply comes back from the PCE and the PCC wants to resend its path computation monitoring request, the same monitoring-id-number MUST be used ✨. Going the other way, a different monitoring-id-number MUST be used for different requests sent to a PCE. A PCEP implementation SHOULD checkpoint the Monitoring-id-number of pending monitoring requests in case of restart 🛟, which helps it avoid reusing the number of a monitoring request that's still in process.
Unassigned bits count as reserved 🔒. They MUST be set to zero on transmission and ignored on reception. Don't get clever with them, periodt.
No optional TLVs are currently defined 🫧.
4.2. PCC-ID-REQ Object 🎀
The PCC-ID-REQ object is how you specify the IP address of the requesting PCC 📍. The PCC-ID-REQ MUST be inserted within a PCReq or a PCMonReq message to do that. No skipping it 🙅♀️.
There are two PCC-ID-REQ objects, one for IPv4 and one for IPv6 🌈. PCC-ID-REQ Object-Class (20) has been assigned by IANA. PCC-ID-REQ Object-Type (1 for IPv4 and 2 for IPv6) has been assigned by IANA as well 🦋.
The IPv4 and IPv6 bodies look like this 💜:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The PCC-ID-REQ object body has a fixed length of 4 octets for IPv4 and 16 octets for IPv6 📏✨.
4.3. PCE-ID Object 🧚
The PCE-ID object is used to specify a PCE's IP address 🛰️. It has two jobs, and both are kind of iconic 👑. It can list the PCEs you want monitoring data for, and it can also specify the IP address of the requesting PCC.
A set of PCE-ID objects MAY be inserted within a PCReq or a PCMonReq message to name the PCEs whose PCE state metrics you're requesting. Hmm, let me be precise, because the original says it's inserted in a PCReq or PCMonReq to specify the PCE for which metrics are requested 🫶. And in a PCMonRep or PCRep message, they record the IP address of the PCE that reported the PCE state metrics, or that was involved in the path computation chain 🔗.
Two PCE-ID objects (for IPv4 and IPv6) are defined 🌸. PCE-ID Object-Class (25) has been assigned by IANA. PCE-ID Object-Type (1 for IPv4 and 2 for IPv6) has been assigned by IANA too 💅.
Here are the bodies for IPv4 and IPv6 📐:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The PCE-ID object body has a fixed length of 4 octets for IPv4 and 16 octets for IPv6 🎀.
When a dynamic discovery mechanism is used for PCE discovery 🔍, a PCE advertises its PCE address in the PCE-ADDRESS sub-TLV defined in [RFC5088] and [RFC5089] 📣. A PCC MUST use this address in PCReq and PCMonReq messages, and a PCE MUST also use this address in PCRep and PCMonRep messages. No freelancing on the address, bestie 🫶✨.
4.4. PROC-TIME Object ✨
okay so, if policy allows it, the PCE tacks a PROC-TIME object onto a PCMonRep or a PCRep message whenever the P bit of the MONITORING object in the matching PCMonReq or PCReq is set 🙌 it's how the PCE reports all its processing-time metrics 📊
1) Case of general monitoring requests 🌸
a PCC can ask for processing-time stats in general, like "what's the minimum, maximum, and average processing time on this PCE?" 🧐 general requests can ONLY go through PCMonReq/PCMonRep messages. the Current-processing-time field is only for specific requests, so it MUST be cleared for general ones 🧹 how the PCE actually crunches the min, max, average, and variance numbers is out of scope for this doc. the PCE could do the minimum over a window of time, or over its last N path computation requests, or whatever else it wants 🤷♀️
2) Case of specific monitoring requests 🎀
for a specific request, how the PCE computes the Processing-time metrics is also out of scope, but there's a flag that tells the requester whether the number was estimated or actually computed 🔍 the PCE can either (1) estimate the processing time without doing a real path computation, or (2) actually run the computation and report how long it took ⏱️ in the first case, the E bit of the PROC-TIME object MUST be set 💅 the G bit MUST be cleared, and the Min-processing-time, Max-processing-time, Average-processing-time, and Variance-processing-time MUST be set to 0x00000000 🫶
when processing time is requested alongside a path computation (so the MONITORING object is inside a PCReq message), the PROC-TIME object always reports the real processing time for that request, so the E bit MUST be cleared 💖
The PROC-TIME Object-Class (26) has been assigned by IANA. ✨
The PROC-TIME Object-Type (1) has been assigned by IANA. ✨
here's the body layout 👀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |E|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Current-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Average-processing time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variance-processing-time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags: 16 bits, and only one flag is defined so far 🦋
E (Estimated), 1 bit: when it's set, the metric is based on estimated processing time rather than actual computations 🧠
Unassigned bits are reserved, and they MUST be set to zero on transmission 🚫
Current-processing-time: in milliseconds, the processing time for the path computation of interest from the corresponding PCMonReq message ⏳
Min-processing-time: in milliseconds, the minimum processing time 📉
Max-processing-time: in milliseconds, the maximum processing time 📈
Average-processing-time: in milliseconds, the average processing time 🎯
Variance-processing-time: in milliseconds, the variance of the processing times 🌈
bestie, this part is lowkey important 😭 since a PCC might use monitoring metrics as an input when it picks a PCE, the MAY be required to normalize how time metrics (along with the other metrics described in a further revision of this document) are computed, so that a set of PCEs' monitoring metrics stay consistent with each other 💜 MAY, yes, it's a real MAY in there 🙈
4.5. OVERLOAD Object 🔥
the OVERLOAD object reports a PCE's processing congestion state 🚦 quick heads up, "overload" here is about the PCE's processing state and whether it can take on new PCEP requests 🫧 a PCE is overloaded when it has a backlog of PCEP requests, so it can't start on a new request right away and things end up waiting ⏳ the overload duration is measured as the (estimated) time until the PCE expects it can immediately process a new PCEP request 🧚
The OVERLOAD object MUST be present within a PCMonRep or a PCRep message if the C bit of the MONITORING object carried within the corresponding PCMonReq or PCReq message is set and the PCE is experiencing a congested state. ✨ The OVERLOAD Object-Class (27) has been assigned by IANA. The overload Object-Type (1) has been assigned by IANA. 🎀
the CONGESTION object body layout is 👇
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | Reserved | Overload Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Flags: 8 bits, and no flag is defined right now 🫥
Overload duration, 16 bits: in seconds, the amount of time the responding PCE expects it may still be overloaded, counted from when the response message was generated ⏰ the receiver MAY use this value to decide whether or not to send further requests to the same PCE 💅
it's worth noting that a PCE in the path computation chain that's involved in the monitoring request may decide to learn from the overload info it gets from one of its downstream PCEs 🧠🔗
5. Policy 🛡️
getting a PCMonReq might trigger a policy violation on some PCE 🚨 if that happens, the PCE MUST send a PCErr message with Error-type=5 and Error-value=6 🙅♀️
6. Elements of Procedure 📜
I bit processing: as Section 4.1 says, if a PCE supports a received PCMonReq and that message doesn't trigger any policy violation, but the PCE still can't provide any of the requested performance metrics for unspecified reasons, the PCE MUST set the I bit 🙋♀️ once it's set, the I bit MUST NOT be changed by a receiving PCE 🔒
Upon receiving a PCMonReq message: 💌
- As specified in [RFC5440], if the PCE doesn't support the PCMonReq message, the PCE peer MUST send a PCErr message with Error-value=2 (capability not supported). According to the procedure defined in Section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages at a rate equal of greater than specified rate, the PCC/PCE must send a PCEP CLOSE message with close value=5 "Reception of an unacceptable number of unrecognized PCEP messages". In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session. 💀
- If the PCE supports the PCMonReq message but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in Section 5. As pointed out in Section 4.3, a PCE may still partially satisfy a request, leaving out some of the required data if not allowed by policy. 🫶
- If the PCE supports the PCMonReq and the monitoring request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCMonReq message is relayed to the next-hop PCE: such a next hop may be either specified by means of a PCE-ID object present in the PCMonReq message or dynamically determined by means of a procedure outside of the scope of this document. Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCMonRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING object carried in the corresponding PCMonReq message. 🌟
Upon receiving a PCReq message that carries a MONITORING and potentially other monitoring objects (e.g., PCE-ID object): 🧚
- As specified in [RFC5440], if the PCE doesn't support (in-band) monitoring, the PCE peer MUST send a PCErr message with Error-value=2 (capability not supported). According to the procedure defined in Section 6.9 of [RFC5440], if a PCC/PCE receives unrecognized messages at a rate equal or greater than a specified rate, the PCC/PCE must send a PCEP CLOSE message with close value=5 "Reception of an unacceptable number of unrecognized PCEP messages". In this case, the PCC/PCE must also close the TCP session and must not send any further PCEP messages on the PCEP session. 😭
- If the PCE supports the monitoring request but the monitoring request is prohibited by policy, the PCE must follow the procedure specified in Section 5. As pointed out in Section 4.3, a PCE may still partially satisfy a request, leaving out some of the required data if not allowed by policy. 🙈
- If the PCE supports the monitoring request and that request is not prohibited by policy, the receiving PCE MUST first determine whether it is the last PCE of the path computation chain. If the PCE is not the last element of the path computation chain, the PCReq message (with the MONITORING object and potentially other monitoring objects such as the PCE-ID) is relayed to the next-hop PCE: such a next hop may be either specified by means of a PCE-ID object present in the PCReq message or dynamically determined by means of a procedure outside of the scope of this document.
Conversely, if the PCE is the last PCE of the path computation chain, the PCE originates a PCRep message that contains the requested objects according to the set of requested PCE states metrics listed in the MONITORING and potentially other monitoring objects carried in the corresponding PCReq message. 🍓
Upon receiving a PCMonRep message, the PCE processes the request, adds the relevant objects to the PCMonRep message, and forwards the PCMonRep message to the upstream requesting PCE or PCC 💫
Upon receiving a PCRep message that carries monitoring data, the message is processed, additional monitoring data is added according to this specification, and the message is forwarded upstream to the requesting PCE or PCC 🦋
7. Manageability Considerations ✨
7.1. Control of Function and Policy ✨
okay bestie, first things first: it MUST be possible to configure whether PCEP monitoring is turned on or off on a PCEP speaker 🔐💖 that's non-negotiable, no cap. On top of the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD let you configure on a PCE whether specific, generic, in-band and out-of-band monitoring requests are allowed 🎀. It SHOULD also let you set up a list of authorized state metrics (aliveness, overload, processing time, etc.) 📋✨. This can apply to every session the PCEP speaker is in, to one specific session with one PCEP peer, or to a whole group of sessions with a group of PCEP peers, like the PCEP peers of a neighbor AS 🌸🫶.
7.2. Information and Data Models 🧚
A new MIB Module MAY be defined that gives you local PCE state metrics, plus state metrics of other PCEs gathered using the mechanisms in this document 💜.
7.3. Liveness Detection and Monitoring 🦋
This document gives you mechanisms to keep an eye on the liveliness and performance of a given path computation chain 👀💅.
7.4. Verify Correct Operations 🍓
The mechanisms in this document don't add any new operation verification requirements beyond the ones already listed in [RFC5440] ✅. Not me being all "more checks!" lol 🙈.
7.5. Requirements on Other Protocols 🌈
Same vibe here: these mechanisms don't add any requirements on other protocols beyond what [RFC5440] already lists 🫶.
7.6. Impact on Network Operations 🔥
Okay, real talk: how often PCMonReq messages get sent can actually affect how PCEs operate 😭. So an implementation SHOULD let you put a limit on the rate of PCMonReq messages a PCEP speaker sends and processes from a peer 🚦. It SHOULD also be able to send a notification when a rate threshold gets hit 🔔. An implementation SHOULD let PCReq messages jump ahead of PCMonReq messages in priority 👑. And an implementation SHOULD let you configure a second limit for PCReq messages that are asking for monitoring data 💅✨.
8. Guidelines to Avoid Overload Thrashing 💀
The big worry when you're handling overload info is making sure the overload on one PCE doesn't just get moved onto another PCE 😬. Like, there's a real risk that reacting to an overload makes the overload in the network even worse 🌪️. And if the overload info isn't handled properly, PCEs can end up bouncing back and forth between each other 🎢.
This section gives some quick advice on how a PCC (which, FYI, includes a PCE making requests to another PCE) should react when it hears that a PCE is overloaded 🧁.
When an overload indication shows up (in a PCRep message or a PCMonRep message), it's telling you that new PCReq messages sent to that PCE might get delayed by the value in the Overload Duration field (when that field is present) ⏳.
It also means PCReq messages already queued at the PCE might get delayed too 😩. The PCC has to decide how to handle new PCReq messages and what to do about the ones already sitting in the PCE's queue 🤔.
It is RECOMMENDED that a PCC does not cancel a queued PCReq and reissue it to another PCE just because the PCE is overloaded 🙅♀️. That kind of move is likely to cause overload thrashing, since lots of PCCs keep shuffling the PCE queue over to other PCEs 🌀. It just adds more delay to processing everyone's requests 😭.
A PCC MAY choose to cancel a queued PCE request if it's willing to sacrifice that request, maybe reissuing it later (once the overload has been confirmed to clear with a PCMonReq/Rep exchange) 🦋.
It is then RECOMMENDED to send the cancellation request with a higher priority, so the overloaded PCE spots the cancellation before it processes the related request 🏃♀️💨.
A PCC that knows about PCE overload at one PCE MAY pick a different PCE to handle its next PCReq message 💖. When it does, it is RECOMMENDED that the PCC checks whether the other PCE is overloaded or might become overloaded soon because other PCCs are sending new PCReq messages its way too 👀.
And if that second PCE is overloaded as well, it is RECOMMENDED not to try switching back to the other PCE unless it knows the first PCE is no longer overloaded 🔁🙅♀️.
9. IANA Considerations 🎀
9.1. New PCEP Message 💌
Every PCEP message has a message type value 🏷️.
Two new PCEP messages (specified in [RFC5440]) are defined in this document 💫:
Value Description Reference
8 Path Computation Monitoring Request (PCMonReq) This document
9 Path Computation Monitoring Reply (PCMonRep) This document9.2. New PCEP Objects 🧸
Every PCEP object has an Object-Class and an Object-Type 🗂️. The following new PCEP objects are defined in this document 🌷:
Object-Class Value Name Object-Type Reference
19 MONITORING 1 This document
20 PCC-REQ-ID 1: IPv4 addresses This document
2: IPv6 addresses
25 PCE-ID 1: IPv4 addresses This document
2: IPv6 addresses This document
26 PROC-TIME 1 This document
27 OVERLOAD 1: overload This document9.3. New Error-Values 🚨
A registry was created for the Error-type and Error-value of the PCEP Error Object 📒.
A new Error-value for the PCErr message Error-type=5 (Policy Violation) (see [RFC5440]) is defined in this document 🙌:
Error-type Meaning Error-value Reference
5 Policy violation 6: Monitoring message This document
supported but rejected
due to policy violationA new Error-value for the PCErr message Error-type=6 (Mandatory object missing) (see [RFC5440]) is defined in this document 🙌:
Error-type Meaning Error-value Reference
6 Mandatory Object 4: MONITORING object This document
missing missing9.4. MONITORING Object Flag Field 🏳️
IANA has created a registry to manage the Flag field of the MONITORING object 🗃️.
New bit numbers may be allocated only by an IETF Review 🔍. Each bit should be tracked with the following qualities 📝:
- Bit number (counting from bit 0 as the most significant bit)
- Capability Description
- Defining RFC
Several bits are defined for the MONITORING Object flag field in this document 🌟:
Codespace of the Flag field (MONITORING Object)
Bit Description Reference
0-18 Unassigned
19 Incomplete This document
20 Overload This document
21 Processing Time This document
22 General This document
23 Liveness This document9.5. PROC-TIME Object Flag Field ⏱️
IANA has created a registry to manage the Flag field of the PROC-TIME object 🗂️.
New bit numbers may be allocated only by an IETF Review 🔍. Each bit should be tracked with the following qualities 📝:
- Bit number (counting from bit 0 as the most significant bit)
- Capability Description
- Defining RFC
One bit is defined for the PROC-TIME Object flag field in this document 🎯:
Codespace of the Flag field (PROC-TIME Object)
Bit Description Reference
0-14 Unassigned
15 Estimated This document9.6. OVERLOAD Object Flag Field 🏷️
IANA has created a registry to manage the Flag field of the OVERLOAD object 🗃️.
New bit numbers may be allocated only by an IETF Review 🔍. Each bit should be tracked with the following qualities 📝:
- Bit number (counting from bit 0 as the most significant bit)
- Capability Description
- Defining RFC
No Flag is currently defined for the OVERLOAD Object flag field in this document 🫥. Here's the codespace anyway:
Codespace of the Flag field (OVERLOAD Object)
Bit Description Reference
0-7 Unassigned10. Security Considerations 🚨🔐
Heads up, this one is serious. The monitoring data can be abused for attacks like denial-of-service (DoS) attacks, for example by setting the C bit and overload duration field of the OVERLOAD object to stop PCCs from using a PCE 😱.
So it is recommended to use the security mechanisms discussed in [RFC5440] to secure a PCEP session (authenticity, integrity, privacy, DoS protection, and so on) 🛡️. That covers securing the PCMonReq and PCMonRep messages and the PCE state metric objects defined in this document 🔒. An implementation SHOULD let you limit the rate at which PCMonReq or PCReq messages carrying monitoring requests from a specific peer get processed (input shaping), as discussed in Section 10.7.2 of [RFC5440], or from another domain (see also Section 7.6) 🚦💖.
11. Acknowledgments 🫶
The authors would like to thank Eiji Oki, Mach Chen, Fabien Verhaeghe, Dimitri Papadimitriou, and Francis Dupont for their useful comments 🙏. Special thanks to Adrian Farrel for his detailed review 🌟.
12. References 📚
12.1. Normative References 💎
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, April 2009.
[RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
Objective Functions in the Path Computation Element
Communication Protocol (PCEP)", RFC 5541, June 2009.12.2. Informative References 📖
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "OSPF Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5088, January 2008.
[RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R.
Zhang, "IS-IS Protocol Extensions for Path Computation
Element (PCE) Discovery", RFC 5089, January 2008.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441, April
2009.Authors' Addresses 🏡
JP. Vasseur (editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
JL. Le Roux
France Telecom
2, Avenue Pierre-Marzin
Lannion 22307
France
EMail: jeanlouis.leroux@orange-ftgroup.com
Yuichi Ikejiri
NTT Communications Corporation
1-1-6, Uchisaiwai-cho, Chiyoda-ku
Tokyo 100-8019
Japan
EMail: y.ikejiri@ntt.com📦 where this page comes from
- ietf: rfc5886 2010-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms