RFC 4420
Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)
Okay bestie, let's get into RFC 4420 💖✨ It's a Standards Track doc from February 2006, from the Network Working Group. The main editor is A. Farrel (Ed.) of Old Dog Consulting 🐶, with D. Papadimitriou (Alcatel), J.-P. Vasseur (Cisco Systems, Inc.), and A. Ayyangar (Juniper Networks) helping write it 🫶. It updates [RFC3209] and [RFC3473], so it doesn't replace them. It just adds new stuff on top 🦋
Encoding of Attributes for Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) Establishment Using Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) 🎀
Status of This Memo 📜
This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💌 If you want to know where this protocol stands in terms of standardization, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍 Also, anyone can distribute this memo, no limits 🌸
Copyright Notice ©️
Copyright (C) The Internet Society (2006). 💅
Abstract 🌈
Okay so, Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) can be set up using the Resource Reservation Protocol Traffic Engineering (RSVP-TE) extensions ✨ One object here, the SESSION_ATTRIBUTE object, has a Flags field for signaling the options and attributes of the LSP. That Flags field only has eight bits, so only eight options can be set 😭 Lately, a bunch of documents extending RSVP-TE have wanted to use every one of the bits that nobody was using yet 💀
So this document makes a new object for RSVP-TE messages. It lets you signal more attribute bits, and it can carry arbitrary attribute parameters too. Basically RSVP-TE becomes super easy to extend for new requirements 🧚 It also defines a way to record the attributes applied to the LSP on a hop-by-hop basis 📝
The object mechanisms here work just as well for Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and for GMPLS non-PSC LSPs 🍓
Table of Contents 📑
1. Introduction and Problem Statement ..............................3
1.1. Applicability to Generalized MPLS ..........................4
1.2. A Rejected Alternate Solution ..............................4
2. Terminology .....................................................5
3. Attributes TLVs .................................................5
3.1. Attributes Flags TLV .......................................6
4. LSP_ATTRIBUTES Object ...........................................6
4.1. Format .....................................................7
4.2. Generic Processing Rules for Path Messages .................7
4.3. Generic Processing Rules for Resv Messages .................8
5. LSP_REQUIRED_ATTRIBUTES Object ..................................9
5.1. Format .....................................................9
5.2. Generic Processing Rules ...................................9
6. Inheritance Rules ..............................................10
7. Recording Attributes Per LSP ...................................11
7.1. Requirements ..............................................11
7.2. RRO Attributes Subobject ..................................11
7.3. Procedures ................................................12
7.3.1. Subobject Presence Rules ...........................12
7.3.2. Reporting Compliance with LSP Attributes ...........12
7.3.3. Reporting Per-Hop Attributes .......................13
7.3.4. Default Behavior ...................................13
8. Summary of Attribute Bit Allocation ............................13
9. Message Formats ................................................14
10. Guidance for Key Application Scenarios ........................14
10.1. Communicating to Egress LSRs .............................15
10.2. Communicating to Key Transit LSRs ........................15
10.3. Communicating to All LSRs ................................16
11. IANA Considerations ...........................................16
11.1. New RSVP C-Nums and C-Types ..............................16
11.2. New TLV Space ............................................17
11.3. Attributes Flags .........................................17
11.4. New Error Codes ..........................................18
11.5. New Record Route Subobject Identifier ....................18
12. Security Considerations .......................................18
13. Acknowledgements ..............................................19
14. Normative References ..........................................19
15. Informative References ........................................191. Introduction and Problem Statement ✨
RSVP-TE is how you set up Traffic-Engineered MPLS Label Switched Paths (LSPs) 🛤️ It's described in [RFC3031], and you use the Path message from the RSVP-TE signaling protocol [RFC3209] to do it. The Path message includes the SESSION_ATTRIBUTE object, and that object has a Flags field that says which options and attributes the LSP wants 🎯
Here's the drama: the Flags field in SESSION_ATTRIBUTE only has eight bits 😩 [RFC3209] only assigned three of them. Then [RFC4090] took two more for fast re-reroute, which leaves only three bits free. Lots of recent proposals and Internet Drafts want those last three, and it's giving high demand 🔥 Some (maybe all!) of those proposals will probably become RFCs, which means the Flags field is going to be full or almost full. Then it gets really hard to signal new options and attributes people come up with later 💀
So this document makes a new object for RSVP-TE messages that signals further attribute bits 💅 The new object is built out of TLVs, and there's a new TLV that carries a variable number of attribute bits 🧩
The new RSVP-TE message object is super flexible because it uses the TLV format. It allows:
- future specification of bit flags
- additional options and attribute parameters carried in TLV format.
Also, the LSP Attributes in this document are scoped to a single LSP 🎀 They can be set differently on separate LSPs that share the same Tunnel ID between the same source and destination (in other words, within the same session) 💜
Some options and attributes don't need every Label Switched Router (LSR) along the path to act on them 🙈 These might only matter for key LSRs on the path, like the ingress LSR and the egress LSR. Special transit LSRs, like Area or Autonomous System Border Routers (ABRs or ASBRs), can fall into this group too. So the new options and attributes should be signaled transparently, and only looked at by the places that actually need to act on them 🦋
Other options and attributes do need every transit LSR on the path to act on them ⭐ If one of those transit LSRs can't support a required attribute, it may have to refuse setting up the LSP 😬
Backward compatibility matters a ton here 🫶 In general, it should be possible to offer new MPLS services over a legacy network without upgrading the LSRs that don't need to take part in the new services. Some features also only need action on specific intermediate hops, not on every LSR the LSP visits 🧚
Heads up: options that are already specified for SESSION_ATTRIBUTE in older RFCs are not moved over to the new mechanisms in this document 🙅♀️
RSVP has a built-in way for transit nodes to transparently forward objects they don't recognize. They don't refuse the incoming protocol messages, and the objects don't get stripped from the outgoing message either (see [RFC2205], Section 3.10). That capability extends to RSVP-TE too, and it's a great way to make sure only the LSRs that understand a particular object actually look at it 👑
This document splits options and attributes into two groups: the ones only key LSRs need to act on, and the ones that every LSR on the LSP must act on 🌈 It defines two LSP Attributes objects. Using the C-Num definition rules inherited from [RFC2205], the first one is passed along transparently by LSRs that don't recognize it. The second one causes LSP setup to fail, with a PathErr message carrying an appropriate Error Code, if an LSR doesn't recognize it 💀
1.1. Applicability to Generalized MPLS 🌸
RSVP-TE is also the base for a signaling protocol for Generalized MPLS (GMPLS), as described in [RFC3471] and [RFC3473] 🍓 The extensions in this document apply equally to MPLS and GMPLS ✨
1.2. A Rejected Alternate Solution 🙅♀️
There was another idea: define a new C-Type for the existing SESSION_ATTRIBUTE object. That new C-Type could allow a bigger Flags field and fix the immediate problem 🤔
It got rejected, though, and here's why 👇
- A new C-Type isn't backward compatible with deployed implementations that expect to see a C-Type of
1or7. It's really important that any solution can carry new attributes transparently across legacy LSRs when those LSRs don't need to act on the attributes 🫶 - Supporting arbitrary attribute parameters through TLVs would have meant a big change to the existing object 😵
2. Terminology 📚
This document uses terminology from the MPLS architecture document [RFC3031] and from the RSVP-TE protocol specification [RFC3209], which inherits from the RSVP specification [RFC2205]. It also uses the Generalized MPLS RSVP-TE terminology introduced in [RFC3471] and [RFC3473] 🧠
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]. 💖
3. Attributes TLVs ✨
Okay bestie, so the attributes carried by the new objects in this doc get packed into TLVs 📦 One or more TLVs can live in each object. There are no ordering rules for TLVs, so don't read anything into the order they show up in 🙈
Every TLV is laid out 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type is the identifier of the TLV 🆔
Length is the length of the Value field in bytes. So if there's no Value field at all, Length is just zero 0️⃣ Each Value field must be zero padded at the end to take it up to a four byte boundary. The padding doesn't count toward the length, so a one byte value gets encoded in an eight byte TLV with the Length field set to one. Iconic math 🧮
Value is the data for the TLV, padded as described above 💖
3.1. Attributes Flags TLV
This document only defines one TLV type value: Type 1 is the Attributes Flags TLV 🦋 Other TLV types might be defined later, with type values assigned by IANA (see Section 11.2) 🌸
The Attributes Flags TLV can be present in an LSP_ATTRIBUTES object and/or an LSP_REQUIRED_ATTRIBUTES object, which we'll get to in Sections 4 and 5 ✨ The bits in the TLV mean the same attributes no matter which object is carrying it. Documents that define individual bits MUST specify whether the bit may be set in one object, the other, or both 🫶 It's not expected that a bit gets set in both objects on a single Path message at the same time, but this doc doesn't rule it out, so keep your eyes open 👀
The Attribute Flags TLV Value field is an array of units of 32 flags. The flags are numbered from the most significant bit, which is bit zero (very backwards, very iconic 🙃). Because of that, the Length field for this TLV is always a multiple of 4 bytes, no matter how many bits it carries, and no padding is needed 💅
Unassigned bits count as reserved and MUST be set to zero on transmission by the originator of the object 🚫 Bits not contained in the TLV MUST be assumed to be set to zero 🤍 If the TLV is absent, either because it isn't in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object or because those objects are themselves absent, all processing MUST be performed as though the bits were present and set to zero. That's the vibe ✨ Basically, assigned bits that aren't present, whether because the TLV is deliberately foreshortened or because it isn't included, MUST be treated as though they're present and set to zero 🧚
No bits are defined in this document. IANA manages the assignment of bits (see Section 11.3) 📋
4. LSP_ATTRIBUTES Object 🎀
The LSP_ATTRIBUTES object is used to signal attributes that are required in support of an LSP, or to indicate the nature or use of an LSP where that info doesn't have to be acted on by all transit LSRs 🌈 Specifically, if an LSR doesn't support the object, it forwards it unexamined and unchanged. This is what makes it possible to swap attributes across legacy networks that don't know this new object exists 🫶
This object basically extends the Flags field in the SESSION_ATTRIBUTE object, and it leaves room for more complex objects in the future through TLVs 🔥
Some functions might require an LSR to inspect both the SESSION_ATTRIBUTE object and the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. Noted, bestie 📝
The LSP_ATTRIBUTES object can also be used to report LSP operational state on a Resv, even when no LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object was carried on the corresponding Path message 👑 LSRs that support the object add or update it. LSRs that don't understand the object, or that have nothing to report, don't add it, and they forward it unchanged on the Resv messages they generate 🍓
The LSP_ATTRIBUTES object class is 197, of the form 11bbbbbb. This C-Num value (see [RFC2205], Section 3.10) makes sure that LSRs which don't recognize the object pass it on transparently 🦋
One C-Type is defined: C-Type = 1 for LSP Attributes 💜
This object is optional and may be placed on Path messages to convey additional information about the desired attributes of the LSP. It can also go on Resv messages to report operational state ⭐
4.1. Format
LSP_ATTRIBUTES class = 197, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Attributes TLVs are encoded as described in Section 3 🧁
4.2. Generic Processing Rules for Path Messages
An LSR that doesn't support this object is required to pass it on unaltered, as indicated by the C-Num and the rules defined in [RFC2205] 🫡
An LSR that does support this object, but doesn't recognize a TLV type code carried in it, MUST pass the TLV on unaltered in the LSP_ATTRIBUTES object it places in the Path message it sends downstream 🚀
An LSR that does support this object and recognizes a TLV, but doesn't support the attribute the TLV defines, MUST act as specified in the document that defines the TLV 📖
An LSR that supports the Attributes Flags TLV, but doesn't recognize a bit set in it, MUST forward the TLV unchanged 🔁
An LSR that supports the Attributes Flags TLV and recognizes a bit that's set, but doesn't support the indicated attribute, MUST act as specified in the document that defines the bit 🧠
4.3. Generic Processing Rules for Resv Messages
An LSR that wants to report operational status of an LSP may include this object in a Resv message, or update the object that's already carried in a Resv message 📣
Heads up: this usage reports the state of the entire LSP, not the state of the LSP at an individual LSR 👀 That second thing is handled using the LSP Attributes subobject of the Record Route object (RRO), as described in Section 7 🗺️
The bits in the Attributes TLV may be used to report operational status for the whole LSP. For example, an egress LSR might report a particular status by setting a bit 🏁 LSRs inside the network that figure out this status hasn't been achieved may clear the bit as they forward the Resv message 🧹
Observe that LSRs which don't support the object, or don't support the function a particular bit characterizes, won't clear the bit when they forward the Resv. So care must be taken in defining how this object gets used on a Resv 🙈 The usage of an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object on a Resv must be fully defined in the document that defines the bit 📚
Additional TLVs may also be defined to be carried in this object on a Resv ✨
An LSR that doesn't support this object will pass it on unaltered because of the C-Num 💖
5. LSP_REQUIRED_ATTRIBUTES Object 🔥
The LSP_REQUIRED_ATTRIBUTES object is used to signal attributes required in support of an LSP, or to indicate the nature or use of an LSP where that information MUST be inspected at each transit LSR 🚨 Specifically, each transit LSR MUST examine the attributes in the LSP_REQUIRED_ATTRIBUTES object and MUST NOT forward the object without acting on its contents. No skipping, periodt 💅
This object basically extends the Flags field in the SESSION_ATTRIBUTE object, and leaves room for more complex objects in the future through TLVs. It complements the LSP_ATTRIBUTES object 🫶
The LSP_REQUIRED_ATTRIBUTES object class is 67, of the form 0bbbbbbb. This C-Num value makes sure that LSRs which don't recognize the object reject the LSP setup, which basically means "we don't support the attributes you asked for" 🙅♀️ So this object SHOULD only be used for attributes that need support at some transit LSRs and therefore need examining at all transit LSRs 🎯 See Section 4 for how end-to-end and selective attributes get signaled 🧭
One C-Type is defined: C-Type = 1 for LSP Required Attributes 💜
This object is optional and may be placed on Path messages to convey additional information about the desired attributes of the LSP ⭐
5.1. Format
LSP_REQUIRED_ATTRIBUTES class = 67, C-Type = 1
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attributes TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Attributes TLVs are encoded as described in Section 3 🎀
5.2. Generic Processing Rules
An LSR that doesn't support this object will use a PathErr to reject the Path message based on the C-Num, using the Error Code "Unknown Object Class" 🚫
An LSR that doesn't recognize a TLV type code carried in this object MUST reject the Path message using a PathErr with Error Code "Unknown Attributes TLV", and Error Value set to the value of the unknown TLV type code 🙅♀️
An LSR that doesn't recognize a bit set in the Attributes Flags TLV MUST reject the Path message using a PathErr with Error Code "Unknown Attributes Bit", and Error Value set to the bit number of the unknown bit in the Attributes Flags 🛑
An LSR that recognizes an attribute (however it's encoded), but doesn't support that attribute, MUST act according to the behavior specified in the document that defines that specific attribute 🧩
Note that this object isn't used on a Resv. To report the status of an LSP, either the LSP_ATTRIBUTES object on a Resv or the Attributes subobject in the Record Route object (see Section 7) must be used 📊
6. Inheritance Rules ✨
okay so sometimes a triggering LSP hits an LSP region boundary, and the boundary LSR sets up a forwarding adjacency LSP (FA-LSP; see [RFC4206]) first 🦋. That FA-LSP exists so the LSP carrying the LSP_ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES objects can actually get established 💅. In that situation, if the boundary LSR supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY inherit a subset of the Attributes TLVs, depending on local policy 🎀. This is especially likely when the FA-LSP is in the same switching capability class as the triggering LSP 🌸.
When those conditions are met, the LSP_ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES objects are just copied, with the inherited Attributes TLVs, into the Path message used to set up the FA-LSP 🧚. By default (and to keep deployment simple 🙈), none of the incoming LSP Attributes TLVs count as inheritable. Also, if setting up the FA-LSP itself needs one or more Attributes TLVs, an 'OR' operation is done with the inherited set of values ✨.
Documents that define individual bits for the LSP Attributes Flags TLV MUST specify whether or not these bits MAY be inherited, including the condition that has to be met for that inheritance to happen 📜. The same goes for any other TLV defined under the rules in Section 3 💜.
7. Recording Attributes Per LSP
7.1. Requirements
Sometimes it's really useful to figure out which of the requested LSP attributes got applied at which LSRs along the path of the LSP 🔍. For example, an attribute might be requested in the LSP_ATTRIBUTES object, so LSRs that don't support that object aren't required to support the attribute or provide the requested function. In that case, the ingress LSR would love to know which LSRs acted on the request and which ones ignored it 👀.
There are also other qualities that need reporting on a hop-by-hop basis 🍓. Right now those are indicated in the Flags field of RRO subobjects. But there are only eight bits in that field, some are already taken, and new documents will probably keep asking for more, so we need another way to report per-hop attributes 😭🫶.
7.2. RRO Attributes Subobject
The RRO Attributes Subobject may be carried in the RECORD_ROUTE object if it's present 🎀. It uses the standard format of an RRO subobject 💖.
Its length is variable, just like the Attributes Flags TLV. The content is the same as the Attribute Flags TLV, meaning it's a series of bit flags 🌈.
Every bit in the Attributes Flags TLV has a one-to-one match with a bit in the RRO Attributes Subobject 🦋. If a bit is only needed in one of the two places, it's reserved in the other place. The procedures sections below have more detail ✨.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Attribute Flags //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
0x05 🍓
Length
The Length is the total length of the subobject in bytes, including the Type and Length fields 📏. It must be a multiple of 4 and must be at least 8 💅.
Attribute Flags
The attribute flags recorded for that specific hop 🔥.
7.3. Procedures
7.3.1. Subobject Presence Rules
As [RFC3209] makes clear, the RECORD_ROUTE object works like a "stack", with each LSR adding subobjects to the start of the object 🥞. The Attributes subobject gets pushed onto the RECORD_ROUTE object right before the node's IP address or link identifier gets pushed 💜. So if label recording is in use, the Attributes subobject SHOULD be pushed onto the RECORD_ROUTE object after the Record Label subobject(s) 🌸.
A node MUST NOT push an Attributes subobject onto the RECORD_ROUTE object without also pushing an IPv4, IPv6, or Unnumbered Interface ID subobject 🙅♀️.
That means an Attributes subobject is tied to the LSR identified by the subobject sitting right before it in the RRO 🔗.
If adding the new subobject makes the RRO too big to fit in a Path (or Resv) message, the processing MUST be as described in Section 4.4.3 of [RFC3209] 😬.
If more than one Attributes subobject shows up between a pair of subobjects that identify LSRs, only the first one found (the one nearest the top of the stack) SHALL have any meaning in the context of this document 👑. All of these subobjects MUST be forwarded unmodified by transit LSRs 🫶
7.3.2. Reporting Compliance with LSP Attributes
To report compliance with an attribute requested in the Attributes Flags TLV, an LSR MAY set the matching bit (see Section 8) in the Attributes subobject ✅. To report non-compliance, an LSR MAY clear that matching bit in the Attributes subobject ❌.
The document that defines how a bit gets used MUST specify the requirement to report compliance 📚. In practice this boils down to saying whether hop-by-hop acknowledgement is required 🧐.
7.3.3. Reporting Per-Hop Attributes
To report a per-hop attribute, an LSR sets the right bit in the Attributes subobject 🦋.
The document that defines the usage of the bit MUST specify the requirement to report a per-hop attribute 💅.
7.3.4. Default Behavior
By default, every bit in an Attributes subobject SHOULD be set to zero 0️⃣.
If a received Attribute subobject isn't long enough to include a specific numbered bit, that bit MUST be treated as though it's present and set to zero 🧠.
If the RRO subobject isn't present for a hop in the LSP, all bits MUST be assumed to be set to zero 🫠.
8. Summary of Attribute Bit Allocation
This document defines two uses of per-LSP attribute flag bit fields 🎀. The bit numbering in the Attributes Flags TLV and the RRO Attributes subobject is identical 💖. So the same attribute is indicated by the same bit in both places, which means only a single registry of bits gets maintained 📋.
The consequence is a nice bit of clarity for implementation and registration 🌷.
Heads up though, it's not always the case that a bit gets used in both the Attributes Flags TLV and the RRO Attributes subobject ⚠️. For example, an attribute might be requested using the Attributes Flags TLV, but there's no requirement to report how that attribute was handled on a hop-by-hop basis 🙃. The reverse can happen too: there may be a requirement to report an LSP's attributes hop by hop, with no matching request attribute 🔄.
In those cases, a single bit number still gets assigned for both the Attributes Flags TLV and the RRO Attributes subobject, even though the bit might be irrelevant in one of them 🤷♀️. The document that defines the new bit MUST state in which places it is used and MUST handle a default setting of zero 📝.
9. Message Formats
The LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object MAY be carried in a Path message 🛣️. The LSP_ATTRIBUTES object MAY be carried in a Resv message 🔙.
The order of objects in RSVP-TE messages is recommended 📋, but implementations must be capable of receiving the objects in any meaningful order 🫶.
On a Path message, the LSP_ATTRIBUTES object and LSP_REQUIRED_ATTRIBUTES objects are RECOMMENDED to be placed immediately after the SESSION_ATTRIBUTE object if it's present, or otherwise immediately after the LABEL_REQUEST object 💖.
If both the LSP_ATTRIBUTES object and the LSP_REQUIRED_ATTRIBUTES object are present, the LSP_REQUIRED_ATTRIBUTES object is RECOMMENDED to be placed first 🥇.
LSRs MUST be prepared to receive these objects in any order and in any position within a Path message 🧚. Subsequent instances of these objects within a Path message SHOULD be ignored, and those objects MUST be forwarded unchanged 🔁.
On a Resv message, the LSP_ATTRIBUTES object goes in the flow descriptor and is associated with the FILTER_SPEC object that comes before it 🌊. It is RECOMMENDED that the LSP_ATTRIBUTES object be placed immediately after the LABEL object 🏷️.
LSRs MUST be prepared to receive this object in any order and in any position within a Resv message, subject to the previous note 🎯. Only one instance of the LSP_ATTRIBUTES object is meaningful within the context of a FILTER_SPEC object 👑. Subsequent instances of the object SHOULD be ignored and MUST be forwarded unchanged 🫠.
10. Guidance for Key Application Scenarios
As the Introduction of this document explained, requested LSP attributes might need to be acted on by only the egress LSR of the LSP, by certain key transit points (such as ABRs and ASBRs), or by all LSRs along the LSP 🗺️. This section quickly describes how each of those scenarios gets met 💅. It's informational and doesn't define any new procedures 📖.
10.1. Communicating to Egress LSRs
When you're communicating LSP attributes that must be acted on only by the LSP egress LSR, those attributes should go in the LSP_ATTRIBUTES object 🎯. Because of its C-Num, transit LSRs that don't understand this object may ignore it (passing it onward, untouched) 🫶. That means the Path message won't be rejected by LSRs that don't understand the object 🙌. This way, the requested LSP attributes are guaranteed to reach the egress LSR 💖.
Attributes get set within the LSP_ATTRIBUTES object according to which LSP attributes are required 📋. Each attribute is defined in some RFC and comes with a statement of what the expected behavior is ✨. That behavior includes whether the attribute must be acted on by any LSR that recognizes it, or specifically by the egress LSR 👀. So any attribute that must be acted on only by an egress LSR will be defined that way. Any transit LSR that sees this attribute will either understand its semantics and ignore it (forwarding it, unchanged), or not understand the attribute and ignore it (forwarding it, unchanged), following the rules of the LSP_ATTRIBUTES object 🧠.
The remaining question is how the ingress LSR can tell whether the egress LSR has acted correctly on the required LSP attribute 🔎. Another part of the attribute's definition (in the defining RFC) says whether reporting is required 📜. If reporting is required, the egress LSR is required to use the RRO Attributes subobject to report whether it acted on the received attribute 📣.
If an egress LSR understands a received attribute as mandatory for an egress LSR, but doesn't want to satisfy the request, it will reject the Path message 🚫. If an egress LSR understands the attribute but believes it's optional and doesn't want to satisfy the request, it reports its non-compliance in the RRO Attributes subobject 🙅♀️. If the egress LSR doesn't understand the received attribute, it may report non-compliance in the RRO Attributes subobject explicitly, or it may leave out the RRO Attributes subobject, which implies it hasn't satisfied the request 🤔💀.
10.2. Communicating to Key Transit LSRs ✨
okay so key transit LSRs (think ABRs and ASBRs 🌸) get handled exactly the way egress LSRs do 💅. the only plot twist is that the defining RFC for the LSP attribute will say the attribute must be acted on by these transit LSRs 🦋
10.3. Communicating to All LSRs 🎀
bestie, if you want EVERY LSR to look at the LSP attributes, you use the LSP_REQUIRED_ATTRIBUTES object 👑 its C-Num is picked so that any LSR that doesn't recognize the object has to reject a received Path message that contains it 💀
an LSR that DOES recognize the LSP_REQUIRED_ATTRIBUTES object but doesn't recognize some attribute will reject the Path message. no mercy 😭
and if an LSR recognizes an attribute but doesn't want to support it, it just follows whatever the attribute's defining RFC says 🧚 that might let it ignore the attribute and forward it unchanged, or it might have to fail the LSP setup. the LSR may also be required to report whether it supports the attribute using the RRO Attributes subobject 🍓
11. IANA Considerations 💜
11.1. New RSVP C-Nums and C-Types 🌈
two brand new RSVP C-Nums come with this document, and IANA has already assigned them 🥰
o LSP_ATTRIBUTES object
the C-Num is value 197, written in the form 11bbbbbb. the vibe here: LSRs that don't recognize the object just ignore it, but forward it along, unexamined and unmodified, in every message that results from this message 🦋
one C-Type is defined for this object, and IANA has assigned it too:
- LSP Attributes TLVs: Recommended C-Type value 1.
o LSP_REQUIRED_ATTRIBUTES object
the C-Num is value 67, written in the form 0bbbbbbb. this one is the strict one 😤 LSRs that don't recognize it will reject the message carrying it with an "Unknown Object Class" error 💀
one C-Type is defined for this object, assigned by IANA:
- LSP Required Attributes TLVs: Recommended C-Type value 1.
11.2. New TLV Space 🧚
both of those new objects are built out of TLVs. each TLV starts with a 16-bit type identifier (the T-field), and the same T-field values work for both objects ✨
IANA has created a new registry to manage TLV type identifiers, with these columns:
- TLV Type (T-field value)
- TLV Name
- Whether allowed on LSP_ATTRIBUTES object
- Whether allowed on LSP_REQUIRED_ATTRIBUTES object.
this document defines one TLV type:
- TLV Type = 1
- TLV Name = Attributes Flags TLV
- allowed on LSP_ATTRIBUTES object
- allowed on LSP_REQUIRED_ATTRIBUTES object.
new TLV type values can only be allocated through an IETF Consensus action 🔒
11.3. Attributes Flags 🌸
this document hands out new attribute bit flags for other documents that define new RSVP-TE attributes 💖 the flags live in the Attributes Flags TLV from the previous section.
IANA has created another new registry to manage the attribute bit flags. they're numbered in the usual IETF way, starting at zero and going at least through 31 🎀
new bit numbers can only be allocated through an IETF Consensus action 🔒
each bit should be tracked with these qualities:
- Bit number
- Defining RFC
- Name of bit
- Whether there is meaning in the Attribute Flags TLV on a Path
- Whether there is meaning in the Attribute Flags TLV on a Resv
- Whether there is meaning in the RRO Attributes Subobject.
so basically, a bit uses the same bit number in the Attribute Flags TLV and the RRO Attributes Subobject, no matter where it's used. that means you only need one list of bits to maintain 🙌 (and it would be meaningless for a bit to have no meaning in either the Attribute Flags TLV or the RRO Attributes Subobject, so that's not a thing 🙈)
11.4. New Error Codes 💀
this document defines these new Error Codes and Error Values. IANA has assigned the numeric values:
Error Code Error Value
29 "Unknown Attributes TLV" Identifies the unknown TLV type code.
30 "Unknown Attributes Bit" Identifies the unknown Attribute Bit.11.5. New Record Route Subobject Identifier 🦋
there's a new subobject for the RECORD_ROUTE object 🧚
the RRO Attributes subobject is identified by a Type value of 5 ✨
12. Security Considerations 🔐
this document adds two new objects to the RSVP Path message (as used in MPLS and GMPLS signaling) and a new subobject to the RECORD_ROUTE object, which rides along on lots of RSVP messages. it doesn't introduce any new direct security issues on its own 🫶 if you want the full security story, check out the security considerations in [RFC2205], [RFC3209], and [RFC3473].
it's a passing note, but it matters 😭 any signaling request that shows the functional preferences or attributes of an MPLS LSP might give anyone unauthorized access to the message contents, including info about the LSP that an administrator would want kept secret. this document adds new objects for signaling desired LSP attributes, but it doesn't make that problem any worse. the only real fix for that is encrypting the content of the signaling message 🔐
same deal with recording attributes in the RRO. adding attribute recording info might reveal the status of the LSP and the capabilities of individual LSRs, and operators might want to keep that quiet 🙈 the same strategy that works for other RRO subobjects works here too. but heads up: there's a real tension between telling the head end about LSP status at transit LSRs and hiding the existence or identity of those transit LSRs 🌈
13. Acknowledgements 💖
big thank-you to the OSPF Working Group for the inspiration from their solution to a similar problem 🫶 thanks to Rahul Aggarwal for a careful review and for backing this work ✨ also huge thanks to Raymond Zhang, Kireeti Kompella, Philip Matthews, Jim Gibson, and Alan Kullberg for their input 💜 as always, John Drake gets a shoutout for useful offline discussions 🎀 and thanks to Mike Shand for the Routing Directorate review and to Joel Halpern for the General Area review. both of them caught some unclear bits 👑
14. Normative References 📚
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S., and
S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205, September
1997.
[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.
[RFC3471] Berger, L. (Ed.), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003.
[RFC3473] Berger, L. (Ed.), "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.15. Informative References 🧚
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
[RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005.Authors' Addresses 💌
Adrian Farrel
Old Dog Consulting
Phone: +44 (0) 1978 860944
EMail: adrian@olddog.co.uk
Dimitri Papadimitriou
Alcatel
Fr. Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
EMail: dimitri.papadimitriou@alcatel.be
Jean Philippe Vasseur
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA - 01719
USA
EMail: jpv@cisco.com
Arthi Ayyangar
Juniper Networks, Inc.
1194 N.Mathilda Ave
Sunnyvale, CA 94089
USA
EMail: arthi@juniper.netFull Copyright Statement ©️
copyright (C) The Internet Society (2006) 💜
this document is subject to the rights, licenses and restrictions in BCP 78. except as set forth there, the authors keep all their rights 🫶
this document and the information in it 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 the technology in this document, or on whether any license under those rights might be available. it also doesn't claim to have made any independent effort to find those rights. info about the procedures for rights in RFC documents is in BCP 78 and BCP 79 📚
copies of IPR disclosures sent to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr.
the IETF invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info 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: rfc4420 2006-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms