RFC 5440
Path Computation Element (PCE) Communication Protocol (PCEP)
RFC 5440: Path Computation Element (PCE) Communication Protocol (PCEP) β¨
okay bestie, this is the RFC that defines PCEP, the protocol that lets a PCC and a PCE talk to each other π«Ά It's a Standards Track document from March 2009. The main authors are JP. Vasseur, Ed. from Cisco Systems and JL. Le Roux, Ed. from France Telecom π It's from the Network Working Group.
Status of This Memo π
So this document specifies an Internet standards track protocol for the Internet community, and it's basically asking everyone to discuss it and suggest improvements π For where this protocol stands in standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1). Also, distribution of this memo is unlimited π
Copyright Notice Β©οΈ
Copyright (c) 2009 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, as they stand on the date this document was published. You can find them at http://trustee.ietf.org/license-info. Please read these carefully, because they spell out your rights and restrictions for this document π§
Heads up: this document may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The person or people who own the copyright on some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process π¬ So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process either. The exceptions are formatting it for publication as an RFC or translating it into languages other than English β¨
Abstract π¦
This document defines the Path Computation Element (PCE) Communication Protocol (PCEP) for talking between a Path Computation Client (PCC) and a PCE, or between two PCEs. The chats include path computation requests, path computation replies, and notifications about specific states tied to using a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering π PCEP is designed to be flexible and extensible, so adding more messages and objects is easy if new requirements show up later πΈ
Table of Contents ποΈ
1. Introduction ....................................................5
1.1. Requirements Language ......................................5
2. Terminology .....................................................5
3. Assumptions .....................................................6
4. Architectural Protocol Overview (Model) .........................7
4.1. Problem ....................................................7
4.2. Architectural Protocol Overview ............................7
4.2.1. Initialization Phase ................................8
4.2.2. Session Keepalive ...................................9
4.2.3. Path Computation Request Sent by a PCC to a PCE ....10
4.2.4. Path Computation Reply Sent by The PCE to a PCC ....11
4.2.5. Notification .......................................12
4.2.6. Error ..............................................14
4.2.7. Termination of the PCEP Session ....................14
4.2.8. Intermittent versus Permanent PCEP Session .........15
5. Transport Protocol .............................................15
6. PCEP Messages ..................................................15
6.1. Common Header .............................................16
6.2. Open Message ..............................................16
6.3. Keepalive Message .........................................18
6.4. Path Computation Request (PCReq) Message ..................19
6.5. Path Computation Reply (PCRep) Message ....................20
6.6. Notification (PCNtf) Message ..............................21
6.7. Error (PCErr) Message .....................................22
6.8. Close Message .............................................23
6.9. Reception of Unknown Messages .............................23
7. Object Formats .................................................23
7.1. PCEP TLV Format ...........................................24
7.2. Common Object Header ......................................24
7.3. OPEN Object ...............................................25
7.4. RP Object .................................................27
7.4.1. Object Definition ..................................27
7.4.2. Handling of the RP Object ..........................30
7.5. NO-PATH Object ............................................31
7.6. END-POINTS Object .........................................34
7.7. BANDWIDTH Object ..........................................35
7.8. METRIC Object .............................................36
7.9. Explicit Route Object .....................................39
7.10. Reported Route Object ....................................39
7.11. LSPA Object ..............................................40
7.12. Include Route Object .....................................42
7.13. SVEC Object ..............................................42
7.13.1. Notion of Dependent and Synchronized Path
Computation Requests ..............................42
7.13.2. SVEC Object .......................................44
7.13.3. Handling of the SVEC Object .......................45
7.14. NOTIFICATION Object ......................................46
7.15. PCEP-ERROR Object ........................................49
7.16. LOAD-BALANCING Object ....................................54
7.17. CLOSE Object .............................................55
8. Manageability Considerations ...................................56
8.1. Control of Function and Policy ............................56
8.2. Information and Data Models ...............................57
8.3. Liveness Detection and Monitoring .........................57
8.4. Verifying Correct Operation ...............................58
8.5. Requirements on Other Protocols and Functional
Components ................................................58
8.6. Impact on Network Operation ...............................58
9. IANA Considerations ............................................59
9.1. TCP Port ..................................................59
9.2. PCEP Messages .............................................59
9.3. PCEP Object ...............................................59
9.4. PCEP Message Common Header ................................61
9.5. Open Object Flag Field ....................................61
9.6. RP Object .................................................61
9.7. NO-PATH Object Flag Field .................................62
9.8. METRIC Object .............................................63
9.9. LSPA Object Flag Field ....................................63
9.10. SVEC Object Flag Field ...................................64
9.11. NOTIFICATION Object ......................................64
9.12. PCEP-ERROR Object ........................................65
9.13. LOAD-BALANCING Object Flag Field .........................67
9.14. CLOSE Object .............................................67
9.15. PCEP TLV Type Indicators .................................68
9.16. NO-PATH-VECTOR TLV .......................................68
10. Security Considerations .......................................69
10.1. Vulnerability ............................................69
10.2. TCP Security Techniques ..................................70
10.3. PCEP Authentication and Integrity ........................70
10.4. PCEP Privacy .............................................71
10.5. Key Configuration and Exchange ...........................71
10.6. Access Policy ............................................73
10.7. Protection against Denial-of-Service Attacks .............73
10.7.1. Protection against TCP DoS Attacks ................73
10.7.2. Request Input Shaping/Policing ....................74
11. Acknowledgments ...............................................75
12. References ....................................................75
12.1. Normative References .....................................75
12.2. Informative References ...................................76
Appendix A. PCEP Finite State Machine (FSM) ......................79
Appendix B. PCEP Variables .......................................85
Appendix C. Contributors .........................................861. Introduction β¨
okay so this is where it all starts π¦ [RFC4655] explains the motivations and architecture for a Path Computation Element (PCE) based model. That model is for computing Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) π The model lets you split the PCE off from the Path Computation Client (PCC), and it lets PCEs cooperate with each other. That means you need a communication protocol between the PCC and the PCE, and between PCEs too π
[RFC4657] lays out the generic requirements for that protocol. One of them is that the same protocol gets used between a PCC and a PCE, and between PCEs. Application-specific requirements, like for inter-area or inter-AS scenarios, aren't in [RFC4657]. But there's a requirement that any solution protocol has to be easily extensible, so it can handle new requirements as they show up in application-specific requirements documents π₯ Examples of those are [RFC4927], [RFC5376], and [INTER-LAYER].
This document specifies the Path Computation Element Protocol (PCEP) for communications between a PCC and a PCE, or between two PCEs, in compliance with [RFC4657] π The interactions include path computation requests and path computation replies, plus notifications about specific states related to using a PCE in the context of MPLS and GMPLS Traffic Engineering.
PCEP is designed to be flexible and extensible, so adding more messages and objects is easy if further requirements come up in the future π
1.1. Requirements Language π
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] π§
2. Terminology β¨
okay so let's get into the vocab, bestie π this section is basically the glossary that keeps everyone on the same page, and it's giving organized π
The following terminology is used in this document.
AS: Autonomous System. πΈ
Explicit path: the full explicit path from start to destination π¦ it's made of a list of strict hops, and a hop can be an abstract node like an AS, so it's not always a physical box.
IGP area: either an OSPF area or an IS-IS level. π§
Inter-domain TE LSP: a TE LSP whose path goes through at least two different domains π and a domain can be an IGP area, an Autonomous System, or a sub-AS (a BGP confederation). iconic π
PCC: Path Computation Client π any client application that asks for a path computation to be done by a Path Computation Element.
PCE: Path Computation Element π₯ an entity (a component, an application, or a network node) that can compute a network path or route based on a network graph and apply computational constraints. the brain of the operation, no cap π§
PCEP Peer: any element involved in a PCEP session, which means a PCC or a PCE. β¨
TED: Traffic Engineering Database π it holds the topology and resource info of the domain. The TED might be fed by IGP extensions, or potentially by other means.
TE LSP: Traffic Engineering Label Switched Path. π«Ά
Strict/loose path: a mix of strict and loose hops with at least one loose hop representing the destination π a hop can be an abstract node like an AS too.
Within this document, when we're describing PCE-PCE communications, the requesting PCE takes on the role of a PCC. π¦ this saves documentation without losing any function, which is very efficient of them ngl π
The message formats in this document are specified using Backus-Naur Format (BNF) encoding as specified in [RBNF]. π
3. Assumptions π
[RFC4655] describes various types of PCE. πΈ PCEP doesn't make any assumption about the nature of the PCE, and so it doesn't impose any constraint on it either. not me being like "wow, so flexible" π¦
Moreover, it's assumed that the PCE has the required information (usually including network topology and resource information) so it can compute a path for a TE LSP. π§ That info can be gathered by routing protocols or by some other means. How it gets gathered is out of scope for this document, bestie π
Similarly, no assumption is made about the discovery method a PCC uses to find a set of PCEs (for example, static configuration or dynamic discovery) π and no assumption is made about the algorithm used to select a PCE either. For reference, [RFC4674] defines a list of requirements for dynamic PCE discovery, and IGP-based solutions for that discovery are specified in [RFC5088] and [RFC5089]. β¨
4. Architectural Protocol Overview (Model) π
The aim of this section is to describe the PCEP model in the spirit of [RFC4101]. π An architectural protocol overview (the big picture of the protocol) is provided here, and protocol details live in later sections. iykyk π«Ά
4.1. Problem π₯
The PCE-based architecture used for computing paths for MPLS and GMPLS TE LSPs is described in [RFC4655]. π¦ When the PCC and the PCE aren't collocated, you need a communication protocol between them. That's where PCEP comes in π it's designed specifically for communication between a PCC and a PCE, or between two PCEs, in compliance with [RFC4657]. A PCC can use PCEP to send a path computation request for one or more TE LSPs to a PCE, and the PCE can reply with a set of computed paths if one or more paths can be found that satisfy the set of constraints. slay π β¨
4.2. Architectural Protocol Overview πΈ
PCEP runs over TCP, which handles reliable messaging and flow control without any extra protocol work. literally so convenient π
Several PCEP messages are defined: π§
- Open and Keepalive messages are used to initiate and maintain a PCEP session, respectively. π¦
- PCReq: a PCEP message sent by a PCC to a PCE to request a path computation. π
- PCRep: a PCEP message sent by a PCE to a PCC in reply to a path computation request. A PCRep message can contain either a set of computed paths if the request can be satisfied, or a negative reply if not. The negative reply may indicate the reason why no path could be found. π
- PCNtf: a PCEP notification message, sent either by a PCC to a PCE or by a PCE to a PCC, to notify of a specific event. π
- PCErr: a PCEP message sent when a protocol error condition occurs. π
- Close message: a message used to close a PCEP session. π«Ά
The set of available PCEs may be either statically configured on a PCC or dynamically discovered. π The mechanisms used to discover one or more PCEs and to select a PCE are out of scope for this document.
A PCC may have PCEP sessions with more than one PCE, and similarly a PCE may have PCEP sessions with multiple PCCs. π
Each PCEP message is regarded as a single transmission unit, and parts of messages MUST NOT be interleaved. π« So, for example, a PCC sending a PCReq that wants to close the session must finish sending the request message before it starts sending a Close message. no interleaving, periodt π
4.2.1. Initialization Phase π¦
The initialization phase has two successive steps (shown schematically in Figure 1): πΈ
- Establishment of a TCP connection (3-way handshake) between the PCC and the PCE. π§
- Establishment of a PCEP session over the TCP connection. β¨
Once the TCP connection is up, the PCC and the PCE (also called "PCEP peers") start PCEP session establishment, during which various session parameters get negotiated. π These parameters are carried within Open messages and include the Keepalive timer, the DeadTimer, and potentially other detailed capabilities and policy rules that specify the conditions under which path computation requests may be sent to the PCE. If the PCEP session establishment fails because the PCEP peers disagree on the session parameters, or one of them doesn't answer before the establishment timer expires, the TCP connection is immediately closed. π Successive retries are permitted, but an implementation SHOULD use an exponential back-off session establishment retry procedure. π₯
Keepalive messages are used to acknowledge Open messages, and they're used once the PCEP session has been successfully established. π«Ά
Only one PCEP session can exist between a pair of PCEP peers at any one time. π Only one TCP connection on the PCEP port can exist between a pair of PCEP peers at any one time. π
Details about the Open message and the Keepalive message can be found in Sections 6.2 and 6.3, respectively. π
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| Open msg |
|-------- |
| \ Open msg |
| \ ---------|
| \/ |
| /\ |
| / -------->|
| / |
|<------ Keepalive|
| --------|
|Keepalive / |
|-------- / |
| \/ |
| /\ |
|<------ ---------->|
| |Figure 1: PCEP Initialization Phase (Initiated by a PCC) π
(Note that once the PCEP session is established, the exchange of Keepalive messages is OPTIONAL. π¦)
4.2.2. Session Keepalive πΈ
Once a session has been established, a PCE or PCC may want to know that its PCEP peer is still available for use. π§
It can rely on TCP for this information, but the remote PCEP function might have failed without disturbing the TCP connection. Γ°ΕΈΛΒ± Okay wait, that's a plot twist π It's also possible to rely on the mechanisms built into TCP implementations, but those might not provide failure notifications that are timely enough. Lastly, a PCC could wait until it has a path computation request to send and use its failed transmission, or the failure to receive a response, as evidence that the session has failed. clearly inefficient though π
To handle this, PCEP includes a keepalive mechanism based on a Keepalive timer, a DeadTimer, and a Keepalive message. π«Ά
Each end of a PCEP session runs a Keepalive timer. It restarts the timer every time it sends a message on the session. When the timer expires, it sends a Keepalive message. Other traffic may serve as Keepalive (see Section 6.3). β¨
The ends of the PCEP session also run DeadTimers, and they restart the timers whenever a message is received on the session. If one end of the session receives no message before the DeadTimer expires, it declares the session dead. π
Note that the Keepalive message is unresponded and does not form part of a two-way keepalive handshake like some other protocols use. Also, the mechanism is designed to reduce the amount of keepalive traffic on the session to a minimum. π
The keepalive traffic on the session may be unbalanced according to the requirements of each session end. Each end can specify (in an Open message) the Keepalive timer it will use, meaning how often it will transmit a Keepalive message if there is no other traffic, and a DeadTimer that it recommends its peer use, meaning how long the peer should wait before declaring the session dead if it receives no traffic. The session ends may use different Keepalive timer values. π
The minimum value of the Keepalive timer is 1 second, and it is specified in units of 1 second. The recommended default value is 30 seconds. The timer MAY be disabled by setting it to zero. π§
The recommended default for the DeadTimer is 4 times the value of the Keepalive timer used by the remote peer. This means there is never any risk of congesting TCP with excessive Keepalive messages. no congestion, no drama π
4.2.3. Path Computation Request Sent by a PCC to a PCE π¦
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request sent to | |
the selected PCE | |Figure 2: Path Computation Request πΈ
Once a PCC has successfully established a PCEP session with one or more PCEs, if an event is triggered that requires computing a set of paths, the PCC first selects one or more PCEs. Note that the PCE selection decision process may have taken place before the PCEP session was established. π§
Once the PCC has selected a PCE, it sends a path computation request to the PCE (PCReq message). That request contains a variety of objects that specify the set of constraints and attributes for the path to be computed. For example, "Compute a TE LSP path with source IP address=x.y.z.t, destination IP address=x'.y'.z'.t', bandwidth=B Mbit/s, Setup/Holding priority=P, ...". π The PCC may also want to specify the urgency of the request by assigning a request priority. Each request is uniquely identified by a request-id number and the PCC-PCE address pair. β¨ The process is shown schematically in Figure 2.
Note that multiple path computation requests may be outstanding from a PCC to a PCE at any time. π«Ά
Details about the PCReq message can be found in Section 6.4. π
4.2.4. Path Computation Reply Sent by The PCE to a PCC
Okay so the PCE has the request, and now it's time to answer π Here's the happy path first:
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) Path successfully
| | computed
| |
| |3) Computed paths
| | sent to the PCC
| |
|<--- PCRep message ---|
| (Positive reply) |
Figure 3a: Path Computation Request With Successful
Path ComputationAnd here's the not-so-happy path π₯Ί
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
| |
|---- PCReq message--->|
| |1) Path computation
| | request received
| |
| |2) No Path found that
| | satisfies the request
| |
| |3) Negative reply sent to
| | the PCC (optionally with
| | various additional
| | information)
|<--- PCRep message ---|
| (Negative reply) |
Figure 3b: Path Computation Request With Unsuccessful
Path ComputationSo when the PCE gets a path computation request from a PCC, it kicks off a path computation, and the result can be one of two things:
- Positive (Figure 3a): the PCE manages to find a path that meets the full set of required constraints. The PCE then sends the computed paths back to the PCC that asked. Also, PCEP can handle a single request that needs more than one path (for example, a set of link-diverse paths) β¨
- Negative (Figure 3b): no path can be found that meets the set of constraints. In this case, the PCE may include the constraints that caused the failure. After getting a negative reply, a PCC may decide to resend a modified request or do something else that makes sense for it π
Details about the PCRep message can be found in Section 6.5.
4.2.5. Notification
Sometimes a PCE needs to tell a PCC about something important π£ For example, imagine the PCE suddenly gets overloaded and its response times start getting ugly. The PCE can notify one or more PCCs that some of their requests (the ones listed in the notification) won't be satisfied, or might face unacceptable delays. Once a PCC gets that heads-up, it can redirect its path computation requests to another PCE, if one is available π¦ It can also go the other way around: a PCC may want to tell a PCE about an event, like cancelling pending requests.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
5) Path computation | |
request X cancelled| |
|---- PCNtf message -->|
| |6) Path computation
| | request X cancelled
Figure 4: Example of PCC Notification (Cancellation Notification)
Sent to a PCE +-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Path computation
the selected PCE | | request queued
| |
| |
| |5) PCE gets overloaded
| |
| |
| |6) Path computation
| | request X cancelled
| |
|<--- PCNtf message----|
Figure 5: Example of PCE Notification (Cancellation Notification)
Sent to a PCCDetails about the PCNtf message can be found in Section 6.6.
4.2.6. Error
The PCEP Error message (also called a PCErr message) gets sent in a few situations: when a protocol error condition shows up, or when a request doesn't follow the PCEP spec. Examples include a capability that isn't supported, a message that's missing a mandatory object, a policy violation, an unexpected message, or an unknown request reference π¨
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
1) Path computation | |
event | |
2) PCE Selection | |
3) Path computation |---- PCReq message--->|
request X sent to | |4) Reception of a
the selected PCE | | malformed object
| |
| |5) Request discarded
| |
|<-- PCErr message ---|
| |
Figure 6: Example of Error Message Sent by a PCE to a PCC
in Reply to the Reception of a Malformed ObjectDetails about the PCErr message can be found in Section 6.7.
4.2.7. Termination of the PCEP Session
When one of the PCEP peers wants to end a PCEP session, it first sends a PCEP Close message and then closes the TCP connection π If the PCE is the one ending the session, the PCC clears all the states tied to pending requests it sent to that PCE. It works the other way too: if the PCC ends the session, the PCE clears all pending path computation requests from that PCC, plus the related states. A Close message can only be sent to terminate a PCEP session if that session was previously established.
If the TCP connection fails, the PCEP session is terminated right away. No goodbye message needed, bestie π
Details about the Close message can be found in Section 6.8.
4.2.8. Intermittent versus Permanent PCEP Session
An implementation may choose to keep the PCEP session (and the TCP connection under it) alive for an unlimited time π This can make sense when path computation requests come in frequently, so you don't have to open a new TCP connection every time you need a path, which would add processing delays. On the flip side, in some situations it may be better to open and close a PCEP session for each PCEP request, like when sending a path computation request is a rare event π§
5. Transport Protocol
PCEP runs over TCP using a registered TCP port, 4189 π That's how it gets reliable messaging and flow control without any extra protocol work. All PCEP messages MUST be sent using the registered TCP port as both the source and destination TCP port.
6. PCEP Messages
Every PCEP message is a common header followed by a variable-length body, made of a set of objects. Each object is either mandatory or optional π«Ά For this document, an object counts as mandatory in a PCEP message when it MUST be included for the message to be valid. If a PCEP message is missing a mandatory object, it MUST trigger an Error message (see Section 7.15). Optional objects, on the other hand, may or may not show up.
Each object's common header has a flag called the P flag (see Section 7.2). When this flag is set in an object inside a PCReq, the PCE MUST take the information in that object into account during path computation. For example, the METRIC object from Section 7.8 lets a PCC specify a bounded acceptable path cost. METRIC is optional, but a PCC can set the flag to make sure the constraint gets considered. If the PCE can't take that constraint into account, the PCE MUST trigger an Error message π₯
For each PCEP message type, there are rules that define which objects the message can carry. We use the Backus-Naur Form (BNF) (see [RBNF]) to write those rules. Square brackets mark optional sub-sequences. An implementation MUST form PCEP messages using the object ordering specified in this document π
6.1. Common Header
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Message-Type | Message-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: PCEP Message Common HeaderHere's the breakdown of the common header fields π
Ver(Version - 3 bits): the PCEP version number. The current version is version 1.Flags(5 bits): no flags are defined right now. Unassigned bits count as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt.Message-Type(8 bits): the message types that are currently defined are below.
Value Meaning
1 Open
2 Keepalive
3 Path Computation Request
4 Path Computation Reply
5 Notification
6 Error
7 CloseMessage-Length(16 bits): the total length of the PCEP message, including the common header, in bytes.
6.2. Open Message π
okay so the Open message is the very first hello in a PCEP session π It's sent by a PCC to a PCE and by a PCE to a PCC to get the session started. The Message-Type field of the PCEP common header is set to 1 for this one π¦
Once the TCP connection is up, the first message the PCC sends to the PCE (or the PCE sends to the PCC) MUST be an Open message, as specified in Appendix A β¨
Anything that shows up before an Open message MUST trigger a protocol error condition. That means a PCErr message gets sent with Error-Type "PCEP session establishment failure" and Error-value "reception of an invalid Open message or a non Open message", and the session establishment attempt MUST be terminated by closing the TCP connection. no notes, that's a hard stop π
The Open message is how the PCEP peers set up a session with each other. During the establishment phase they swap a bunch of session characteristics, and if both sides agree on them, the session is successfully established πΈ
Here's what an Open message looks like:
<Open Message>::= <Common Header>
<OPEN>The Open message MUST contain exactly one OPEN object (see Section 7.3) π
The session characteristics live inside the OPEN object. Once the TCP connection is successfully established, the sender MUST start an initialization timer called OpenWait. If the timer runs out and no Open message has come in, the sender sends a PCErr message and lets go of the TCP connection (see Appendix A for details) β°
Once an Open message has been sent to a PCEP peer, the sender MUST start a second initialization timer called KeepWait. When that one expires, if the sender has received neither a Keepalive message nor a PCErr message (the PCErr is for when the session characteristics don't match), a PCErr message MUST be sent and the TCP connection MUST be released (see Appendix A for details) π
Both the OpenWait and KeepWait timers have a fixed value of 1 minute β³
When an Open message comes in, the receiving PCEP peer MUST work out whether the suggested session characteristics are acceptable. If even one of them isn't acceptable to that peer, it MUST send an Error message. The Error message SHOULD also carry the related OPEN object, and for each unacceptable session parameter, an acceptable value SHOULD be proposed in the matching field of the OPEN object, replacing the originally proposed value π
The PCEP peer MAY decide to resend an Open message with different session characteristics. If a second Open message arrives with the same set of parameters, or with parameters that are still unacceptable, the receiving peer MUST send an Error message AND MUST immediately close the TCP connection. (okay I'm screaming, that second strike is a hard no π₯) Details about error messages can be found in Section 7.15.
Successive retries are permitted, but an implementation SHOULD make use of an exponential back-off session establishment retry procedure π¦
If the PCEP session characteristics are acceptable, the receiving PCEP peer MUST send a Keepalive message (defined in Section 6.3). That Keepalive is basically the acknowledgment, the "yep, we're good" π
And the session counts as established once both PCEP peers have received a Keepalive message from their peer β¨
6.3. Keepalive Message π§
A Keepalive message is a PCEP message sent by a PCC or a PCE to keep the session in an active state π It's also what gets sent back in response to an Open message, to say "got your Open, and your session characteristics are fine." The Message-Type field of the PCEP common header is set to 2 for Keepalive messages. And there's no object in a Keepalive message, zero, none, nada π
PCEP has its own keepalive mechanism to check that the session is still alive. That means each PCEP peer has to decide how often it sends Keepalive messages. The values can be asymmetric, so there's no rule that both peers have to use the same keepalive frequency π
The DeadTimer is the amount of time a PCEP peer waits, if it hasn't received any PCEP message (Keepalive or otherwise), before it declares the session down. Any PCEP message counts as a Keepalive, so basically anything that shows up resets the clock π«Ά Again, the DeadTimers don't have to match on both sides. The minimum Keepalive timer value is 1 second β Deployments SHOULD consider carefully the impact of using low values for the Keepalive timer, because those might not give the expected results when the network is temporarily unstable π
Keepalive messages are sent at the frequency specified in the OPEN object carried within an Open message, following the rules in Section 7.3. And since any PCEP message can do the job of a Keepalive, an implementation can either send Keepalives at fixed intervals no matter what else has gone out since the last Keepalive, or it can push back the next Keepalive based on when the last non-Keepalive PCEP message was sent β°
Sending Keepalive messages to keep the session alive is optional. PCEP peers may decide not to send them once the session is established. In that case, the peer that isn't receiving Keepalives doesn't expect to get them, and it MUST NOT declare the session as inactive π
The format of a Keepalive message is:
<Keepalive Message>::= <Common Header>6.4. Path Computation Request (PCReq) Message π
A Path Computation Request message (also called a PCReq message) is a PCEP message a PCC sends to a PCE to ask for a path computation. A single PCReq message can carry more than one path computation request. The Message-Type field of the PCEP common header is set to 3 for PCReq messages π¦
There are two mandatory objects that MUST be included in a PCReq message: the RP object and the END-POINTS object (see Section 7). If one or both of them are missing, the receiving PCE MUST send an error message to the requesting PCC. Everything else is optional πΈ
Here's the format of a PCReq message:
<PCReq Message>::= <Common Header>
[<svec-list>]
<request-list>where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]
<request>::= <RP>
<END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>[<BANDWIDTH>]]
[<IRO>]
[<LOAD-BALANCING>]
<metric-list>::=<METRIC>[<metric-list>]The SVEC, RP, END-POINTS, LSPA, BANDWIDTH, METRIC, RRO, IRO, and LOAD-BALANCING objects are all defined in Section 7. The special case of two BANDWIDTH objects is covered in detail in Section 7.7 β¨
A PCEP implementation is free to process received requests in any order π For example, the requests could be handled in the order they arrived, reshuffled and given priority based on local policy, reordered according to the priority encoded in the RP object (Section 7.4.1), or processed in parallel π§
6.5. Path Computation Reply (PCRep) Message π
The PCEP Path Computation Reply message (also called a PCRep message) is a PCEP message a PCE sends to a requesting PCC in response to a PCReq message it got earlier. The Message-Type field of the PCEP common header is set to 4 for PCRep messages π
PCEP supports bundling several replies to a set of path computation requests into a single PCRep message. If a PCE gets non-synchronized path computation requests through one or more PCReq messages from a requesting PCC, it MAY decide to bundle the computed paths into a single PCRep message, which cuts down on control plane load. The catch is that some of the requests in the set may see extra delays π On the flip side, a PCE that gets multiple requests in the same PCReq message MAY decide to send each computed path in a separate PCRep message, or put them all in the same PCRep message. A PCRep message may contain both positive and negative replies π
A PCRep message may contain a set of computed paths that correspond either to a single path computation request with load-balancing (see Section 7.16) or to multiple path computation requests originated by a requesting PCC. It may also contain multiple acceptable paths for the same request π«Ά
The PCRep message MUST contain at least one RP object. For each reply bundled into a single PCReq message, an RP object MUST be included that carries a Request-ID-number identical to the one in the RP object of the matching PCReq message (see Section 7.4 for the definition of the RP object) π
If the path computation request can be satisfied (meaning the PCE finds a set of paths that meet the constraints), the computed paths are inserted into the PCRep message as Explicit Route Objects (EROs). The ERO is defined in Section 7.9. The case where multiple computed paths show up in one PCRep message is discussed in detail in Section 7.13. And when a PCC asks for a set of paths for a total amount of bandwidth using a LOAD-BALANCING object in a PCReq message, the ERO of each computed path may be followed by a BANDWIDTH object, as discussed in section Section 7.16 β¨
If the path computation request can't be satisfied, the PCRep message MUST include a NO-PATH object. The NO-PATH object (described in Section 7.5) may also carry other info, like the reasons the path computation failed π
The format of a PCRep message is:
<PCRep Message> ::= <Common Header>
<response-list>where:
<response-list>::=<response>[<response-list>]
<response>::=<RP>
[<NO-PATH>]
[<attribute-list>]
[<path-list>]
<path-list>::=<path>[<path-list>]
<path>::= <ERO><attribute-list>where:
<attribute-list>::=[<LSPA>]
[<BANDWIDTH>]
[<metric-list>]
[<IRO>]
<metric-list>::=<METRIC>[<metric-list>]6.6. Notification (PCNtf) Message π
okay so the PCEP Notification message (aka the PCNtf message) is the one a PCE can send to a PCC, or a PCC can send to a PCE, to tell the other side about a specific event π its Message-Type is set to 5 π
the PCNtf message MUST carry at least one NOTIFICATION object π«Ά it MAY have several NOTIFICATION objects if the PCE or the PCC wants to report multiple events. the NOTIFICATION object is in Section 7.14 β¨ and the PCNtf message MAY also include RP objects (see Section 7.4) when the notification is about particular path computation requests π
a PCC or a PCE can send a PCNtf in response to a request, or just unsolicited π¦
here's the format:
<PCNtf Message>::=<Common Header>
<notify-list>
<notify-list>::=<notify> [<notify-list>]
<notify>::= [<request-id-list>]
<notification-list>
<request-id-list>::=<RP>[<request-id-list>]
<notification-list>::=<NOTIFICATION>[<notification-list>]6.7. Error (PCErr) Message π¨
the PCEP Error message (aka PCErr) gets sent when something goes wrong π like a protocol error condition, or a request that doesn't follow the PCEP spec. examples are a malformed message, a message missing a mandatory object, a policy violation, an unexpected message, or an unknown request reference π its Message-Type is set to 6.
a PCC or a PCE sends a PCErr in response to a request or unsolicited. if it's sent in response to a request, the PCErr MUST include the set of RP objects for the pending path computation requests that triggered the error β¨ if it's unsolicited, no RP object goes in the PCErr. like, if the error happened during the initialization phase, there's no RP object at all πΈ
also, a PCErr MUST contain a PCEP-ERROR object that says what the error condition is π that object is in Section 7.15 π
the format:
<PCErr Message> ::= <Common Header>
( <error-obj-list> [<Open>] ) | <error>
[<error-list>]
<error-obj-list>::=<PCEP-ERROR>[<error-obj-list>]
<error>::=[<request-id-list>]
<error-obj-list>
<request-id-list>::=<RP>[<request-id-list>]
<error-list>::=<error>[<error-list>]the procedure for receiving a PCErr is in Section 7.15 π₯
6.8. Close Message π
the Close message is a PCEP message that a PCC sends to a PCE, or a PCE sends to a PCC, to close an established PCEP session π₯ its Message-Type is set to 7.
format:
<Close Message>::= <Common Header>
<CLOSE>the Close message MUST contain exactly one CLOSE object (see Section 6.8) π if there's more than one CLOSE object, the first one MUST be processed and the rest get ignored. bestie, that's the rule π
once a valid Close message is received, the receiving PCEP peer MUST cancel all pending requests, it MUST close the TCP connection, and it MUST NOT send any further PCEP messages on the PCEP session π₯Ή literally done.
6.9. Reception of Unknown Messages π
if a PCEP implementation gets a message it doesn't recognize, it MUST send a PCErr message with Error-value=2 (capability not supported) π
if a PCC or PCE gets unrecognized messages at a rate equal to or greater than MAX-UNKNOWN-MESSAGES unknown message requests per minute, it MUST send a PCEP CLOSE message with the close value "Reception of an unacceptable number of unknown PCEP message" π in code-speak:
close value="Reception of an unacceptable number of unknown PCEP message"a RECOMMENDED value for MAX-UNKNOWN-MESSAGES is 5 β¨ and the PCC or PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session π€ not it.
7. Object Formats π§
PCEP objects all share a common format π they start with a common object header (see Section 7.2), followed by fields that are specific to each different object. an object can also include one or more type-length-value (TLV) encoded data sets π and each TLV has the same structure as the one in Section 7.1.
7.1. PCEP TLV Format π
a PCEP object can include a set of one or more optional TLVs π
every PCEP TLV looks like this:
Type: 2 bytes
Length: 2 bytes
Value: variableso a PCEP object TLV is 2 bytes for the type, 2 bytes for the TLV length, and then a value field π¦ the Length field tells you how long the value part is in bytes. the TLV is padded to 4-byte alignment, and the padding isn't counted in the Length field. so a 3-byte value has a length of 3, but the whole TLV is 8 bytes total β¨
Unrecognized TLVs MUST be ignored π
IANA manages the PCEP Object TLV type identifier codespace, and that's described in Section 9 πΈ
7.2. Common Object Header π·
a PCEP object carried inside a PCEP message is made of one or more 32-bit words, with a common header that looks like this:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Object-Class | OT |Res|P|I| Object Length (bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Object body) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 8: PCEP Common Object Header πΈ
let's break down the fields π§
Object-Class(8 bits): identifies the PCEP object class πOT(Object-Type - 4 bits): identifies the PCEP object type. the Object-Class and Object-Type fields are managed by IANA, and together they uniquely identify each PCEP object π₯Resflags (2 bits): reserved. this field MUST be set to zero on transmission and MUST be ignored on receipt πPflag (Processing-Rule - 1-bit): this lets a PCC say, in a PCReq message sent to a PCE, whether the object has to be taken into account by the PCE during path computation or is just optional π«Ά when the P flag is set, the object MUST be taken into account by the PCE. when the P flag is cleared, the object is optional and the PCE is free to ignore it πIflag (Ignore - 1 bit): the PCE uses this in a PCRep message to tell the PCC whether an optional object was processed. the PCE MAY include the ignored optional object in its reply and set the I flag to show it was ignored during path computation π when the I flag is cleared, the PCE is saying the optional object was processed during path computation. setting the I flag for optional objects is purely indicative and optional πΈ and the I flag has no meaning in a PCRep message when the P flag was set in the matching PCReq message πObject Length(16 bits): the total object length in bytes, including the header. the Object Length field MUST always be a multiple of 4, and at least 4 π the maximum object content length is 65528 bytes π
now, the drama π if the PCE doesn't understand an object with the P flag set, or it understands the object but decides to ignore it, the entire PCEP message MUST be rejected π and the PCE MUST send a PCErr message with Error-Type="Unknown Object" or "Not supported Object" along with the matching RP object. and note this: if a PCReq has multiple requests, only the requests whose P-flagged object is unknown or unrecognized MUST be rejected π₯Ή the rest are fine, bestie β¨
7.3. OPEN Object π
okay bestie, the OPEN object MUST be present in each Open message π and it MAY be present in a PCErr message too. There MUST be only one OPEN object per Open or PCErr message, so no doubles, periodt β¨
the OPEN object is basically the session's intro card π¦. it holds the PCEP version, the Keepalive frequency, the DeadTimer, and the PCEP session ID, plus some flags π . it can also carry TLVs for session stuff like detailed PCE capabilities and policy rules, but no TLVs are currently defined, so it's lowkey empty for now π₯Ί
OPEN Object-Class is 1.
OPEN Object-Type is 1.
the body looks like this π
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ver | Flags | Keepalive | DeadTimer | SID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: OPEN Object Formathere's the breakdown of each field π§
- Ver (3 bits): the PCEP version. Current version is 1. β¨
- Flags (5 bits): no flags are currently defined. Unassigned bits are considered as reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. π
- Keepalive (8 bits): the maximum period of time (in seconds) between two consecutive PCEP messages sent by the sender of this message. The minimum value for the Keepalive is 1 second. When set to 0, once the session is established, no further Keepalive messages are sent to the remote peer. A RECOMMENDED value for the keepalive frequency is 30 seconds. π
- DeadTimer (8 bits): specifies the amount of time after the expiration of which the PCEP peer can declare the session with the sender of the Open message to be down if no PCEP message has been received. The DeadTimer SHOULD be set to 0 and MUST be ignored if the Keepalive is set to 0. A RECOMMENDED value for the DeadTimer is 4 times the value of the Keepalive. β°
- SID (PCEP session ID - 8 bits): an unsigned PCEP session number that identifies the current session. The SID MUST be incremented each time a new PCEP session is established. It is used for logging and troubleshooting purposes. Each increment SHOULD have a value of 1 and may cause a wrap back to zero. π’
an example, because examples are everything π
A sends an Open message to B with Keepalive=10 seconds and DeadTimer=40 seconds. This means that A sends Keepalive messages (or any other PCEP message) to B every 10 seconds, and B can declare the PCEP session with A down if no PCEP message has been received from A within any 40-second period. π«Ά
about the SID, it's used to tell apart instances of sessions to the same peer π. an implementation could use a single source of SIDs across all peers, or one source for each peer. the former might limit the implementation to only 256 concurrent sessions, and the latter potentially needs more state. there is one SID number in each direction. π
Optional TLVs may be included within the OPEN object body to specify PCC or PCE characteristics. the specification of those TLVs is outside the scope of this document π
when an OPEN object shows up in an Open message, it's the proposed PCEP session characteristics. if the receiving PCEP peer (PCE) gets session characteristics it can't accept during session initialization, it MAY include an OPEN object within the PCErr message to propose alternative acceptable session characteristic values. it's giving "let's negotiate" energy π€
7.4. RP Object πΈ
the RP (Request Parameters) object MUST be carried within each PCReq and PCRep message, and it MAY be carried within PCNtf and PCErr messages π . it's used to specify various characteristics of the path computation request.
the P flag of the RP object MUST be set in PCReq and PCRep messages and MUST be cleared in PCNtf and PCErr messages π©. if the RP object arrives with the P flag set incorrectly by those rules, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. and the corresponding path computation request MUST be cancelled by the PCE without further notification. no warning, just gone π
7.4.1. Object Definition β¨
RP Object-Class is 2.
RP Object-Type is 1.
the RP object body looks like this π¦
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |O|B|R| Pri |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: RP Object Body Formatthe body has a variable length and may contain additional TLVs. no TLVs are currently defined π
Flags (32 bits) π©
the following flags are currently defined:
Pri(Priority - 3 bits): the Priority field may be used by the requesting PCC to specify to the PCE the request's priority from 1 to 7. The decision of which priority should be used for a specific request is a local matter; it MUST be set to 0 when unused. Furthermore, the use of the path computation request priority by the PCE's scheduler is implementation specific and out of the scope of this document. Note that it is not required for a PCE to support the priority field: in this case, it is RECOMMENDED that the PCC set the priority field to 0 in the RP object. If the PCE does not take into account the request priority, it is RECOMMENDED to set the priority field to 0 in the RP object carried within the corresponding PCRep message, regardless of the priority value contained in the RP object carried within the corresponding PCReq message. A higher numerical value of the priority field reflects a higher priority. Note that it is the responsibility of the network administrator to make use of the priority values in a consistent manner across the various PCCs. The ability of a PCE to support request prioritization MAY be dynamically discovered by the PCCs by means of PCE capability discovery. If not advertised by the PCE, a PCC may decide to set the request priority and will learn the ability of the PCE to support request prioritization by observing the Priority field of the RP object received in the PCRep message. If the value of the Pri field is set to 0, this means that the PCE does not support the handling of request priorities: in other words, the path computation request has been honored but without taking the request priority into account. πR(Reoptimization - 1 bit): when set, the requesting PCC specifies that the PCReq message relates to the reoptimization of an existing TE LSP. For all TE LSPs except zero-bandwidth LSPs, when the R bit is set, an RRO (see Section 7.10) MUST be included in the PCReq message to show the path of the existing TE LSP. Also, for all TE LSPs except zero-bandwidth LSPs, when the R bit is set, the existing bandwidth of the TE LSP to be reoptimized MUST be supplied in a BANDWIDTH object (see Section 7.7). This BANDWIDTH object is in addition to the instance of that object used to describe the desired bandwidth of the reoptimized LSP. For zero-bandwidth LSPs, the RRO and BANDWIDTH objects that report the characteristics of the existing TE LSP are optional. πB(Bi-directional - 1 bit): when set, the PCC specifies that the path computation request relates to a bi-directional TE LSP that has the same traffic engineering requirements, including fate sharing, protection and restoration, LSRs, TE links, and resource requirements (e.g., latency and jitter) in each direction. When cleared, the TE LSP is unidirectional. βοΈO(strict/loose - 1 bit): when set, in a PCReq message, this indicates that a loose path is acceptable. Otherwise, when cleared, this indicates to the PCE that a path exclusively made of strict hops is required. In a PCRep message, when the O bit is set this indicates that the returned path is a loose path; otherwise (when the O bit is cleared), the returned path is made of strict hops. π§
unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. π
Request-ID-number (32 bits): the Request-ID-number value, combined with the source IP address of the PCC and the PCE address, uniquely identifies the path computation request context. The Request-ID-number is used for disambiguation between pending requests, so it MUST be changed (such as by incrementing it) each time a new request is sent to the PCE, and it may wrap. π’
the value 0x00000000 is considered invalid π
ββοΈ
if no path computation reply comes back from the PCE (say the request got dropped because of memory overflow) and the PCC wants to resend its request, the same Request-ID-number MUST be used. when the PCE gets a path computation request from a PCC with the same Request-ID-number, the PCE SHOULD treat it as a new request. an implementation MAY choose to cache path computation replies so retransmissions get handled quickly, without processing a path computation request twice (in case the first one was dropped or lost). and when a PCC gets a path computation reply from a PCE with the same Request-ID-number, the PCC SHOULD silently discard that reply. π
conversely, different Request-ID-numbers MUST be used for different requests sent to a PCE. β¨
the same Request-ID-number MAY be used for path computation requests sent to different PCEs. the path computation reply is unambiguously identified by the IP source address of the replying PCE π
7.4.2. Handling of the RP Object β¨
okay bestie, this is where the PCE decides what to do with the RP object π
If a PCReq message shows up with no RP object in it, the PCE MUST send a PCErr message back to the requesting PCC with Error-Type="Required Object missing" and Error-value="RP Object missing" π
If the O bit of the RP message inside a PCReq is cleared, but the PCE has local policy set up to not hand out explicit paths (like for confidentiality reasons π), then a PCErr message MUST be sent by the PCE to the requesting PCC and the pending path computation request MUST be discarded. The Error-Type is "Policy Violation" and the Error-value is "O bit cleared". not me the PCE just ghosting the request like that π
When the R bit of the RP object is set in a PCReq message, it means the request is about reoptimizing an existing TE LSP π¦ In this case, the PCC MUST also provide the strict/loose path by including an RRO object in the PCReq message, so it avoids or limits double-bandwidth counting, but only if and only if the TE LSP is a non-zero-bandwidth TE LSP. If the PCC didn't ask for a strict path (O bit set), a reoptimization can still be requested, but that requires the PCE to either be stateful (keep track of the previously computed path along with its list of strict hops) or have the ability to retrieve the complete required path segment π§ Alternatively, the PCC MUST inform the PCE about the working path and the associated list of strict hops in PCReq. The absence of an RRO in the PCReq message for a non-zero-bandwidth TE LSP (when the R bit of the RP object is set) MUST trigger the sending of a PCErr message with Error-Type="Required Object Missing" and Error-value="RRO Object missing for reoptimization" π
If a PCC/PCE gets a PCRep/PCReq message with an RP object that refers to an unknown Request-ID-number, the PCC/PCE MUST send a PCErr message with Error-Type="Unknown request reference". This one is for debugging purposes π If a PCC/PCE receives PCRep/PCReq messages with unknown requests at a rate equal or greater than MAX-UNKNOWN-REQUESTS unknown requests per minute, the PCC/PCE MUST send a PCEP CLOSE message with close value="Reception of an unacceptable number of unknown requests/replies". A RECOMMENDED value for MAX-UNKNOWN-REQUESTS is 5 πΈ The PCC/PCE MUST close the TCP session and MUST NOT send any further PCEP messages on the PCEP session. Bye bye, connection π
The reception of a PCEP message that contains an RP object referring to a Request-ID-number=0x00000000 MUST be treated in similar manner as an unknown request. Same energy, different number π
7.5. NO-PATH Object
okay so the NO-PATH object shows up in PCRep messages when a path computation request didn't work out (the PCE couldn't find a path that fits the set of constraints) π₯ When a PCE can't find a path that satisfies a set of constraints, it MUST include a NO-PATH object in the PCRep message.
There are a few different kinds of issues that can lead to a negative reply β¨ For example, the PCE chain might be broken (if more than one PCE is involved in the path computation), or no path obeying the set constraints could be found. The "NI (Nature of Issue)" field in the NO-PATH object is what reports the error category π
Optionally, if the PCE supports that capability, the NO-PATH object MAY contain an optional NO-PATH-VECTOR TLV (defined below) that gives more info on why it said no π The PCRep message MAY also contain a list of objects that specify the set of constraints that could not be satisfied. The PCE MAY just replicate the set of objects that was received and caused the failed computation, or MAY optionally report a suggested value for which a path could have been found (in which case the value is different from the one in the original request). Suggesting a better option is so thoughtful π«Ά
NO-PATH Object-Class is 3.
NO-PATH Object-Type is 1.
The format of the NO-PATH object body looks like this π¦
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Nature of Issue|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 11: NO-PATH Object Format
NI - Nature of Issue (8 bits): the NI field reports what kind of issue led to the negative reply. Two values are currently defined:
- 0: No path satisfying the set of constraints could be found
- 1: PCE chain broken
The Nature of Issue field value can be used by the PCC for a few things π§
- Constraint adjustment before reissuing a new path computation request,
- Explicit selection of a new PCE chain,
- Logging of the error type for further action by the network administrator.
IANA management of the NI field codespace is described in Section 9.
Flags (16 bits). Only one flag is defined so far π
- C flag (1 bit): when set, the PCE indicates the set of unsatisfied constraints (the reasons a path couldn't be found) in the PCRep message by including the relevant PCEP objects. When cleared, no failing constraints are specified. The C flag has no meaning and is ignored unless the NI field is set to 0x00.
Unassigned bits are considered reserved. They MUST be set to zero on transmission and MUST be ignored on receipt. Keep your zeros clean, bestie π§Ή
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt.
The NO-PATH object body has a variable length and may contain additional TLVs. The only TLV currently defined is the NO-PATH-VECTOR TLV, which we'll get to in a sec π
Example time, because examples slap β¨ Say a PCC sends a path computation request to a PCE for a TE LSP of X Mbit/s. Suppose the PCE can't find a path for X Mbit/s. In this case, the PCE must include a NO-PATH object in the PCRep message. Optionally, the PCE may also include the original BANDWIDTH object to show that the reason it failed is the bandwidth constraint (here, the NI field value is 0x00 and the C flag is set). If the PCE supports that capability, it may instead include the BANDWIDTH object and report a value of Y in the bandwidth field of the BANDWIDTH object (here the C flag is set), where Y is the bandwidth for which a TE LSP with the same other characteristics (like Setup/Holding priorities, TE LSP attribute, local protection, etc.) could have been computed π
When the NO-PATH object is absent from a PCRep message, that means the path computation request was fully satisfied and the corresponding paths are provided in the PCRep message. Yay, no NO-PATH means success π
An optional TLV named NO-PATH-VECTOR MAY be included in the NO-PATH object to give more info on the reasons that led to a negative reply π₯
The NO-PATH-VECTOR TLV follows the PCEP TLV format defined in Section 7.1 and is made up of 2 bytes for the type, 2 bytes for the TLV length (the length of the value portion in bytes), followed by a fixed-length 32-bit flags field π§
Type: 1
Length: 4 bytes
Value: 32-bit flags fieldIANA manages the space of flags carried in the NO-PATH-VECTOR TLV (see Section 9).
The following flags are currently defined:
- Bit number: 31 - PCE currently unavailable
- Bit number: 30 - Unknown destination
- Bit number: 29 - Unknown source
7.6. END-POINTS Object
the END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path you want computed πΊοΈ The P flag of the END-POINTS object MUST be set. If the END-POINTS object is received with the P flag cleared, the receiving peer MUST send a PCErr message with Error-Type=10 and Error-value=1. The corresponding path computation request MUST be cancelled by the PCE without further notification. Rude π
Note that the source and destination addresses in the END-POINTS object may match the source and destination IP address of the TE LSP, or they may match those of a path segment π«Ά Two END-POINTS objects are defined: one for IPv4 and one for IPv6 πΈ
END-POINTS Object-Class is 4.
END-POINTS Object-Type is 1 for IPv4 and 2 for IPv6.
The format of the END-POINTS object body for IPv4 (Object-Type=1) is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IPv4 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 12: END-POINTS Object Body Format for IPv4
The format of the END-POINTS object for IPv6 (Object-Type=2) is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Source IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Destination IPv6 address (16 bytes) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 13: END-POINTS Object Body Format for IPv6
The END-POINTS object body has a fixed length of 8 bytes for IPv4 and 32 bytes for IPv6 π
If more than one END-POINTS object is present, the first MUST be processed and subsequent objects ignored. First one wins, bestie π
7.7. BANDWIDTH Object β¨
okay bestie, the BANDWIDTH object is how we tell the PCE how much bandwidth a TE LSP wants π the notion is basically the same vibe as RSVP signaling in [RFC2205], [RFC3209], and [RFC3473], so if you already know those, you'll feel right at home π‘
if the requested bandwidth is equal to 0, the BANDWIDTH object is optional π«Ά but if the requested bandwidth is NOT equal to 0, the PCReq message MUST contain a BANDWIDTH object. no skipping, periodt π
when you're reoptimizing a TE LSP, the bandwidth of the existing TE LSP MUST also be included alongside the requested bandwidth if and only if the two values differ π so there are two Object-Type values: one for the requested bandwidth and one for the bandwidth of the TE LSP being reoptimized. main character energy π
the BANDWIDTH object may be carried within PCReq and PCRep messages.
BANDWIDTH Object-Class is 5.
there are two Object-Type values for this object:
- Requested bandwidth: BANDWIDTH Object-Type is 1.
- Bandwidth of an existing TE LSP for which a reoptimization is requested. BANDWIDTH Object-Type is 2.
here's the body format π¦
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 14: BANDWIDTH Object Body Format
Bandwidth (32 bits): the requested bandwidth is encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second π Section 3.1.2 of [RFC3471] has a table of commonly used values if you want the cheat sheet π
the BANDWIDTH object body has a fixed length of 4 bytes.
7.8. METRIC Object π
the METRIC object is optional and can be used for several purposes. it's a whole multitasker π§
in a PCReq message, a PCC MAY insert one or more METRIC objects:
- To indicate the metric that MUST be optimized by the path computation algorithm (IGP metric, TE metric, hop counts). currently there are three metrics defined: the IGP cost, the TE metric (see [RFC3785]), and the number of hops traversed by a TE LSP.
- To indicate a bound on the path cost that MUST NOT be exceeded for the path to be considered as acceptable by the PCC. the upper limit, basically π§
in a PCRep message, the METRIC object MAY be inserted to provide the cost for the computed path. it MAY also be inserted within a PCRep with the NO-PATH object to indicate that the metric constraint could not be satisfied π
the path computation algorithmic aspects that the PCE uses to optimize a path with respect to a specific metric are outside the scope of this document. that's a whole other mood πΈ
it must be understood that these path metrics are only meaningful if they're used consistently. for example, if the delay of a computed path segment is exchanged between two PCEs in different domains, they need to use consistent ways of defining the delay π«Ά
the absence of the METRIC object MUST be interpreted by the PCE as a path computation request for which no constraints need be applied to any of the metrics.
METRIC Object-Class is 6.
METRIC Object-Type is 1.
the body format is below π
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |C|B| T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| metric-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 15: METRIC Object Body Format
the METRIC object body has a fixed length of 8 bytes.
Reserved (16 bits): this field MUST be set to zero on transmission and MUST be ignored on receipt π€
T (Type - 8 bits): specifies the metric type. three values are currently defined:
- T=1: IGP metric
- T=2: TE metric
- T=3: Hop Counts
Flags (8 bits): two flags are currently defined:
- B (Bound - 1 bit): when set in a PCReq message, the metric-value indicates a bound (a maximum) for the path metric that must not be exceeded for the PCC to consider the computed path as acceptable. the path metric must be less than or equal to the value in the metric-value field. when the B flag is cleared, the metric-value field is not used to reflect a bound constraint.
- C (Computed Metric - 1 bit): when set in a PCReq message, this indicates that the PCE MUST provide the computed path metric value (should a path satisfying the constraints be found) in the PCRep message for the corresponding metric π
unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt.
Metric-value (32 bits): metric value encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]) β¨
multiple METRIC objects MAY be inserted in a PCRep or a PCReq message for a given request (i.e., for a given RP). for a given request, there MUST be at most one instance of the METRIC object for each metric type with the same B flag value. if two or more instances of a METRIC object with the same B flag value are present for a metric type, only the first instance MUST be considered and the other instances MUST be ignored. no double-dipping π ββοΈ
for a given request, it's allowed to have two METRIC objects of the same type with different B flag values. it's also allowed to insert, for a given request, two METRIC objects with different types that both have their B flag cleared. in that case, an objective function must be used by the PCE to solve a multi-parameter optimization problem π§
a METRIC object used to indicate the metric to optimize during path computation MUST have the B flag cleared and the C flag set to the appropriate value. when the path computation relates to the reoptimization of an exiting TE LSP (in which case, the R flag of the RP object is set), an implementation MAY decide to set the metric-value field to the computed value of the metric of the TE LSP being reoptimized for a specific metric type π
a METRIC object used to reflect a bound MUST have the B flag set, and the C flag and metric-value field set to the appropriate values.
in a PCRep message, unless PCE policy doesn't allow it, at least one METRIC object MUST be present that reports the computed path metric if the C flag of the METRIC object was set in the corresponding path computation request (the B flag MUST be cleared). the C flag has no meaning in a PCRep message. optionally, the PCRep message MAY contain additional METRIC objects that correspond to bound constraints. in that case, the metric-value MUST be equal to the corresponding computed path metric (the B flag MUST be set). if no path satisfying the constraints could be found by the PCE, the METRIC objects MAY also be present in the PCRep message with the NO-PATH object to indicate the constraint metric that could be satisfied π
example time π say a PCC sends a path computation request where the metric to optimize is the IGP metric, and the TE metric must not exceed the value of M. two METRIC objects go in the PCReq message:
- First METRIC object with
B=0,T=1,C=1,metric-value=0x0000 - Second METRIC object with
B=1,T=2,metric-value=M
if the PCE finds a path that satisfies the set of constraints, and there's no policy stopping it from returning the computed metric, the PCE inserts one METRIC object with B=0, T=1, metric-value= computed IGP path cost. the PCE may also insert a second METRIC object with B=1, T=2, metric-value= computed TE path cost π
7.9. Explicit Route Object π£οΈ
the ERO is how we encode the path of a TE LSP through the network πΊοΈ it rides along in a PCRep message to deliver the computed TE LSP when path computation works out π
the contents of this object are encoded exactly like the Resource Reservation Protocol Traffic Engineering Extensions (RSVP-TE) Explicit Route Object (ERO) defined in [RFC3209], [RFC3473], and [RFC3477]. so the object is built from a series of sub-objects. any RSVP-TE ERO sub-object that's already defined, or that could be defined in the future for the RSVP-TE ERO, is acceptable in this object π¦
PCEP ERO sub-object types correspond to RSVP-TE ERO sub-object types.
since the explicit path is available for immediate signaling by the MPLS or GMPLS control plane, the meanings of all of the sub-objects and fields in this object are identical to those defined for the ERO. no new meanings, just the same ones π
ERO Object-Class is 7.
ERO Object-Type is 1.
7.10. Reported Route Object π
the RRO is exclusively carried within a PCReq message so it can report the route followed by a TE LSP that you want to reoptimize π it's giving "here's where I've been" β¨
the contents of this object are encoded exactly like the Route Record Object defined in [RFC3209], [RFC3473], and [RFC3477]. so again, it's a series of sub-objects. any RSVP-TE RRO sub-object that's already defined, or that could be defined in the future for the RSVP-TE RRO, is acceptable in this object π«Ά
the meanings of all of the sub-objects and fields in this object are identical to those defined for the RSVP-TE RRO.
PCEP RRO sub-object types correspond to RSVP-TE RRO sub-object types.
RRO Object-Class is 8.
RRO Object-Type is 1.
7.11. LSPA Object β¨
okay so the LSPA (LSP Attributes) object is optional π and it carries a bunch of TE LSP attributes the PCE should take into account during path computation π§. It can ride along in a PCReq message, or in a PCRep message when path computation fails π. In that failure case the PCRep also has a NO-PATH object, and the LSPA object shows which constraints couldn't be satisfied π. Most of its fields match the SESSION-ATTRIBUTE object (C-Type = 7) from [RFC3209] and [RFC4090] π . If it's missing from a PCReq, that means the Setup and Holding priorities are both 0 and there are no affinity constraints β¨. For the full scoop on resource affinities, see Section 4.7.4 of [RFC3209] π¦.
LSPA Object-Class is 9. πΈ
LSPA Object-Type is 1. πΈ
Here's the body format of the LSPA object π:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Exclude-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-any |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Include-all |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Setup Prio | Holding Prio | Flags |L| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 16: LSPA Object Body FormatSetup Prio (Setup Priority - 8 bits): this is how important the TE LSP is when it comes to grabbing resources, from 0 to 7 π₯. Zero is the highest priority, so it's the VIP π. Setup Priority decides whether this session is allowed to preempt another session π.
Holding Prio (Holding Priority - 8 bits): this one's about how hard the TE LSP holds onto its resources, also from 0 to 7 π«Ά. Again, zero is the highest priority π. Holding Priority decides whether this session can get preempted by another session π.
Flags (8 bits)
- L flag: this matches the "Local Protection Desired" bit ([RFC3209]) in the SESSION-ATTRIBUTE object π¦. When it's set, the computed path must include links protected with Fast Reroute, as defined in [RFC4090] β¨.
Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt π.
Reserved (8 bits): this field MUST be set to zero on transmission and MUST be ignored on receipt π.
Heads up, optional TLVs might get defined later to carry extra TE LSP attributes, like the ones in [RFC5420] π§.
7.12. Include Route Object π¦
okay the IRO (Include Route Object) is optional, and it lets you say that the computed path MUST traverse a specific set of network elements π₯. The IRO MAY be carried within PCReq and PCRep messages π. When it shows up in a PCRep with the NO-PATH object, the IRO tells you which elements made the PCE fail to find a path π.
IRO Object-Class is 10. πΈ
IRO Object-Type is 1. πΈ
Here's the body format π:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// (Sub-objects) //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 17: IRO Body FormatSub-objects: the IRO is made up of sub-objects that look exactly like the ones in [RFC3209], [RFC3473], and [RFC3477] π§©. The IRO sub-object type matches the sub-object type from whichever related document it comes from π .
These sub-object types are supported π:
Type Sub-object
1 IPv4 prefix
2 IPv6 prefix
4 Unnumbered Interface ID
32 Autonomous system numberThe L bit of such a sub-object has no meaning within an IRO π.
7.13. SVEC Object π
7.13.1. Notion of Dependent and Synchronized Path Computation Requests π§
okay so first, the vocab π. Path computation requests are independent if they aren't related to each other π¦. They're dependent if their computations can't be done independently of each other, and the classic example is computing a set of diverse paths π₯.
A set of path computation requests is non-synchronized if the PCE can handle each one in a serialized, independent way π.
Synchronization can be super useful, or even required, in a bunch of situations β¨.
Picture a PCC that needs N TE LSPs computed π§. The first option is sending N separate PCReq messages to the chosen PCE, and in that case the requests are non-synchronized πΈ. The PCC may choose to spread those N requests across K PCEs for load balancing π
. If M of them (with M<N) go to a particular PCEi, they can be sent as successive PCReq messages to PCEi, or bundled into a single PCReq message, because PCEP lets you bundle multiple path computation requests together π«Ά.
Even with independent requests, it can still be a good idea to ask the PCE to compute them in a synchronized way π₯. That can lead to more optimal computations and/or reduced blocking probability if the PCE is a stateless PCE π. So instead of doing them one by one, the PCE should compute the paths "simultaneously" π. Doing M TE LSPs at once can help the PCE meet multiple constraints at the same time π.
Let's say two TE LSPs each request N1 Mbit/s and N2 Mbit/s, and each has a max tolerable end-to-end delay of X ms β±οΈ. Computing the first TE LSP without caring about the second might make it impossible to meet the second one's delay constraint π.
Bandwidth is another example π. Doing a serialized, independent computation could make it impossible to satisfy both requests because of bandwidth fragmentation π. A synchronized computation can satisfy both π¦.
One more: synchronization can stop the same resource from getting allocated to multiple requests π. That helps cut down the call setup failure probability compared to computing independent requests one at a time π.
Dependent computations are usually synchronized π. For instance, if you compute M diverse paths without synchronizing them, you seriously raise the chance of not being able to satisfy every request (aka the well-known "trapping problem") π.
On top of that, non-synchronized computation would stop a PCE from doing objective functions like minimizing the sum of the TE LSP costs π . So in that case the path computation requests must be synchronized: they can't be computed independently of each other π₯.
Also, a set of independent path computation requests may or may not be synchronized π.
Synchronization is handled by the SVEC object, which lists the synchronized requests, and those requests can be either dependent or independent β¨.
PCEP supports these three modes π:
- Bundle of a set of independent and non-synchronized path computation requests,
- Bundle of a set of independent and synchronized path computation requests (requires the SVEC object defined below),
- Bundle of a set of dependent and synchronized path computation requests (requires the SVEC object defined below).
7.13.2. SVEC Object π§
Section 7.13.1 covers when it's helpful, or even necessary, to synchronize a set of path computation requests π. The SVEC (Synchronization VECtor) object is how a PCC asks for synchronization of a set of dependent or independent path computation requests π¦. It's optional and may be carried within a PCReq message π.
When the SVEC object rides in a PCReq message, its job is to request synchronization of M path computation requests π . It's a variable-length object that lists those M requests that must be synchronized β¨. Each request gets identified by the Request-ID-number in its own RP object π«Ά. The SVEC object also carries a set of flags that specify the type of synchronization π₯.
SVEC Object-Class is 11. πΈ
SVEC Object-Type is 1. πΈ
Here's the body format π:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags |S|N|L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Request-ID-number #1 |
// //
| Request-ID-number #M |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 18: SVEC Body Object FormatReserved (8 bits): this field MUST be set to zero on transmission and MUST be ignored on receipt π.
Flags (24 bits): these define the potential dependency between the set of path computation requests π§©.
- L (Link diverse) bit: when set, the computed paths for the requests in the following RP objects MUST NOT have any link in common π₯.
- N (Node diverse) bit: when set, the computed paths for the requests in the following RP objects MUST NOT have any node in common π.
- S (SRLG diverse) bit: when set, the computed paths for the requests in the following RP objects MUST NOT share any SRLG (Shared Risk Link Group) π.
For a set of M synchronized independent path computation requests, the bits L, N, and S are cleared π¦.
Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt β¨.
The flags defined above are not exclusive π.
7.13.3. Handling of the SVEC Object β¨
Okay so the SVEC object lets a PCC bestie bundle up a list of M path computation requests that MUST be synchronized, along with a potential dependency between them π«Ά. The whole set can ride in one PCReq message or get split across multiple PCReq messages.
If it's split up, it is RECOMMENDED for the PCE to run a local timer called the SyncTimer π§. That timer starts when the first PCReq message containing the SVEC object shows up. When it expires, if all M path computation requests haven't arrived yet, a protocol error gets triggered π.
When a PCE gets a request that can't be satisfied (for example, because the PCReq message has an object with the P bit set that isn't supported), the PCE sends a PCErr message for this request (see Section 7.2). The PCE MUST cancel the whole set of related path computation requests and MUST send a PCErr message with Error-Type="Synchronized path computation request missing" π.
Note that these PCReq messages can also hold non-synchronized path computation requests π. For example, one PCReq might carry N synchronized path computation requests tied to RP 1, ..., RP N, listed in the SVEC object, alongside any other path computation requests that get processed as normal π.
7.14. NOTIFICATION Object π
The NOTIFICATION object lives exclusively inside a PCNtf message π. A PCC can send it to a PCE, or a PCE can send it to a PCC, to notify the other side of an event.
NOTIFICATION Object-Class is 12.
NOTIFICATION Object-Type is 1.
Here's the format of the NOTIFICATION body object π:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | NT | NV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 19: NOTIFICATION Body Object Format
Reserved (8 bits): This field MUST be set to zero on transmission and MUST be ignored on receipt π.
Flags (8 bits): No flags are currently defined. Unassigned flags MUST be set to zero on transmission and MUST be ignored on receipt πΈ.
NT (Notification Type - 8 bits): The Notification-type specifies the class of notification π.
NV (Notification Value - 8 bits): The Notification-value provides additional information related to the nature of the notification β¨.
Both the Notification-type and Notification-value are managed by IANA.
These are the Notification-type and Notification-value values that are currently defined π :
Notification-type=1: Pending Request cancelledNotification-value=1: PCC cancels a set of pending requests. ANotification-type=1, Notification-value=1tells a PCE that the PCC wants to cancel a set of pending requests. This could be triggered by external conditions, like getting a positive reply from another PCE (if the PCC sent multiple requests to a set of PCEs for the same path computation request), a network event like a failure that makes the request obsolete, or any other event local to the PCC π₯. A NOTIFICATION object withNotification-type=1, Notification-value=1is carried within a PCNtf message sent by the PCC to the PCE. The RP object corresponding to the cancelled request MUST also be present in the PCNtf message. Multiple RP objects may be carried within the PCNtf message, in which case the notification applies to all of them. If a PCC receives this kind of notification from a PCE, the PCC MUST silently ignore it and no errors should be generated π« .Notification-value=2: PCE cancels a set of pending requests. ANotification-type=1, Notification-value=2tells a PCC that the PCE wants to cancel a set of pending requests. A NOTIFICATION object withNotification-type=1, Notification-value=2is carried within a PCNtf message sent by a PCE to a PCC. The RP object corresponding to the cancelled request MUST also be present in the PCNtf message. Multiple RP objects may be carried within the PCNtf message, in which case the notification applies to all of them. If a PCE receives this notification from a PCC, the PCE MUST silently ignore it and no errors should be generated π.
Notification-type=2: Overloaded PCENotification-value=1: ANotification-type=2, Notification-value=1tells the PCC that the PCE is currently in an overloaded state π. If no RP objects are included in the PCNtf message, that means no other requests SHOULD be sent to that PCE until the overloaded state is cleared. The pending requests are not affected and will be served. If some pending requests can't be served because of the overloaded state, the PCE MUST also include a set of RP objects that identifies the pending requests it is cancelling and won't honor. In that case, the PCE doesn't have to send an additional PCNtf message withNotification-type=1andNotification-value=2, since the cancelled requests are already listed by including the corresponding set of RP objects π. If a PCE receives this notification from a PCC, the PCE MUST silently ignore it and no errors should be generated.- A PCE implementation SHOULD use a dual-threshold mechanism to decide whether it's in a congestion state for specific resource monitoring (e.g. CPU, memory) π§ . The thresholds are there to avoid flip-flopping between overloaded and non-overloaded states, since that could make the PCCs keep changing their request targets.
- Optionally, a TLV named OVERLOADED-DURATION may be included in the NOTIFICATION object to specify the period of time during which no further requests should be sent to the PCE β³. Once that period has elapsed, the PCE should no longer be considered congested.
The OVERLOADED-DURATION TLV is compliant with the PCEP TLV format defined in Section 7.1. It's made of 2 bytes for the type, 2 bytes for the TLV length (the length of the value portion in bytes), followed by a fixed-length value field consisting of a 32-bit flags field π¦.
Type: 2
Length: 4 bytes
Value: 32-bit flags field indicates the estimated PCE
congestion duration in seconds.Notification-value=2: ANotification-type=2, Notification-value=2tells the PCC that the PCE is no longer overloaded and is available to process new path computation requests π. An implementation SHOULD make sure that a PCE sends this notification to every PCC that was sent a Notification message withNotification-type=2, Notification-value=1. The exception is when an OVERLOADED-DURATION TLV was included in that message and the PCE wants to wait for that period to expire before receiving new requests. If a PCE receives this notification from a PCC, the PCE MUST silently ignore it and no errors should be generated. It is RECOMMENDED to support some dampening notification procedure on the PCE so it doesn't send too many congestion state and congestion release notifications π«Ά. For example, an implementation could use a hysteresis approach with a dual-threshold mechanism that triggers the sending of congestion state notifications. Also, if the PCE's resources are very unstable, an additional dampening mechanism SHOULD be used (linear or exponential) to pace the notification frequency and avoid oscillation of path computation requests π.
When a PCC receives an overload indication from a PCE, it should consider the impact on the entire network π. Keep in mind that other PCCs may get the notification too, so a lot of path computation requests could get redirected to other PCEs. That can cause further overloading at PCEs in the network. So an application at a PCC that receives an overload notification should consider applying some form of back-off (e.g., exponential) to the rate at which it generates path computation requests into the network π. This matters even more as the number of PCEs reporting overload grows π.
7.15. PCEP-ERROR Object β¨
Okay bestie, the PCEP-ERROR object only ever travels inside a PCErr message π. Its whole job is to say "hey, something went wrong with PCEP" π¨
PCEP-ERROR Object-Class is 13.
PCEP-ERROR Object-Type is 1.
The body looks like this π
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Error-Type | Error-value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 20: PCEP-ERROR Object Body Format
So a PCEP-ERROR object reports a PCEP error. It's described by an Error-Type, which says what kind of error it is, and an Error-value, which gives extra detail about that type π. Both of them are managed by IANA (see the IANA section) π
- Reserved (8 bits): this field MUST be set to zero on transmission and MUST be ignored on receipt.
- Flags (8 bits): no flag is defined yet π. This flag MUST be set to zero on transmission and MUST be ignored on receipt.
- Error-Type (8 bits): defines the class of error.
- Error-value (8 bits): provides additional details about the error.
Optionally, the PCEP-ERROR object may contain extra TLVs to give more info about the error that happened β¨
A single PCErr message may contain multiple PCEP-ERROR objects π§
Every PCEP error comes with an Error-Type and an Error-value that are defined for it π
Here's the full error table π
Error-Type Meaning
1 PCEP session establishment failure
Error-value=1: reception of an invalid Open message or
a non Open message.
Error-value=2: no Open message received before the
expiration of the OpenWait timer
Error-value=3: unacceptable and non-negotiable session
characteristics
Error-value=4: unacceptable but negotiable session
characteristics
Error-value=5: reception of a second Open message with
still unacceptable session
characteristics
Error-value=6: reception of a PCErr message proposing
unacceptable session characteristics
Error-value=7: No Keepalive or PCErr message received
before the expiration of the KeepWait
timer
2 Capability not supported
3 Unknown Object
Error-value=1: Unrecognized object class
Error-value=2: Unrecognized object Type
4 Not supported object
Error-value=1: Not supported object class
Error-value=2: Not supported object Type
5 Policy violation
Error-value=1: C bit of the METRIC object set
(request rejected)
Error-value=2: O bit of the RP object set
(request rejected)
6 Mandatory Object missing
Error-value=1: RP object missing
Error-value=2: RRO object missing for a reoptimization
request (R bit of the RP object set)
when bandwidth is not equal to 0.
Error-value=3: END-POINTS object missing
7 Synchronized path computation request missing
8 Unknown request reference
9 Attempt to establish a second PCEP session
10 Reception of an invalid object
Error-value=1: reception of an object with P flag not
set although the P flag must be set according to this
specification.Now let's go through each error type π«Ά
Error-Type=1: PCEP session establishment failure. π€
If a malformed message shows up, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=1 π
If no Open message arrives before the OpenWait timer runs out, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=2 (see Appendix A for details) β°
If one or more PCEP session characteristics are unacceptable to the receiving peer and can't be negotiated, it MUST send a PCErr message with Error-Type=1, Error-value=3 π ββοΈ
If an Open message comes in with unacceptable session characteristics but those characteristics are negotiable, the receiving PCEP peer MUST send a PCErr message with Error-Type-1, Error-value=4 (see Section 6.2 for details) π
If a second Open message arrives during session establishment and the session characteristics are still unacceptable, the receiving PCEP peer MUST send a PCErr message with Error-Type-1, Error-value=5 (see Section 6.2 for details) π€
If a PCErr message shows up during session establishment and it contains an Open message proposing unacceptable session characteristics, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=6 π«
If neither a Keepalive message nor a PCErr message arrives before the KeepWait timer expires during session establishment, the receiving PCEP peer MUST send a PCErr message with Error-Type=1, Error-value=7 β
Error-Type=2: Capability not supported. π« The PCE says it can't honor the path computation request because it doesn't support one or more required capabilities. The corresponding path computation request MUST be cancelled.
Error-Type=3 or Error-Type=4: Unknown or not supported object. π If a PCEP message carries a PCEP object (with the P flag set) that the PCE doesn't recognize, or recognizes but doesn't support, then the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=3 and 4, respectively). The PCE MAY also include the unknown or not supported object in the PCErr message. The corresponding path computation request MUST be cancelled by the PCE without further notification π«₯
Error-Type=5: Policy violation. π If a path computation request doesn't comply with a policy that the PCC and the PCE agreed on, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=5). The corresponding path computation MUST be cancelled. Policy-specific TLVs carried in the PCEP-ERROR object may be defined in other documents to explain the nature of the policy violation π
Error-Type=6: Mandatory Object missing. 𧩠If a path computation request arrives without a mandatory object, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=6). If several mandatory objects are missing, the PCErr message MUST contain one PCEP-ERROR object per missing object. The corresponding path computation MUST be cancelled π
Error-Type=7: Synchronized path computation request missing. π If a PCC sends a synchronized path computation request to a PCE, and the PCE hasn't received all the synchronized path computation requests listed in the matching SVEC object by the time the SyncTimer defined in Section 7.13.3 expires, the PCE MUST send a PCErr message with a PCEP-ERROR object (Error-Type=7). The corresponding synchronized path computation MUST be cancelled. It is RECOMMENDED that the PCE include the REQ-MISSING TLVs (defined below) that identify the missing requests π
The REQ-MISSING TLV follows the PCEP TLV format defined in section 7.1. It's made of 2 bytes for the type, 2 bytes for the length (the length of the value portion, in bytes), and then a fixed-length value field of 4 bytes π
Type: 3
Length: 4 bytes
Value: 4 bytes that indicate the Request-ID-number that
corresponds to the missing request.Error-Type=8: Unknown request reference. π΅οΈββοΈ If a PCC receives a PCRep message related to a path computation request it doesn't know about, the PCC MUST send a PCErr message with a PCEP-ERROR object (Error-Type=8). On top of that, the PCC MUST include the unknown RP object in the PCErr message π
Error-Type=9: Attempt to establish a second PCEP session. π― If a PCEP peer notices another PCEP peer trying to set up a second PCEP session, it MUST send a PCErr message with Error-Type=9, Error-value=1. The existing PCEP session MUST be preserved, and all subsequent messages related to that tentative second session MUST be silently ignored π‘οΈ
Error-Type=10: Reception of an invalid object. π If a PCEP peer receives an object with the P flag not set, even though the P flag must be set according to this specification, it MUST send a PCErr message with Error-Type=10, Error-value=1 π©
7.16. LOAD-BALANCING Object π
Sometimes a PCE can't find a single TE LSP with a bandwidth of X, even though a set of TE LSPs whose bandwidths add up to X would work just fine π€― So it can be super useful for a PCC to ask for a set of TE LSPs whose total bandwidth is X Mbit/s, maybe with some limits on how many TE LSPs there are and how small each one can be π To ask for that, the PCC puts a LOAD-BALANCING object in a PCReq message it sends to a PCE β¨
The LOAD-BALANCING object is optional.
LOAD-BALANCING Object-Class is 14.
LOAD-BALANCING Object-Type is 1.
Here's the body layout π§
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Max-LSP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Min-Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 21: LOAD-BALANCING Object Body Format
- Reserved (16 bits): this field MUST be set to zero on transmission and MUST be ignored on receipt.
- Flags (8 bits): no flag is defined yet π. The Flags field MUST be set to zero on transmission and MUST be ignored on receipt.
- Max-LSP (8 bits): the maximum number of TE LSPs in the set π’
- Min-Bandwidth (32 bits): specifies the minimum bandwidth of each element of the set of TE LSPs π The bandwidth is encoded in 32 bits in IEEE floating point format (see [IEEE.754.1985]), expressed in bytes per second.
The LOAD-BALANCING object body is always exactly 8 bytes long π
So here's how it goes: if a PCC wants a set of TE LSPs whose bandwidths add up to X, with at most N TE LSPs, and each one has to be at least B in bandwidth, it includes a BANDWIDTH object that says X is the required bandwidth, plus a LOAD-BALANCING object with Max-LSP set to N and Min-Bandwidth set to B π«Ά
7.17. CLOSE Object πͺβ¨
okay so the CLOSE object MUST be present in every Close message, bestie π and there MUST be only one CLOSE object per Close message. if a Close message somehow shows up with more than one CLOSE object, the first one is the one that must be processed. the rest MUST be silently ignored π no drama, just vibes.
CLOSE Object-Class is 15. π
CLOSE Object-Type is 1. π
here's how the CLOSE object body is laid out π
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Flags | Reason |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 22: CLOSE Object Format π¦
- Reserved (16 bits): this field MUST be set to zero on transmission and MUST be ignored on receipt. πΈ
- Flags (8 bits): no flags are currently defined π ββοΈ. The Flag field MUST be set to zero on transmission and MUST be ignored on receipt.
- Reason (8 bits): this one says why the PCEP session is getting closed π₯Ί. Setting it is optional. IANA manages the codespace of the Reason field, and these values are currently defined:
Reasons
Value Meaning
1 No explanation provided
2 DeadTimer expired
3 Reception of a malformed PCEP message
4 Reception of an unacceptable number of unknown
requests/replies
5 Reception of an unacceptable number of unrecognized
PCEP messagesOptional TLVs can be tucked into the CLOSE object body too π§. Their specification is outside the scope of this document, so that's a different story for another day.
8. Manageability Considerations π οΈ
this section follows the guidance of [PCE-MANAGE], so go check that one out too π.
8.1. Control of Function and Policy ποΈ
a PCEP implementation SHOULD let you configure the following PCEP session parameters π:
- the local Keepalive and DeadTimer (aka the parameters the PCEP peer sends in an Open message),
- the maximum acceptable remote Keepalive and DeadTimer (aka the parameters received from a peer in an Open message),
- whether negotiation is enabled or disabled,
- if negotiation is allowed, the minimum acceptable Keepalive and DeadTimer timers received from a PCEP peer,
- the SyncTimer,
- the maximum number of sessions that can be set up,
- the request timer, which is how long a PCC waits for a reply before resending its path computation requests (potentially to an alternate PCE) β°,
- the MAX-UNKNOWN-REQUESTS,
- the MAX-UNKNOWN-MESSAGES.
these parameters can be set as defaults for any PCEP session the PCEP speaker joins π, or they can apply to one specific session with a given PCEP peer, or to a specific group of sessions with a specific group of PCEP peers. a PCEP implementation SHOULD also let you configure initiating a PCEP session with a selected subset of discovered PCEs. PCE selection is a local implementation issue, so it's up to you π . A PCEP implementation SHOULD allow configuring a specific PCEP session with a given PCEP peer, and that includes configuring the following:
- the IP address of the PCEP peer,
- the PCEP speaker role: PCC, PCE, or both,
- whether the PCEP speaker should initiate the PCEP session or wait for the peer to initiate it,
- the PCEP session parameters, as listed above, if they differ from the defaults,
- a set of PCEP policies, including the type of operations allowed for the PCEP peer (e.g., diverse path computation, synchronization, etc.).
and this part is a big one π: a PCEP implementation MUST allow restricting the set of PCEP peers that can initiate a PCEP session with the PCEP speaker (e.g., a list of authorized PCEP peers, all PCEP peers in the area, or all PCEP peers in the AS). no open doors, periodt πͺπ«.
8.2. Information and Data Models π
there's a PCEP MIB module defined in [PCEP-MIB] that describes the managed objects for modeling PCEP communication, including:
- PCEP client configuration and status,
- PCEP peer configuration and information,
- PCEP session configuration and information,
- notifications to indicate PCEP session changes.
8.3. Liveness Detection and Monitoring π
PCEP has a keepalive mechanism to check that a PCEP peer is still alive π«Ά, plus a notification procedure that lets a PCE advertise when it's overloaded to a PCC. Also, procedures for monitoring the liveliness and performance of a given PCE chain (for multiple-PCE path computation) are defined in [PCE-MONITOR] π.
8.4. Verifying Correct Operation β
you can check that PCEP is working correctly by keeping an eye on various parameters π. A PCEP implementation SHOULD provide the following:
- response time (minimum, average, and maximum), on a per-PCE-peer basis,
- PCEP session failures,
- the amount of time the session has been in active state,
- the number of corrupted messages,
- the number of failed computations,
- the number of requests for which no reply has been received after a configurable timer expired, and by verifying that at least one path exists that satisfies the set of constraints π§.
and a PCEP implementation SHOULD log error events (e.g., corrupted messages, unrecognized objects) π.
8.5. Requirements on Other Protocols and Functional Components π§©
PCEP doesn't put any new requirements on other protocols π. Since PCEP relies on the TCP transport protocol, PCEP management can use TCP management mechanisms (such as the TCP MIB defined in [RFC4022]).
the PCE Discovery mechanisms ([RFC5088], [RFC5089]) may have an impact on PCEP. So that a high frequency of PCE Discoveries/Disappearances doesn't trigger a high frequency of PCEP session setups/deletions, it is RECOMMENDED to introduce some dampening for establishment of PCEP sessions π. Calm down, PCEs π€.
8.6. Impact on Network Operation π
to avoid any unacceptable impact on network operations, an implementation SHOULD allow a limit on the number of sessions that can be set up on a PCEP speaker π§. It MAY also allow a limit on the rate of messages sent by a PCEP speaker and received from a peer, and it MAY allow sending a notification when a rate threshold is reached π.
9. IANA Considerations π
IANA assigns values to the PCEP protocol parameters (messages, objects, TLVs) ποΈ.
IANA established a new top-level registry to contain all PCEP codepoints and sub-registries β¨.
the allocation policy for each new registry is IETF Consensus: new values are assigned through the IETF consensus process (see [RFC5226]). Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists) π€.
9.1. TCP Port π
PCEP has been registered as TCP port 4189. π
9.2. PCEP Messages π
IANA created a registry for PCEP messages. Each PCEP message has a message type value.
Value Meaning Reference
1 Open This document
2 Keepalive This document
3 Path Computation Request This document
4 Path Computation Reply This document
5 Notification This document
6 Error This document
7 Close This document9.3. PCEP Object π§±
IANA created a registry for PCEP objects. Each PCEP object has an Object-Class and an Object-Type.
Object-Class Value Name Reference
1 OPEN This document
Object-Type
1
2 RP This document
Object-Type
1
3 NO-PATH This document
Object-Type
1
4 END-POINTS This document
Object-Type
1: IPv4 addresses
2: IPv6 addresses
5 BANDWIDTH This document
Object-Type
1: Requested bandwidth
2: Bandwidth of an existing TE LSP
for which a reoptimization is performed.
6 METRIC This document
Object-Type
1
7 ERO This document
Object-Type
1
8 RRO This document
Object-Type
1
9 LSPA This document
Object-Type
1
10 IRO This document
Object-Type
1
11 SVEC This document
Object-Type
1
12 NOTIFICATION This document
Object-Type
1
13 PCEP-ERROR This document
Object-Type
1
14 LOAD-BALANCING This document
Object-Type
1
15 CLOSE This document
Object-Type
19.4. PCEP Message Common Header π·οΈ
IANA created a registry to manage the Flag field of the PCEP Message Common Header. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- bit number (counting from bit 0 as the most significant bit),
- capability description,
- defining RFC.
No bits are currently defined for the PCEP message common header. π«§
9.5. Open Object Flag Field π©
IANA created a registry to manage the Flag field of the OPEN object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- bit number (counting from bit 0 as the most significant bit),
- capability description,
- defining RFC.
No bits are currently for the OPEN Object flag field. π
9.6. RP Object π
okay so new bit numbers may be allocated only by an IETF Consensus action π no shortcuts, bestie. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
Several bits are defined for the RP Object flag field in this document. The following values have been assigned:
Codespace of the Flag field (RP Object)
Bit Description Reference
26 Strict/Loose This document
27 Bi-directional This document
28 Reoptimization This document
29-31 Priority This document9.7. NO-PATH Object Flag Field π¦
IANA created a registry to manage the codespace of the NI field and the Flag field of the NO-PATH object. It's giving organized π
Value Meaning Reference
0 No path satisfying the set This document
of constraints could be found
1 PCE chain broken This documentNew bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
One bit is defined for the NO-PATH Object flag field in this document:
Codespace of the Flag field (NO-PATH Object)
Bit Description Reference
0 Unsatisfied constraint indicated This document9.8. METRIC Object πΈ
IANA created a registry to manage the codespace of the T field and the Flag field of the METRIC Object. The T field values are:
Codespace of the T field (Metric Object)
Value Meaning Reference
1 IGP metric This document
2 TE metric This document
3 Hop Counts This documentNew bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
Several bits are defined in this document. The following values have been assigned:
Codespace of the Flag field (Metric Object)
Bit Description Reference
6 Computed metric This document
7 Bound This document9.9. LSPA Object Flag Field π
IANA created a registry to manage the Flag field of the LSPA object. Main character energy for this one π
New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
One bit is defined for the LSPA Object flag field in this document:
Codespace of the Flag field (LSPA Object)
Bit Description Reference
7 Local Protection Desired This document9.10. SVEC Object Flag Field π§
IANA created a registry to manage the Flag field of the SVEC object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
Three bits are defined for the SVEC Object flag field in this document:
Codespace of the Flag field (SVEC Object)
Bit Description Reference
21 SRLG Diverse This document
22 Node Diverse This document
23 Link Diverse This document9.11. NOTIFICATION Object π₯
IANA created a registry for the Notification-type and Notification-value of the NOTIFICATION object and manages the code space. The types look like this:
Notification-type Name Reference
1 Pending Request cancelled This document
Notification-value
1: PCC cancels a set of pending requests
2: PCE cancels a set of pending requests
2 Overloaded PCE This document
Notification-value
1: PCE in congested state
2: PCE no longer in congested stateIANA also created a registry to manage the Flag field of the NOTIFICATION object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
No bits are currently for the Flag Field of the NOTIFICATION object. Empty, but make it iconic π
9.12. PCEP-ERROR Object π
IANA created a registry for the Error-Type and Error-value of the PCEP Error Object and manages the code space. For each PCEP error, an Error-Type and an Error-value are defined.
Error- Meaning Reference
Type
1 PCEP session establishment failure This document
Error-value=1: reception of an invalid Open message or
a non Open message.
Error-value=2: no Open message received before the expiration
of the OpenWait timer
Error-value=3: unacceptable and non-negotiable session
characteristics
Error-value=4: unacceptable but negotiable session
characteristics
Error-value=5: reception of a second Open message with
still unacceptable session characteristics
Error-value=6: reception of a PCErr message proposing
unacceptable session characteristics
Error-value=7: No Keepalive or PCErr message received
before the expiration of the KeepWait timer
Error-value=8: PCEP version not supported
2 Capability not supported This document
3 Unknown Object This document
Error-value=1: Unrecognized object class
Error-value=2: Unrecognized object Type
4 Not supported object This document
Error-value=1: Not supported object class
Error-value=2: Not supported object Type
5 Policy violation This document
Error-value=1: C bit of the METRIC object set
(request rejected)
Error-value=2: O bit of the RP object cleared
(request rejected)
6 Mandatory Object missing This document
Error-value=1: RP object missing
Error-value=2: RRO missing for a reoptimization
request (R bit of the RP object set)
Error-value=3: END-POINTS object missing
7 Synchronized path computation request missing This document
8 Unknown request reference This document
9 Attempt to establish a second PCEP session This document
10 Reception of an invalid object This document
Error-value=1: reception of an object with P flag
not set although the P flag must be
set according to this specification.IANA created a registry to manage the Flag field of the PCEP-ERROR object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
No bits are currently for the Flag Field of the PCEP-ERROR Object. Nothing to see here, periodt π
9.13. LOAD-BALANCING Object Flag Field π
IANA created a registry to manage the Flag field of the LOAD-BALANCING object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
No bits are currently for the Flag Field of the LOAD-BALANCING Object.
9.14. CLOSE Object π
The CLOSE object MUST be present in each Close message in order to close a PCEP session. The reason field of the CLOSE object specifies the reason for closing the PCEP session. The reason field of the CLOSE object is managed by IANA. The reasons are:
Value Meaning
1 No explanation provided
2 DeadTimer expired
3 Reception of a malformed PCEP message
4 Reception of an unacceptable number of unknown
requests/replies
5 Reception of an unacceptable number of unrecognized
PCEP messagesIANA created a registry to manage the flag field of the CLOSE object. New bit numbers may be allocated only by an IETF Consensus action. Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Capability description
- Defining RFC
No bits are currently for the Flag Field of the CLOSE Object.
9.15. PCEP TLV Type Indicators β
IANA created a registry for the PCEP TLVs. The values are:
Value Meaning Reference
1 NO-PATH-VECTOR TLV This document
2 OVERLOAD-DURATION TLV This document
3 REQ-MISSING TLV This document9.16. NO-PATH-VECTOR TLV π«Ά
IANA manages the space of flags carried in the NO-PATH-VECTOR TLV defined in this document, numbering them from 0 as the least significant bit. New bit numbers may be allocated only by an IETF Consensus action.
Each bit should be tracked with the following qualities:
- Bit number (counting from bit 0 as the most significant bit)
- Name flag
- Reference
Bit Number Name Reference
31 PCE currently unavailable This document
30 Unknown destination This document
29 Unknown source This document10. Security Considerations β¨
10.1. Vulnerability β¨
okay bestie, attacks on PCEP can seriously mess with live networks ππ₯ If someone changes the path computation responses, the PCC might get nudged into setting up sketchy LSPs π Those LSPs could wander into parts of the network that are easy to snoop on, or go right through congested or reserved links. Attackers can also go after path computation responses by modifying the PCRep message, by impersonating the PCE, or by modifying the PCReq so the PCE does a different computation than the one that was originally requested π
It's also possible to wreck a PCE's operation with a bunch of denial-of-service attacks π« These can make the PCE so congested that path computations arrive too slowly to be useful to PCCs. That could mean slower-than-acceptable recovery times or delayed LSP establishment, and in extreme cases, service requests might not get satisfied at all π©
PCEP could be the target of the following attacks:
- Spoofing (PCC or PCE impersonation)
- Snooping (message interception)
- Falsification
- Denial of Service
In inter-AS scenarios, where PCE-to-PCE communication is required, these attacks can be especially significant, with commercial as well as service-level implications πΈ
Snooping on PCEP requests and responses is also a big deal, because an attacker can learn a lot about how the network is operating π Just by viewing the PCEP messages, someone can figure out the pattern of service establishment in the network and see where traffic is being routed. That makes the network a easy target for targeted attacks, and the data inside specific LSPs becomes vulnerable too π―
The following sections identify mechanisms to protect PCEP against security attacks π‘οΈ
10.2. TCP Security Techniques β¨
At the time of writing, TCP-MD5 [RFC2385] is the only available security mechanism for securing the TCP connections that underly PCEP sessions π
As explained in [RFC2385], MD5 has some limitations and doesn't give as high a level of security as people once thought π₯² A PCEP implementation supporting TCP-MD5 SHOULD be designed so that stronger security keying techniques or algorithms that may be specified for TCP can be easily integrated in future releases π
The TCP Authentication Option [TCP-AUTH] (TCP-AO) specifies new security procedures for TCP, but it isn't finished yet π§ Since [TCP-AUTH] is expected to offer significantly improved security for applications using TCP, implementers should expect to update their implementation as soon as the TCP Authentication Option is published as an RFC β¨
Implementations MUST support TCP-MD5 and should make the security function available as a configuration option π
Operators need to watch out, because some deployed PCEP implementations may pre-date the completion of [TCP-AUTH] π It will be necessary to configure policy for secure communication between PCEP speakers that support the TCP Authentication Option and those that don't π§
An alternative approach for security over TCP transport is to use the Transport Layer Security (TLS) protocol [RFC5246] π¦ This provides protection against eavesdropping, tampering, and message forgery. BUT, TLS doesn't protect the TCP connection itself, because it doesn't authenticate the TCP header π So it's vulnerable to attacks such as TCP reset attacks (something TCP-MD5 does protect against). Using TLS would, however, require a specification of how PCEP initiates TLS handshaking and how it interprets the certificates exchanged in TLS. That specification is out of the scope of this document, but it could be the subject of future work πΈ
10.3. PCEP Authentication and Integrity β¨
Authentication and integrity checks let the receiver of a PCEP message know that the message genuinely comes from the node that claims to have sent it, and know whether the message has been modified π«Ά
The TCP-MD5 mechanism [RFC2385] from the previous section provides this, subject to the concerns listed in [RFC2385] and [RFC4278] π These issues will be addressed and resolved by [TCP-AUTH] π
10.4. PCEP Privacy β¨
Keeping PCEP communication private is of key importance π€« This is especially true in an inter-AS context, where PCEP communication end-points don't live in the same AS, because an attacker who intercepts a PCE message could get sensitive info about computed paths and resources π±
PCEP privacy can be ensured by encryption π TCP MAY be run over IPsec [RFC4303] tunnels to provide the required encryption. Note that IPsec can also ensure authentication and integrity, in which case TCP-MD5 or TCP-AO wouldn't be required. However, there's some concern that IPsec on this scale would be hard to configure and operate π₯΄ Use of IPSec with PCEP is out of the scope of this document and may be addressed in a separate document π
10.5. Key Configuration and Exchange β¨
Authentication, tamper protection, and encryption all require keys to be used by the sender and receiver π
Configuring keys per session is possible, but it can be super onerous for operators (same as for the Border Gateway Protocol (BGP), as discussed in [BGP-SEC]) π© If there's a relatively small number of PCCs and PCEs in the network, manual key configuration MAY be considered a valid choice by the operator. Still, it's important to be aware of the vulnerabilities this introduces, because configuration errors, social engineering, and carelessness could all lead to security breaches π Manually configured keys are also less likely to be regularly updated, which increases the security risk. Where there's a large number of PCCs and PCEs, the operator could find that key configuration and maintenance is a significant burden, since each PCC needs to be configured to the PCE π₯²
An alternative to individual keys is a group key π― A group key is common knowledge among all members of a trust domain. Since the routers in an IGP area or an AS are part of a common trust domain [MPLS-SEC], a PCEP group key MAY be shared among all PCCs and PCEs in an IGP area or AS. Using a group key will considerably simplify the operator's configuration task while still securing PCEP against attack from outside the network π However, the more entities that have access to a key, the greater the risk of that key becoming public π¬
With a group key, separate keys would need to be configured for the PCE-to-PCE communications that cross trust domain (e.g., AS) boundaries. The good news is the number of these relationships is likely to be very small π§
PCE discovery ([RFC5088] and [RFC5089]) is a significant feature for successfully deploying PCEP in large networks π It lets a PCC discover suitable PCEs within the network without needing configuration. It should be obvious that, where PCEs are discovered and not configured, the PCC can't know the correct key to use π€·ββοΈ There are three possible approaches to this problem that keep some aspect of security:
- The PCCs may use a group key as previously discussed.
- The PCCs may use some form of secure key exchange protocol with the PCE (such as the Internet Key Exchange protocol v2 (IKE) [RFC4306]). The drawback is that IKE implementations on routers aren't common, and this may be a barrier to deploying PCEP. Details are out of the scope of this document and may be addressed in a separate document π οΈ
- The PCCs may make use of a key server to determine the key to use when talking to the PCE. To some extent this is just moving the problem, since the PCC's communications with the key server must also be secure (for example, using Kerberos [RFC4120]). There may be some (minor) scaling benefit if the PCC is to learn about several PCEs and only needs to know one key server. Note that key servers currently have very limited implementation. Details are out of the scope of this document and may be addressed in a separate document π¦
PCEP relationships are likely to be long-lived, even if the PCEP sessions are repeatedly closed and re-established β³ Where protocol relationships persist for a large number of protocol interactions or over a long period of time, changes in the keys used by the protocol peers is RECOMMENDED [RFC4107] π Note that TCP-MD5 doesn't allow the key to be changed without closing and reopening the TCP connection, which would result in the PCEP session being terminated and needing to be restarted. That might not be a significant issue for PCEP π€ Also, the plans for the TCP Authentication Option [TCP-AUTH] will allow dynamic key change (roll-over) for an active TCP connection π
If key exchange is used (for example, through IKE), it's relatively simple to support dynamic key updates and apply them to PCEP π
Note that in-band key management for the TCP Authentication Option [TCP-AUTH] is currently unresolved π«
[RFC3562] sets out some of the issues for the key management of secure TCP connections π
10.6. Access Policy β¨
Unauthorized access to PCE function opens the door to a variety of potential attacks πͺ It can be a simple denial-of-service attack (see Section 10.7), but it's also a way for an intruder to figure out important information about the network and its operational policies, simply by inserting bogus computation requests π΅οΈββοΈ False computation requests could even be used to predict where traffic will be placed in the network when real requests are made, letting the attacker target specific network resources π―
PCEs SHOULD be configurable for access policy π Where authentication is used, access policy can be achieved through the exchange or configuration of keys, as described in Section 10.5. Simpler policies MAY be configured on PCEs in the form of access lists where the IP addresses of the legitimate PCCs are listed π Policies SHOULD also be configurable to limit the type of computation requests that are supported from different PCCs π«Ά
It is RECOMMENDED that access policy violations are logged by the PCE and are available for inspection by the operator, so they can tell whether attempts have been made to attack the PCE π΅οΈ Such mechanisms MUST be lightweight, so they can't be used to support denial-of-service attacks (see Section 10.7) πͺΆ
10.7. Protection against Denial-of-Service Attacks β¨
Denial-of-service (DoS) attacks could be mounted at the TCP level or at the PCEP level π That is, the PCE could be attacked through TCP, or through attacks within established PCEP sessions π
10.7.1. Protection against TCP DoS Attacks π‘οΈ
okay so PCEP can get hit with TCP DoS attacks, like SYN attacks, same as any other protocol that runs over TCP π other protocol specs have already dealt with this, so PCEP can borrow their experience. the Label Distribution Protocol (LDP) spec [RFC5036] is a good one to check out π to protect against TCP DoS attacks, PCEP implementations can support these techniques:
- PCEP uses a single registered port for all communications. The PCE SHOULD listen for TCP connections only on ports where communication is expected. π¦
- The PCE MAY implement an access list to immediately reject (or discard) TCP connection attempts from unauthorized PCCs. π
- The PCE SHOULD NOT allow parallel TCP connections from the same PCC on the PCEP-registered port. π
- The PCE MAY require the use of the MD5 option on all TCP connections, and MAY reject (or discard) any connection setup attempt that does not use MD5. A PCE MUST NOT accept any SYN packet for which the MD5 segment checksum is invalid. π₯ Heads up though: using MD5 means the receiver has to burn CPU computing the checksum before it can decide to throw out an otherwise fine SYN segment π
10.7.2. Request Input Shaping/Policing π§
okay this one is so real: a PCEP implementation can get hit with DoS attacks even inside a totally legit PCEP session π€ like, a PCC could send a huge pile of PCReq messages, which makes the PCE congested or leaves requests from other PCCs stuck in the queue π
the direct use of the Priority field on the RP object to prioritize requests does NOT protect you, ngl π ββοΈ the attacker could just mark every single request as the highest priority lol. so it's RECOMMENDED that PCE implementations include input shaping/policing mechanisms. These either throttle the requests received from any one PCC, or apply queuing or priority-degradation techniques to over-communicative PCCs π
such mechanisms MAY be set by default, but SHOULD be available for configuration β¨ these techniques may be considered especially important in multi-service-provider environments, to protect one service provider's resources from unwarranted, over-zealous, or malicious use by PCEs in another service provider π«Ά
11. Acknowledgments π
the authors want to thank Dave Oran, Dean Cheng, Jerry Ash, Igor Bryskin, Carol Iturrade, Siva Sivabalan, Rich Bradford, Richard Douville, Jon Parker, Martin German, and Dennis Aristow for their super valuable input πΈ they also want to thank Fabien Verhaeghe for the very fruitful discussions and useful suggestions π§ David McGrew and Brian Weis gave great input to the Security Considerations section, so iconic π
Ross Callon, Magnus Westerlund, Lars Eggert, Pasi Eronen, Tim Polk, Chris Newman, and Russ Housley gave important input during IESG review β
12. References π
12.1. Normative References
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
- [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
- [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
- [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
- [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, January 2003.
- [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May 2005.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
12.2. Informative References
- [BGP-SEC] Christian, B. and T. Tauber, "BGP Security Requirements", Work in Progress, November 2008.
- [IEEE.754.1985] IEEE Standard 754, "Standard for Binary Floating-Point Arithmetic", August 1985.
- [INTER-LAYER] Oki, E., Roux, J., Kumaki, K., Farrel, A., and T. Takeda, "PCC-PCE Communication and PCE Discovery Requirements for Inter-Layer Traffic Engineering", Work in Progress, January 2009.
- [MPLS-SEC] Fang, L. and M. Behringer, "Security Framework for MPLS and GMPLS Networks", Work in Progress, November 2008.
- [PCE-MANAGE] Farrel, A., "Inclusion of Manageability Sections in PCE Working Group Drafts", Work in Progress, January 2009.
- [PCE-MONITOR] Vasseur, J., Roux, J., and Y. Ikejiri, "A set of monitoring tools for Path Computation Element based Architecture", Work in Progress, November 2008.
- [PCEP-MIB] Stephan, E. and K. Koushik, "PCE communication protocol (PCEP) Management Information Base", Work in Progress, November 2008.
- [RBNF] Farrel, A., "Reduced Backus-Naur Form (RBNF) A Syntax Used in Various Protocol Specifications", Work in Progress, November 2008.
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
- [RFC3562] Leech, M., "Key Management Considerations for the TCP MD5 Signature Option", RFC 3562, July 2003.
- [RFC3785] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., and T. Telkamp, "Use of Interior Gateway Protocol (IGP) Metric as a second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 2004.
- [RFC4022] Raghunarayan, R., "Management Information Base for the Transmission Control Protocol (TCP)", RFC 4022, March 2005.
- [RFC4101] Rescorla, E. and IAB, "Writing Protocol Models", RFC 4101, June 2005.
- [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, June 2005.
- [RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
- [RFC4278] Bellovin, S. and A. Zinin, "Standards Maturity Variance Regarding the TCP MD5 Signature Option (RFC 2385) and the BGP-4 Specification", RFC 4278, January 2006.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
- [RFC5420] Farrel, A., Ed., Papadimitriou, D., Vasseur, JP., and A. Ayyangarps, "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC 5420, February 2009.
- [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
- [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006.
- [RFC4674] Le Roux, J., "Requirements for Path Computation Element (PCE) Discovery", RFC 4674, October 2006.
- [RFC4927] Le Roux, J., "Path Computation Element Communication Protocol (PCECP) Specific Requirements for Inter-Area MPLS and GMPLS Traffic Engineering", RFC 4927, June 2007.
- [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
- [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5088, January 2008.
- [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery", RFC 5089, January 2008.
- [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
- [RFC5376] Bitar, N., Zhang, R., and K. Kumaki, "Inter-AS Requirements for the Path Computation Element Communication Protocol (PCECP)", RFC 5376, November 2008.
- [TCP-AUTH] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", Work in Progress, November 2008.
Appendix A. PCEP Finite State Machine (FSM) π§©
this section describes the PCEP finite state machine (FSM) π¦ check out the diagram:
+-+-+-+-+-+-+<------+
+------| SessionUP |<---+ |
| +-+-+-+-+-+-+ | |
| | |
| +->+-+-+-+-+-+-+ | |
| | | KeepWait |----+ |
| +--| |<---+ |
|+-----+-+-+-+-+-+-+ | |
|| | | |
|| | | |
|| V | |
|| +->+-+-+-+-+-+-+----+ |
|| | | OpenWait |-------+
|| +--| |<------+
||+----+-+-+-+-+-+-+<---+ |
||| | | |
||| | | |
||| V | |
||| +->+-+-+-+-+-+-+ | |
||| | |TCPPending |----+ |
||| +--| | |
|||+---+-+-+-+-+-+-+<---+ |
|||| | | |
|||| | | |
|||| V | |
|||+--->+-+-+-+-+ | |
||+---->| Idle |-------+ |
|+----->| |----------+
+------>+-+-+-+-+Figure 23: PCEP Finite State Machine for the PCC π
PCEP defines the following set of variables:
Connect is the timer (in seconds) that starts after the system has initialized a TCP connection using the PCEP-registered TCP port. Its value is 60 seconds. β±οΈ
ConnectRetry counts the number of times the system has tried to set up a TCP connection with a PCEP peer without success. π
ConnectMaxRetry is the maximum number of times the system will try to establish a TCP connection using the PCEP-registered TCP port before it goes back to the Idle state. Its value is 5. π
OpenWait is the timer for how long a PCEP peer will wait to receive an Open message from the PCEP peer. When it expires, the system releases the PCEP resource and goes back to the Idle state. It has a fixed value of 60 seconds. π«Ά
KeepWait is the timer for how long a PCEP peer will wait to receive a Keepalive or a PCErr message from the PCEP peer. When it expires, the system releases the PCEP resource and goes back to the Idle state. It also has a fixed value of 60 seconds. π
OpenRetry counts the number of times the system has received an Open message with unacceptable PCEP session characteristics. π
There are also two state variables. RemoteOK is a boolean that gets set to 1 once the system has received an acceptable Open message. LocalOK is a boolean that gets set to 1 once the system has received a Keepalive message acknowledging that the Open message it sent to the peer was valid. π
Idle State π€
Idle is the starting PCEP state, where PCEP (also called "the system") waits for an initialization event. That event can be triggered manually by the user through configuration, or automatically by various events. In Idle, PCEP resources are allocated (memory, potential process, and so on), but no PCEP messages are accepted from any PCEP peer. The system listens on the PCEP-registered TCP port. π§
The following variables get initialized:
TCPRetry=0LocalOK=0RemoteOK=0OpenRetry=0
When a local initialization event happens (for example, user configuration to set up a PCEP session with a particular PCEP peer, or a local event that kicks off a PCEP session with a peer, such as automatically detecting one), the system:
- Initiates a TCP connection with the PCEP peer,
- Starts the Connect timer,
- Moves to the TCPPending state.
When a TCP connection comes in on the PCEP-registered TCP port, and the TCP connection establishment succeeds, the system:
- Sends an Open message,
- Starts the OpenWait timer,
- Moves to the OpenWait state.
If the connection establishment fails, the system stays in the Idle state. Any other event that shows up in Idle gets ignored. π
An implementation is expected to use an exponentially increasing timer between automatically generated Initialization events, and between retries of TCP connection establishment. β³
TCPPending State π
If the TCP connection establishment succeeds, the system:
- Sends an Open message,
- Starts the OpenWait timer,
- Moves to the OpenWait state.
If the TCP connection establishment fails (an error is detected while setting it up) or the Connect timer expires:
- If
ConnectRetry = ConnectMaxRetry, the system moves to the Idle State. - If
ConnectRetry < ConnectMaxRetry, the system:- Initiates a TCP connection with the PCEP peer,
- Increments the
ConnectRetryvariable, - Restarts the Connect timer,
- Stays in the TCPPending state.
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state. π
OpenWait State π¬
In the OpenWait state, the system waits for an Open message from its PCEP peer. π
If the system receives an Open message from the PCEP peer before the OpenWait timer expires, it first checks all of its sessions that are in the OpenWait or KeepWait state. If another session with the same PCEP peer already exists (same IP address), then the system runs this collision-resolution procedure:
- If the system initiated the current session and has a lower IP address than the PCEP peer, the system closes the TCP connection, releases the PCEP resources for the pending session, and moves back to the Idle state.
- If the session was initiated by the PCEP peer and the system has a higher IP address than the PCEP peer, the system closes the TCP connection, releases the PCEP resources for the pending session, and moves back to the Idle state.
- Otherwise, the system checks the PCEP session attributes (Keepalive frequency, DeadTimer, and so on).
If an error is detected (for example, a malformed Open message, receiving a message that isn't an Open message, or the presence of two OPEN objects), PCEP generates an error notification, and the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state. π¨
If no errors are detected, OpenRetry=1, and the session characteristics are unacceptable, the PCEP peer sends a PCErr with Error-Type=1 and Error-value=5. The system then releases the PCEP resources for that peer and moves back to the Idle state. π¬
If no errors are detected and the session characteristics are acceptable to the local system, the system:
- Sends a Keepalive message to the PCEP peer,
- Starts the Keepalive timer,
- Sets the
RemoteOKvariable to1.
If LocalOK=1, the system clears the OpenWait timer and moves to the UP state.
If LocalOK=0, the system clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state. π€
If no errors are detected, but the session characteristics are unacceptable and non-negotiable, the PCEP peer sends a PCErr with Error-Type=1 and Error-value=3. The system releases the PCEP resources for that peer and moves back to the Idle state. π«
If no errors are detected, OpenRetry is 0, and the session characteristics are unacceptable but negotiable (such as the Keepalive period or the DeadTimer), then the system:
- Increments the
OpenRetryvariable, - Sends a PCErr message with
Error-Type=1andError-value=4that contains proposed acceptable session characteristics, - If
LocalOK=1, restarts the OpenWait timer and stays in the OpenWait state, - If
LocalOK=0, clears the OpenWait timer, starts the KeepWait timer, and moves to the KeepWait state.
If no Open message arrives before the OpenWait timer expires, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=2. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state. β
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state. π§Ή
KeepWait State π«§
In the KeepWait state, the system waits for one of two things: a Keepalive from its PCEP peer acknowledging its Open message, or a PCErr message in response to unacceptable PCEP session characteristics proposed in the Open message. π
If an error is detected (for example, a malformed Keepalive message), PCEP generates an error notification, and the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=1. The system releases the PCEP resources for the PCEP peer, closes the TCP connection, and moves to the Idle state. π₯
If a Keepalive message is received before the KeepWait timer expires, the system sets LocalOK=1 and then:
- If
RemoteOK=1, the system clears the KeepWait timer and moves to the UP state. - If
RemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait State.
If a PCErr message is received before the KeepWait timer expires:
- If the proposed values are unacceptable, the PCEP peer sends a PCErr message with
Error-Type=1andError-value=6, and the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle state. - If the proposed values are acceptable, the system adjusts its PCEP session characteristics according to the proposed values received in the PCErr message, restarts the KeepWait timer, and sends a new Open message. If
RemoteOK=1, the system restarts the KeepWait timer and stays in the KeepWait state. IfRemoteOK=0, the system clears the KeepWait timer, starts the OpenWait timer, and moves to the OpenWait state. ποΈ
If neither a Keepalive nor a PCErr arrives after the KeepWait timer expires, the PCEP peer sends a PCErr message with Error-Type=1 and Error-value=7. The system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. π
In response to any other event, the system releases the PCEP resources for that peer and moves back to the Idle state. π
UP State π
In the UP state, the PCEP peer starts exchanging PCEP messages according to the session characteristics. This is the main event, bestie. π
If the Keepalive timer expires, the system restarts the Keepalive timer and sends a Keepalive message. π
If no PCEP message (Keepalive, PCReq, PCRep, PCNtf) arrives from the PCEP peer before the DeadTimer expires, the system terminates the PCEP session according to the procedure defined in Section 6.8, releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. Not the ghosting π
If a malformed message is received, the system terminates the PCEP session according to the procedure defined in Section 6.8, releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. ποΈ
If the system detects that the PCEP peer tries to set up a second TCP connection, it stops the TCP connection establishment and sends a PCErr with Error-Type=9. π
If the TCP connection fails, the system releases the PCEP resources for that PCEP peer, closes the TCP connection, and moves to the Idle State. π₯
Appendix B. PCEP Variables β¨
okay so PCEP has a few configurable variables, and they're basically the timers and limits that keep everything running smoothly π§
Keepalive timer: this is the minimum amount of time between sending PCEP messages (Keepalive, PCReq, PCRep, PCNtf) to a PCEP peer π a suggested value is 30 seconds β°
DeadTimer: this is the period of time that, once it runs out, a PCEP peer declares the session down if it hasn't received any PCEP message π
SyncTimer: this one is for synchronized path computation requests that use the SVEC object from Section 7.13.3 π picture a PCReq that a PCE receives, containing an SVEC object that refers to M synchronized path computation requests. if the SyncTimer expires before all M of those requests have arrived, that's a protocol error and the PCE MUST cancel the whole set π the whole point is to stop unused synchronized requests from hanging around in storage if one of them gets lost (say, a misbehaving PCC π). so the SyncTimer has to be big enough that it doesn't expire under normal circumstances β¨ a RECOMMENDED value is 60 seconds π«Ά
MAX-UNKNOWN-REQUESTS: a RECOMMENDED value is 5 πΈ
MAX-UNKNOWN-MESSAGES: a RECOMMENDED value is 5 πΈ
Appendix C. Contributors π¦
the content of this document was contributed by the people listed below, plus the editors listed at the end of the document π
Arthi Ayyangar Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 USA
EMail: arthi@juniper.net
Adrian Farrel Old Dog Consulting Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Eiji Oki NTT Midori 3-9-11 Musashino, Tokyo, 180-8585 JAPAN
EMail: oki.eiji@lab.ntt.co.jp
Alia Atlas British Telecom
EMail: akatlas@alum.mit.edu
Andrew Dolganow Alcatel 600 March Road Ottawa, ON K2K 2E6 CANADA
EMail: andrew.dolganow@alcatel.com
Yuichi Ikejiri NTT Communications Corporation 1-1-6 Uchisaiwai-cho, Chiyoda-ku Tokyo, 100-819 JAPAN
EMail: y.ikejiri@ntt.com
Kenji Kumaki KDDI Corporation Garden Air Tower Iidabashi, Chiyoda-ku, Tokyo, 102-8460 JAPAN
EMail: ke-kumaki@kddi.com
Authors' Addresses π
JP Vasseur (editor) Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
EMail: jpv@cisco.com
JL Le Roux (editor) France Telecom 2, Avenue Pierre-Marzin Lannion 22307 FRANCE
EMail: jeanlouis.leroux@orange-ftgroup.com
That's the whole thing, bestie ππ PCEP is officially wrapped! π
π¦ where this page comes from
- ietf: rfc5440 2009-03
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms