RFC 5520
Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism
RFC 5520 Title Block 🎀
Okay bestie, here's the deets on this one 💅
- Title: Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism ✨
- Series: Network Working Group, Request for Comments 5520 🦋
- Authors: R. Bradford, Ed., JP. Vasseur (Cisco Systems, Inc.), and A. Farrel (Old Dog Consulting) 👑
- Category: Standards Track 🔥
- Date: April 2009 🌸
- Obsoletes/Updates: The header doesn't list anything this one obsoletes or updates 🙈
Status of This Memo ✨
This doc specifies an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶. For the standardization state and status of this protocol, go check the current edition of the "Internet Official Protocol Standards" (STD 1). 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, because they describe your rights and restrictions with respect to this document 🌈.
Abstract 🦋
Okay so, Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) may be computed by Path Computation Elements (PCEs). When the TE LSP crosses multiple domains, like Autonomous Systems (ASes), the path may be computed by multiple PCEs that cooperate, and each one is responsible for computing a segment of the path. 🧚 But here's the drama: in some cases (e.g., when ASes are administered by separate Service Providers), it would break confidentiality rules for a PCE to hand a path segment over to a PCE in another domain. That would disclose AS-internal topology information 😭. You can work around this by returning a loose hop and invoking a new path computation from the domain boundary Label Switching Router (LSR) during TE LSP setup, as the signaling message enters the second domain. The catch is that this technique has several issues, including the problem of maintaining path diversity 💀.
This document defines a mechanism to hide the contents of a segment of a path, called the Confidential Path Segment (CPS). ✨ The CPS may be replaced by a path-key that can be conveyed in the PCE Communication Protocol (PCEP) and signaled inside a Resource Reservation Protocol TE (RSVP-TE) explicit route object 🎀.
Table of contents 🌸
1. Introduction ....................................................3
1.1. Terminology ................................................4
2. Path-Key Solution ...............................................5
2.1. Mode of Operation ..........................................5
2.2. Example ....................................................6
3. PCEP Protocol Extensions ........................................7
3.1. Path-Keys in PCRep Messages ................................7
3.1.1. PKS with 32-Bit PCE ID ..............................8
3.1.2. PKS with 128-Bit PCE ID .............................9
3.2. Unlocking Path-Keys .......................................10
3.2.1. Path-Key Bit .......................................10
3.2.2. PATH-KEY Object ....................................10
3.2.3. Path Computation Request (PCReq) Message
with Path-Key ......................................11
4. PCEP Mode of Operation for Path-Key Expansion ..................12
5. Security Considerations ........................................12
6. Manageability Considerations ...................................13
6.1. Control of Function through Configuration and Policy ......13
6.2. Information and Data Models ...............................14
6.3. Liveness Detection and Monitoring .........................15
6.4. Verifying Correct Operation ...............................15
6.5. Requirements on Other Protocols and Functional
Components ................................................15
6.6. Impact on Network Operation ...............................16
7. IANA Considerations ............................................16
7.1. New Subobjects for the ERO Object .........................16
7.2. New PCEP Object ...........................................17
7.3. New RP Object Bit Flag ....................................17
7.4. New NO-PATH-VECTOR TLV Bit Flag ...........................17
8. References .....................................................17
8.1. Normative References ......................................17
8.2. Informative References ....................................18
Acknowledgements ..................................................191. Introduction ✨
Path computation techniques using the Path Computation Element (PCE) are described in [RFC4655]. They allow for path computation of inter-domain Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) and Generalized MPLS (GMPLS) Label Switched Paths (LSPs) 🦋.
An important element of inter-domain TE is that TE information is not shared between domains, for scalability and confidentiality reasons ([RFC4105] and [RFC4216]). So, bestie, a single PCE is unlikely to be able to compute a full inter-domain path 🙈.
There are two path computation scenarios for inter-domain TE LSPs. The first uses per-domain path computation, defined in [RFC5152]. The second uses a PCE-based path computation technique with cooperation between PCEs, as described in [RFC4655]. In this second case, paths for inter-domain LSPs can be computed through cooperation between PCEs, and each one computes a segment of the path across one domain. That procedure is described in [RFC5441] 💅.
If confidentiality is required between domains (like it very likely would be between Autonomous Systems (ASes) belonging to different Service Providers), then cooperating PCEs cannot exchange path segments. If they did, the receiving PCE and the Path Computation Client (PCC) would be able to see the individual hops through another domain, and that breaks the confidentiality requirement stated in [RFC4105] and [RFC4216] 😭. We define the part of the path that we wish to keep confidential as the Confidential Path Segment (CPS) 🔐.
One mechanism for preserving the confidentiality of the CPS is for the PCE to return a path containing a loose hop in place of the segment that must be kept confidential. The concept of loose and strict hops for the route of a TE LSP is described in [RFC3209]. The Path Computation Element Communication Protocol (PCEP) defined in [RFC5440] supports the use of paths with loose hops. It's a local policy decision at a PCE whether it returns a full explicit path with strict hops or uses loose hops 👑. Also, a path computation request may request an explicit path with strict hops, or it may allow loose hops as detailed in [RFC5440] 🌈.
Returning a loose hop in place of the CPS can be achieved without further extensions to PCEP or the signaling protocol 🧚. If loose hops are used, the TE LSPs are signaled as normal ([RFC3209]). When a loose hop is encountered in the explicit route, it gets resolved by performing a secondary path computation to reach the resource or set of resources identified by the loose hop. Given the nature of the cooperation between PCEs in computing the original path, this secondary computation occurs at or on behalf of a Label Switching Router (LSR) at a domain boundary (i.e., an Area Border Router (ABR) or an AS Border Router (ASBR)). Then the path is expanded as described in [RFC5152] ✨.
The PCE-based computation model is especially useful for determining mutually disjoint inter-domain paths, like the ones that might be needed for service protection [RFC5298]. A single path computation request is used. However, if loose hops are returned, the path of each TE LSP must be recomputed at the domain boundaries as the TE LSPs are signaled. Since the TE LSP signaling proceeds independently for each TE LSP, disjoint paths cannot be guaranteed, because the LSRs in charge of expanding the explicit route objects (EROs) are not synchronized 💀. So, if the loose hop technique is used without further extensions, path segment confidentiality and path diversity are mutually incompatible requirements 😤.
This document defines the notion of a Path-Key, which is a token that replaces a path segment in an explicit route 🎀. The Path-Key is encoded as a Path-Key Subobject (PKS) returned in the PCEP Path Computation Reply message (PCRep) ([RFC5440]). Once the computed path is received, the PKS is carried in an RSVP-TE Path message (RSVP-TE [RFC3209] and [RSVP-PKS]) during signaling 🦋.
The BNF in this document follows the format described in [RBNF] 🍓.
Please note that the term "path-key" used in this document refers to an identifier allocated by a PCE to represent a segment of a computed path. This term has no relation to the term "cryptographic key" used in some documents that describe security mechanisms 🙅♀️.
1.1. Terminology 🌸
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] 💅.
This document makes use of the following terminology and acronyms. Let's get into it 🧚.
- AS: Autonomous System.
- ASBR: Autonomous System Border Routers, used to connect to another AS of a different or the same Service Provider via one or more links inter-connecting between ASes.
- CPS: Confidential Path Segment. A segment of a path that contains nodes and links that the AS policy requires to not be disclosed outside the AS.
- Inter-AS TE LSP: A TE LSP that crosses an AS boundary.
- LSR: Label Switching Router.
- LSP: Label Switched Path.
- PCC: Path Computation Client. Any client application requesting a path computation to be performed by a Path Computation Element.
- 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.
- TE LSP: Traffic Engineering Label Switched Path.
2. Path-Key Solution 🦋
Okay, here's where the magic happens ✨. The Path-Key solution may be applied in the PCE-based path computation context like this. A PCE computes a path segment related to a particular domain, and it replaces any CPS in the path reported to the requesting PCC (or another PCE) with one or more subobjects referred to as PKSes. The entry boundary LSR of each CPS SHOULD be specified using its TE Router Id as a hop in the returned path, immediately preceding the CPS. Other subobjects MAY be included in the path immediately before the hop identifying the boundary LSR, to indicate link and label choices 💖. Where two PKSes are supplied in sequence with no intervening nodes, the entry node to the second CPS MAY be part of the first CPS, and it does not need to be explicitly present in the returned path 🌈. Last but not least, the exit node of a CPS MAY be present as a strict hop immediately following the PKS 🫶.
2.1. Mode of Operation 🫶
okay so this is where the PCE gets secretive 🤫. When local policy says part or all of the path segment being computed has to stay confidential, or the path computation request explicitly asks for it, the PCE gives the CPS a path-key. Then it adds its own PCE ID to that path-key in a PKS and slips the PKS object into the path it returns to the requesting PCC or PCE. The PKS goes right after the subobject that names (using the TE Router Id) the LSR that's gonna expand it into explicit hops. Usually that's the LSR at the start of the CPS 💅.
The PCE that generates a PKS SHOULD store the computed path segment and the path-key so it can grab them later. A local policy SHOULD decide how long that info sticks around, and whether it gets tossed after someone queries it. It is RECOMMENDED that a PCE keeps the PKS for 10 minutes ⏰.
A path-key value is scoped to the PCE that computed it, as identified by the PCE-ID in the PKS 🧚. A PCE MUST NOT re-use a path-key value to represent a new CPS for at least 30 minutes after it discards the previous use of that same path-key. And if a PCE can't keep track of old path-key values across a restart, it SHOULD use some other way to keep them unique, like putting a timestamp or version number in the path-key 🕰️.
A head-end LSR that's also a PCC turns the path from the PCE into an explicit route object (ERO), and puts that ERO in the Resource Reservation Protocol (RSVP) Path message 🌸. If the PCE's path has a PKS, the PKS goes into the ERO too. Like any other subobject, the PKS gets passed along transparently from hop to hop until it becomes the first subobject in the ERO. That happens at the start of the CPS, which is usually the domain boundary. The PKS MUST be preceded by an ERO subobject that names the LSR that has to expand it. So, following the ERO processing rules in [RFC3209], the PKS doesn't get encountered until the ERO is being processed by an LSR that can actually handle it 🙈.
An LSR that hits a PKS while trying to figure out the next hop pulls the PCE-ID out of the PKS and sends a Path Computation Request (PCReq) message to that PCE. The PCReq is defined in [RFC5440], and it has to include the path-key object 📨.
When the PCE gets that PCReq, it uses the path-key to find the computed path segment, and sends the previously computed segment back as explicit hops. It does this in an ERO object inside a Path Computation Reply (PCRep) going to the requesting node, as defined in [RFC5440] 💌. The requesting node slots those explicit hops into its ERO and keeps setting up the TE LSP as per [RFC3209] ✨.
2.2. Example 🗺️
Figure 1 shows a simple two-AS topology, with a PCE handling path computations in each AS 🌈. Someone wants an LSP from the ingress LSR in one AS to the egress LSR in the other AS. The ingress is the PCC, so it sends a path computation request to PCE-1. PCE-1 can't compute an end-to-end path on its own, so it invokes PCE-2, maybe using the techniques from [RFC5441] 🤝. PCE-2 computes a path segment from ASBR-2 to the egress as {ASBR-2, C, D, Egress}. It could send that whole segment back to PCE-1, or it could send back {ASBR-2, Egress}, where the second hop is a loose hop.
But here's the twist 🎀. To keep the topology of the second AS confidential while still specifying the path in full, PCE-2 can send PCE-1 a path segment written as {ASBR-2, PKS, Egress}, where the PKS is a Path-Key Subobject as defined in this document. PCE-2 has marked {ASBR-2, C, D, Egress} as a Confidential Path Segment (CPS). PCE-1 computes the path segment it's responsible for, then hands the full path to the PCC as {Ingress, A, B, ASBR-1, ASBR-2, PKS, Egress} 👑.
Signaling runs through the first AS like normal. But when the Path message reaches ASBR-2, the next hop is the PKS, and that has to be expanded before signaling can keep going 😭. ASBR-2 uses the info in the PKS to ask PCE-2 for a path segment. PCE-2 returns {ASBR-2, C, D, Egress}, and signaling carries on and sets up the LSP 🦋.
----------------------------- ----------------------------
| ------- | | ------- |
| | PCE-1 |<---------------+--+-->| PCE-2 | |
| ------- | | ------- |
| ^ | | ^ |
| | | | | |
| v | | v |
| ------- ---- | | ---- |
| | PCC | - - |ASBR| | | |ASBR| - - ------ |
| |Ingress|--|A|--|B|--| 1 |-+--+-| 2 |--|C|--|D|--|Egress| |
| ------- - - ----- | | ---- - - ------ |
| | | |
----------------------------- ----------------------------
Figure 1 : A Simple network to demonstrate the use of the PKS3. PCEP Protocol Extensions 💜
3.1. Path-Keys in PCRep Messages 🫧
Path-Keys ride along in PCReq and PCRep messages, as part of the various objects that carry path definitions. Specifically, a Path-Key is carried in the Explicit Route Object (ERO) on PCRep messages 💖.
Every time, the Path-Key lives in a Path-Key Subobject (PKS) 📦.
The PKS is a fixed-length subobject that holds a Path-Key and a PCE-ID. The Path-Key is an identifier, or token, that stands in for the CPS within the context of the PCE named by the PCE-ID. The PCE-ID identifies the PCE that can decode the Path-Key, using an identifier that's unique within the domain that PCE serves 🔑. The first node of the CPS (usually a domain border router) has to map the PCE-ID to a reachable IPv4 or IPv6 address of the PCE. A PCE MAY use one of its reachable IP addresses as its PCE-ID. Or, for more security (see Section 5) or extra confidentiality, the PCE MAY use some other identifier that only means something within the domain, depending on domain-local policy 🙈.
To allow IPv4 and IPv6 addresses to be carried, two subobjects are defined in the following subsections 🌟.
The Path-Key Subobject may be present in the PCEP ERO or the PCEP PATH-KEY object (see Section 3.2) 🎀.
3.1.1. PKS with 32-Bit PCE ID 🍓
The Subobject Type for the PKS with 32-bit PCE ID is 64. The format of this subobject 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path-Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L
The L bit SHOULD NOT be set, so the subobject represents a strict hop in the explicit route 🙅♀️.
Type
This is the Subobject Type for a Path-Key with 32-bit PCE ID (64) 🏷️.
Length
The Length is the total length of the subobject in bytes, including the Type and Length fields. It's always 8 📏.
PCE ID
This is a 32-bit identifier of the PCE that can decode this path-key. The identifier MUST be unique within the scope of the domain that the CPS crosses, and MUST be understood by the LSR that will act as PCC for the expansion of the PKS. How the PCE-ID gets interpreted is up to domain-local policy. It MAY be an IPv4 address of the PCE that's always reachable, and it MAY be an address restricted to the domain where the LSR that's called upon to expand the CPS lives. Other values that have no meaning outside the domain (for example, the Router ID of the PCE) MAY be used to boost security or confidentiality (see Section 5) 🔒.
3.1.2. PKS with 128-Bit PCE ID 🌌
The Subobject Type for the PKS with 128-bit PCE ID is 65. The format of the subobject 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Path-Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PCE ID (16 bytes) |
| |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L
As above.
Type
This is the Subobject Type for a Path-Key with 128-bit PCE ID (65).
Length
The Length is the total length of the subobject in bytes, including the Type and Length fields. It's always 20 📐.
PCE ID
This is a 128-bit identifier of the PCE that can decode this path-key. The identifier MUST be unique within the scope of the domain that the CPS crosses, and MUST be understood by the LSR that will act as PCC for the expansion of the PKS. How the PCE-ID gets interpreted is up to domain-local policy. It MAY be an IPv6 address of the PCE that's always reachable, but it MAY also be an address restricted to the domain where the LSR that's called upon to expand the CPS lies. Other values that have no meaning outside the domain (for example, the IPv6 TE Router ID) MAY be used to boost security (see Section 5) 🛡️.
3.2. Unlocking Path-Keys 🔓
When a network node needs to decode a Path-Key so it can keep signaling for an LSP, it must send a PCReq to the designated PCE 🗝️. The PCReq defined in [RFC5440] needs a tweak to support this, since it's different from a normal path computation request. So there's a new flag to show that the PCReq is about expanding a PKS, and a new object to carry the PKS in the PCReq. Both of these update the BNF for the message. The BNF used in this document is described in [RBNF] 💅.
3.2.1. Path-Key Bit 🎈
[RFC5440] defines the Request Parameters (RP) object, which specifies various characteristics of the Path Computation Request (PCReq) 📋.
In this document, we define a new bit called the Path-Key bit. See Section 7.3 for the IANA assignment of the bit number 🔢.
Path-Key bit: When set, the requesting PCC needs to retrieve a Confidential Path Segment that corresponds to the PKS carried in a PATH-KEY object in the path computation request. The Path-Key bit MUST be cleared when the path computation request isn't related to a CPS retrieval 🙃.
3.2.2. PATH-KEY Object 🗝️✨
okay so, when a PCC needs to expand a path-key so it can expand a CPS 💅, it sends a Path Computation Request (PCReq) to the PCE named in the PKS inside the RSVP-TE ERO it's currently processing. The PCC puts the PKS that needs expanding into a PATH-KEY Object inside that PCReq message 🫶
The PATH-KEY Object is defined like this 👑:
PATH-KEY Object-Class is 16.
Path-Key Object-Type is 1.Now the rules 🔥: the PATH-KEY Object MUST contain at least one Path-Key Subobject (see Section 3.1). The first PKS MUST be processed by the PCE. Subsequent subobjects SHOULD be ignored. so the PCE only really cares about the first one 💀
3.2.3. Path Computation Request (PCReq) Message with Path-Key 🎀
good news, bestie: the format of a PCReq message that includes a PATH-KEY object is unchanged, so the overall shape stays exactly the same 🦋
<PCReq Message>::= <Common Header>
[<SVEC-list>]
<request-list>
where:
<svec-list>::=<SVEC>[<svec-list>]
<request-list>::=<request>[<request-list>]To support using the message to expand a PKS, the definition of <request> gets a little glow-up ✨ (the new branch is <path-key-expansion>):
<request>::= <RP>
<segment-computation> | <path-key-expansion>
where:
<segment-computation> ::= <END-POINTS>
[<LSPA>]
[<BANDWIDTH>]
[<BANDWIDTH>]
[<metric-list>]
[<RRO>]
[<IRO>]
[<LOAD-BALANCING>]
<path-key-expansion> ::= <PATH-KEY>Thus, the format of the message for use in normal path computation is unmodified 🌸 so nothing changes for regular path requests, obsessed with how chill that is 😭
4. PCEP Mode of Operation for Path-Key Expansion 🌈
the retrieval of the explicit path (the CPS) for a PKS by a PCC is basically like any other path computation request, with one big exception 🙈: the PCReq message MUST contain a PATH-KEY object and the Path-Key bit of the RP object MUST be set. When the PCC gets a PCRep carrying a CPS, it SHOULD insert that CPS into the ERO it's about to signal, following local policy 🍓
now let's talk about the PCE side 🧚. if the receiving PCE doesn't recognize itself as the one identified by the PCE ID in the PKS, it MAY forward the PCReq to another PCE according to local policy. but if it doesn't forward, it MUST respond with a PCRep message containing a NO-PATH object 💅
if the receiving PCE does recognize itself but can't find the related CPS, or if policy doesn't allow retrieving the CPS, the PCE MUST send a PCRep message that contains a NO-PATH object. the NO-PATH-VECTOR TLV SHOULD be used as described in [RFC5440], and a new bit number (see Section 7.4) gets assigned to mean "Cannot expand PKS" 🫠
and when the requesting LSR gets a negative reply, it MUST fail the LSP setup, and it SHOULD use the procedures tied to loose hop expansion failure [RFC3209] 💔
5. Security Considerations 🔐💀
okay, serious moment, bestie 😭: this document describes tunneling confidential path information across an untrusted domain (like an AS). there are many security considerations that apply to PCEP and RSVP-TE, and they're all kinda big deals.
the issues include:
- Confidentiality of the CPS (can other network elements probe for expansion of path-keys, possibly at random?).
- Authenticity of the path-key (resilience to alteration by intermediaries, resilience to fake expansion of path-keys).
- Resilience from Denial-of-Service (DoS) attacks (insertion of spurious path-keys; flooding of bogus path-key expansion requests).
most of the interactions this extension needs are point to point, and they can be authenticated and made secure as described in [RFC5440] and [RFC3209]. these interactions include:
- PCC->PCE request
- PCE->PCE request(s)
- PCE->PCE response(s)
- PCE->PCC response
- LSR->LSR request and response. Note that a rogue LSR could modify the ERO and insert or modify Path-Keys. This would result in an LSR (which is downstream in the ERO) sending decode requests to a PCE. This is actually a larger problem with RSVP. The rogue LSR is an existing issue with RSVP and will not be addressed here.
- LSR->PCE request. Note that the PCE can check that the LSR requesting the decode is the LSR at the head of the Path-Key. This largely contains the previous problem of DoS rather than a security issue. A rogue LSR can issue random decode requests, but these will amount only to DoS.
- PCE->LSR response
the rogue LSR thing is the big drama here, so keep an eye on it 👀
so the major security issues can be handled with standard techniques for securing and authenticating point-to-point communications. in addition, it is recommended that the PCE providing a decode response check that the LSR that issued the decode request is the head end of the decoded ERO segment 🫶
further protection can come from using a PCE ID that identifies the decoding PCE and is only meaningful within the domain containing the LSR at the head of the CPS. this may be an IP address that's only reachable from inside the domain, or some not-address value. the former needs policy configured on the PCEs, and the latter needs domain-wide policy 🦋
6. Manageability Considerations 🛠️🎀
6.1. Control of Function through Configuration and Policy 👑
the treatment of a path segment as a CPS, and its swap-out for a PKS in a PCRep ERO, is a function that MUST be under operator and policy control wherever a PCE supports it. the operator MUST be given the ability to specify which path segments get replaced and under what circumstances. for example, an operator might set a policy saying every path segment in the operator's domain gets replaced by a PKS when the PCReq came from outside the domain 🌍
the PKS extensions require that path-keys are retained by the issuing PCE so an LSR (acting as a PCC) can retrieve them later 📦. but the retrieval request might never happen, so good housekeeping means running a timer to discard the unwanted path-keys 🧹. a default value for this timer is suggested in Section 2.1. Implementations SHOULD provide the ability to override this value through operator configuration or policy ⚙️
after a PKS has been expanded in response to a retrieval request, it may be valuable to keep the path-key and CPS around for debugging 🔍. that retention SHOULD NOT be the default behavior of an implementation, but it MAY be available when the operator asks for it 💜
once a path-key has been discarded, its value SHOULD NOT be immediately available for re-use for a new CPS, since that could lead to accidental misuse 🙈. a default timer value is suggested in Section 2.1. Implementations SHOULD provide the ability to override this value through operator configuration or policy 🌸
a PCE must set a PCE-ID value in each PKS it creates so PCCs can correctly identify it and send PCReq messages to expand the PKS to a path segment. a PCE implementation SHOULD allow operator or policy control of the value used as the PCE-ID. if the PCE allows PCE-ID values that are not routable addresses, the PCCs MUST be configurable (by the operator or through policy) so they can map from the PCE-ID to a routable address of the PCE. this mapping may be algorithmic, procedural (for example, mapping a PCE-ID equal to the IGP Router ID into a routable address), or configured through a local or remote mapping table 🗺️
6.2. Information and Data Models 📊
a MIB module for PCEP is already defined in [PCEP-MIB]. the configurable items listed in Section 6.1 MUST be added as readable objects in that module and SHOULD be added as writable objects 💅
a new MIB module MUST be created to let people inspect path-keys. for a given PCE, this MIB module MUST provide a mapping from path-key to path segment (that is, a list of hops), and MUST supply other information including:
- The identity of the PCC that issued the original request that led to the creation of the path-key.
- The request ID of the original PCReq.
- Whether the path-key has been retrieved yet, and if so, by which PCC.
- How long until the path segment associated with the path-key will be discarded.
- How long until the path-key will be available for re-use.
6.3. Liveness Detection and Monitoring 💓
the procedures in this document extend PCEP but don't introduce new interactions between network entities 🧚. so no new liveness detection or monitoring is required.
a head-end LSR that's been given a path including PKSs replacing specific CPSs might want to know whether those path-keys are still valid (or have timed out) 🤔. but rather than adding a mechanism to poll the PCE responsible for the PKS, it's considered pragmatic to simply signal the associated LSP 🦋
6.4. Verifying Correct Operation 🔎
again, the procedures in this document extend PCEP but don't introduce new interactions between network entities, so no new tools for verifying correct operation are required 💖
a PCE SHOULD maintain counters and logs of the following events, since they might indicate incorrect operation (or might indicate security issues) 👀:
- Attempts to expand an unknown path-key.
- Attempts to expand an expired path-key.
- Duplicate attempts to expand the same path-key.
- Expiry of path-key without attempt to expand it.
6.5. Requirements on Other Protocols and Functional Components 🧩
the procedures in this document require that LSRs signal PKSs as defined in [RSVP-PKS]. the only changes to LSRs are at the PCCs. specifically, changes are only needed at the head-end LSRs that build RSVP-TE Path messages containing Path-Key Subobjects in their EROs, and at the LSRs that discover such subobjects as next hops and must expand them. other LSRs in the network, even if they're on the LSP's path, won't be called upon to process the PKS 🌈✨
6.6. Impact on Network Operation
okay so bestie, the PKS isn't just about keeping things secret 🦋 it can also make things way more efficient ✨ a single PKS in an explicit route can stand in for a whole bunch of subobjects, which means the overall message gets smaller. 📉 in some situations the difference is honestly huge, like when each hop has multiple subobjects (node IDs, TE link IDs, component link IDs for each direction of a bidirectional LSP, and label IDs for each direction of a bidirectional LSP) or when the LSP is a point-to-multipoint LSP. the scaling win can be very significant 🤯
ngl the PCE is also super careful about who gets a PKS 🧚 it won't hand one out unless it knows the LSR that will receive the PKS through signaling can actually handle it. and like we said in Section 6.5, only the LSRs that get specifically called on to expand the PKS have to process those subobjects during signaling. so the only backward compatibility problem from this whole procedure shows up when a head-end LSR gets a PCRep with an ERO containing a PKS and doesn't know how to encode it into signaling. 🙈
here's the tea 🍵 the PCE that inserted the PKS has to keep the CPS confidential, which means the legacy head-end LSR can't be protected. it's stuck with two options: it can fail the LSP setup, or it can request a new path computation that avoids the domain that gave it those unknown subobjects. no cap, that's a lot of pressure on a legacy box 💀
7. IANA Considerations 🎀
IANA assigns values to PCEP parameters in registries defined in [RFC5440]. it has also made the following additional assignments, bestie 💖
7.1. New Subobjects for the ERO Object
IANA has already assigned an Object-Class and Object-Type to the ERO carried in PCEP messages [RFC5440]. IANA also keeps a list of subobject types that are valid for inclusion in the ERO 📋
IANA assigned two new subobject types for inclusion in the ERO, and they look like this:
Subobject Type Reference
64 Path-Key with 32-bit PCE ID [RFC5520]
65 Path-Key with 128-bit PCE ID [RFC5520]7.2. New PCEP Object
IANA assigned a new object class in the registry of PCEP Objects, and it's giving main character energy 👑
Object Name Object Name Reference
Class Type
16 PATH-KEY 1 Path-Key [RFC5520]
Subobjects
This object may carry the following subobjects as defined
for the ERO object.
64 Path-Key with 32-bit PCE ID [RFC5520]
65 Path-Key with 128-bit PCE ID [RFC5520]7.3. New RP Object Bit Flag
IANA keeps a registry of bit flags carried in the PCEP RP object as defined in [RFC5440]. IANA assigned one new bit flag, and it's giving 🌈
Bit Number Hex Name Reference
23 0x000017 Path-Key (P-bit) [RFC5520]7.4. New NO-PATH-VECTOR TLV Bit Flag
IANA also keeps a registry of bit flags carried in the PCEP NO-PATH-VECTOR TLV, which lives inside the PCEP NO-PATH object as defined in [RFC5440]. IANA assigned one new bit flag here too ✨
Bit Number Name Flag Reference
27 PKS expansion failure [RFC5520]8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
March 2009.8.2. Informative References
[PCEP-MIB] Koushik, K., and E. Stephan, "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.
[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.
[RFC4105] Le Roux, J.-L., Ed., Vasseur, J.-P., Ed., and J. Boyle,
Ed., "Requirements for Inter-Area MPLS Traffic
Engineering", RFC 4105, June 2005.
[RFC4216] Zhang, R., Ed., and J.-P. Vasseur, Ed., "MPLS Inter-
Autonomous System (AS) Traffic Engineering (TE)
Requirements", RFC 4216, November 2005.
[RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655,
August 2006.
[RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A
Per-Domain Path Computation Method for Establishing
Inter-Domain Traffic Engineering (TE) Label Switched Paths
(LSPs)", RFC 5152, February 2008.
[RFC5298] Takeda, T., Ed., Farrel, A., Ed., Ikejiri, Y., and JP.
Vasseur, "Analysis of Inter-Domain Label Switched Path
(LSP) Recovery", RFC 5298, August 2008.
[RFC5441] Vasseur, JP., Ed., Zhang, R., Bitar, N., and JL. Le Roux,
"A Backward-Recursive PCE-Based Computation (BRPC)
Procedure to Compute Shortest Constrained Inter-Domain
Traffic Engineering Label Switched Paths", RFC 5441, April
2009.
[RSVP-PKS] Bradford, R., Vasseur, JP., and A. Farrel, "RSVP
Extensions for Path Key Support", Work in Progress,
February 2008.Acknowledgements 🫶
The authors would like to thank Eiji Oki, Ben Campbell, and Ross Callon for their comments on this document. thank you to them, they're literally the MVPs 🏆
Authors' Addresses 💌
Rich Bradford (Editor)
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: rbradfor@cisco.com
JP. Vasseur
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
EMail: jpv@cisco.com
Adrian Farrel
Old Dog Consulting
EMail: adrian@olddog.co.uk📦 where this page comes from
- ietf: rfc5520 2009-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms