RFC 8231
Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
RFC 8231 🎀 Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE
(part 1 of 11)
Okay bestie, so this is RFC 8231 💖, and it's a Standards Track document, which means it's the real-deal, proper Internet standard category 💅. It came out in September 2017 from the IETF (Internet Engineering Task Force), and its ISSN is 2070-1721 ✨.
The authors are E. Crabbe from Oracle, I. Minei from Google, Inc., J. Medved from Cisco Systems, Inc., and R. Varga from Pantheon Technologies SRO 🫶. The title block doesn't list any RFCs that this one obsoletes or updates, so it's standing on its own 🦋.
Abstract 🌸
PCEP is the protocol that gives Path Computation Elements (PCEs) the tools to run path computations whenever Path Computation Clients (PCCs) send them requests 💅.
Here's the tea 🍵: PCEP explicitly makes no assumptions about what information the PCE has access to, but it also doesn't say anything about PCE control of the timing and sequence of path computations, either within or across PCEP sessions. So this document adds a set of extensions to PCEP that let you do stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) through PCEP 🧚.
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 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8231 🔥.
Copyright Notice
Copyright (c) 2017 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 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🙈
Table of Contents 📚
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Motivation and Objectives for Stateful PCE ......................6
3.1. Motivation .................................................6
3.1.1. Background ..........................................6
3.1.2. Why a Stateful PCE? .................................7
3.1.3. Protocol vs. Configuration ..........................8
3.2. Objectives .................................................9
4. New Functions to Support Stateful PCEs ..........................9
5. Overview of Protocol Extensions ................................10
5.1. LSP State Ownership .......................................10
5.2. New Messages ..............................................11
5.3. Error Reporting ...........................................11
5.4. Capability Advertisement ..................................11
5.5. IGP Extensions for Stateful PCE Capabilities
Advertisement .............................................12
5.6. State Synchronization .....................................13
5.7. LSP Delegation ............................................16
5.7.1. Delegating an LSP ..................................16
5.7.2. Revoking a Delegation ..............................17
5.7.3. Returning a Delegation .............................19
5.7.4. Redundant Stateful PCEs ............................19
5.7.5. Redelegation on PCE Failure ........................20
5.8. LSP Operations ............................................21
5.8.1. Passive Stateful PCE Path Computation
Request/Response ...................................21
5.8.2. Switching from Passive Stateful to Active
Stateful ...........................................22
5.8.3. Active Stateful PCE LSP Update .....................23
5.9. LSP Protection ............................................24
5.10. PCEP Sessions ............................................24
6. PCEP Messages ..................................................25
6.1. The PCRpt Message .........................................25
6.2. The PCUpd Message .........................................27
6.3. The PCErr Message .........................................30
6.4. The PCReq Message .........................................31
6.5. The PCRep Message .........................................31
7. Object Formats .................................................32
7.1. OPEN Object ...............................................32
7.1.1. STATEFUL-PCE-CAPABILITY TLV ........................32
7.2. SRP Object ................................................33
7.3. LSP Object ................................................34
7.3.1. LSP-IDENTIFIERS TLVs ...............................36
7.3.2. Symbolic Path Name TLV .............................39
7.3.3. LSP Error Code TLV .................................40
7.3.4. RSVP Error Spec TLV ................................41
8. IANA Considerations ............................................42
8.1. PCE Capabilities in IGP Advertisements ....................42
8.2. PCEP Messages .............................................43
8.3. PCEP Objects ..............................................43
8.4. LSP Object ................................................44
8.5. PCEP-Error Object .........................................45
8.6. Notification Object .......................................46
8.7. PCEP TLV Type Indicators ..................................46
8.8. STATEFUL-PCE-CAPABILITY TLV ...............................47
8.9. LSP-ERROR-CODE TLV ........................................47
9. Manageability Considerations ...................................48
9.1. Control Function and Policy ...............................48
9.2. Information and Data Models ...............................49
9.3. Liveness Detection and Monitoring .........................49
9.4. Verifying Correct Operation ...............................49
9.5. Requirements on Other Protocols and Functional
Components ................................................50
9.6. Impact on Network Operation ...............................50
10. Security Considerations .......................................50
10.1. Vulnerability ............................................50
10.2. LSP State Snooping .......................................51
10.3. Malicious PCE ............................................51
10.4. Malicious PCC ............................................52
11. References ....................................................52
11.1. Normative References .....................................52
11.2. Informative References ...................................53
Acknowledgements ..................................................55
Contributors ......................................................56
Authors' Addresses ................................................571. Introduction ✨
[RFC5440] is where PCEP, the Path Computation Element Communication Protocol, is described 💖. PCEP sets up the conversation between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCEs themselves, so that Multiprotocol Label Switching (MPLS) can be computed for Traffic Engineering Label Switched Path (TE LSP) characteristics 🧚. The extensions that let PCEP support Generalized MPLS (GMPLS) are defined in [PCEP-GMPLS].
This document specifies a set of extensions to PCEP that enable stateful control of LSPs, both within and across PCEP sessions, in compliance with [RFC4657] 🎀. It brings in mechanisms for Label Switched Path (LSP) State Synchronization between PCCs and PCEs, for handing control of LSPs over to PCEs (delegation), and for PCE control of the timing and sequence of path computations within and across PCEP sessions 👑.
Extensions that let the PCE kick off the creation of an LSP are a whole other story, defined in [PCE-Init-LSP], which specifies PCE-initiated LSP creation 🦋.
1.1. Requirements Language
Quick keyword check 📜: the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, exactly as shown here 💅.
2. Terminology 📖
This document uses the following terms from [RFC5440]: PCC, PCE, PCEP Peer, and PCEP speaker 💜.
It also uses the following term from [RFC4655]: Traffic Engineering Database (TED) 🌸.
It uses the following term from [RFC3031]: LSP 🍓.
It uses the following terms from [RFC8051]: Stateful PCE, Passive Stateful PCE, Active Stateful PCE, Delegation, and LSP State Database 🫶.
These terms are defined in this document:
- Revocation: an operation performed by a PCC on a previously delegated LSP. Revocation revokes the rights granted to the PCE in the delegation operation. 🔥
- Redelegation Timeout Interval: the period of time a PCC waits for, when a PCEP session is terminated, before revoking LSP delegation to a PCE and attempting to redelegate LSPs associated with the terminated PCEP session to an alternate PCE. The Redelegation Timeout Interval is a PCC-local value that can be either operator configured or dynamically computed by the PCC based on local policy. ⏳
- State Timeout Interval: the period of time a PCC waits for, when a PCEP session is terminated, before flushing LSP state associated with that PCEP session and reverting to operator-defined default parameters or behaviors. The State Timeout Interval is a PCC-local value that can be either operator configured or dynamically computed by the PCC based on local policy. 🕰️
- LSP State Report: an operation to send LSP state (operational/administrative status, LSP attributes configured at the PCC and set by a PCE, etc.) from a PCC to a PCE. 📨
- LSP Update Request: an operation where an Active Stateful PCE requests a PCC to update one or more attributes of an LSP and to re-signal the LSP with updated attributes. ✏️
- SRP-ID-number: a number used to correlate errors and LSP State Reports to LSP Update Requests. It is carried in the Stateful PCE Request Parameter (SRP) object described in Section 7.2. 🔗
Within this document, PCEP communications are described through PCC-PCE relationships. The PCE architecture also supports PCE-PCE communication, by having the requesting PCE fill the role of a PCC, as usual. 💞
The message formats in this document are specified using Routing Backus-Naur Format (RBNF) encoding as specified in [RFC5511] 🧁.
3. Motivation and Objectives for Stateful PCE 🎀
3.1. Motivation
okay so [RFC8051] lays out several use cases showing when a stateful PCE is actually worth it 🦋 and the best part is that the scenarios apply equally to MPLS-TE and GMPLS deployments ✨
3.1.1. Background
traffic engineering has been a goal of the MPLS architecture since literally the beginning [RFC2702] [RFC3031] [RFC3346] 🌸 in the traffic engineering system from [RFC3209], [RFC3630], and [RFC5305], info about network resource utilization is only visible as total reserved capacity by traffic class on a per-interface basis. individual LSP state is only available locally on each Label Edge Router (LER) for its own LSPs 💅 ngl that makes sense, because keeping total LSP state for all LERs across the whole network would be prohibitively costly 😭
tbh though, that global visibility gap can cause problems for some demand patterns, especially when LSPs share a common setup and hold priority 🙈 and it hits online traffic engineering systems the hardest.
a sufficiently over-provisioned system will by definition have no issues routing its demand on the shortest path 👑 but being able to lower how much over-provisioning you need to run a healthy network is a clear and explicit promise of the MPLS architecture 🔥 it has always been a goal of MPLS to provide mechanisms that ease congestion, where "traffic streams are inefficiently mapped onto available resources; causing subsets of network resources to become over-utilized while others remain underutilized" [RFC2702] 💀
3.1.2. Why a Stateful PCE?
so [RFC4655] defines a stateful PCE as one that keeps "strict synchronization between the PCE and not only the network states (in term of topology and resource information), but also the set of computed paths and reserved resources in use in the network." ✨ [RFC4655] also raised some concerns about stateful PCEs, specifically:
- Any reliable synchronization mechanism would result in significant control-plane overhead
- Out-of-band TED synchronization would be complex and prone to race conditions
- Path calculations incorporating total network state would be highly complex
in general, stress on the control plane is directly proportional to the size of the system being controlled and the tightness of the control loop, and indirectly proportional to the amount of over-provisioning in terms of both network capacity and reservation overhead 🧚
but despite those implementation and scalability worries, several TE algorithms exist today that have been shown to be extremely effective in large TE systems, giving both rapid convergence and big wins in optimality of resource usage [MXMN-TE] 🤩 all of these systems share at least two traits: they need global visibility of a flow (or, in this case, a TE LSP) state, and they need ordered control of path reservations across the devices in the system being controlled 🫶 some approaches have been suggested to drop the need for ordered control (see [MPLS-PC]), but those are highly dependent on traffic distribution and don't allow multiple simultaneous LSP priorities representing Diffserv classes 🙅♀️
the use cases in [RFC8051] show a need for visibility into global inter-PCC LSP state in PCE path computations, and for PCE control of sequence and timing when altering LSP path characteristics within and across PCEP sessions 💖
3.1.3. Protocol vs. Configuration
ok but wait, existing configuration tools and protocols can already set LSP state, like a Command Line Interface (CLI) tool 💻 however, that solution has a few shortcomings:
- Scale & Performance: configuration operations often have transactional semantics that are typically heavyweight and often require processing of additional configuration portions beyond the state being directly acted upon, with corresponding cost in CPU cycles, negatively impacting both PCC stability LSP Update rate capacity.
- Security: when a PCC opens a configuration channel allowing a PCE to send configuration, a malicious PCE may take advantage of this ability to take over the PCC. in contrast, the PCEP extensions described in this document only allow a PCE control over a very limited set of LSP attributes 🔒
- Interoperability: each vendor has a proprietary information model for configuring LSP state, which limits interoperability of a stateful PCE with PCCs from different vendors. the PCEP extensions described in this document allow for a common information model for LSP state for all vendors 🌈
- Efficient State Synchronization: configuration channels may be heavyweight and unidirectional; therefore, efficient State Synchronization between a PCC and a PCE may be a problem 😵💫
3.2. Objectives
the objectives for the protocol extensions that support stateful PCE in this document are as follows 🎯
- Allow a single PCC to interact with a mix of stateless and stateful PCEs simultaneously using the same protocol, i.e., PCEP.
- Support efficient LSP State Synchronization between the PCC and one or more active or passive stateful PCEs.
- Allow a PCC to delegate control of its LSPs to an active stateful PCE such that a given LSP is under the control of a single PCE at any given time.
- A PCC may revoke this delegation at any time during the lifetime of the LSP. If LSP delegation is revoked while the PCEP session is up, the PCC MUST notify the PCE about the revocation. 🚨
- A PCE may return an LSP delegation at any point during the lifetime of the PCEP session. If LSP delegation is returned by the PCE while the PCEP session is up, the PCE MUST notify the PCC about the returned delegation. 🔁
- Allow a PCE to control computation timing and update timing across all LSPs that have been delegated to it.
- Enable uninterrupted operation of a PCC's LSPs in the event of a PCE failure or while control of LSPs is being transferred between PCEs. 🛡️
4. New Functions to Support Stateful PCEs ✨
several new functions are required in PCEP to support stateful PCEs 🧁 a function can be initiated either from a PCC towards a PCE (C-E) or from a PCE towards a PCC (E-C). the new functions are:
Capability advertisement (E-C,C-E): both the PCC and the PCE must announce during PCEP session establishment that they support the PCEP Stateful PCE extensions defined in this document. 📣
LSP State Synchronization (C-E): after the session between the PCC and a stateful PCE is initialized, the PCE must learn the state of a PCC's LSPs before it can perform path computations or update LSP attributes in a PCC. 🧠
LSP Update Request (E-C): a PCE requests modification of attributes on a PCC's LSP. ✏️
LSP State Report (C-E): a PCC sends an LSP State Report to a PCE whenever the state of an LSP changes. 📬
LSP control delegation (C-E,E-C): a PCC grants to a PCE the right to update LSP attributes on one or more LSPs; the PCE becomes the authoritative source of the LSP's attributes as long as the delegation is in effect (see Section 5.7); the PCC may withdraw the delegation or the PCE may give up the delegation at any time. 🤝
similarly to [RFC5440], no assumption is made about the discovery method a PCC uses to discover a set of PCEs (e.g., via static configuration or dynamic discovery), or about the algorithm used to select a PCE. 🔍
5. Overview of Protocol Extensions 🌷
5.1. LSP State Ownership
in PCEP (defined in [RFC5440]), LSP state and operation are under the control of a PCC (a PCC may be a Label Switching Router (LSR) or a management station). attributes received from a PCE are subject to the PCC's local policy. the PCEP extensions described in this document do not change this behavior 🙌
an active stateful PCE may have control of a PCC's LSPs that were delegated to it, but the LSP state ownership is retained by the PCC. in particular, in addition to specifying values for LSP's attributes, an active stateful PCE also decides when to make LSP modifications 🕰️
retaining LSP state ownership on the PCC allows for:
- a PCC to interact with both stateless and stateful PCEs at the same time
- a stateful PCE to only modify a small subset of LSP parameters, i.e., to set only a small subset of the overall LSP state; other parameters may be set by the operator, for example, through CLI commands
- a PCC to revert delegated LSP to an operator-defined default or to delegate the LSPs to a different PCE, if the PCC gets disconnected from a PCE with currently delegated LSPs 🔄
5.2. New Messages
in this document, we define the following new PCEP messages 📨
Path Computation State Report (PCRpt): a PCEP message sent by a PCC to a PCE to report the status of one or more LSPs. Each LSP State Report in a PCRpt message MAY contain the actual LSP's path, bandwidth, operational and administrative status, etc. An LSP Status Report carried on a PCRpt message is also used in delegation or revocation of control of an LSP to/from a PCE. The PCRpt message is described in Section 6.1. 📊
Path Computation Update Request (PCUpd): a PCEP message sent by a PCE to a PCC to update LSP parameters, on one or more LSPs. Each LSP Update Request on a PCUpd message MUST contain all LSP parameters that a PCE wishes to be set for a given LSP. An LSP Update Request carried on a PCUpd message is also used to return LSP delegations if at any point the PCE no longer desires control of an LSP. The PCUpd message is described in Section 6.2. 🛠️
the new functions defined in Section 4 are mapped onto the new messages as shown in the following table 🗺️
+----------------------------------------+--------------+
| Function | Message |
+----------------------------------------+--------------+
| Capability Advertisement (E-C,C-E) | Open |
| State Synchronization (C-E) | PCRpt |
| LSP State Report (C-E) | PCRpt |
| LSP Control Delegation (C-E,E-C) | PCRpt, PCUpd |
| LSP Update Request (E-C) | PCUpd |
+----------------------------------------+--------------+
Table 1: New Function to Message Mapping5.3. Error Reporting
error reporting is done using the procedures defined in [RFC5440], reusing the applicable error types and error values of [RFC5440] wherever appropriate. the current document defines new error values for several error types to cover failures specific to stateful PCE 🚫💜
5.4. Capability Advertisement ✨
Okay bestie, so during the PCEP initialization phase, both PCEP speakers (the PCE and the PCC) announce that they're ready for the PCEP Stateful PCE extensions 💅. A speaker tucks the STATEFUL-PCE-CAPABILITY TLV, described in Section 7.1.1, into its OPEN object to say "yep, I can do stateful things" 🎀. That TLV has an LSP Update flag that tells you whether the speaker can handle LSP parameter updates 🦋.
If a PCC puts the STATEFUL-PCE-CAPABILITY TLV in its OPEN object, it's basically saying it's willing to send LSP State Reports whenever LSP parameters or operational status change 📨. If a PCE puts it in its OPEN message, that means the PCE is interested in getting those LSP State Reports whenever LSP parameters or operational status change 👑.
The stateful PCEP extensions MUST NOT be used if one or both PCEP speakers didn't include the STATEFUL-PCE-CAPABILITY TLV in their OPEN message. 🙅♀️ Now, if the PCC's speaker supports this spec but never advertised the capability, and then it gets a PCUpd message from the PCE, it MUST generate a PCEP Error (PCErr) with Error-type=19 (Invalid Operation) and error-value 2 (Attempted LSP Update Request if the stateful PCE capability was not advertised) (see Section 8.5). It SHOULD also terminate the PCEP session 💀. Same energy on the PCE side: if the PCE's speaker supports the spec but didn't advertise, and it gets a PCRpt message from the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation) and error-value 5 (Attempted LSP State Report if stateful PCE capability was not advertised) (see Section 8.5), and it SHOULD terminate the PCEP session 😭.
LSP delegation and LSP Update operations from this document may only be used if both PCEP speakers set the LSP-UPDATE-CAPABILITY flag in the STATEFUL-PCE-CAPABILITY TLV to 'Updates Allowed (U flag = 1)' ✨. If that's not the case and someone tries LSP delegation or LSP Update operations anyway, a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP) (see Section 8.5) MUST be generated 🚫. Also, even if one speaker doesn't set the LSP-UPDATE-CAPABILITY flag, a PCE can still be a passive stateful PCE. It does that by accepting LSP State Reports from the PCC so it can build and maintain an up-to-date view of the PCC's LSPs 🔍. Lowkey genius.
5.5. IGP Extensions for Stateful PCE Capabilities Advertisement 🌈
So when PCCs are LSRs taking part in the IGP (OSPF or IS-IS), and PCEs are either LSRs or servers also in the IGP, an effective way to discover PCEs inside an IGP routing domain is to use IGP advertisements 🗺️. The extensions for advertising PCE Discovery Information are defined for OSPF in [RFC5088] and for IS-IS in [RFC5089], respectively 🧚.
The PCE-CAP-FLAGS sub-TLV, defined in [RFC5089], is an optional sub-TLV used to advertise PCE capabilities 🎀. It MAY be present within the PCE Discovery (PCED) sub-TLV carried by OSPF or IS-IS. [RFC5088] and [RFC5089] give the description and processing rules for this sub-TLV when it's carried within OSPF and IS-IS, respectively 📚.
Here's the format of the PCE-CAP-FLAGS sub-TLV, for easy reference 💖:
Type: 5
Length: Multiple of 4.
Value: This contains an array of units of 32-bit flags with the most
significant bit as 0. Each bit represents one PCE capability.PCE capability bits are defined in [RFC5088]. This document adds new capability bits for the stateful PCE, like so 🦋:
Bit Capability
--- -------------------------------
11 Active stateful PCE capability
12 Passive stateful PCE capabilityNote that even though active and passive stateful PCE capabilities can be advertised during discovery, PCEP speakers that want to use stateful PCEP MUST negotiate stateful PCEP capabilities during PCEP session setup, as this document specifies 🤝. A PCC MAY start stateful PCEP capability negotiation at PCEP session setup even if it didn't get any IGP PCE capability advertisements 🌸.
5.6. State Synchronization 📸
State Synchronization is all about giving a PCE a checkpoint-in-time replica of a PCC's LSP state 🪞. It happens right after the initialization phase [RFC5440] 💅.
During State Synchronization, a PCC first takes a snapshot of its LSP state. Then it sends that snapshot to a PCE in a sequence of LSP State Reports 📨. Each LSP State Report sent during State Synchronization has the SYNC flag in the LSP object set to 1 🔁. The set of LSPs whose state gets synchronized with a PCE is decided by the PCC's local configuration (see more details in Section 9.1), and it MAY also be decided by stateful PCEP capabilities defined in other documents, like [RFC8232] ⚙️.
The end-of-sync marker is a PCRpt message with the SYNC flag set to 0, for an LSP object whose PLSP-ID is the reserved value 0 (see Section 7.3) 🏁. In this case, the LSP object SHOULD NOT include the SYMBOLIC-PATH-NAME TLV, and SHOULD include the LSP-IDENTIFIERS TLV with the special value of all zeroes 🫶. The PCRpt message MUST include an empty Explicit Route Object (ERO) as its intended path, and SHOULD NOT include the optional Record Route Object (RRO) for its actual path 🛣️. If the PCC has no state to synchronize, it SHOULD only send the end-of-sync marker 🤷♀️.
A PCE SHOULD NOT send PCUpd messages to a PCC before State Synchronization is complete, and a PCC SHOULD NOT send PCReq messages to a PCE before State Synchronization is complete 🙈. This is so the PCE can get the best possible view of the network before it starts computing new paths 🧠.
Either the PCE or the PCC MAY terminate the session using the PCEP session termination procedures during the synchronization phase 🛑. If the session gets terminated, the PCE MUST clean up the state it received from this PCC 🧹. The session re-establishment MUST be re-attempted per the procedures in [RFC5440], including use of a backoff timer ⏳.
If the PCC runs into a problem that stops it from finishing LSP State Synchronization, it MUST send a PCErr message with error-type 20 (LSP State Synchronization Error) and error-value 5 (indicating an internal PCC error) to the PCE, and then terminate the session 🚨.
The PCE doesn't send positive acknowledgments for synchronization messages it properly receives 🤐. But if the PCE runs into a problem with an LSP State Report it got from the PCC, it MUST respond with a PCErr message with Error-type=20 (LSP State Synchronization Error) and error-value 1 (indicating an error in processing the PCRpt) (see Section 8.5), and it MUST terminate the session 😱.
A PCE that limits the resources a single PCC can occupy MUST send a PCEP Notify (PCNtf) message with Notification Type 4 (Stateful PCE resource limit exceeded) and Notification Value 1 (Entering resource limit exceeded state) in response to the PCRpt message that triggers this condition during the synchronization phase, and it MUST terminate the session 🚫🧱.
The successful State Synchronization sequence is shown in Figure 1 🎬:
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->| (Sync start)
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
| |
|-----PCRpt, SYNC=0----->| (End of sync marker
| | LSP State Report
| | for PLSP-ID=0)
| | (Sync done)Figure 1: Successful State Synchronization
The sequence where the PCE fails during the State Synchronization phase is shown in Figure 2 💀:
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->|
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-----PCRpt, SYNC=1----->|
| |
|-PCRpt, SYNC=1 |
| \ ,-PCErr |
| \ / |
| \/ |
| /\ |
| / `-------->| (Ignored)
|<--------` |Figure 2: Failed State Synchronization (PCE Failure)
And the sequence where the PCC fails during the State Synchronization phase is shown in Figure 3 🥲:
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|-----PCRpt, SYNC=1----->|
| |
|-----PCRpt, SYNC=1----->|
| . |
| . |
| . |
|-------- PCErr=? ------>|
| |Figure 3: Failed State Synchronization (PCC Failure)
Optimizations to the synchronization procedures, and alternate ways of providing the synchronization function, are out of scope for this document. They're discussed elsewhere (see [RFC8232]) 📖.
5.7. LSP Delegation 🤝
If, during capability advertisement, both the PCE and the PCC have indicated that they support LSP Update, then the PCC may choose to give the PCE a temporary right to update (a subset of) LSP attributes on one or more LSPs 👑. This is called "LSP delegation", and it MAY be performed at any time after the initialization phase, including during the State Synchronization phase 🫧.
A PCE MAY return an LSP delegation at any time if it no longer wants to update the LSP's state 🔙. A PCC MAY revoke an LSP delegation at any time 🚪. Delegation, Revocation, and Return are each done individually for each LSP 🎀.
If a PCE rejects or returns a delegation, the PCC SHOULD react based on local policy 🧭. For example, it can either retry delegating to the same PCE using an exponentially increasing timer, or delegate to an alternate PCE 🔁✨.
5.7.1. Delegating an LSP ✨
okay so a PCC delegates an LSP to a PCE by setting the Delegate flag in the LSP State Report to 1 💅. if the PCE doesn't accept the delegation, it MUST immediately respond with an empty LSP Update Request that has the Delegate flag set to 0. if the PCE does accept, it MUST set the Delegate flag to 1 when it sends an LSP Update Request for the delegated LSP (and this might happen later on, fr 🕰️). the PCE MAY also immediately acknowledge a delegation by sending an empty LSP Update Request that has the Delegate flag set to 1 🦋.
the whole delegation sequence looks like this 🧚:
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->| LSP delegated
| |
|---PCRpt, Delegate=1--->|
| . |
| . |
| . |
|<--(PCUpd,Delegate=1)---| Delegation confirmed
| |
|---PCRpt, Delegate=1--->|
| |
Figure 4: Delegating an LSPngl the main thing to remember is that for an LSP to stay delegated to a PCE, the PCC MUST set the Delegate flag to 1 on each LSP State Report it sends to that PCE 🫶💖.
5.7.2. Revoking a Delegation 🙈
5.7.2.1. Explicit Revocation
when a PCC decides a PCE is no longer allowed to modify an LSP, it revokes that LSP's delegation to the PCE 🚫. a PCC can revoke an LSP delegation at any time during the LSP's lifetime 🌸. a PCC revoking an LSP delegation MAY immediately remove the updated parameters provided by the PCE and go back to the operator-defined parameters, but to avoid traffic loss, it SHOULD do so in a make-before-break fashion 🛡️. if the PCC has received but not yet acted on PCUpd messages from the PCE for the LSP whose delegation is being revoked, then it SHOULD ignore those PCUpd messages when it processes the message queue 🙅♀️. all effects of all messages whose processing started before the revocation took place MUST be allowed to complete, and the result MUST be given the same treatment as any LSP that had been previously delegated to the PCE (e.g., the state MAY immediately revert to the operator-defined parameters) ✨.
if a PCEP session with the PCE the LSP is delegated to exists in the UP state during the revocation, the PCC MUST notify that PCE by sending an LSP State Report with the Delegate flag set to 0, as shown in Figure 5 📣.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->|
| |
|<--(PCUpd,Delegate=1)---| Delegation confirmed
| . |
| . |
| . |
|---PCRpt, Delegate=0--->| PCC revokes delegation
| |
Figure 5: Revoking a Delegationafter an LSP delegation has been revoked, the PCE can no longer update that LSP's parameters 🥲. if it tries anyway, the PCC will send a PCErr message with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP) (see Section 8.5) 🚨.
5.7.2.2. Revocation on Redelegation Timeout
when a PCC's PCEP session with a PCE terminates unexpectedly, the PCC MUST wait the time interval specified in the Redelegation Timeout Interval before it revokes LSP delegations to that PCE and tries to redelegate those LSPs to an alternate PCE ⏳. if a PCEP session with the original PCE can be re-established before the Redelegation Timeout Interval timer expires, the LSP delegations to that PCE stay intact 🥰.
likewise, when a PCC's PCEP session with a PCE terminates unexpectedly and the PCC does not succeed in redelegating its LSPs, the PCC MUST wait for the State Timeout Interval before flushing any LSP state associated with that PCE 🧹. the State Timeout Interval timer may expire before the PCC has redelegated the LSPs to another PCE, for example if the PCC isn't connected to any active stateful PCE, or if no connected active stateful PCE accepts the delegation 😬. in that case, the PCC MUST flush any LSP state set by the PCE when the State Timeout Interval expires and revert to operator-defined default parameters or behaviors. this operation SHOULD be done in a make-before-break fashion 🛡️✨.
the State Timeout Interval MUST be greater than or equal to the Redelegation Timeout Interval, and it MAY be set to infinity (meaning that until the PCC specifically takes action to change the parameters set by the PCE, they will remain intact) ♾️💜.
5.7.3. Returning a Delegation 🔁
so, in order to keep a delegation, a PCE MUST set the Delegate flag to 1 on each LSP Update Request it sends to the PCC 💅. a PCE that no longer wants to update an LSP's parameters SHOULD give the LSP delegation back to the PCC by sending an empty LSP Update Request that has the Delegate flag set to 0 🎀. if a PCC receives an LSP Update Request with the Delegate flag set to 0 (whether the LSP Update Request is empty or not), it MUST treat that as a delegation return 🫡.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---PCRpt, Delegate=1--->| LSP delegated
| . |
| . |
| . |
|<--PCUpd, Delegate=0----| Delegation returned
| |
|---PCRpt, Delegate=0--->| No delegation for LSP
| |
Figure 6: Returning a Delegationif a PCC can't delegate an LSP to a PCE (for example, if the PCC isn't connected to any active stateful PCE, or if no connected active stateful PCE accepts the delegation), the LSP delegation on the PCC will time out within a configurable Redelegation Timeout Interval 🕰️. and at that point the PCC MUST flush any LSP state set by a PCE when the State Timeout Interval expires, then revert to operator-defined default parameters or behaviors 🧹💫.
5.7.4. Redundant Stateful PCEs 👯♀️
in a redundant setup where one PCE is backing up another, the backup PCE may only have a subset of the network's LSPs delegated to it 🌈. the backup PCE does not update any LSPs that aren't delegated to it 🙅♀️. so the backup can run in hot-standby mode and skip State Synchronization if the primary fails, the backup receives all LSP State Reports from a PCC 📨. when the primary PCE for a given LSP set fails, the PCC SHOULD, after the Redelegation Timeout Interval expires, delegate to the redundant PCE all of the LSPs that had been previously delegated to the failed PCE 🦸♀️. assuming the State Timeout Interval was configured to be greater than the Redelegation Timeout Interval (as MANDATORY), and assuming the primary and redundant PCEs make similar decisions, this delegation change won't cause any changes to the LSP parameters 💖✅.
5.7.5. Redelegation on PCE Failure 💔➡️💚
on failure, the goal is to: 1) avoid any traffic loss on the LSPs that were updated by the PCE that crashed, 2) minimize the churn in the network in terms of ownership of the LSPs, 3) not leave any "orphan" (undelegated) LSPs, and 4) be able to control when the state that was set by the PCE can be changed or purged 🎯. the values chosen for the Redelegation Timeout and State Timeout affect how well we can hit those goals 🧠.
this section sums up what happens to LSP delegation and LSP state when a PCE fails 📋.
if the PCE crashes but recovers within the Redelegation Timeout, both the delegation state and the LSP state stay intact 🥳.
if the PCE crashes but doesn't recover within the Redelegation Timeout, the delegation state goes back to the PCC 🔙. if the PCC can redelegate the LSPs to another PCE, and that PCE accepts the delegations, there is no change in LSP state ✨. if the PCC can't redelegate the LSPs to another PCE, then once the State Timeout Interval expires, the state set by the PCE is removed and the LSP reverts to operator-defined parameters, which may cause a change in the LSP state 😱. note that an operator may choose an infinite State Timeout Interval if they want to keep the PCE state indefinitely ♾️. also note that flushing the state should be implemented using make-before-break to avoid traffic loss 🛡️.
if there is a standby PCE, the Redelegation Timeout may be set to 0 through policy on the PCC, which makes the LSPs redelegate immediately to the PCC, and the PCC can then delegate them right away to the standby PCE 🏃♀️💨. assuming the PCC can redelegate the LSP to the standby PCE within the State Timeout Interval, and assuming the standby PCE makes similar decisions to the failed PCE, the LSP state will be kept intact 🥹🎀.
5.8. LSP Operations 🌟
5.8.1. Passive Stateful PCE Path Computation Request/Response ✨
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) Path computation |----- PCReq message --->|
request sent to | |2) Path computation
PCE | | request received,
| | path computed
| |
|<---- PCRep message ----|3) Computed paths
| (Positive reply) | sent to the PCC
| (Negative reply) |
4) LSP state change | |
event | |
| |
5) LSP State Report |----- PCRpt message --->|
sent to all | . |
stateful PCEs | . |
| . |
6) Repeat for each |----- PCRpt message --->|
LSP state change | |
| |
Figure 7: Passive Stateful PCE Path Computation Request/Responseokay so once a PCC has successfully set up a PCEP session with a passive stateful PCE and its LSP state is synced up (aka the PCE knows about all of the PCC's existing LSPs 🫶), the vibe is: if some event pops off that needs a set of paths computed, the PCC sends a path computation request to the PCE ([RFC5440], Section 4.2.3). The PCReq message MAY contain the LSP object so the PCE knows exactly which LSP the request is about 💅
when the PCE gets a path computation request from a PCC, it triggers the computation and sends back either a positive or a negative reply ([RFC5440], Section 4.2.4). ✨
if the reply is positive, the PCC gets its set of computed paths and starts setting up the LSPs. for each LSP, it MAY send an LSP State Report on a PCRpt message to the PCE saying the status is "Going-up" 🚀
once an LSP is up or active, the PCC MUST send an LSP State Report on a PCRpt message to the PCE with the status 'Up' or 'Active', respectively. if the LSP couldn't be set up, the PCC MUST send an LSP State Report saying it's 'Down' AND why it failed 💀 also, timing is a lil chaotic, so the status can jump from 'Going-up' straight to 'Up' (or 'Down') before the PCC gets a chance to report 'Going-up'. in that case the PCC MAY choose to only send the PCRpt with the latest status ('Active', 'Up', or 'Down') 🦋
if a PCE sends back a negative reply, the PCC MAY resend a modified request or take any other appropriate action. for each requested LSP, it SHOULD also send an LSP State Report on a PCRpt message to the PCE saying the status is 'Down' 🙈
there's no direct one-to-one link between PCRep and PCRpt messages, bestie. for a given LSP, multiple LSP State Reports can follow a single PCRep message, since the PCC keeps the PCE posted on every state change 📬
the PCC MUST send each LSP State Report to each stateful PCE that's connected to it. ✨
and a single PCRpt message MAY contain multiple LSP State Reports, so it can be efficient about it 🎀
the passive stateful model for stateful PCEs is described in [RFC4655], Section 6.8. 🌸
5.8.2. Switching from Passive Stateful to Active Stateful 🦋
this section is all about an LSP transitioning from passive stateful mode to active stateful mode. when the LSP has no working path, the PCC MUST first use the procedure from Section 5.8.1 to request the initial path from the PCE before delegating the LSP. this is required because delegating an LSP to a PCE with a PCRpt message is NOT an explicit request for the PCE to compute a path. the only explicit way for a PCC to ask for a path is to send a PCReq message. the PCRpt message MUST NOT be used by the PCC to try to request a path from the PCE 🚫
when the LSP gets delegated after it's already been set up, it can be super useful for the PCC to tell the PCE the locally configured intended parameters, so the PCE can reuse them in its computations 🧠 those parameters MAY be acquired through an out-of-band channel, OR MAY be communicated in the PCRpt message that delegates the LSPs, by including them as part of the intended-attribute-list as explained in Section 6.1. and an implementation MAY let policies on the PCC decide which configuration parameters get sent to the PCE ✨
5.8.3. Active Stateful PCE LSP Update 🔥
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
1) LSP State |-- PCRpt, Delegate=1 -->|
Synchronization | . |
| . |2) PCE decides to
| . | update the LSP
| |
|<---- PCUpd message ----|3) PCUpd message sent
| | to the PCC
| |
| |
4) LSP State Report |---- PCRpt message ---->|
sent(->Going-up) | . |
| . |
| . |
5) LSP State Report |---- PCRpt message ---->|
sent (->Up|Down) | |
| |
Figure 8: Active Stateful PCEokay so once a PCC has successfully set up a PCEP session with an active stateful PCE, its LSP state is synced with the PCE (the PCE knows about all of the PCC's existing LSPs 🫶). after LSPs get delegated to the PCE, the PCE can modify the parameters of those delegated LSPs. it's giving main character energy 👑
to update an LSP, a PCE MUST send the PCC an LSP Update Request using a PCUpd message. the LSP Update Request holds a bunch of objects that spell out the constraints and attributes for the LSP's path. every LSP Update Request MUST have a unique identifier, the SRP-ID-number, carried in the SRP object described in Section 7.2. the SRP-ID-number is how errors and state reports get matched back to their LSP Update Requests 🔗 and a single PCUpd message MAY contain multiple LSP Update Requests. 🍓
when the PCC gets a PCUpd message, it starts setting up the LSPs listed in the LSP Update Requests inside it. for each LSP, it MAY send an LSP State Report on a PCRpt message to the PCE saying the status is 'Going-up' 🚀
if the PCC decides the LSP parameters in the PCUpd message are unacceptable, it MUST report that error by including the LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable parameters" in the LSP object of the PCRpt message to the PCE. based on local policy, the PCC MAY react further to that error by revoking the delegation 🙅♀️
if the PCC receives a PCUpd message for an LSP object identified with a PLSP-ID that doesn't exist on the PCC, it MUST generate a PCErr with Error-type=19 (Invalid Operation), error-value 3, (Attempted LSP Update Request for an LSP identified by an unknown PSP-ID) (see Section 8.5). 😭
once an LSP is up, the PCC MUST send an LSP State Report (PCRpt message) to the PCE saying the status is 'Up'. if the LSP couldn't be set up, the PCC MUST send an LSP State Report saying it's 'Down' and stating the cause of the failure. a PCC MAY compress LSP State Reports so they only reflect the most up to date state, as discussed in the previous section ✨
the PCC MUST send each LSP State Report to each stateful PCE that's connected to it. 💌
PCErr and PCRpt messages triggered by a PCUpd message MUST include the SRP-ID-number from that PCUpd. this is what gives you correlation of requests and errors, plus acknowledgement of state processing 🧾 the PCC MAY compress the state when processing PCUpd. in that case, receiving a higher SRP-ID-number implicitly acknowledges that all the updates with a lower SRP-ID-number for that specific LSP were processed (as per Section 7.2). it's a whole vibe 🫶
a PCC MUST NOT send any PCE a path computation request for a delegated LSP. if the PCC decides it wants to issue a Path Computation Request on a delegated LSP, it MUST perform the Delegation Revocation procedure first. no shortcuts, periodt 🙅♀️
5.9. LSP Protection 🛡️
LSP protection and how it interacts with the stateful PCE, plus the extensions needed to make it work, will be covered in a separate document. stay tuned, bestie 📚
5.10. PCEP Sessions 🌈
a permanent PCEP session MUST be established between a stateful PCE and the PCC. if the session fails, session re-establishment MUST be re-attempted using the procedures defined in [RFC5440]. the comeback is always on 💪
6. PCEP Messages 💜
as defined in [RFC5440], a PCEP message is made of a common header followed by a variable-length body, which is a set of objects. for each PCEP message type, there's a set of rules that spells out which objects that message can carry 🎀
6.1. The PCRpt Message ✨
okay bestie, so the PCRpt message (the Path Computation LSP State Report, if we're being formal 🙄) is how a PCC tells a PCE what's going on with an LSP 💅. One PCRpt can carry more than one LSP State Report 🌸. A PCC can send one either as a reply to an LSP Update Request from a PCE, or on its own whenever an LSP's state changes ✨. In the PCEP common header, the Message-Type field for PCRpt is 10 🎀.
Here's the shape of the message:
<PCRpt Message> ::= <Common Header>
<state-report-list>Where:
<state-report-list> ::= <state-report>[<state-report-list>]
<state-report> ::= [<SRP>]
<LSP>
<path>
Where:
<path>::= <intended-path>
[<actual-attribute-list><actual-path>]
<intended-attribute-list>
<actual-attribute-list>::=[<BANDWIDTH>]
[<metric-list>]Where:
<intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440] 🦋. The <actual-attribute-list> holds the actual computed and signaled values of the <BANDWIDTH> and <metric-lists> objects defined in [RFC5440] 💖. The <actual-path> is represented by the RRO object defined in Section 7.10 of [RFC5440] 🧚. The <intended-attribute-list> is the attribute-list defined in Section 6.5 of [RFC5440], extended by PCEP extensions 🌈.
The SRP object (see Section 7.2) is OPTIONAL 🫶. If the PCRpt message is not in response to a PCUpd message, the SRP object MAY be omitted 🙈.
When the PCC leaves out the SRP object, the PCE MUST treat it as an SRP object with an SRP-ID-number of the reserved value 0x00000000 🍓. That reserved value means the state being reported is not the result of processing a PCUpd message 💅.
If the PCRpt message is in response to a PCUpd message, the SRP object MUST be included, and its SRP-ID-number MUST match the one in the PCUpd message that triggered the reported state 🔥. If the PCC compressed several PCUpd messages for the same LSP by only processing the one with the highest number, then it should use the SRP-ID-number of that request 🦋. No state compression is allowed for state reporting, so PCRpt messages MUST NOT be pruned from the PCC's egress queue, even if later operations on the same LSP finish before the PCRpt has been sent to the TCP stack 😭. The PCC MUST explicitly report state changes (including removal) for the paths it manages 👑.
The LSP object (see Section 7.3) is REQUIRED, and it MUST be included in each LSP State Report on the PCRpt message 💜. If the LSP object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value 8 (LSP object missing) 💀.
If the LSP transitioned to a non-operational state, the PCC SHOULD include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error Code to report the error to the PCE 🌸.
The intended path, represented by the ERO object, is REQUIRED 🎀. If the ERO object is missing, the receiving PCE MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value 9 (ERO object missing) 😭. The ERO may be empty if the PCE does not have a path for a delegated LSP 🫶.
The actual path, represented by the RRO object, SHOULD be included in a PCRpt by the PCC when the path is up or active 🌈, but it MAY be omitted if the path is down due to a signaling error or another failure 🙈.
The intended-attribute-list maps to the attribute-list in Section 6.5 of [RFC5440] and is used to convey the requested parameters of the LSP path 🦋. This is needed to support the switch from passive to active stateful PCE, as described in Section 5.8.2 ✨. When it's included as part of the intended-attribute-list, the BANDWIDTH object means the requested bandwidth, as intended by the operator 💅. In that case, the BANDWIDTH Object-Type of 1 SHOULD be used 🔥. Similarly, to indicate a limiting constraint, the METRIC object SHOULD be included as part of the intended-attribute-list with the B flag set and with a specific metric value 👑. To indicate the optimization metric, the METRIC object SHOULD be included as part of the intended-attribute-list with the B flag unset and the metric value set to zero 🧚. Note that the intended-attribute-list is optional and may be omitted 💖. In that case, the PCE MAY use the values in the actual-attribute-list as the requested parameters for the path 🍓.
The actual-attribute-list consists of the actual computed and signaled values of the BANDWIDTH and METRIC objects defined in [RFC5440] 🌸. When it's included as part of the actual-attribute-list, Object-Type 2 [RFC5440] SHOULD be used for the BANDWIDTH object, and the C flag SHOULD be set in the METRIC object [RFC5440] ✨.
Note that the ordering of intended-path, actual-attribute-list, actual-path, and intended-attribute-list was chosen to keep compatibility with implementations of an earlier version of this standard 🎀.
A PCE may choose to put a limit on the resources a single PCC can occupy 🌈. If a PCRpt is received that causes the PCE to exceed this limit, the PCE MUST notify the PCC using a PCNtf message with Notification Type 4 (Stateful PCE resource limit exceeded) and Notification Value 1 (Entering resource limit exceeded state), and it MUST terminate the session 💀😭.
6.2. The PCUpd Message 💅
A Path Computation LSP Update Request message (also known as a PCUpd message) is a PCEP message a PCE sends to a PCC to update the attributes of an LSP 🫶. One PCUpd message can carry more than one LSP Update Request 🌸. In the PCEP common header, the Message-Type field for PCUpd is 11 🦋.
Here's the format of a PCUpd message:
<PCUpd Message> ::= <Common Header>
<update-request-list>Where:
<update-request-list> ::= <update-request>[<update-request-list>]
<update-request> ::= <SRP>
<LSP>
<path>
Where:
<path>::= <intended-path><intended-attribute-list>Where:
<intended-path> is represented by the ERO object defined in Section 7.9 of [RFC5440] 🧚. The <intended-attribute-list> is the attribute-list defined in [RFC5440] and extended by PCEP extensions 🌈.
There are three mandatory objects that MUST be included within each LSP Update Request in the PCUpd message: the SRP object (see Section 7.2), the LSP object (see Section 7.3), and the ERO object (as defined in [RFC5440], which represents the intended path) 👑. If the SRP object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=10 (SRP object missing) 😭. If the LSP object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=8 (LSP object missing) 💀. If the ERO object is missing, the receiving PCC MUST send a PCErr message with Error-type=6 (Mandatory Object missing) and Error-value=9 (ERO object missing) 🙈.
The ERO in the PCUpd may be empty if the PCE cannot find a valid path for a delegated LSP 🍓. One typical situation that leads to this empty ERO is when a PCE can no longer find a strict SRLG-disjoint path for a delegated LSP after a link failure 🔥. The PCC SHOULD implement a local policy to decide the appropriate action: either tear down the LSP, revoke the delegation and use a locally computed path, or keep the existing LSP 💖.
A PCC only acts on an LSP Update Request if the local policy configured by the network manager permits it 🫶. Each LSP Update Request that the PCC acts on results in an LSP setup operation ✨. An LSP Update Request MUST contain all LSP parameters that a PCE wishes to be set for the LSP 🎀. A PCC MAY set missing parameters from locally configured defaults 🌸. If the LSP specified in the Update Request is already up, it will be re-signaled 🦋.
The PCC SHOULD minimize the traffic interruption and MAY use the make-before-break procedures described in [RFC3209] to achieve this goal 🌈. If the make-before-break procedures are used, two paths will briefly coexist 🧚. The PCC MUST send separate PCRpt messages for each, identified by the LSP-IDENTIFIERS TLV 💜. When the old path is torn down after the head end switches over the traffic, this event MUST be reported by sending a PCRpt message with the LSP-IDENTIFIERS-TLV of the old path and the R bit set 😭. The SRP-ID-number that the PCC associates with this PCRpt MUST be 0x00000000 💅. So a make-before-break operation will typically result in at least two PCRpt messages: one for the new path and one for the removal of the old path (more messages may be possible if intermediate states are reported) 👑.
If the path setup fails due to an RSVP signaling error, the error is reported to the PCE 💀. The PCC will not attempt to re-signal the path until the PCE prompts it again with a subsequent PCUpd message 🙈.
A PCC MUST respond with an LSP State Report to each LSP Update Request it processed, to indicate the resulting state of the LSP in the network (even if this processing did not change the state of the LSP) 🔥. The SRP-ID-number included in the PCRpt MUST match the one in the PCUpd 🫶. A PCC MAY respond with multiple LSP State Reports to report the LSP setup progress of a single LSP 🌸. In that case, the SRP-ID-number MUST be included for the first message, and for subsequent messages the reserved value 0x00000000 SHOULD be used 🧚.
Note that a PCC MUST process all LSP Update Requests, for example an LSP Update Request is sent when a PCE returns delegation or puts an LSP into a non-operational state 💖. The protocol relies on TCP for message-level flow control 🎀.
If the rate of PCUpd messages sent to a PCC for the same target LSP exceeds the rate at which the PCC can signal LSPs into the network, the PCC MAY perform state compression on its ingress queue ✨. The compression algorithm is based on the fact that each PCUpd request contains the complete LSP state the PCE wishes to be set 💅. It works like this: when the PCC starts processing a PCUpd message at the head of its ingress queue, it may search the queue forward for more recent PCUpd messages pertaining to that particular LSP, prune all but the latest one from the queue, and process only the last one, because that request contains the most up-to-date desired state for the LSP 🌈. The PCC MUST NOT send PCRpt nor PCErr messages for requests that were pruned from the queue this way 😭. This compression step may be performed only while the LSP is not being signaled 🍓. For example, if two PCUpd messages arrive for the same LSP in quick succession, and the PCC started signaling the changes for the first PCUpd, then it MUST wait until the signaling finishes (and report the new state via a PCRpt) before attempting to apply the changes indicated in the second PCUpd 👑.
Note also that it is up to the PCE to handle inter-LSP dependencies 🧚. For example, if ordering of LSP setups is required, the PCE has to wait for an LSP State Report for a previous LSP before starting the update of the next LSP 🦋.
If the PCUpd cannot be satisfied (for example, due to an unsupported object or a TLV), the PCC MUST respond with a PCErr message indicating the failure (see Section 7.3.3) 💀🎀
6.3. The PCErr Message 💌
okay bestie, PCErr messages get a glow-up for stateful PCE 💅 If the stateful PCE capability was advertised on the PCEP session, the PCErr message MAY include the SRP object ✨ If the error is the result of an LSP Update Request, then the SRP-ID-number MUST be the one from the PCUpd that triggered the error 🎯 If the error is unsolicited, the SRP object MAY be omitted 🙈 Omitting it is basically the same as including an SRP object with the SRP-ID-number set to the reserved value 0x00000000 🧚
The format of a PCErr message from [RFC5440] gets extended like this 🌸
<PCErr Message> ::= <Common Header>
( <error-obj-list> [<Open>] ) | <error>
[<error-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error>::=[<request-id-list> | <stateful-request-id-list>]
<error-obj-list>
<request-id-list>::=<RP>[<request-id-list>]
<stateful-request-id-list>::=<SRP>[<stateful-request-id-list>]
<error-list>::=<error>[<error-list>]6.4. The PCReq Message 📮
okay so a PCC MAY include the LSP object in the PCReq message (see Section 7.3) if the stateful PCE capability has been negotiated on a PCEP session between the PCC and a PCE 🫶
The PCReq message from [RFC5440] gets extended to optionally include the LSP object after the END-POINTS object 💖 The encoding from [RFC5440] becomes:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>Where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSP>]
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]6.5. The PCRep Message 🦋
a PCE MAY include the LSP object in the PCRep message (see Section 7.3) if the stateful PCE capability has been negotiated on a PCEP session between the PCC and the PCE, and the LSP object was included in the matching PCReq message from the PCC 🧁
The PCRep message from [RFC5440] gets extended to optionally include the LSP object after the Request Parameter (RP) object 🌈 The encoding from [RFC5440] becomes:
<PCRep Message> ::= <Common Header>
<response-list>Where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<LSP>]
[<NO-PATH>]
[<attribute-list>]
[<path-list>]7. Object Formats 🧩
the PCEP objects defined in this document are compliant with the PCEP object format defined in [RFC5440] 🎀 The P and I flags of the PCEP objects defined in this document MUST be set to 0 on transmission and SHOULD be ignored on receipt, since they are exclusively related to path computation requests 🙈
7.1. OPEN Object 💜
this document defines one new optional TLV for use in the OPEN object 🌸
7.1.1. STATEFUL-PCE-CAPABILITY TLV ⭐
the STATEFUL-PCE-CAPABILITY TLV is an optional TLV for use in the OPEN object for stateful PCE capability advertisement 💅 Its format is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=16 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 9: STATEFUL-PCE-CAPABILITY TLV Format
the type (16 bits) of the TLV is 16 💖 The length field is 16 bits long and has a fixed value of 4 ✨
the value comprises a single field, which is Flags (32 bits) 🎀
- U (LSP-UPDATE-CAPABILITY - 1 bit): if set to 1 by a PCC, the U flag indicates that the PCC allows modification of LSP parameters; if set to 1 by a PCE, the U flag indicates that the PCE is capable of updating LSP parameters. The LSP-UPDATE-CAPABILITY flag must be advertised by both a PCC and a PCE for PCUpd messages to be allowed on a PCEP session 🫶
Unassigned bits are considered reserved 🔒 They MUST be set to 0 on transmission and MUST be ignored on receipt.
a PCEP speaker operating in passive stateful PCE mode advertises the stateful PCE capability with the U flag set to 0 🦋 A PCEP speaker operating in active stateful PCE mode advertises the stateful PCE capability with the U flag set to 1 👑
advertisement of the stateful PCE capability implies support of LSPs that are signaled via RSVP, as well as the objects, TLVs, and procedures defined in this document 🌈
7.2. SRP Object 🔥
the SRP (Stateful PCE Request Parameters) object MUST be carried within PCUpd messages and MAY be carried within PCRpt and PCErr messages 💅 The SRP object is used to correlate between update requests sent by the PCE and the error reports and state reports sent by the PCC 🧠
SRP Object-Class is 33 🍓
SRP Object-Type is 1 🌸
The format of the SRP object body is shown in Figure 10:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 10: The SRP Object Format
the SRP object body has a variable length and may contain additional TLVs 🎀
Flags (32 bits): None defined yet 🫧
SRP-ID-number (32 bits): the SRP-ID-number value in the scope of the current PCEP session uniquely identifies the operation that the PCE has requested the PCC to perform on a given LSP 💖 The SRP-ID-number is incremented each time a new request is sent to the PCC, and it may wrap around 🔄
the values 0x00000000 and 0xFFFFFFFF are reserved 🚫
Optional TLVs MAY be included within the SRP object body 🧩 The specification of such TLVs is outside the scope of this document.
every request to update an LSP receives a new SRP-ID-number 💌 This number is unique per PCEP session and is incremented each time an operation is requested from the PCE 📈 So for a given LSP, there may be more than one SRP-ID-number unacknowledged at a given time 👀 The value of the SRP-ID-number is echoed back by the PCC in PCErr and PCRpt messages, so requests made by the PCE can be correlated with errors or state reports generated by the PCC 🔗 If the error or report was not a result of a PCE operation (for example, in the case of a link down event), the reserved value of 0x00000000 is used for the SRP-ID-number 🛑 The absence of the SRP object is equivalent to an SRP object with the reserved value of 0x00000000 ✨
An SRP-ID-number is considered unacknowledged and cannot be reused until a PCErr or PCRpt arrives with an SRP-ID-number equal or higher for the same LSP 🙅♀️ In case of SRP-ID-number wrapping, the last SRP-ID-number before the wrapping MUST be explicitly acknowledged, so SRP-ID-numbers don't stay unacknowledged after the wrap 😭 This means that the PCC may need to issue two PCUpd messages on detecting a wrap 🥹
7.3. LSP Object ✨
okay bestie, the LSP object is where the real drama lives 💅 It MUST be present within PCRpt and PCUpd messages, and it MAY be carried within PCReq and PCRep messages if the stateful PCE capability has been negotiated on the session. It's giving "control panel for one specific tunnel" 🎀 It has fields for naming the target LSP, the operation to perform on it, and LSP delegation, plus a flag that tells the PCE the LSP State Synchronization is in progress 🔄 This doc is mostly about LSPs signaled with RSVP, and a lot of the TLVs here basically mirror RSVP state, so if you know RSVP, you're already halfway there 🧚
LSP Object-Class is 32 💖
LSP Object-Type is 1 💖
The LSP object body looks like this (Figure 11) 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID | Flag | O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: The LSP Object Format
PLSP-ID (20 bits): this is the PCEP-specific ID for the LSP, and it's giving main character 🌸 A PCC creates a unique PLSP-ID for each LSP, and it stays constant for the whole lifetime of a PCEP session. The PCC will advertise the same PLSP-ID on all PCEP sessions it maintains at a given time 🫶 The symbolic path name gets mapped to the PLSP-ID by sending a PCRpt message containing the SYMBOLIC-PATH-NAME TLV. After that, every PCEP message addresses the LSP by its PLSP-ID. The values 0 and 0xFFFFF are reserved 🙈 Also, the PLSP-ID is constant for the session, but during that time an RSVP-signaled LSP might get different RSVP identifiers (LSP-id, tunnel-id) allocated to it. So the ID stays the same while the RSVP bits change underneath, iykyk 😭
Flags (12 bits), starting from the least significant bit:
D (Delegate - 1 bit): on a PCRpt message, D set to 1 means the PCC is delegating the LSP to the PCE 👑 On a PCUpd message, D set to 1 means the PCE is confirming the LSP delegation. To keep an LSP delegated to the PCE, the PCC MUST set D to 1 on each PCRpt message for the whole delegation. The first PCRpt with D set to 0 revokes the delegation 💀 To keep the delegation, the PCE MUST set D to 1 on each PCUpd message for the whole delegation. The first PCUpd with D set to 0 returns the delegation. So it's a vibe check every single message 🔥
S (SYNC - 1 bit): the PCC MUST set S to 1 on each PCRpt it sends during State Synchronization ✨ In all other messages the PCC sends, S MUST be set to 0. When the PCE sends a PCUpd message, it MUST set S to 0 🌈
R (Remove - 1 bit): on PCRpt messages, R indicates the LSP has been removed from the PCC, and the PCE SHOULD remove all state from its database 🗑️ When an LSP State Report arrives with R set to 1 for an RSVP-signaled LSP, the PCE SHOULD remove all state for the path identified by the LSP-IDENTIFIERS TLV from its database. When the all-zeros LSP-IDENTIFIERS TLV is used, the PCE SHOULD remove all state for the PLSP-ID from its database. When the PCE sends a PCUpd message, it MUST set R to 0. Not me deleting my whole database for one path 😭
A (Administrative - 1 bit): on PCRpt messages, A shows the PCC's target operational status for this LSP. On PCUpd messages, A shows the LSP status the PCE wants for this LSP. In both cases, '1' means the desired operational state is active and '0' means it's inactive 🦋 A PCC ignores the A flag on a PCUpd message unless the operator's policy lets the PCE control that LSP's administrative state. So the PCE only gets a say if the operator says so 🎀
O (Operational - 3 bits): on PCRpt messages, O represents the operational status of the LSP 🍓 These values are defined:
0 - DOWN: not active.
1 - UP: signaled.
2 - ACTIVE: up and carrying traffic.
3 - GOING-DOWN: LSP is being torn down, and resources are being
released.
4 - GOING-UP: LSP is being signaled.
5-7 - Reserved: these values are reserved for future use.Unassigned bits are reserved for future use. They MUST be set to 0 on transmission and MUST be ignored on receipt 🧚 When the PCE sends a PCUpd message, it MUST set the O field to 0. Literally just don't touch it 💅
TLVs that may be included in the LSP object are described in the following sections. Other optional TLVs that are not defined in this document MAY also be included within the LSP object body 🌸
7.3.1. LSP-IDENTIFIERS TLVs
The LSP-IDENTIFIERS TLV MUST be included in the LSP object in PCRpt messages for RSVP-signaled LSPs. If the TLV is missing, the PCE will generate an error with Error-type=6 (Mandatory Object missing) and error-value 11 (LSP-IDENTIFIERS TLV missing) and close the session 💀 The LSP-IDENTIFIERS TLV MAY be included in the LSP object in PCUpd messages for RSVP-signaled LSPs. The special all-zeros value for this TLV refers to all paths pertaining to a particular PLSP-ID 🫶 There are two LSP-IDENTIFIERS TLVs, one for IPv4 and one for IPv6, so pick your fighter 🌈
It is the PCC's responsibility to send the PCE the identifiers for each RSVP incarnation of the tunnel ✨ For example, in a make-before-break scenario, the PCC MUST send a separate PCRpt for the old and reoptimized paths, and it has to explicitly report removal of any of these paths using the R bit in the LSP object. Two paths, two reports, no ghosting 👻
The IPV4-LSP-IDENTIFIERS TLV looks like this (Figure 12) 🦋
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=18 | Length=16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Sender Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Tunnel Endpoint Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: IPV4-LSP-IDENTIFIERS TLV Format
The type (16 bits) of this TLV is 18. The length field is 16 bits long and has a fixed value of 16. The value holds these fields:
IPv4 Tunnel Sender Address: the sender node's IPv4 address, as defined in [RFC3209], Section 4.6.2.1, for the LSP_TUNNEL_IPv4 Sender Template Object 🌸
LSP ID: the 16-bit 'LSP ID' identifier defined in [RFC3209], Section 4.6.2.1 for the LSP_TUNNEL_IPv4 Sender Template Object. A value of 0 MUST be used if the LSP is not yet signaled 🙈
Tunnel ID: the 16-bit 'Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object 🎀
Extended Tunnel ID: the 32-bit 'Extended Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.1 for the LSP_TUNNEL_IPv4 Session Object 🧚
IPv4 Tunnel Endpoint Address: the egress node's IPv4 address, as defined in [RFC3209], Section 4.6.1.1, for the LSP_TUNNEL_IPv4 Sender Template Object 🍓
The IPV6-LSP-IDENTIFIERS TLV looks like this (Figure 13) 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=19 | Length=52 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Tunnel Sender Address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP ID | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Extended Tunnel ID |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| IPv6 Tunnel Endpoint Address |
+ (16 octets) +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: IPV6-LSP-IDENTIFIERS TLV Format
The type (16 bits) of this TLV is 19. The length field is 16 bits long and has a fixed value of 52. The value holds these fields:
IPv6 Tunnel Sender Address: the sender node's IPv6 address, as defined in [RFC3209], Section 4.6.2.2, for the LSP_TUNNEL_IPv6 Sender Template Object 🌸
LSP ID: the 16-bit 'LSP ID' identifier defined in [RFC3209], Section 4.6.2.2 for the LSP_TUNNEL_IPv6 Sender Template Object. A value of 0 MUST be used if the LSP is not yet signaled 🙈
Tunnel ID: the 16-bit 'Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object 🎀
Extended Tunnel ID: the 128-bit 'Extended Tunnel ID' identifier defined in [RFC3209], Section 4.6.1.2 for the LSP_TUNNEL_IPv6 Session Object 🧚
IPv6 Tunnel Endpoint Address: the egress node's IPv6 address, as defined in [RFC3209], Section 4.6.1.2, for the LSP_TUNNEL_IPv6 Session Object 🍓
The Tunnel ID stays constant over the lifetime of a tunnel 💜
7.3.2. Symbolic Path Name TLV ✨
okay bestie, every LSP MUST have a symbolic path name that's unique in the PCC 🫶 It's a human-readable string that names the LSP out there in the network, and it MUST stay constant for the LSP's whole life, which can stretch across multiple consecutive PCEP sessions and/or PCC restarts 🦋 An operator MAY set it in a PCC's configuration. If the operator doesn't give the LSP a unique symbolic name, the PCC MUST auto-generate one 💅
The PCE uses the symbolic path name as a stable identifier for the LSP 👑 If the PCEP session restarts, or the PCC restarts, or the PCC re-delegates the LSP to a different PCE, the symbolic path name stays the same, so it can be used to correlate things across the PCEP session instances. iconic 🌸
The other protocol identifiers for the LSP cannot reliably be used to identify the LSP across multiple PCEP sessions, and here's why 🙈
- The PLSP-ID is unique only within the scope of a single PCEP session.
- The LSP-IDENTIFIERS TLV is only guaranteed to be present for LSPs that are signaled with RSVP-TE, and it may change during the lifetime of the LSP.
The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the LSP State Report (PCRpt) message when, during a given PCEP session, an LSP is first reported to a PCE. A PCC sends the first LSP State Report to a PCE either during State Synchronization or when a new LSP is configured at the PCC 🧚
The initial PCRpt creates a binding between the symbolic path name and the PLSP-ID for the LSP, and that binding lasts for the duration of the PCEP session 💜 The PCC MAY omit the symbolic path name from subsequent LSP State Reports for that LSP on that PCEP session, and just use the PLSP-ID. main character energy 💖
The format of the SYMBOLIC-PATH-NAME TLV is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=17 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Symbolic Path Name //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: SYMBOLIC-PATH-NAME TLV FormatType (16 bits): the type is 17.
Length (16 bits): indicates the total length of the TLV in octets and MUST be greater than 0. The TLV MUST be zero-padded so that the TLV is 4-octet aligned 🎀
Symbolic Path Name (variable): symbolic name for the LSP, unique in the PCC. It SHOULD be a string of printable ASCII characters, without a NULL terminator 🍓
7.3.3. LSP Error Code TLV
The LSP Error Code TLV is an optional TLV for use in the LSP object to convey error information 🚨 When an LSP Update Request fails, an LSP State Report MUST be sent to report the current state of the LSP, and it SHOULD contain the LSP-ERROR-CODE TLV indicating the reason for the failure. Similarly, when a PCRpt is sent because an LSP transitioned to non-operational state, the LSP-ERROR-CODE TLV SHOULD be included to indicate the reason for the transition 😭
The format of the LSP-ERROR-CODE TLV is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=20 | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 15: LSP-ERROR-CODE TLV FormatThe type (16 bits) of the TLV is 20. The length field is 16 bits long and has a fixed value of 4. The value contains an error code that indicates the cause of the failure 🦋
The following LSP Error Codes are currently defined:
Value Description
----- -------------------------------------
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error7.3.4. RSVP Error Spec TLV
The RSVP-ERROR-SPEC TLV is an optional TLV for use in the LSP object to carry RSVP error information 🧚 It includes the RSVP ERROR_SPEC or USER_ERROR_SPEC object ([RFC2205] and [RFC5284]), which were returned to the PCC from a downstream node. If the setup of an LSP fails at a downstream node that returned an ERROR_SPEC to the PCC, the PCC SHOULD include in the PCRpt for this LSP the LSP-ERROR-CODE TLV with LSP Error Code = "RSVP signaling error" and the RSVP-ERROR-SPEC TLV with the relevant RSVP ERROR-SPEC or USER_ERROR_SPEC object 🔥
The format of the RSVP-ERROR-SPEC TLV is shown in the following figure:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=21 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ RSVP ERROR_SPEC or USER_ERROR_SPEC Object +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: RSVP-ERROR-SPEC TLV FormatType (16 bits): the type is 21.
Length (16 bits): indicates the total length of the TLV in octets. The TLV MUST be zero-padded so that the TLV is 4-octet aligned.
Value (variable): contains the RSVP ERROR_SPEC or USER_ERROR_SPEC object, as specified in [RFC2205] and [RFC5284], including the object header 🫶
8. IANA Considerations 🌈
The code points described below have been allocated for the protocol elements defined in this document 💅
8.1. PCE Capabilities in IGP Advertisements
The following bits have been registered in the "Path Computation Element (PCE) Capability Flags" subregistry of the "Open Shortest Path First (OSPF) Parameters" registry:
Bit Description Reference
--- ------------------------------- -------------
11 Active stateful PCE capability This document
12 Passive stateful PCE capability This document8.2. PCEP Messages
The following message types have been allocated within the "PCEP Messages" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
Value Description Reference
----- ------------ -------------
10 Report This document
11 Update This document8.3. PCEP Objects
The following object-class values and object types have been allocated within the "PCEP Objects" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry:
Object-Class Value Name Reference
------------------ ---------------- -------------
32 LSP This document
Object-Type
0: Reserved
1: LSP
33 SRP This document
Object-Type
0: Reserved
1: SRP8.4. LSP Object
A new subregistry, named "LSP Object Flag Field", has been created within the "Path Computation Element Protocol (PCEP) Numbers" registry to manage the Flag field of the LSP object. New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
The following values are defined in this document:
Bit Description Reference
--- -------------------- -------------
0-4 Unassigned This document
5-7 Operational (3 bits) This document
8 Administrative This document
9 Remove This document
10 SYNC This document
11 Delegate This document8.5. PCEP-Error Object
The following error types and error values have been registered within the "PCEP-ERROR Object Error Types and Values" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry 🙈
Error-Type Meaning
---------- -------------------------------------------------------
6 Mandatory Object missing
Error-value
8: LSP object missing
9: ERO object missing
10: SRP object missing
11: LSP-IDENTIFIERS TLV missing
19 Invalid Operation
Error-value
1: Attempted LSP Update Request for a non-delegated
LSP. The PCEP-ERROR object is followed by the LSP
object that identifies the LSP.
2: Attempted LSP Update Request if the stateful PCE
capability was not advertised.
3: Attempted LSP Update Request for an LSP identified
by an unknown PLSP-ID.
5: Attempted LSP State Report if stateful PCE
capability was not advertised.
20 LSP State Synchronization Error
Error-value
1: A PCE indicates to a PCC that it cannot process (an
otherwise valid) LSP State Report. The PCEP-ERROR
object is followed by the LSP object that
identifies the LSP.
5: A PCC indicates to a PCE that it cannot complete
the State Synchronization.8.6. Notification Object
The following Notification Types and Notification Values have been allocated within the "Notification Object" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry 💜
Notification-Type Name
4 Stateful PCE resource limit exceeded
Notification-value
1: Entering resource limit exceeded state
2: DeprecatedNote that the early allocation included an additional Notification Value 2 for "Exiting resource limit exceeded state". This Notification Value is no longer required and has been marked as "Deprecated" ⭐
8. IANA Considerations 🎀
8.7. PCEP TLV Type Indicators 💅
okay so IANA registered these TLV Type Indicator values in the "PCEP TLV Type Indicators" subregistry of the "Path Computation Element Protocol (PCEP) Numbers" registry, and they're all giving main character energy 🦋
Value Description Reference
----- ----------------------- -------------
16 STATEFUL-PCE-CAPABILITY This document
17 SYMBOLIC-PATH-NAME This document
18 IPV4-LSP-IDENTIFIERS This document
19 IPV6-LSP-IDENTIFIERS This document
20 LSP-ERROR-CODE This document
21 RSVP-ERROR-SPEC This document8.8. STATEFUL-PCE-CAPABILITY TLV 🌸
so there's a brand new subregistry called "STATEFUL-PCE-CAPABILITY TLV Flag Field" inside the "Path Computation Element Protocol (PCEP) Numbers" registry 🧚 its whole job is to manage the Flag field in the STATEFUL-PCE-CAPABILITY TLV, which lives in the PCEP OPEN object (class = 1). new values get handed out by Standards Action [RFC8126]. each bit should be tracked with these three qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
and this document only defines one value so far, which is giving very "first one in the group chat" vibes 👑
Value Description Reference
----- --------------------- -------------
31 LSP-UPDATE-CAPABILITY This document8.9. LSP-ERROR-CODE TLV 🍓
we also made a subregistry called "LSP-ERROR-CODE TLV Error Code Field" in the "Path Computation Element Protocol (PCEP) Numbers" registry 💖 this one manages the LSP Error Code field of the LSP-ERROR-CODE TLV, and that field tells you why updating the LSP failed. honestly the reasons are so specific it's kind of iconic 💀
new values come from Standards Action [RFC8126]. each value should be tracked with three things: the value, its meaning, and the defining RFC. these are the values defined in this document:
Value Meaning
--- -------------------------------------
0 Reserved
1 Unknown reason
2 Limit reached for PCE-controlled LSPs
3 Too many pending LSP Update Requests
4 Unacceptable parameters
5 Internal error
6 LSP administratively brought down
7 LSP preempted
8 RSVP signaling error9. Manageability Considerations ⭐
okay manageability time 🧁 all the manageability requirements and considerations in [RFC5440] apply to the PCEP extensions in this document too. on top of that, the stuff in this section applies as well.
9.1. Control Function and Policy 🎀
so on top of the PCEP session parameters you already configure as described in [RFC5440], Section 8.1, a PCE or PCC implementation MUST allow configuring the stateful PCEP capability and the LSP Update capability 🔥 a PCC implementation SHOULD let the operator list multiple candidate PCEs and set a delegation preference for each one. a PCC SHOULD let the operator set an LSP delegation policy where LSPs get delegated to the most-preferred online PCE. a PCC MAY let the operator set different LSP delegation policies too, which is very flexible of it 🦋
a PCC implementation that allows concurrent connections to multiple PCEs SHOULD let the operator group the PCEs by administrative domain. and it MUST NOT advertise LSP existence and state to a PCE if that LSP is delegated to a PCE in a different group 🙈 no sharing secrets across the wrong group chat!
a PCC implementation SHOULD let the operator decide whether the PCC advertises LSP existence and state for LSPs that no PCE controls, like LSPs that are statically configured at the PCC 🌈
a PCC implementation SHOULD let the operator set both the Redelegation Timeout Interval and the State Timeout Interval. the default for the Redelegation Timeout Interval SHOULD be 30 seconds. an operator MAY also set up a policy that adjusts the Redelegation Timeout Interval dynamically, like setting it to zero when the PCC has an established session to a backup PCE 🧚 the default for the State Timeout Interval SHOULD be 60 seconds ⏰
after the State Timeout Interval expires, the LSP goes back to the operator-defined default parameters. a PCC implementation MUST let the operator specify those default LSP parameters 💜 if you want the LSP to keep whatever parameters the PCE set until the PCC changes them, use a State Timeout Interval of infinity, which SHOULD be used for that behavior ✨ and any changes to LSP parameters SHOULD be done in a make-before-break fashion 🫶
LSP delegation is controlled by operator-defined policies on a PCC. LSPs get delegated individually, so different LSPs can go to different PCEs 💅 an LSP is delegated to at most one PCE at any given point in time. a PCC implementation SHOULD support the delegation policy where all of the PCC's LSPs are delegated to a single PCE at any given time. and the policy that revokes delegation for all of the PCC's LSPs SHOULD also be supported.
a PCC implementation SHOULD let the operator set delegation priority for PCEs 👑 this basically decides the primary PCE, plus one or more backup PCEs that a primary PCE's LSPs can be delegated to when the primary fails.
policies for stateful PCEs and PCCs should eventually fit into the policy-enabled path computation framework defined in [RFC5394], and that framework should be extended to support stateful PCEs 🧠
9.2. Information and Data Models 📚
the PCEP YANG module [PCEP-YANG] should include:
- advertised stateful capabilities and synchronization status per PCEP session.
- the delegation status of each configured LSP.
the PCEP MIB [RFC7420] could also get updated to include this info 🍓
9.3. Liveness Detection and Monitoring 💓
the PCEP extensions in this document don't need any new mechanisms beyond the ones already defined in [RFC5440], Section 8.3. zero new drama here 🙌
9.4. Verifying Correct Operation 🔍
the mechanisms in [RFC5440], Section 8.4 also apply to the PCEP extensions in this document. on top of the monitoring parameters from [RFC5440], a stateful PCC-side PCEP implementation SHOULD provide these parameters:
- Total number of LSP Updates
- Number of successful LSP Updates
- Number of dropped LSP Updates
- Number of LSP Updates where LSP setup failed
a PCC implementation SHOULD provide a command that shows, for each LSP, whether it's delegated and, if it is, which PCE has it 👀 and a PCC implementation SHOULD let the operator manually revoke LSP delegation. main character operator energy 💅
9.5. Requirements on Other Protocols and Functional Components 🧩
the PCEP extensions in this document don't put any new requirements on other protocols. easy peasy 🦋
9.6. Impact on Network Operation 🌊
the mechanisms in [RFC5440], Section 8.6 also apply to the PCEP extensions in this document 🫶
on top of that, a PCEP implementation SHOULD let you put a limit on the number of LSPs delegated to the PCE, and on the rate of PCUpd and PCRpt messages sent by a PCEP speaker and processed from a peer. it SHOULD also be able to send a notification when a rate threshold gets hit 🚨
a PCC implementation SHOULD let you put a limit on the rate of LSP Updates to the same LSP, so you don't get signaling overload, which is discussed in Section 10.3 💀
10. Security Considerations 🔐
10.1. Vulnerability 🙈
this document defines PCEP extensions that enable stateful PCEs, and honestly the stakes just went up 😭 the nature of these extensions, plus handing path control over to PCEs, means more information is available for a hypothetical adversary, and there are a bunch of extra attack surfaces that have to be protected.
the security provisions in [RFC5440] still apply to these extensions. but because the protocol changes in this document let the PCE control the timing and sequence of path computation, the PCE defense mechanisms in [RFC5440], Section 7.2 now also apply to PCC security 🛡️
As a general precaution, it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs belonging to the same administrative authority, using Transport Layer Security (TLS) [PCEPS], as per the recommendations and best current practices in [RFC7525]. Please, bestie, lock those sessions down 🔒
the following sections call out specific security concerns that might come from the PCEP extensions in this document, along with recommended mechanisms to protect PCEP infrastructure against those attacks 🫶
10.2. LSP State Snooping 👀
the stateful nature of this extension explicitly requires LSP status updates to be sent from PCC to PCE. that's great because the PCE can give the PCC more optimal computations, BUT it also gives an adversary the chance to eavesdrop on decisions made by network systems outside the PCE 😱 this is especially true if the PCC delegates LSPs to multiple PCEs at the same time.
adversaries can get this info by eavesdropping on unsecured PCEP sessions, and then use it to target or optimize attacks on network infrastructure. for example, they could work around anti-DDoS measures that are protecting the network, or figure out choke points where the greatest harm could be done 💀
PCC implementations that allow concurrent connections to multiple PCEs SHOULD let the operator group the PCEs by administrative domain. and they MUST NOT advertise LSP existence and state to a PCE if that LSP is delegated to a PCE in a different group 🔐
10.3. Malicious PCE 😈
the LSP delegation mechanism in this document lets a PCC give the PCE effective control of an LSP for the duration of a PCEP session. that's cool for PCE control over the timing and sequence of path computations, both within and across PCEP sessions, but it also opens up a brand new attack vector 🚩 an attacker can flood the PCC with PCUpd messages at a rate that's faster than either the PCC can process them or the network can signal the changes. they can do this by spoofing messages or by compromising the PCE itself. yikes 😭
a PCC is free to revoke an LSP delegation at any time, no justification needed 💅 a defending PCC can do this by enqueueing the appropriate PCRpt message. once that message is enqueued in the session, the PCC is free to drop any incoming PCUpd messages without doing any additional processing. the boundary has been set, periodt ✨
10.4. Malicious PCC 💅
A stateful session also gives attackers a bigger target, bestie, because the PCE has to keep an LSP state replica for every single PCC 😭. It is RECOMMENDED that PCE implementations put a limit on how many resources one PCC can take up 🔒. A PCE that has such a limit MUST send a PCNtf message with notification-type 4 (Stateful PCE resource limit exceeded) and notification-value 1 (Entering resource limit exceeded state) when an LSP State Report pushes it over that threshold 🚨.
Delegation adds even more strain on PCE resources, so a PCE implementation MAY give delegations back early if it realises it doesn't have what it needs to manage them properly 🫶. Since the PCC is the one ultimately in charge of the delegation state, PCE implementations SHOULD add throttling so that flaps of either a PCEP session or an LSP delegation don't wreck things 🌊. It's giving protection, periodt ✨.
11. References 📚
11.1. Normative References 🎀
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
- [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, <https://www.rfc-editor.org/info/rfc2205>.
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <https://www.rfc-editor.org/info/rfc3209>.
- [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, January 2008, <https://www.rfc-editor.org/info/rfc5088>.
- [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, DOI 10.17487/RFC5089, January 2008, <https://www.rfc-editor.org/info/rfc5089>.
- [RFC5284] Swallow, G. and A. Farrel, "User-Defined Errors for RSVP", RFC 5284, DOI 10.17487/RFC5284, August 2008, <https://www.rfc-editor.org/info/rfc5284>.
- [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, <https://www.rfc-editor.org/info/rfc5440>.
- [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, DOI 10.17487/RFC5511, April 2009, <https://www.rfc-editor.org/info/rfc5511>.
- [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a Stateful Path Computation Element (PCE)", RFC 8051, DOI 10.17487/RFC8051, January 2017, <https://www.rfc-editor.org/info/rfc8051>.
- [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
11.2. Informative References 🌸
- [MPLS-PC] Chaieb, I., Le Roux, JL., and B. Cousin, "Improved MPLS-TE LSP Path Computation using Preemption", Global Information Infrastructure Symposium, DOI 10.1109/GIIS.2007.4404195, July 2007.
- [MXMN-TE] Danna, E., Mandal, S., and A. Singh, "A practical algorithm for balancing the max-min fairness and throughput objectives in traffic engineering", INFOCOM, 2012 Proceedings IEEE, pp. 846-854, DOI 10.1109/INFCOM.2012.6195833, March 2012.
- [PCE-Init-LSP] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", Work in Progress, draft-ietf-pce-pce-initiated-lsp-10, June 2017.
- [PCEP-GMPLS] Margaria, C., de Dios, O., and F. Zhang, "PCEP extensions for GMPLS", Work in Progress, draft-ietf-pce-gmpls-pcep-extensions-11, October 2015.
- [PCEP-YANG] Dhody, D., Hardwick, J., Beeram, V., and j. jefftant@gmail.com, "A YANG Data Model for Path Computation Element Communications Protocol (PCEP)", Work in Progress, draft-ietf-pce-pcep-yang-05, June 2017.
- [PCEPS] Lopez, D., de Dios, O., Wu, Q., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-18, September 2017.
- [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. McManus, "Requirements for Traffic Engineering Over MPLS", RFC 2702, DOI 10.17487/RFC2702, September 1999, <https://www.rfc-editor.org/info/rfc2702>.
- [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>.
- [RFC3346] Boyle, J., Gill, V., Hannan, A., Cooper, D., Awduche, D., Christian, B., and W. Lai, "Applicability Statement for Traffic Engineering with MPLS", RFC 3346, DOI 10.17487/RFC3346, August 2002, <https://www.rfc-editor.org/info/rfc3346>.
- [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, September 2003, <https://www.rfc-editor.org/info/rfc3630>.
- [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <https://www.rfc-editor.org/info/rfc4655>.
- [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, <https://www.rfc-editor.org/info/rfc4657>.
- [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <https://www.rfc-editor.org/info/rfc5305>.
- [RFC5394] Bryskin, I., Papadimitriou, D., Berger, L., and J. Ash, "Policy-Enabled Path Computation Framework", RFC 5394, DOI 10.17487/RFC5394, December 2008, <https://www.rfc-editor.org/info/rfc5394>.
- [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014, <https://www.rfc-editor.org/info/rfc7420>.
- [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
- [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
- [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, <http://www.rfc-editor.org/info/rfc8232>.
Acknowledgements 💖
We would like to thank Adrian Farrel, Cyril Margaria, and Ramon Casellas for their contributions to this document 🙌.
We would like to thank Shane Amante, Julien Meuric, Kohei Shiomoto, Paul Schultz, and Raveendra Torvi for their comments and suggestions. Thanks also to Jon Hardwick, Oscar Gonzales de Dios, Tomas Janciga, Stefan Kobza, Kexin Tang, Matej Spanik, Jon Parker, Marek Zavodsky, Ambrose Kwong, Ashwin Sampath, Calvin Ying, Mustapha Aissaoui, Stephane Litkowski, and Olivier Dugeon for helpful comments and discussions 🫶.
Contributors 🧚
The following people contributed substantially to the content of this document and should be considered coauthors 👑:
Xian Zhang
Huawei Technology
F3-5-B R&D Center
Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
China
Email: zhang.xian@huawei.comDhruv Dhody
Huawei Technology
Leela Palace
Bangalore, Karnataka 560008
INDIA
Email: dhruv.dhody@huawei.comSiva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata, Ontario K2K 3E8
Canada
Email: msiva@cisco.comAuthors' Addresses 🦋
Edward Crabbe
Oracle
1501 4th Ave, suite 1800
Seattle, WA 98101
United States of America
Email: edward.crabbe@oracle.comIna Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: inaminei@google.comJan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: jmedved@cisco.comRobert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.techThat's the whole thing, bestie! RFC 8231 is wrapped up 🌈✨💖
📦 where this page comes from
- ietf: rfc8231 2017-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms