RFC 7897
Domain Subobjects for the Path Computation Element Communication Protocol (PCEP)
Part 1 of 7 💖 more parts are coming, bestie!
RFC 7897 🎀
Domain Subobjects for the Path Computation Element Communication Protocol (PCEP) 🦋
Okay so this is RFC 7897 from the Internet Engineering Task Force (IETF), published in June 2016 ✨ It's an Experimental document, not a Standards Track one, so it's still being tested 🧪 The ISSN is 2070-1721. The authors are D. Dhody, U. Palle (both from Huawei Technologies), and R. Casellas (from CTTC). Its title block doesn't list anything it obsoletes or updates, so no sneaky replacements here 💅
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6
3.1. Domains . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Domain Sequence . . . . . . . . . . . . . . . . . . . . . 6
3.3. Domain Sequence Representation . . . . . . . . . . . . . 7
3.4. Include Route Object (IRO) . . . . . . . . . . . . . . . 8
3.4.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 8
3.4.1.1. Autonomous System . . . . . . . . . . . . . . . . 8
3.4.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Update in IRO Specification . . . . . . . . . . . . . 10
3.4.3. IRO for Domain Sequence . . . . . . . . . . . . . . . 11
3.4.3.1. PCC Procedures . . . . . . . . . . . . . . . . . 11
3.4.3.2. PCE Procedures . . . . . . . . . . . . . . . . . 11
3.5. Exclude Route Object (XRO) . . . . . . . . . . . . . . . 13
3.5.1. Subobjects . . . . . . . . . . . . . . . . . . . . . 13
3.5.1.1. Autonomous System . . . . . . . . . . . . . . . . 14
3.5.1.2. IGP Area . . . . . . . . . . . . . . . . . . . . 14
3.6. Explicit Exclusion Route Subobject (EXRS) . . . . . . . . 16
3.7. Explicit Route Object (ERO) . . . . . . . . . . . . . . . 16
4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1. Inter-Area Path Computation . . . . . . . . . . . . . . . 17
4.2. Inter-AS Path Computation . . . . . . . . . . . . . . . . 19
4.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 22
4.3. Boundary Node and Inter-AS Link . . . . . . . . . . . . . 25
4.4. PCE Serving Multiple Domains . . . . . . . . . . . . . . 25
4.5. P2MP . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.6. Hierarchical PCE . . . . . . . . . . . . . . . . . . . . 27
5. Other Considerations . . . . . . . . . . . . . . . . . . . . 27
5.1. Relationship to PCE Sequence . . . . . . . . . . . . . . 27
5.2. Relationship to RSVP-TE . . . . . . . . . . . . . . . . . 27
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6.1. New Subobjects . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
8. Manageability Considerations . . . . . . . . . . . . . . . . 29
8.1. Control of Function and Policy . . . . . . . . . . . . . 29
8.2. Information and Data Models . . . . . . . . . . . . . . . 29
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 30
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 30
8.5. Requirements on Other Protocols . . . . . . . . . . . . . 30
8.6. Impact on Network Operations . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . 32
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35Abstract 🌸
Here's the big idea: computing shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) across multiple domains in MPLS and GMPLS networks has been flagged as a key requirement, and it's giving important 👑 A domain is a group of network elements that share a sphere of address management or path computation responsibility, like an Interior Gateway Protocol (IGP) area or an Autonomous System (AS) 🧚 This doc specifies a way to represent and encode a domain sequence, which is the ordered list of domains you cross to reach the destination domain. PCEs use that to compute inter-domain constrained shortest paths across a predetermined sequence of domains. It also defines new subobjects for encoding domain identifiers ✨
Status of This Memo 📜
This doc is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation 🔬
It defines an Experimental Protocol for the Internet community. It's a product of the IETF, it reflects IETF community consensus, and it got public review and approval for publication from the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 for the details 🙈
For current status, errata, and how to give feedback, head to http://www.rfc-editor.org/info/rfc7897 💜
Copyright Notice 🌈
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. Please read those carefully, because they spell out your rights and restrictions. Code Components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License ⚖️
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Detail Description . . . . . . . . . . . . . . . . . . . . . 6(The rest of the Table of Contents is in the full listing above, so check there for the later sections 🧸)
1. Introduction ✨
Okay so a Path Computation Element (PCE) can compute end-to-end paths across multi-domain environments using a per-domain path computation technique [RFC5152]. The Backward-Recursive PCE-Based Computation (BRPC) mechanism [RFC5441] also defines a PCE-based procedure for computing an inter-domain constrained path for (G)MPLS TE LSPs. But here's the catch 👀 Both per-domain and BRPC techniques assume that the sequence of domains from source to destination is already known. That sequence is either fixed by the network operator or obtained some other way. For inter-domain point-to-multipoint (P2MP) tree computation, [RFC7334] assumes the domain tree is known a priori.
The list of domains (the domain sequence) in a point-to-point (P2P) path, or the domain tree in a P2MP path, is usually a constraint in an inter-domain path computation procedure 💅
The domain sequence, meaning the set of domains traversed to reach the destination domain, is either administratively predetermined or discovered by some means, like Hierarchical PCE (H-PCE) 🦋
[RFC5440] defines the Include Route Object (IRO) and the Explicit Route Object (ERO). [RFC5521] defines the Exclude Route Object (XRO) and the Explicit Exclusion Route subobject (EXRS). The use of an Autonomous System (albeit with a 2-byte AS number) as an abstract node representing a domain is defined in [RFC3209]. In this doc, we specify new subobjects to include or exclude domains, including an IGP area or an AS (4 bytes, as per [RFC6793]) 🧚
Sometimes the domain identifier just acts as a delimiter, marking where a domain boundary starts and ends 🌸
This is a companion document to the Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions for the domain identifiers [RFC7898] 💖
1.1. Scope 🔭
The procedures in this document are experimental. The experiment is meant to research how the domain sequence gets used at the PCEs for inter-domain paths. To that end, this doc specifies new domain subobjects, plus how they fit together with existing subobjects to represent a domain sequence 🧪
The experiment will end two years after the RFC is published. At that point, the RFC authors will try to figure out how widely it's been implemented and deployed 📆
This document does not change the procedures for handling existing subobjects in the PCE Communication Protocol (PCEP) 🙌
The new subobjects introduced here won't be understood by legacy implementations. If a legacy implementation receives one of these subobjects in a PCEP object that it doesn't understand, it will behave according to the rules for a malformed object, as per [RFC5440]. 😭 So this experiment is assumed to run only when both the PCE and the Path Computation Client (PCC) are part of it. A PCC or PCE can peer with some nodes that are in the experiment and some that aren't. Since no capabilities exchange is used to identify which nodes can use these extensions, manual configuration should be used to decide which peerings are part of the experiment 🛠️
When the implementation and deployment results are in, this document will be updated and refined. After that, it could move from Experimental to Standards Track 🚀
1.2. 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 [RFC2119].
2. Terminology 📖
The following terminology is used in this document 💜
- ABR: Area Border Router. Routers used to connect two IGP areas (Open Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS).
- AS: Autonomous System
- ASBR: Autonomous System Border Router
- BN: Boundary node. Can be an ABR or ASBR.
- BRPC: Backward-Recursive PCE-Based Computation
- Domain: As per [RFC4655], any collection of network elements within a common sphere of address management or path computational responsibility. Examples of domains include IGP area and AS.
- Domain Sequence: An ordered sequence of domains traversed to reach the destination domain.
- ERO: Explicit Route Object
- H-PCE: Hierarchical PCE
- IGP: Interior Gateway Protocol. Either of the two routing protocols: OSPF or IS-IS.
- IRO: Include Route Object
- IS-IS: Intermediate System to Intermediate System
- OSPF: Open Shortest Path First
- 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.
- P2MP: Point-to-Multipoint
- P2P: Point-to-Point
- RSVP: Resource Reservation Protocol
- TE LSP: Traffic Engineering Label Switched Path
- XRO: Exclude Route Object
3. Detail Description ✨
Part 1 wraps up here, and Section 3 is up next! 🫶
3.1. Domains
Okay so [RFC4726] and [RFC4655] say a domain is a separate administrative or geographic environment within the network 🗺️✨ It could also be described as a zone of routing or computational ability 💅 Under those definitions, a domain might be an AS or an IGP area 🎀 Each AS can be made of several IGP areas 🌸 To encode a domain sequence, you REQUIRED to uniquely identify each domain in that sequence 😭 A domain can be uniquely identified by an area-id, an AS number, or both 🫶
3.2. Domain Sequence
Bestie, a domain sequence is an ordered sequence of domains you traverse to reach the destination domain 🦋
A domain sequence can be applied as a constraint and carried in a path computation request to a PCE(s) 💖 It can also be the result of a path computation ✨ For example, with H-PCE [RFC6805], a parent PCE could send the domain sequence back as a result in a path computation reply 👑
In a P2P path, the domains get listed in the order they're crossed 🧚 In a P2MP path, the domain tree is represented as a list of domain sequences 🌈
A domain sequence lets a PCE pick the next domain, plus the PCE serving that domain, to forward the path computation request to, based on the domain information 💜
A domain sequence can include boundary nodes (ABR or ASBR) or border links (inter-AS links) to be traversed as an additional constraint 🍓
So a domain sequence can be made up of one or more of the following:
- AS Number
- Area ID
- Boundary Node ID
- Inter-AS Link Address
These get encoded in the new subobjects defined in this document, as well as in the existing subobjects that represent a domain sequence 🎀
Consequently, a domain sequence can be used by:
- a PCE to discover or select the next PCE in a collaborative path computation, such as in BRPC [RFC5441] 🦋
- the parent PCE to return the domain sequence when it's unknown; this can then be an input to the BRPC procedure [RFC6805] 🌸
- a PCC or a PCE to constrain the domains used in inter-domain path computation, explicitly specifying which domains to be expanded or excluded; and 💅
- a PCE in the per-domain path computation model [RFC5152] to identify the next domain 👑
3.3. Domain Sequence Representation
A domain sequence shows up in PCEP messages, notably in: 💖
- Include Route Object (IRO): As per [RFC5440], IRO can be used to specify a set of network elements to be traversed to reach the destination, which includes subobjects used to specify the domain sequence 🫶
- Exclude Route Object (XRO): As per [RFC5521], XRO can be used to specify certain abstract nodes to be excluded from the whole path, which include subobjects used to specify the domain sequence 🙈
- Explicit Exclusion Route Subobject (EXRS): As per [RFC5521], EXRS can be used to specify exclusion of certain abstract nodes (including domains) between a specific pair of nodes. EXRS is a subobject inside the IRO 🧚
- Explicit Route Object (ERO): As per [RFC5440], ERO can be used to specify a computed path in the network. For example, with H-PCE [RFC6805], a parent PCE can send the domain sequence as a result in a path computation reply using ERO ✨
3.4. Include Route Object (IRO)
Okay, as per [RFC5440], IRO can be used to specify that the computed path needs to traverse a set of specified network elements or abstract nodes 🌈
3.4.1. Subobjects
Some subobjects are defined in [RFC3209], [RFC3473], [RFC3477], and [RFC4874], but new subobjects related to domain sequence are needed 🎀
This document extends the support for 4-byte AS numbers and IGP areas 💜
Value Description
----- ----------------
5 4-byte AS number
6 OSPF Area ID
7 IS-IS Area IDNote: Identical subobjects are carried in RSVP-TE messages as defined in [RFC7898] 🦋
3.4.1.1. Autonomous System
[RFC3209] already defines 2-byte AS numbers 🌸
To support 4-byte AS numbers as per [RFC6793], the following subobject is defined 💖
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L: The L bit is an attribute of the subobject as defined in [RFC3209], and its usage in the IRO subobject is defined in [RFC7896] 🫶
Type: 5 (indicating a 4-byte AS number) 🎀
Length: 8 (total length of the subobject in bytes) 💅
Reserved: Zero at transmission; ignored at receipt 🧚
AS Number: The 4-byte AS number. Note that if 2-byte AS numbers are in use, the low-order bits (16 through 31) MUST be used, and the high-order bits (0 through 15) MUST be set to zero 😭
3.4.1.2. IGP Area
Since the length and format of Area ID is different for OSPF and IS-IS, the following two subobjects are defined below 🌈
For OSPF, the Area ID is a 32-bit number. The subobject is encoded 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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L: The L bit is an attribute of the subobject as defined in [RFC3209], and its usage in the IRO subobject is defined in [RFC7896] 🫶
Type: 6 (indicating a 4-byte OSPF Area ID) 🌸
Length: 8 (total length of the subobject in bytes) 💜
Reserved: Zero at transmission; ignored at receipt 🎀
OSPF Area ID: The 4-byte OSPF Area ID 👑
For IS-IS, the Area ID is of variable length, so the length of the subobject is variable too 🌈 The Area ID is as described in IS-IS by the ISO standard [ISO10589] 💖 The subobject is encoded 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 | Area-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IS-IS Area ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L: The L bit is an attribute of the subobject as defined in [RFC3209], and its usage in the IRO subobject is defined in [RFC7896] 🦋
Type: 7 (indicating the IS-IS Area ID) 🧚
Length: Variable. The length MUST be at least 8 and MUST be a multiple of 4 🔥
Area-Len: Variable (length of the actual (non-padded) IS-IS area identifier in octets; valid values are from 1 to 13, inclusive) 💀
Reserved: Zero at transmission; ignored at receipt 🌈
IS-IS Area ID: The variable-length IS-IS area identifier. Padded with trailing zeroes to a 4-byte boundary 🍓
3.4.2. Update in IRO Specification
Okay, so [RFC5440] describes IRO as an optional object used to specify network elements to be traversed by the computed path 🎀 It further states that the L bit of such a subobject has no meaning within an IRO 🙈 It also doesn't mention whether IRO is an ordered or unordered list of subobjects 😭
An update to the IRO specification [RFC7896] makes IRO an ordered list and includes support for the L bit ✨
The use of IRO for the domain sequence assumes the updated specification is being used for IRO, as per [RFC7896] 💅
3.4.3. IRO for Domain Sequence
The subobject type for IPv4, IPv6, and unnumbered Interface IDs can be used to specify boundary nodes (ABR/ASBR) and inter-AS links 🦋 The subobject type for the AS Number (2 or 4 bytes) and the IGP area are used to specify the domain identifiers in the domain sequence 👑
The IRO can incorporate the new domain subobjects with the existing subobjects in a sequence of traversal 🫶
Thus, an IRO comprising subobjects that represents a domain sequence defines the domains involved in an inter-domain path computation, typically involving two or more collaborative PCEs 🌈
A domain sequence can have varying degrees of granularity 🌸 It's possible to have a domain sequence composed of, uniquely, AS identifiers 💖 It's also possible to list the involved IGP areas for a given AS ✨
In any case, the mapping between domains and responsible PCEs is not defined in this document 🙈 It is assumed that a PCE that needs to obtain a "next PCE" from a domain sequence is able to do so (e.g., via administrative configuration or discovery) 🎀
3.4.3.1. PCC Procedures
A PCC builds an IRO to encode the domain sequence, so that the cooperating PCEs could compute an inter-domain shortest constrained path across the specified sequence of domains 💜
A PCC MAY intersperse area and AS subobjects with other subobjects without change to the previously specified processing of those subobjects in the IRO 🧚
3.4.3.2. PCE Procedures ✨
Okay so, if a PCE gets an IRO in a PCReq message and it contains subobjects from this doc that it doesn't recognize, it responds using the malformed object rules in [RFC5440] 🙈. The PCE MAY also include the IRO in the PCErr message, as per [RFC5440] 💅.
The L bit gets interpreted as per Section 4.3.3.1 of [RFC3209] (as per [RFC7896]) 🎀.
In a PCRep, the PCE MAY also supply the IRO (with domain sequence info) alongside the NO-PATH object 🌸. This tells you the set of domains in the request's IRO is what stopped the PCEs from finding a path 😭.
Here are the domain sequence processing rules for an IRO 👑:
- When a PCE parses an IRO, it reads each subobject based on the AS number of the subobject right before it. We call this the "current AS" 🦋. Some subobjects can change the current AS, like so:
- The current AS starts out as the AS number of the PCC 🍓.
- If the PCE hits an AS subobject, it updates the current AS to that new AS number 💖.
- If the PCE hits an area subobject, it assumes that area belongs to the current AS 🧚.
- If the PCE hits a globally routable IP address, it updates the current AS to whichever AS owns that IP address. This doc doesn't define how the PCE figures out which AS owns the IP 🤷♀️.
- If the PCE hits an IP address that isn't globally routable, it assumes it belongs to the current AS ✨.
- If the PCE hits an unnumbered link, it assumes it belongs to the current AS 💜.
- When a PCE parses an IRO, it also reads each subobject based on the Area ID of the subobject right before it. We call this the "current area" 🌈. Some subobjects can change the current area, too:
- The current area starts out as the Area ID of the PCC 🫶.
- If the current AS changes, the current area gets reset and has to be figured out again by a current or later subobject 💀.
- If the PCE hits an area subobject, it updates the current area to that new Area ID 🔥.
- If the PCE hits an IP address that belongs to a different area, it updates the current area to the area that has that IP. This doc doesn't define how the PCE learns which area has the IP 🙈.
- If the PCE hits an unnumbered link that belongs to a different area, it updates the current area to the area that has that link 🌸.
- Otherwise, it assumes the subobject belongs to the current area 💅.
- If the current PCE isn't responsible for path computation in the current AS or area, the PCE picks the "next PCE" in the domain sequence based on the current AS and area 🦋.
Note that it's advised that the PCC should use AS and area subobjects when building the domain sequence in the IRO, and avoid other mechanisms to change the "current AS" and "current area" described above 🫶.
3.5. Exclude Route Object (XRO) 🚫
XRO [RFC5521] is an optional object used to specify exclusion of certain abstract nodes or resources from the whole path 💅.
3.5.1. Subobjects 🧁
Some subobjects are used in the XRO as defined in [RFC3209], [RFC3477], [RFC4874], and [RFC5520], but new subobjects related to the domain sequence are needed 🌷.
This doc extends support for 4-byte AS numbers and IGP areas ✨.
Value Description
----- ----------------
5 4-byte AS number
6 OSPF Area ID
7 IS-IS Area IDNote: Identical subobjects are carried in RSVP-TE messages as defined in [RFC7898] 💌.
3.5.1.1. Autonomous System 👑
The new subobjects that support 4-byte AS numbers and the IGP (OSPF/IS-IS) area MAY also be used in the XRO to specify exclusion of certain domains in the path computation procedure 🌈.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS Number (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The X-bit tells you whether the exclusion is mandatory or desired 🎯.
- 0: means the AS specified MUST be excluded from the path computed by the PCE(s) 🚫.
- 1: means the AS specified SHOULD be avoided from the inter-domain path computed by the PCE(s), but it MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints 🥺.
All other fields are consistent with the definition in Section 3.4 💖.
3.5.1.2. IGP Area 🦋
The Area ID is a different length and format for OSPF and IS-IS, so there are two subobjects defined 😤.
For OSPF, the Area ID is a 32-bit number. The subobject is encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OSPF Area ID (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The X-bit tells you whether the exclusion is mandatory or desired 🎯.
- 0: means the OSPF area specified MUST be excluded from the path computed by the PCE(s) 🚫.
- 1: means the OSPF area specified SHOULD be avoided from the inter-domain path computed by the PCE(s), but it MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints 🥺.
All other fields are consistent with the definition in Section 3.4 💅.
For IS-IS, the Area ID is variable length, so the length of the subobject is variable too. The Area ID is described in IS-IS by the ISO standard [ISO10589] 📜. The subobject is encoded 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|X| Type | Length | Area-Len | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// IS-IS Area ID //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The X-bit tells you whether the exclusion is mandatory or desired 🎯.
- 0: means the IS-IS area specified MUST be excluded from the path computed by the PCE(s) 🚫.
- 1: means the IS-IS area specified SHOULD be avoided from the inter-domain path computed by the PCE(s), but it MAY be included subject to PCE policy and the absence of a viable path that meets the other constraints 🥺.
All other fields are consistent with the definition in Section 3.4 💖.
All the processing rules are as per [RFC5521] 🧠.
Note that if a PCE gets an XRO in a PCReq message that contains subobjects from this doc that it doesn't recognize, it responds using the malformed object rules in [RFC5440] 🙈.
IGP area subobjects in the XRO are local to the current AS. If a multi-AS path computation needs to exclude an IGP area in a different AS, the IGP area subobject should be part of EXRS in the IRO to specify the AS where that IGP area gets excluded. Policy may also be applied to prune or ignore area subobjects in the XRO after a "current AS" change during path computation 🚨.
3.6. Explicit Exclusion Route Subobject (EXRS) 🎀
The EXRS [RFC5521] is used to specify exclusion of certain abstract nodes between a specific pair of nodes 🦋.
The EXRS can carry any of the subobjects defined for inclusion in the XRO, so the new subobjects that support 4-byte AS numbers and the IGP (OSPF / IS-IS) area can be used in the EXRS too 🌈. The meanings of the fields in the new XRO subobjects don't change when they're included in an EXRS, except the scope of the exclusion is limited to the single hop between the previous and subsequent elements in the IRO 🧚.
The EXRS should be interpreted in the context of the current AS and current area of the preceding subobject in the IRO. The EXRS doesn't change the current AS or current area. All other processing rules are as per [RFC5521] 💅.
Note that if a PCE that supports the EXRS in an IRO parses an IRO and runs into an EXRS containing subobjects from this doc that it doesn't recognize, it acts according to the setting of the X-bit in that subobject, as per [RFC5521] 🫶.
3.7. Explicit Route Object (ERO) 🛣️
ERO [RFC5440] is used to specify a computed path in the network 💫. PCEP ERO subobject types correspond to RSVP-TE ERO subobject types as defined in [RFC3209], [RFC3473], [RFC3477], [RFC4873], [RFC4874], and [RFC5520] 🔗. The subobjects related to the domain sequence are further defined in [RFC7898] 📚.
The new subobjects that support 4-byte AS numbers and the IGP (OSPF/IS-IS) area can also be used in the ERO to specify an abstract node (a group of nodes whose internal topology is opaque to the ingress node of the LSP) 🫧. Using this idea of abstraction, an explicitly routed LSP can be specified as a sequence of domains 🌸.
In the case of H-PCE [RFC6805], a parent PCE can be requested to find the domain sequence. Check the example in Section 4.6 of this document 🧠. The ERO in the reply from the parent PCE can then be used in per-domain path computation or BRPC 🌟.
If a PCC receives an ERO in a PCRep message that contains a subobject defined in this document that it doesn't recognize, it responds according to the rules for a malformed object as per [RFC5440] 🙈.
4. Examples 🧁
The examples in this section are for illustration purposes only, to show how the new subobjects could be encoded 🍬. They're not meant to be an exhaustive list of every possible use case and combination 💕.
4.1. Inter-Area Path Computation ✨
okay so when the ingress and egress nodes are chilling in different IGP areas but still in the same AS 🫶, the domain sequence could be written as an ordered list of area subobjects 🦋
----------------- -----------------
| | | |
| +--+ | | +--+ |
| +--+ | | | | | | |
| | | +--+ | | +--+ +--+ |
| +--+ | | | | |
| | | +--+ |
| +--+ | | |
| | | | | +--+ |
| +--+ | | | | |
| | -------------------------- | +--+ |
| +--+ +--+ |
| | | +--+ | | |
|Area 2 +--+ | | +--+ Area 4 |
----------------- | +--+ | -----------------
| |
| +--+ |
| +--+ | | |
| | | +--+ |
| +--+ |
| |
| |
| |
| |
| +--+ |
| | | |
| +--+ |
----------------- | | ------------------
| +--+ +--+ |
| | | | | |
| +--+ Area 0 +--+ |
| | -------------------------- | +--+ |
| +--+ | | | | |
| | | | | +--+ |
| +--+ +--+ | | |
| | | | | +--+ |
| +--+ | | | | |
| | | +--+ |
| +--+ | | |
| | | | | +--+ |
| +--+ | | | | |
| | | +--+ |
| | | |
| Area 1 | | Area 5 |
----------------- ------------------
Figure 1: Inter-Area Path ComputationThe AS Number is 100.
If the ingress is in area 2, the egress is in area 4, and transit goes through area 0, here are some possible ways a PCC can encode the IRO 💜
+---------+ +---------+ +---------+
|IRO | |Sub- | |Sub- |
|Object | |object | |object |
|Header | |Area 0 | |Area 4 |
| | | | | |
| | | | | |
+---------+ +---------+ +---------+
or
+---------+ +---------+ +---------+ +---------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |Area 2 | |Area 0 | |Area 4 |
| | | | | | | |
| | | | | | | |
+---------+ +---------+ +---------+ +---------+
or
+---------+ +---------+ +---------+ +---------+ +---------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object AS| |object | |object | |object |
|Header | |100 | |Area 2 | |Area 0 | |Area 4 |
| | | | | | | | | |
| | | | | | | | | |
+---------+ +---------+ +---------+ +---------+ +---------+The domain sequence can also include encompassing AS information in the AS subobject ✨
4.2. Inter-AS Path Computation 🌸
okay now the ingress and egress are in different ASes 🌈 so the domain sequence could be represented as an ordered list of AS subobjects. The domain sequence can also include decomposed area information in the area subobject 💅
4.2.1. Example 1 🎀
As shown in Figure 2, where AS has a single area, the AS subobject in the domain sequence can uniquely identify the next domain and PCE 🧚
AS A AS E AS C
<-------------> <----------> <------------->
A4----------E1---E2---E3---------C4
/ / \
/ / \
/ / AS B \
/ / <----------> \
Ingress------A1---A2------B1---B2---B3------C1---C2------Egress
\ / /
\ / /
\ / /
\ / /
A3----------D1---D2---D3---------C3
<---------->
AS D
* All ASes have one area (area 0)
Figure 2: Inter-AS Path ComputationIf the ingress is in AS A, the egress is in AS C, and transit goes through AS B, here are some possible ways a PCC can encode the IRO 🦋
+-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- |
|Object | |object | |object |
|Header | |AS B | |AS C |
| | | | | |
+-------+ +-------+ +-------+
or
+-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |AS A | |AS B | |AS C |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
or
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object | |object | |object |
|Header | |AS A | |Area 0 | |AS B | |Area 0 | |AS C | |Area 0 |
| | | | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+ +-------+Note that to get a domain disjoint path, the ingress could also request the backup path with:
+-------+ +-------+
|XRO | |Sub |
|Object | |Object |
|Header | |AS B |
| | | |
+-------+ +-------+Heads up, bestie 👀 As described in Section 3.4.3, a domain subobject in IRO changes the domain information associated with the next set of subobjects, until you hit a subobject that changes the domain too. Consider the following IRO:
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object | |object |
|Header | |AS B | |IP | |IP | |AS C | |IP |
| | | | |B1 | |B3 | | | |C1 |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+On processing subobject "AS B", it changes the AS of the subsequent subobjects, until we encounter another subobject "AS C" that changes the AS for its subsequent subobjects 💖
Consider another IRO:
+-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object |
|Header | |AS D | |IP | |IP | |IP |
| | | | |D1 | |D3 | |C3 |
+-------+ +-------+ +-------+ +-------+ +-------+Here as well, on processing "AS D", it changes the AS of the subsequent subobjects, until you encounter another subobject "C3" that belongs in another AS and changes the AS for its subsequent subobjects 🔥
Further description for the boundary node and inter-AS link can be found in Section 4.3 🧚♀️💜
4.2.2. Example 2 🦋
Okay bestie, check out Figure 3 🌸 AS 200 is split into a bunch of areas, and the whole thing is giving complicated maze energy 😭
|
| +-------------+ +----------------+
| |Area 2 | |Area 4 |
| | +--+| | +--+ |
| | | || | | B| |
| | +--+ +--+| | +--+ +--+ |
| | | | | | | | |
| | +--+ | | +--+ |
| | +--+ | | +--+ |
| | | | | | | | |
| | +--+ | | +--+ +--+ |
| | +--+ |+--------------+| | | |
| | | | +--+ +--+ +--+ |
+-------------+| | +--+ | | | | |
| || | +--+ +--+ |
| +--+|| +-------------+| |+----------------+
| | ||| | +--+ |
| +--+|| | | | |
| +--+ || | +--+ |
| | | +---+ +--+ |
| +--+ | |----------------| | |
| +---+ Inter-AS +--+ +--+ |
|+--+ || Links | | | |
||A | +---+ +--+ +--+ |
|+--+ | |----------------| | |
| +---+ +--+ +--+ |
| +--+ || +------------+ | | | |+----------------+
| | | || |Area 3 +--+ +--+ +--+ Area 5 |
| +--+ || | | | | | |
| || | +--+ +--+ |
| +--+|| | +--+ | | Area 0 || +--+ |
| | ||| | | | | +--------------+| | | |
| +--+|| | +--+ | | +--+ |
| || | | | +--+ |
|Area 0 || | +--+ | | +--+ | | |
+-------------+| | | | | | | | +--+ |
| | +--+ +--+ | +--+ |
| | | | | |
| | +--+ | +--+ |
| | +--+ | | | C| |
| | | | | | +--+ |
| | +--+ | | |
| | | | |
| +------------+ +----------------+
|
AS 100 | AS 200
|
Figure 3: Inter-AS Path ComputationSo for LSP (A-B), the ingress A is in (AS 100, area 0) 💜 The egress B is in (AS 200, area 4) ✨ And the transit goes through (AS 200, area 0) 🧚 Here are some of the ways a PCC can encode the IRO, no cap 💅
+-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |AS 200 | |Area 0 | |Area 4 |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+or
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object | |object |
|Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 4 |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+Now LSP (A-C), where the ingress A is still in (AS 100, area 0) 🌈 but the egress C is in (AS 200, area 5) 🎀 and the transit is through (AS 200, area 0) again. Same vibes, different destination, here are the options:
+-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |AS 200 | |Area 0 | |Area 5 |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+or
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+
|IRO | |Sub- | |Sub- | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object | |object | |object |
|Header | |AS 100 | |Area 0 | |AS 200 | |Area 0 | |Area 5 |
| | | | | | | | | | | |
+-------+ +-------+ +-------+ +-------+ +-------+ +-------+4.3. Boundary Node and Inter-AS Link 🌸
A PCC or PCE can add extra constraints about which boundary nodes (ABR or ASBR) or border links (inter-AS link) get traversed while it's defining a domain sequence. When that happens, the boundary node or link can be encoded as part of the domain sequence 🫶
Boundary nodes (ABR/ASBR) can be encoded using the IPv4 or IPv6 prefix subobjects, usually with a loopback address of 32 and a prefix length of 128, respectively. An inter-AS link can be encoded using the IPv4 or IPv6 prefix subobjects or unnumbered interface subobjects. So many options, I'm obsessed 😭
For Figure 1, say an ABR at 203.0.113.1 needs to be traversed. It can be specified in the IRO like this:
+---------+ +---------+ +---------++---------+ +---------+
|IRO | |Sub- | |Sub- ||Sub- | |Sub- |
|Object | |object | |object ||object | |object |
|Header | |Area 2 | |IPv4 ||Area 0 | |Area 4 |
| | | | |203.0. || | | |
| | | | |113.1 || | | |
+---------+ +---------+ +---------++---------+ +---------+For Figure 3, say an inter-AS link (198.51.100.1 - 198.51.100.2) needs to be traversed. It can be specified as:
+---------+ +---------+ +---------+ +---------+
|IRO | |Sub- | |Sub- | |Sub- |
|Object | |object AS| |object | |object AS|
|Header | |100 | |IPv4 | |200 |
| | | | |198.51. | | |
| | | | |100.2 | | |
+---------+ +---------+ +---------+ +---------+4.4. PCE Serving Multiple Domains 🧚
One single PCE can be responsible for multiple domains 💖 For example, a PCE function deployed on an ABR could be responsible for multiple areas. A PCE that can support adjacent domains can handle those domains internally inside the domain sequence, and that doesn't affect the other domains in the domain sequence at all ✨
4.5. P2MP 🌈
[RFC7334] describes an experimental inter-domain P2MP path computation mechanism, where the path domain tree is described as a series of domain sequences. Here's an example in the figure below 👀
+----------------+
| |Domain D1
| R |
| |
| A |
| |
+-B------------C-+
/ \
/ \
/ \
Domain D2 / \ Domain D3
+-------------D--+ +-----E----------+
| | | |
| F | | |
| G | | H |
| | | |
| | | |
+-I--------------+ +-J------------K-+
/\ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ Domain D4 \ Domain D5 / Domain D6 \
+-L-------------W+ +------P---------+ +-----------T----+
| | | | | |
| | | Q | | U |
| M O | | S | | |
| | | | | V |
| N | | R | | |
+----------------+ +----------------+ +----------------+
Figure 4: Domain Tree ExampleThe domain tree can be written out as a series of domain sequences:
- Domain D1, Domain D3, Domain D6
- Domain D1, Domain D3, Domain D5
- Domain D1, Domain D2, Domain D4
The domain sequence handling described in this document could be applied to the P2MP path domain tree 🍓
4.6. Hierarchical PCE 👑
In the case of H-PCE [RFC6805], the parent PCE can be asked to figure out the domain sequence and send it back in the path computation reply, using the ERO. For the example in Section 4.6 of [RFC6805], the domain sequence can possibly look like this:
+---------+ +---------+ +---------+ +---------+
|ERO | |Sub- | |Sub- | |Sub- |
|Object | |object | |object | |object |
|Header | |Domain 1 | |Domain 2 | |Domain 3 |
| | | | | | | |
| | | | | | | |
+---------+ +---------+ +---------+ +---------+or
+---------+ +---------+ +---------+
|ERO | |Sub- | |Sub- |
|Object | |object | |object |
|Header | |BN 21 | |Domain 3 |
| | | | | |
| | | | | |
+---------+ +---------+ +---------+5. Other Considerations 💅
5.1. Relationship to PCE Sequence 🦋
Instead of a domain sequence, a sequence of PCEs MAY be enforced by policy on the PCC 🫶 This constraint can be carried in the PCReq message (as defined in [RFC5886]).
Note that PCE Sequence can be used along with domain sequence. When both are in play, PCE Sequence MUST have higher precedence in selecting the next PCE in the inter-domain path computation procedures ⭐
5.2. Relationship to RSVP-TE 🌸
[RFC3209] already describes the notion of abstract nodes, where an abstract node is a group of nodes whose internal topology is opaque to the ingress node of the LSP. It also defines a subobject for AS, but with a 2-byte AS number.
[RFC7898] extends the notion of abstract nodes by adding new subobjects for IGP areas and 4-byte AS numbers. These subobjects can be included in ERO, XRO, or EXRS in RSVP-TE 🧚
In any case, the subobject types defined in RSVP-TE are identical to the subobject types defined in the related documents in PCEP 💖
6. IANA Considerations 🌈
6.1. New Subobjects ✨
okay so IANA keeps the "Path Computation Element Protocol (PCEP) Numbers" registry at http://www.iana.org/assignments/pcep 🎀, and inside it there are two sub-registries, bestie 💅
- IRO Subobjects
- XRO Subobjects
IANA made the exact same additions to both of them. Here's the lineup 🦋
Value Description Reference
----- ---------------- -------------------
5 4-byte AS number RFC 7897, [RFC7898]
6 OSPF Area ID RFC 7897, [RFC7898]
7 IS-IS Area ID RFC 7897, [RFC7898]Also, IANA added a reference to this document next to the new RSVP numbers that [RFC7898] registered, which you can check on http://www.iana.org/assignments/rsvp-parameters 🌸
7. Security Considerations 🔐
ngl this is the part to read carefully 🫶 The protocol extensions in this document don't really change what PCEP is, so the security considerations in [RFC5440] apply unchanged. There are also more security notes for running PCEP over TCP in [RFC6952] 💜
This document defines a way to represent the domain sequence and some new subobjects, which can be used in inter-domain PCE setups like the ones explained in [RFC5152], [RFC5441], [RFC6805], [RFC7334], etc. Each of those mechanisms keeps its own security considerations, and the new subobjects and domain sequence representation here don't change any of them 🧚
But here's the spicy bit 🌶️ The new subobjects give much finer, more specific control over the path that a cooperating PCE (or PCEs) computes. That control raises the risk if a PCEP message is intercepted, modified, or spoofed, because an attacker could take control of the path the PCE computes, or make the path computation impossible 😭 So it's really important that implementations follow the relevant security requirements in [RFC5440]. Those mechanisms include:
- Securing the PCEP session messages using TCP security techniques (Section 10.2 of [RFC5440]). PCEP implementations SHOULD also consider the additional security provided by the TCP Authentication Option (TCP-AO) [RFC5925] or Transport Layer Security (TLS) [PCEPS].
- Authenticating the PCEP messages to ensure the messages are intact and sent from an authorized node (Section 10.3 of [RFC5440]).
- PCEP operates over TCP, so it's also important to secure the PCE and PCC against TCP denial-of-service attacks. Section 10.7.1 of [RFC5440] outlines a number of mechanisms for minimizing the risk of TCP-based denial-of-service attacks against PCEs and PCCs.
- In inter-AS scenarios, attacks may be particularly significant, with commercial as well as service-level implications 💀
Also, the domain sequence mechanisms give the operator a way to route around vulnerable parts of the network, so they can be used to boost overall network security 🛡️✨
8. Manageability Considerations 🍓
8.1. Control of Function and Policy
The exact behavior for including and excluding domains MUST be available for an operator to examine, and it MAY be configurable 👑 Manual configuration is needed to figure out which PCEP peers understand the new domain subobjects defined in this document 🙈
8.2. Information and Data Models
A MIB module for managing PCEP is being specified in a separate document, [RFC7420] 📚 This document doesn't imply any new extension to the current MIB module, so no new MIB stuff here 💅
8.3. Liveness Detection and Monitoring
The mechanisms in this document don't add any new liveness detection and monitoring requirements beyond the ones already listed in [RFC5440] 🫶
8.4. Verify Correct Operations
The mechanisms in this document don't add any new operation verification requirements beyond the ones already listed in [RFC5440] ✅
8.5. Requirements on Other Protocols
For per-domain path computation [RFC5152], the full path of an inter-domain TE LSP can't be determined (or isn't determined) at the ingress node. In that case, a signaling message can use the domain identifiers 🧠 The subobjects defined in this document SHOULD be supported by RSVP-TE. [RFC7898] extends the idea of abstract nodes by adding new subobjects for IGP areas and 4-byte AS numbers 🎀
Apart from this, the mechanisms in this document don't imply any requirements on other protocols beyond the ones already listed in [RFC5440] 🦋
8.6. Impact on Network Operations
The mechanisms in this document can give the operator finer, more specific control over path computation by including or excluding domain subobjects 🎯 There may be some scaling benefit, because one domain subobject can stand in for many subobjects, which can shrink the overall message size and processing 📉✨
Backward compatibility issues with the new subobjects come up when a PCE doesn't recognize them. In that case, the PCE responds according to the rules for a malformed object as per [RFC5440] 😬 For successful operations, the PCEs in the network would need to be upgraded 💖
9. References 📖
9.1. Normative References
[ISO10589] International Organization for Standardization,
"Information technology -- Telecommunications and
information exchange between systems -- Intermediate
System to Intermediate System intra-domain routeing
information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode network
service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<http://www.rfc-editor.org/info/rfc3209>.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) Extensions", RFC 3473,
DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links
in Resource ReSerVation Protocol - Traffic Engineering
(RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003,
<http://www.rfc-editor.org/info/rfc3477>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<http://www.rfc-editor.org/info/rfc5440>.
[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,
DOI 10.17487/RFC5441, April 2009,
<http://www.rfc-editor.org/info/rfc5441>.
[RFC5521] Oki, E., Takeda, T., and A. Farrel, "Extensions to the
Path Computation Element Communication Protocol (PCEP) for
Route Exclusions", RFC 5521, DOI 10.17487/RFC5521, April
2009, <http://www.rfc-editor.org/info/rfc5521>.
[RFC6805] King, D., Ed. and A. Farrel, Ed., "The Application of the
Path Computation Element Architecture to the Determination
of a Sequence of Domains in MPLS and GMPLS", RFC 6805,
DOI 10.17487/RFC6805, November 2012,
<http://www.rfc-editor.org/info/rfc6805>.
[RFC7896] Dhody, D., "Update to the Include Route Object (IRO)
Specification in the Path Computation Element
Communication Protocol (PCEP)", RFC 7896,
DOI 10.17487/RFC7896, June 2016,
<http://www.rfc-editor.org/info/rfc7896>.
[RFC7898] Dhody, D., Palle, U., Kondreddy, V., and R. Casellas,
"Domain Subobjects for Resource Reservation Protocol -
Traffic Engineering (RSVP-TE)", RFC 7898,
DOI 10.17487/RFC7898, June 2016,
<http://www.rfc-editor.org/info/rfc7898>.9.2. Informative References 📚
these are the bonus reads that round out the story 💅
- [PCEPS] Lopez, D., Dios, O., Wu, W., and D. Dhody, "Secure Transport for PCEP", Work in Progress, draft-ietf-pce-pceps-09, November 2015.
- [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006,
http://www.rfc-editor.org/info/rfc4655. - [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for Inter-Domain Multiprotocol Label Switching Traffic Engineering", RFC 4726, DOI 10.17487/RFC4726, November 2006,
http://www.rfc-editor.org/info/rfc4726. - [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI 10.17487/RFC4873, May 2007,
http://www.rfc-editor.org/info/rfc4873. - [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude Routes - Extension to Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, DOI 10.17487/RFC4874, April 2007,
http://www.rfc-editor.org/info/rfc4874. - [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, DOI 10.17487/RFC5152, February 2008,
http://www.rfc-editor.org/info/rfc5152. - [RFC5520] Bradford, R., Ed., Vasseur, JP., and A. Farrel, "Preserving Topology Confidentiality in Inter-Domain Path Computation Using a Path-Key-Based Mechanism", RFC 5520, DOI 10.17487/RFC5520, April 2009,
http://www.rfc-editor.org/info/rfc5520. - [RFC5886] Vasseur, JP., Ed., Le Roux, JL., and Y. Ikejiri, "A Set of Monitoring Tools for Path Computation Element (PCE)-Based Architecture", RFC 5886, DOI 10.17487/RFC5886, June 2010,
http://www.rfc-editor.org/info/rfc5886. - [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, DOI 10.17487/RFC5925, June 2010,
http://www.rfc-editor.org/info/rfc5925. - [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012,
http://www.rfc-editor.org/info/rfc6793. - [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
http://www.rfc-editor.org/info/rfc6952. - [RFC7334] Zhao, Q., Dhody, D., King, D., Ali, Z., and R. Casellas, "PCE-Based Computation Procedure to Compute Shortest Constrained Point-to-Multipoint (P2MP) Inter-Domain Traffic Engineering Label Switched Paths", RFC 7334, DOI 10.17487/RFC7334, August 2014,
http://www.rfc-editor.org/info/rfc7334. - [RFC7420] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, DOI 10.17487/RFC7420, December 2014,
http://www.rfc-editor.org/info/rfc7420.
Acknowledgments 🫶
okay the authors have to give a huge shoutout to Adrian Farrel, who gave super detailed reviews AND wrote text that ended up in the document. legend 👑
also massive thanks to Pradeep Shastry, Suresh Babu, Quintin Zhao, Fatai Zhang, Daniel King, Oscar Gonzalez, Chen Huaimo, Venugopal Reddy, Reeja Paul, Sandeep Boina, Avantika Sergio Belotti, and Jonathan Hardwick for their useful comments and suggestions 💖
thanks to Jonathan Hardwick for shepherding this document 🧚
thanks to Deborah Brungard for being the responsible AD 🌸
thanks to Amanda Baber for the IANA review 🎀
thanks to Joel Halpern for the Gen-ART review ✨
thanks to Klaas Wierenga for the SecDir review 🦋
and thanks to Spencer Dawkins and Barry Leiba for comments during the IESG review 🫶
Authors' Addresses 💌
the authors, where you can find them 🌈
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.com
Udayasree Palle
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: udayasree.palle@huawei.com
Ramon Casellas
CTTC
Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860
Spain
Email: ramon.casellas@cttc.es📦 where this page comes from
- ietf: rfc7897 2016-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms