RFC 4657
Path Computation Element (PCE) Communication Protocol Generic Requirements
📚 Part 1 of 4 (title block through Section 5.1.3, more to come bestie!) 🎀
Title Block 🎀
Okay so this is RFC 4657, titled Path Computation Element (PCE) Communication Protocol Generic Requirements 💖 It's from the Network Working Group, dated September 2006, and it's Informational. The authors are J. Ash, Ed. from AT&T and J.L. Le Roux, Ed. from France Telecom. The header doesn't list anything it obsoletes or updates, so it's standing on its own 💅
Status of This Memo ✨
This memo gives information to the Internet community. It is not an Internet standard of any kind, and distribution of it is unlimited 🌸
Copyright Notice 🦋
Copyright (C) The Internet Society (2006). 🫶
Abstract 🌈
So the PCE model is described in the "PCE Architecture" document, and its whole thing is making path computation requests go from Path Computation Clients (PCCs) to Path Computation Elements (PCEs) 🧚 This document lays out the generic requirements for a communication protocol between PCCs and PCEs, and also between PCEs when it's useful for them to cooperate. Later documents will cover the application-specific requirements for the PCE communication protocol 💜
Table of Contents 🍓
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................3
3. Terminology .....................................................3
4. Overview of PCE Communication Protocol (PCECP) ..................4
5. PCE Communication Protocol Generic Requirements .................5
5.1. Basic Protocol Requirements ................................5
5.1.1. Commonality of PCC-PCE and PCE-PCE Communication ....5
5.1.2. Client-Server Communication .........................5
5.1.3. Transport ...........................................5
5.1.4. Path Computation Requests ...........................5
5.1.5. Path Computation Responses ..........................7
5.1.6. Cancellation of Pending Requests ....................7
5.1.7. Multiple Requests and Responses .....................8
5.1.8. Reliable Message Exchange ...........................8
5.1.9. Secure Message Exchange .............................9
5.1.10. Request Prioritization ............................10
5.1.11. Unsolicited Notifications .........................10
5.1.12. Asynchronous Communication ........................10
5.1.13. Communication Overhead Minimization ...............10
5.1.14. Extensibility .....................................11
5.1.15. Scalability .......................................11
5.1.16. Constraints .......................................12
5.1.17. Objective Functions Supported .....................13
5.2. Deployment Support Requirements ...........................13
5.2.1. Support for Different Service Provider
Environments .......................................13
5.2.2. Policy Support .....................................14
5.3. Aliveness Detection & Recovery Requirements ...............14
5.3.1. Aliveness Detection ................................14
5.3.2. Protocol Recovery ..................................14
5.3.3. LSP Rerouting & Reoptimization .....................14
6. Security Considerations ........................................15
7. Manageability Considerations ...................................16
8. Contributors ...................................................17
9. Acknowledgements ...............................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................191. Introduction ✨
A Path Computation Element (PCE) [RFC4655] handles requests for path computation that come from a Path Computation Client (PCC). The PCC can be 'composite' (co-located with the PCE) or 'external' (remote from it) 🎀 When the PCC is external, a request/response communication protocol is needed to carry the path computation request and bring back the response. For the PCC and PCE to talk to each other, the PCC must know where the PCE is located. PCE discovery is covered in [PCE-DISC-REQ] 🔥
The PCE works on a network graph so it can compute paths based on the path computation request(s) that PCCs send in. The request includes the source and destination of the paths to be computed, plus a set of constraints to apply during the computation, and it may also include an objective function. The PCE response carries the computed paths, or the reason the computation failed 💅
This document lists a set of generic requirements for the PCE Communication Protocol (PCECP). Application-specific requirements are out of scope here and will get their own documents. For example, application-specific communication protocol requirements for inter-area and inter-layer PCE applications are in [PCECP-INTER-AREA] and [PCECP-INTER-LAYER] respectively 🦋
2. Conventions Used in This Document 🌸
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "MAY NOT", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Those are the official key words, so read them carefully 🙈
3. Terminology 🧚
Here's the vocab, bestie:
- Domain: Any collection of network elements within a common sphere of address management or path computational responsibility. Examples include Interior Gateway Protocol (IGP) areas, Autonomous Systems (ASs), multiple ASs within a service provider network, or multiple ASs across multiple service provider networks.
- GMPLS: Generalized Multi-Protocol Label Switching
- LSP: MPLS/GMPLS Label Switched Path
- LSR: Label Switch Router
- MPLS: Multi-Protocol Label Switching
- PCC: Path Computation Client: Any client application requesting a path computation to be performed by the PCE.
- PCE: Path Computation Element: An entity (component, application or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints (see further description in [RFC4655]).
- TED: Traffic Engineering Database, which contains the topology and resource information of the network or network segment used by a PCE.
- TE LSP: Traffic Engineering (G)MPLS Label Switched Path.
For more terms, see [RFC4655] 💜
4. Overview of PCE Communication Protocol (PCECP) 🌈
In the PCE model, a PCC sends path computation requests to a PCE, which can be composite (co-located) or external (remote) ✨ If the PCC and PCE aren't co-located, a request/response communication protocol is needed to carry the request and return the response. If they are co-located, no communication protocol is required, though implementations may choose to use one for exchanges between the components 🫶
For a PCC and PCE to communicate, the PCC must know where the PCE is. That location can be configured or discovered. PCE discovery is out of scope for this document, but its requirements are written up in [PCE-DISC-REQ] 🔥
The PCE works on a network graph built from the TED so it can compute paths. How the TED gets populated is out of scope for the PCECP 🧚
A path computation request from the PCC includes a specification of the path(s) it needs. At a minimum that's the source and destination, but it may also carry further requirements (called constraints) as described in Section 5 💅
The PCE's response can be positive, in which case it includes the paths it computed. If the computation fails or can't be performed, a negative response is required, with an indication of the type of failure 💖
A request/response protocol is also needed for a PCE to send path computation requests to another PCE, and for that PCE to send back the path computation response. As described in [RFC4655], there's no reason to assume two different protocols are needed. This document assumes a single protocol will satisfy all requirements for PCC-PCE and PCE-PCE communication 🦋
[RFC4655] describes four PCE models: composite, external, multiple PCE path computation, and multiple PCE path computation with inter-PCE communication. In every case except the composite PCE model, a PCECP is required. The requirements in this document apply to all the models described in [RFC4655] 👑
5. PCE Communication Protocol Generic Requirements 🎀
5.1. Basic Protocol Requirements 🌸
5.1.1. Commonality of PCC-PCE and PCE-PCE Communication 💜
A single protocol MUST be defined for PCC-PCE and PCE-PCE communication. A PCE asking another PCE for a path can be considered a PCC, so from here on this document just calls all of those communications PCC-PCE, whether they're PCC-PCE or PCE-PCE 🫶
5.1.2. Client-Server Communication 🦋
PCC-PCE communication is client-server by nature, so it's giving classic. The PCECP MUST allow a PCC to send a request message to a PCE asking it to compute a path, and for the PCE to reply with a response message to the requesting PCC once the path has been computed ✨
Besides that request-response mode, there are cases where the PCE communicates with the PCC without being asked. That's covered in Section 5.1.11 🧚
5.1.3. Transport 🌈
The PCECP SHOULD use an existing transport protocol that supports congestion control. That transport protocol may also be used to meet some of the requirements in other sections of this document, like reliability. The PCECP SHOULD be defined for one transport protocol only, so that interoperability is ensured 🔥 The transport protocol MUST NOT limit the size of the message used by the PCECP. No size limits from the transport, periodt 💅
5.1.4. Path Computation Requests ✨
okay so the path computation request MUST include at least the source and destination 🫶 and the request is for an LSP or LSP segment, so the source and destination you give are the start and end of the computation you're asking for (aka the LSP segment) 🛤️
the request MUST support including one or more path constraints, like requested bandwidth or resources (hops, affinities, etc.) to include or exclude, but it's not limited to those 💅 like, a PCC may request the PCE exclude points of failure when computing a new path if an LSP setup fails. whether to include constraints at all is totally the PCC's choice 🎀 the core constraints that must be supported by the PCECP are listed in Section 5.1.16. and specifying constraints MUST be future-proofed as described in Section 5.1.14 🔮
the requester MUST be allowed to select from or prefer an advertised list or minimal subset of standard objective functions and functional options. an objective function is what the PCE uses to process constraints when it computes a path, so it can pick the "best" candidate paths (e.g., minimum hop path) 🏆 it's the optimization criteria used for computing one path, or for computing a set of paths together. for unsynchronized computation that could be the path cost or the residual bandwidth on the most loaded path link. for synchronized computation it could be the global bandwidth consumption or the residual bandwidth on the most loaded network link 📊
the core objective functions that MUST be supported by the PCECP are in Section 5.1.17, and specifying them MUST be future-proofed as described in Section 5.1.14 🌈
the requester SHOULD also be able to select a vendor-specific or experimental objective function or functional option 🧪 and the requester MUST be allowed to customize the functions and options in use, because individual objective functions often have parameters that get set in the request from PCC to PCE 🎛️ support for specifying objective functions and objective parameters is required in the protocol extensibility from Section 5.1.14. the rules are giving "built to grow" 🌱
a request message MAY include TE parameters carried by the MPLS/GMPLS LSP setup signaling protocol 📮 and it MUST be possible for the PCE to apply additional objective functions. that might include policy-based routing path computation for load balancing, instructed by the management plane 🧠
shortest path selection may rely on either the TE metric or the IGP metric [METRIC]. so the PCECP request message MUST let the PCC indicate which metric type (IGP or TE) to use for shortest path selection 📏 other metric types may be specified in the future, bestie 🔜
okay now the spicy one: sometimes a single path can't fit a bandwidth request, but a set of paths combined can. that combining is called load-balancing ⚖️ the request message MUST allow the PCC to indicate whether load-balancing is allowed. it MUST also include the maximum number of paths in a load-balancing path group, and the minimum path bandwidth in a load-balancing path group. and it MUST allow specifying the degree of disjointness of the members of the load-balancing group 🧩 the main character of this section, no cap 👑
5.1.5. Path Computation Responses ✨
the path computation response message MUST let the PCE return various elements, including at least the computed path(s) 📬
the protocol MUST be able to return any explicit path that would be acceptable for MPLS and GMPLS LSPs once it's converted to an Explicit Route Object for RSVP-TE signaling 🛣️ and anything that can be expressed in an Explicit Route Object MUST be able to come back in the computed path. the resulting path(s) may be made of strict or loose hops, or any mix of the two. a hop can also be a non-simple abstract node 🌀 see [RFC3209] for the definitions of strict hop, loose hop, and abstract node 📖
a positive response from the PCE MUST include the paths that were computed ✅ and a positive PCECP computation response MUST support including attributes of the computed path, like the path costs (cumulative link TE metrics and cumulative link IGP metrics) and the computed bandwidth 💸 the bandwidth one is super useful when a single path can't serve the requested bandwidth and load balancing is applied 🫧
if a path satisfying the constraints can't be found, or the computation fails or can't be performed, a negative response MUST be sent 🙅♀️ it MAY include more details about the reason(s) for the failure, and it MAY include advice about which constraints might be relaxed to make a positive result more likely 🥺
the PCECP response message MUST support including the set of computed paths of a load-balancing path group, along with their respective bandwidths 🧃
5.1.6. Cancellation of Pending Requests ✨
a PCC MUST be able to cancel a pending request using an appropriate message 🛑 like, if a PCC sent a request and no longer needs the response (say it doesn't want to set up the service anymore), it MUST be able to tell the PCE it can clear the request. that means stop the computation if it already started, and clear the context 🧹 the PCE may also want to cancel a pending request because of some congested state 🚦
5.1.7. Multiple Requests and Responses ✨
it MUST be possible to send multiple path computation requests inside the same request message 📦 those requests can be correlated (e.g., asking for disjoint paths) or uncorrelated (asking for paths for unrelated services). and it MUST be possible to limit, by configuration on both PCCs and PCEs, how many requests can fit in a single message 🔢
same energy for responses: it MUST be possible to return multiple computed paths inside the same response message. those could match the same request (e.g., multiple suited paths, or paths of a load-balancing path group), or distinct requests, correlated or not, from the same request message or from different request messages 💫
it MUST be possible to provide "continuation correlation," where all the related requests or computed paths don't fit in one message and get carried in a sequence of correlated messages 🧵
the PCE MUST inform the PCC of its capabilities. the maximum acceptable message sizes and the maximum number of requests per message that a PCE supports MAY be part of the PCE capabilities advertisement [PCE-DISC-REQ], or MAY be exchanged through information messages from the PCE as part of the protocol described here 📣
it MUST be possible for a PCC to specify, in the request message, the maximum acceptable response message sizes and the maximum number of computed paths per response message it can support 🙌 and it MUST be possible to limit message size by configuration on PCCs and PCEs 📏
5.1.8. Reliable Message Exchange ✨
the PCECP MUST support reliable transmission of PCECP packets 💌 this may form part of the protocol itself, or it may be achieved by picking a suitable transport protocol (see Section 5.1.3) 🚚
in particular, it MUST allow detection and recovery of lost messages to happen quickly, without holding up the operation of the PCECP ⚡
in some cases (e.g., after a link failure), a huge number of PCCs might all send requests to a PCE at the same time, which can lead to the PCEs getting saturated 😵💫 so the PCECP MUST support indicating congestion state and rate limitation state. this should enable things like a PCE limiting the rate of incoming request messages when the request rate is too high 🛑
the PCECP or its transport protocol MUST provide the following 📋
- Detection and report of lost or corrupted messages
- Automatic attempts to retransmit lost messages without reference to the application
- Handling of out-of-order messages
- Handling of duplicate messages
- Flow control and back-pressure to enable throttling of requests and responses
- Rapid PCECP communication failure detection
- Distinction between partner failure and communication channel failure after the PCECP communication is recovered
if it's necessary to add functions to PCECP to get around shortcomings in the chosen transport mechanisms, those functions SHOULD be based on, and re-use where possible, techniques developed in other protocols to overcome the same shortcomings 🔁 but functionality MUST NOT be added to the PCECP where the chosen transport protocol already provides it. don't do double work, periodt 💅
5.1.9. Secure Message Exchange ✨
the PCC-PCE communication protocol MUST include provisions to keep the exchanges between the entities secure 🔐 specifically, it MUST support mechanisms to prevent spoofing (e.g., authentication), snooping (e.g., keeping information confidential with techniques like encryption), and Denial of Service (DoS) attacks (e.g., packet filtering, rate limiting, no promiscuous listening) 🛡️ once a PCC is identified and authenticated, it has the same privileges as all the other PCCs 🫶
to ensure confidentiality, the PCECP SHOULD let local policy on the PCE be configured so it doesn't provide explicit path(s) 🙈 if a PCC requests an explicit path when that isn't allowed, the PCE MUST return an error message to the requesting PCC, and the pending path computation request MUST be discarded ❌
authorization requirements [RFC3127] include reject capability, reauthorization on demand, support for access rules and filters, and unsolicited disconnect 🚪
IP addresses are used to identify PCCs and PCEs 🪪 where the PCC-PCE communication takes place entirely within one limited domain, a private address space that isn't available to customer systems MAY be used to help protect the information exchange, but other mechanisms MUST also be available too 🏰
these functions may be provided by the transport protocol or directly by the PCECP. see Section 6 for further discussion of security considerations 🔍
5.1.10. Request Prioritization ✨
the PCECP MUST let a PCC specify the priority of a computation request 🚨
priority-based activity inside a PCE is subject to implementation and local policy 🧑💻 and that application processing is out of scope of the PCECP. not our problem, bestie 🙅♀️
5.1.11. Unsolicited Notifications ✨
the normal operational mode is for the PCC to make path computation requests and for the PCE to respond 🔄 that's the classic vibe 💖
but the PCECP MUST support unsolicited notifications from PCE to PCC, or from PCC to PCE 📢 this is what makes it possible to share info and alerts between PCCs and PCEs unprompted 🚨 as specified in Section 5.1.8, these notification messages must be supported by a reliable transmission protocol 🫧 and the PCECP MAY also support response messages to the unsolicited notification messages 🌸
5.1.12. Asynchronous Communication 🦋
Okay so the PCC-PCE protocol MUST allow for asynchronous communication, bestie. 🫶 A PCC MUST NOT have to sit around waiting for a response before it can send the next request. Main character energy means you keep going! ✨
It MUST also be possible for responses to come back in a different order than the requests went out. 🔀 This can happen when path request messages have different priorities (see Requirement 5.1.10). So, as a consequence, path computation responses MUST include a direct correlation to the associated request. That way nobody gets mixed up about who asked for what 💅
5.1.13. Communication Overhead Minimization 🌸
Real talk, the request and response messages SHOULD be designed so the communication overhead is minimized. 🧚 Specifically, the overhead per message SHOULD be minimized, and the number of bytes exchanged to arrive at a computation answer SHOULD be minimized too. No bloat, please! 🙈
Other things to think about when trimming overhead include:
- the number of background messages used by the protocol or its transport protocol to keep alive any session or association between the PCE and PCC
- the processing cost at the PCE (or PCC) associated with request/response messages (as distinct from processing the computation requests themselves)
5.1.14. Extensibility 🌈
Lowkey the most iconic part. ✨ The PCECP MUST provide a way to introduce new path computation constraints, diversity types, objective functions, optimization methods and parameters, and so on, without needing major modifications to the protocol. Future-proof era! 👑
For example, the PCECP MUST be extensible enough to support various PCE-based applications, such as:
- intra-area path computation
- inter-area path computation [PCECP-INTER-AREA]
- inter-AS intra provider and inter-AS inter-provider path computation [PCECP-INTER-AS]
- inter-layer path computation [PCECP-INTER-LAYER]
The PCECP MUST support the requirements specified in the application-specific requirements documents. 📋 It MUST also allow extensions as more PCE applications get introduced in the future. The PCECP SHOULD also be extensible to support future applications that aren't currently in the scope of the PCE working group, like point-to-multipoint path computations, multi-hop pseudowire path computation, etc. 🦋
Note that application specific requirements are out of the scope of this document and will be addressed in separate requirements documents. 🎀
5.1.15. Scalability 📈
The PCECP MUST scale well, at least as well as linearly, as any of the following parameters goes up. Minimum order-of-magnitude estimates of what the PCECP should support are given in parentheses. (Note: these are requirements on the PCECP, not on the PCE. 🙈)
- number of PCCs (1000/domain)
- number of PCEs (100/domain)
- number of PCCs communicating with a single PCE (1000)
- number of PCEs communicated to by a single PCC (100)
- number of domains (20)
- number of path request messages (average of 10/second/PCE)
- handling bursts of requests (burst of 100/second/PCE within a 10-second interval)
Path requests can be bundled in path request messages. For example, 10 PCECP request messages/second may correspond to 100 path requests/second. 🍓
Bursts of requests may show up after a network outage, when multiple recomputations get requested. 😭 The PCECP MUST handle that congestion gracefully so it doesn't unduly impact the rest of the network, and so it doesn't gate the ability of the PCE to perform computation. Protect the vibes! 💜
5.1.16. Constraints 💖
This section gives a list of generic constraints that MUST be supported by the PCECP. Other constraints may be added to service-specific applications as identified by separate application-specific requirements documents. Also, the provisions of Section 5.1.14 mean new constraints can be added to this list without impacting the protocol enough to need major protocol changes. ✨
The set of supported generic constraints MUST include at least the following:
- MPLS-TE and GMPLS generic constraints:
- Bandwidth
- Affinities inclusion/exclusion
- Link, Node, Shared Risk Link Group (SRLG) inclusion/exclusion
- Maximum end-to-end IGP metric
- Maximum hop count
- Maximum end-to-end TE metric
- Degree of paths disjointness (Link, Node, SRLG)
- MPLS-TE specific constraints
- Class-type
- Local protection
- Node protection
- Bandwidth protection
- GMPLS specific constraints
- Switching type, encoding type
- Link protection type
5.1.17. Objective Functions Supported 🎯
This section gives a list of generic objective functions that MUST be supported by the PCECP. Other objective functions MAY be added to service-specific applications as identified by separate application-specific requirements documents. Also, the provisions of Section 5.1.14 mean new objective functions MAY be added to this list without impacting the protocol. 🦋
The PCECP MUST support at least the following "unsynchronized" functions:
- Minimum cost path with respect to a specified metric (shortest path)
- Least loaded path
- Maximum available bandwidth path
Also, the PCECP MUST support at least the following "synchronized" objective functions:
- Minimize aggregate bandwidth consumption on all links
- Maximize the residual bandwidth on the most loaded link
- Minimize the cumulative cost of a set of diverse paths
5.2. Deployment Support Requirements 🚀
5.2.1. Support for Different Service Provider Environments 🌍
The PCECP must at least support the following environments:
- MPLS-TE and GMPLS networks
- Packet and non-packet networks
- Centralized and distributed PCE path computation
- Single and multiple PCE path computation
For example, PCECP is possibly applicable to packet networks (e.g., IP networks), non-packet networks (e.g., time-division multiplexed (TDM) transport), and perhaps to multi-layer GMPLS control plane environments. 🧠 Definitions of centralized, distributed, single, and multiple PCE path computation can be found in [RFC4655]. 📖
5.2.2. Policy Support 🛡️
The PCECP MUST allow for the use of policies to accept or reject requests. It MUST include the ability for a PCE to supply enough detail when it rejects a request for policy reasons, so the PCC can figure out why the request was rejected or failed. 🕵️♀️ For example, filtering could be needed for a PCE that serves one domain (perhaps an AS), so that every request coming from another domain (AS) gets rejected. Specific policy details are left to application-specific PCECP requirements, though. Actual policies, how they're configured, and where they apply are out of scope. 🙅♀️
Note that work on supported policy models and the corresponding requirements and implications is being undertaken as a separate work item in the PCE working group. 🔧
PCECP messages MUST be able to carry transparent policy information. 🎀
5.3. Aliveness Detection & Recovery Requirements 💓
5.3.1. Aliveness Detection 💗
The PCECP MUST allow a PCC/PCE to:
- check the liveliness of the PCC-PCE communication,
- rapidly detect PCC-PCE communication failure (regardless of whether the partner failed or the connectivity did), and
- distinguish PCC/PCE node failures from PCC-PCE connectivity failures, after the PCC-PCE communication is recovered.
The aliveness detection mechanism MUST ensure reciprocal knowledge of PCE and PCC liveness. 🫶
5.3.2. Protocol Recovery 🔄
If a sender or the communication channel fails, the PCECP, upon recovery, MUST support resynchronization of information (e.g., PCE congestion status) and requests between the sender and the receiver. This SHOULD be arranged so as to minimize repeat data transfer. ♻️
5.3.3. LSP Rerouting & Reoptimization 🛤️
If an LSP fails because of the failure of a link or node that it traverses, a new computation request may be made to a PCE in order to repair the LSP. Since the PCC can't know whether the PCE's TED has been updated to reflect the failed network information, it's useful to include that information in the new path computation request. 🧩
Also, to re-use the resources the old LSP used, it may be advantageous to indicate the route of the old LSP as part of the new path computation request. ♻️
So the path computation request message MUST allow an indication of whether the computation is for LSP restoration. It MUST support the inclusion of the previously computed path, as well as the identity of the failed element. Note that the old path might only be useful if the old LSP hasn't been torn down yet. The PCE MAY choose to take failure indication information carried in a given request into account when handling subsequent requests. This should be driven by local policy decisions. 🧐
Note that a network failure may impact a large number of LSPs. In this case, a potentially large number of PCCs will send requests to the PCE at the same time. The PCECP MUST properly handle such overload situations, for instance by throttling requests as set forth in Section 5.1.8. 🚦
The path computation request message MUST support TE LSP path reoptimization and the inclusion of a previously computed path. This helps ensure optimal routing of a reoptimized path, since it lets the PCE avoid double bandwidth accounting and helps reduce blocking issues. 👑🌟
6. Security Considerations 🔒✨
okay, security is the part where we get dramatic 💀 and honestly it's giving main character energy. Key management MUST be provided by the PCECP so messages are authentic and their integrity holds up. That's how we stop PCE or PCC impersonation and message content falsification. no cap, this is the foundation for everything else.
The impact of using a PCECP MUST be considered against what it does to the security of the routing and signaling protocols and techniques already running on the network. Intra-domain security takes a hit because there's a brand-new interface, protocol, and element in the network. Any host could impersonate a PCC and read detailed info about network paths 🙈. Any host could also impersonate a PCE, quietly collecting info about the network before forwarding the request to a real PCE, and then spoof responses. Some of that protection depends on how PCE discovery is secured (see [PCE-DISC-REQ]). More inter-domain information flow can make things more vulnerable to attacks, and making inter-domain paths easier to set up can make those attacks hit harder.
The confidentiality implications for a PCECP in multi-domain networks are a whole vibe 🫣. A multi-domain PCE solution won't necessarily compromise security, but solutions MUST examine their impacts in this area, bestie.
Applicability statements for particular combinations of signaling, routing, and path computation techniques are expected to contain detailed security sections 📝.
Using an external PCE brings extra security issues into the chat. The biggest ones are:
- Interception of PCE requests or responses
- Impersonation of PCE or PCC
- DoS attacks on PCEs or PCCs
The PCECP MUST address these issues in detail using authentication, encryption, and DoS protection techniques 🛡️. See also Section 5.1.9.
Arbitrary objective functions come with their own security implications, as covered in Section 5.1.17 😬. The PCECP MUST allow mitigating the risk of, for example, a PCC using complex objectives to intentionally drive a PCE into resource exhaustion. That is a real threat and it's not giving safe if we ignore it 🚨.
7. Manageability Considerations 🎀
Manageability of the PCECP MUST address the following considerations:
- The need for a MIB module for control and monitoring of PCECP
- The need for built-in diagnostic tools to test the operation of the protocol (e.g., partner failure detection, Operations Administration and Maintenance (OAM), etc.)
- Configuration implications for the protocol
PCECP operations MUST be modeled and controlled through appropriate MIB modules 📊. PCCs and PCEs are different enough that they need separate MIB modules, so we're not mixing those up 🙅♀️. Statistics gathering is a huge part of how the PCECP runs. The MIB modules MUST provide information that lets an operator figure out PCECP historical interactions and the success rate of requests. It's also important for an operator to see PCECP and PCE load and whether one PCC is hogging a disproportionate amount of it 👀. Through MIB modules it MUST be possible to record and inspect statistics about PCECP communications, including malformed messages, unauthorized messages, and messages discarded owing to congestion. Literally so much to track, iykyk 💅.
The new MIB modules should also be used to send notifications (traps) when thresholds are crossed or when important events happen 🔔. For example, the MIB module may support indication of exceeding the congestion state threshold or rate limitation state.
PCECP techniques must enable a PCC to determine the liveness of a PCE both before it sends a request and during the wait between sending a request and getting a response 💓.
It's also important for a PCE to know about the liveness of PCCs. That gives it a predictive view of how loaded it's likely to get in the future, and it lets a PCE abandon processing of a request it has already received 🧠.
The PCECP MUST support indication of congestion state and rate limitation state, and MAY allow the operator to control such a function 🎛️.
8. Contributors 🧚
This document came out of the PCE Working Group PCECP requirements design team's joint effort 🫶. Besides the authors and editors listed in the "Authors' Addresses" section, these design team members also contributed:
Alia K. Atlas
Google Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043 USA
EMail: akatlas@alum.mit.edu
Arthi Ayyangar
Nuova Systems,
2600 San Tomas Expressway
Santa Clara, CA 95051
EMail: arthi@nuovasystems.com
Nabil Bitar
Verizon
40 Sylvan Road
Waltham, MA 02145 USA
EMail: nabil.bitar@verizon.com
Igor Bryskin
Independent Consultant
EMail: i_bryskin@yahoo.com
Dean Cheng
Cisco Systems, Inc.
3700 Cisco Way
San Jose CA 95134 USA
Phone: 408 527 0677
EMail: dcheng@cisco.com
Durga Gangisetti
MCI
EMail: durga.gangisetti@mci.com
Kenji Kumaki
KDDI Corporation
Garden Air Tower
Iidabashi, Chiyoda-ku,
Tokyo 102-8460, JAPAN
Phone: 3-6678-3103
EMail: ke-kumaki@kddi.com
Eiji Oki
NTT
Midori-cho 3-9-11
Musashino-shi, Tokyo 180-8585, JAPAN
EMail: oki.eiji@lab.ntt.co.jp
Raymond Zhang
BT INFONET Services Corporation
2160 E. Grand Ave.
El Segundo, CA 90245 USA
EMail: Raymond_zhang@bt.infonet.com9. Acknowledgements 💖
The authors want to give a massive thank-you, in alphabetical order, to Lou Berger, Ross Callon, Adrian Farrel, Thomas Morin, Dimitri Papadimitriou, Robert Sparks, and J.P. Vasseur 🙏✨. They reviewed the work and gave suggestions, and we love them for it 🌸.
10. References 📚
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
March 1997.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture",
RFC 4655, August 2006.10.2. Informative References
[METRIC] 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.
[PCE-DISC-REQ] Le Roux, J.L., et al., "Requirements for Path
Computation Element (PCE) Discovery", Work in
Progress.
[PCECP-INTER-AREA] Le Roux, J.L., et al., "PCE Communication
Protocol (PCECP) specific requirements for
Inter-Area (G)MPLS Traffic Engineering", Work in
Progress.
[PCECP-INTER-LAYER] Oki, E., et al., "PCC-PCE Communication
Requirements for Inter-Layer Traffic
Engineering", Work in Progress.
[PCECP-INTER-AS] Bitar, N., Zhang, R., Kumaki, K., "Inter-AS
Requirements for the Path Computation Element
Communication Protocol (PCECP)", Work in
Progress.
[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.
[RFC3127] Mitton, D., St.Johns, M., Barkley, S., Nelson,
D., Patil, B., Stevens, M., and B. Wolff,
"Authentication, Authorization, and Accounting:
Protocol Evaluation", RFC 3127, June 2001.Authors' Addresses 🦋
Jerry Ash (Editor)
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: (732)-420-4578
EMail: gash@att.com
Jean-Louis Le Roux (Editor)
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, FRANCE
EMail: jeanlouis.leroux@orange-ft.comFull Copyright Statement ©
Copyright (C) The Internet Society (2006) 🌈.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Legal stuff, but it matters 🧾.
The fine print on the warranty goes like this, and I'm keeping it word for word 🙏:
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 💜
The IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to implementing or using the technology in this document, or on whether any license under those rights might be available. It doesn't claim to have independently looked for any such rights either 🕵️♀️. Info about rights in RFC documents lives in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of attempts to get a general license or permission to use such proprietary rights for implementers or users of this specification can all be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone to flag any copyrights, patents or patent applications, or other proprietary rights that might cover technology required to implement this standard. Send that to the IETF at ietf-ipr@ietf.org 📬.
Acknowledgement 🎉
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💅🫶
📦 where this page comes from
- ietf: rfc4657 2006-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms