RFC 5420

Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)

📅 published February 2009, from ietf

Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE) 🦋

Okay bestie, this is RFC 5420 💖. It's a Standards Track document from the Network Working Group, edited by A. Farrel (Old Dog Consulting), with D. Papadimitriou (Alcatel), JP. Vasseur (Cisco Systems, Inc.), and A. Ayyangar (Juniper Networks) as co-authors. It's dated February 2009, and it obsoletes RFC 4420 and updates RFC 3209 and RFC 3473 🎀.

Status of This Memo ✨

This document specifies an Internet standards track protocol for the Internet community, and it asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌸.

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date this document was published. Please read these documents carefully, because they explain your rights and restrictions with respect to this document 📜.

Abstract 🧚

MPLS Label Switched Paths (LSPs) can be established using the RSVP-TE extensions, which are Resource Reservation Protocol Traffic Engineering. This protocol includes an object called the SESSION_ATTRIBUTE object, and it carries a Flags field used to indicate options and attributes of the LSP. That Flags field has eight bits, so it can set eight options. Lots of recent proposals in many documents that extend RSVP-TE want to use each of the bits that were never used before 👀.

This document defines a new object for RSVP-TE messages. It lets you signal more attribute bits, and it also lets you carry arbitrary attribute parameters, which makes RSVP-TE 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 in this document are equally applicable to Generalized MPLS (GMPLS) Packet Switch Capable (PSC) LSPs and to GMPLS non-PSC LSPs 💜.

This document replaces and obsoletes the previous version of this work, which was published as RFC 4420. The only change is in the encoding of the Type-Length-Variable (TLV) data structures 🦋.

Table of Contents 📚

1. Introduction and Problem Statement ..............................4
   1.1. Applicability to Generalized MPLS ..........................5
   1.2. A Rejected Alternate Solution ..............................5
2. Terminology .....................................................6
3. Attributes TLVs .................................................6
   3.1. Attribute Flags TLV ........................................7
4. LSP_ATTRIBUTES Object ...........................................8
   4.1. Format .....................................................9
   4.2. Generic Processing Rules for Path Messages .................9
   4.3. Generic Processing Rules for Resv Messages .................9
5. LSP_REQUIRED_ATTRIBUTES Object .................................10
   5.1. Format ....................................................11
   5.2. Generic Processing Rules ..................................11
6. Inheritance Rules ..............................................11
7. Recording Attributes Per LSP ...................................12
   7.1. Requirements ..............................................12
   7.2. RRO Attributes Subobject ..................................12
   7.3. Procedures ................................................13
        7.3.1. Subobject Presence Rules ...........................13
        7.3.2. Reporting Compliance with LSP Attributes ...........14
        7.3.3. Reporting Per-Hop Attributes .......................14
        7.3.4. Default Behavior ...................................14
8. Summary of Attribute Bit Allocation ............................14
9. Message Formats ................................................15
10. Guidance for Key Application Scenarios ........................16
    10.1. Communicating to Egress LSRs .............................16
    10.2. Communicating to Key Transit LSRs ........................17
    10.3. Communicating to All LSRs ................................17
11. IANA Considerations ...........................................17
    11.1. New RSVP C-Nums and C-Types ..............................17
    11.2. New TLV Space ............................................18
    11.3. Attribute Flags ..........................................19
    11.4. New Error Codes ..........................................19
    11.5. New Record Route Subobject Identifier ....................19
12. Security Considerations .......................................20
13. Acknowledgements ..............................................20
14. Changes from RFC 4420 to RFC 5420 .............................20
15. Normative References ..........................................21
16. Informative References ........................................21

1. Introduction and Problem Statement ✨

This document replaces and obsoletes the previous version of this work, which was published as RFC 4420 [RFC4420]. The only change is in the encoding of the Type-Length-Variable (TLV) data structures presented in Section 3. See Section 14 for a summary of changes 💖.

Traffic-Engineered Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) [RFC3031] can be set up using the Path message of the RSVP-TE signaling protocol [RFC3209]. The Path message includes the SESSION_ATTRIBUTE object, which carries a Flags field used to indicate desired options and attributes of the LSP 🎀.

The Flags field in the SESSION_ATTRIBUTE object has eight bits. Only three of those bits are assigned in [RFC3209]. Then [RFC4090] assigns two more bits for fast re-reroute functionality, which leaves only three bits available 😭. Several recent proposals and Internet Drafts have shown that there's a high demand for the other three bits. Some, if not all, of those proposals are likely to go forward as RFCs. That means the Flags field could be depleted or nearly depleted, which makes it hard to signal new options and attributes that get developed in the future 💀.

This document defines a new object for RSVP-TE messages that allows the signaling of further attributes bits. The new object is built from TLVs, and a new TLV is defined to carry a variable number of attributes bits 🦋.

The new RSVP-TE message object is super flexible because it uses the TLV format, and it allows:

  • future specification of bit flags
  • additional options and attribute parameters carried in TLV format

Note that the LSP Attributes defined in this document are specifically scoped to an LSP. They may be set differently on separate LSPs with the same Tunnel ID between the same source and destination (that is, within the same session) 🌈.

Some options and attributes don't need to be acted on by all Label Switched Routers (LSRs) along the path of the LSP. In particular, these options and attributes may apply only to key LSRs on the path, such as the ingress LSR and egress LSR. Special transit LSRs, such as Area or Autonomous System Border Routers (ABRs or ASBRs), may also fall into this category. This means that the new options and attributes should be signaled transparently, and only examined at the points that need to act on them 🫶.

On the other hand, other options and attributes may require action at all transit LSRs along the path of the LSP. If one of those transit LSRs can't support the required attributes, the LSR may have to refuse the establishment of the LSP 🙈.

These considerations matter a lot for backward compatibility. In general, it should be possible to provide new MPLS services across a legacy network without upgrading the LSRs that don't need to actively take part in the new services. Also, some features only need action on specific intermediate hops, not on every visited LSR 🍓.

Note that options already specified for the SESSION_ATTRIBUTE object in preexisting RFCs are not migrated to the new mechanisms described in this document.

RSVP has a way for unrecognized objects to be transparently forwarded by transit nodes. They don't refuse the incoming protocol messages, and the objects don't get stripped from the outgoing protocol message (see [RFC2205], Section 3.10). This capability extends to RSVP-TE, and it's a great way to make sure only the LSRs that understand a particular object examine it 👑.

This document distinguishes between options and attributes that are only required at key LSRs along the path of the LSP, and those that must be acted on by every LSR along the LSP. Two LSP Attributes objects are defined in this document. Using the C-Num definition rules inherited from [RFC2205], the first one is passed transparently by LSRs that don't recognize it. The second one causes LSP setup failure, with the generation of a PathErr message with an appropriate Error Code, if an LSR doesn't recognize it 🔥.

1.1. Applicability to Generalized MPLS

The RSVP-TE signaling protocol also forms the basis of a signaling protocol for Generalized MPLS (GMPLS), as described in [RFC3471] and [RFC3473]. The extensions in this document are equally applicable to MPLS and GMPLS ✨.

1.2. A Rejected Alternate Solution

One alternate solution was considered and rejected. It was to define a new C-Type for the existing SESSION_ATTRIBUTE object. That new C-Type could allow a larger Flags field and fix the immediate problem 🙃.

This solution was rejected because:

  • A new C-Type is not backward compatible with deployed implementations that expect to see a C-Type of 1 or 7. It's important that any solution can carry new attributes transparently across legacy LSRs if those LSRs aren't required to act on the attributes 😤.
  • Supporting arbitrary attribute parameters through TLVs would have meant a significant change of substance 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 so the attributes in the new objects from this doc all live inside TLVs (Type-Length-Value bundles) 💖 Each object can hold one or more TLVs, and there are no ordering rules for them, so nobody should read anything into the order they show up in 🫶

Here's what a TLV looks like:

    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 🧚

The identifier of the TLV.

Length 📏

This tells you the total length of the TLV in octets. So it's the Type, Length, and Value fields all added up, which is four plus the length of the Value field in octets.

The whole TLV MUST be padded with between zero and three trailing zeros so it lines up on a four-octet boundary. The Length field doesn't count that padding, so don't include it 🙈

Value 🎀

The data the TLV is actually carrying.

3.1. Attribute Flags TLV 🦋

Only one TLV type value is defined in this document. Type 1 is the Attribute Flags TLV. Other TLV types might get defined later, with their type values handed out by IANA (see Section 11.2).

The Attribute Flags TLV can show up in an LSP_ATTRIBUTES object, an LSP_REQUIRED_ATTRIBUTES object, or both (those are defined in Sections 4 and 5 🌸). The bits mean the same thing no matter which object is carrying the TLV. Any document that defines an individual bit MUST say whether that bit may be set in one object, the other, or both. Nobody's expecting a bit to be set in both objects on the same Path message at the same time, but this document doesn't rule it out either 👀

The Attribute Flags TLV Value field is an array of 32-flag units, numbered from the most significant bit as bit zero. Because of that, the Length for this TLV is always a multiple of four bytes, no matter how many bits it carries, so it never needs padding 💅

Unassigned bits count as reserved and MUST be set to zero when the originator sends the object. Any bits that aren't in the TLV MUST be assumed to be zero. And if the TLV is missing, either because it isn't in the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object or because those objects aren't there at all, then all processing MUST be done as though the bits were present and set to zero. In other words, assigned bits that aren't present, whether because the TLV got deliberately cut short or because it just wasn't included, MUST be treated as though they're present and set to zero 🫠

No bits are defined in this document. IANA manages bit assignments (see Section 11.3) 🍓

4. LSP_ATTRIBUTES Object 🌈

The LSP_ATTRIBUTES object is how you signal attributes needed to support an LSP, or how you indicate what an LSP is for or what it's used for, in cases where not every transit LSR has to act on that info 🧚 The main point is that if an LSR doesn't support this object, it just forwards it unexamined and unchanged. That's what makes it possible to swap attributes across legacy networks that don't know about this new object at all 🫶

This object basically extends the Flags field in the SESSION_ATTRIBUTE object, and it leaves room for fancier objects in the future through TLVs. It's giving future-proof 🔥

Heads up: some functions might need an LSR to look at both the SESSION_ATTRIBUTE object and the LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. Keep that in mind 👀

The LSP_ATTRIBUTES object can also be used to report LSP operational state on a Resv message, even when the matching Path message didn't carry an LSP_ATTRIBUTES or LSP_REQUIRED_ATTRIBUTES object. LSRs that support the object are the ones who add or update it. LSRs that don't understand it, or have nothing to report, don't add it. They just forward it unchanged on the Resv messages they generate 🦋

The LSP_ATTRIBUTES object class is 197, in the form 11bbbbbb. This C-Num value (see [RFC2205], Section 3.10) makes sure LSRs that don't recognize the object pass it along transparently 💜

One C-Type is defined: C-Type = 1, for LSP Attributes.

This object is optional. It may go on Path messages to share extra info about the attributes the LSP wants, and 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 the way Section 3 describes 💖

4.2. Generic Processing Rules for Path Messages 🌸

An LSR that doesn't support this object is required to pass it on unaltered, going by the C-Num and the rules in [RFC2205] 🫶

An LSR that does support this object but doesn't recognize a TLV type code in it MUST pass that TLV on unaltered, inside the LSP_ATTRIBUTES object it puts in the Path message it sends downstream 🧚

An LSR that supports this object and recognizes a TLV, but doesn't support the attribute that TLV defines, MUST act as specified in the document that defines the TLV 🦋

An LSR that supports the Attribute Flags TLV but doesn't recognize a set bit in it MUST forward the TLV unchanged 🍓

An LSR that supports the Attribute Flags TLV and recognizes a set bit, but doesn't support the attribute that bit indicates, 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 the operational status of an LSP can put this object in a Resv message, or update the one already sitting in a Resv message ✨

Quick note: this usage reports the state of the whole LSP, not the state at one individual LSR. That per-LSR job is done with the LSP Attributes subobject of the Record Route object (RRO), which Section 7 covers 👑

The bits in the Attributes TLV can be used to report operational status for the entire 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 can clear the bit as they forward the Resv message 🌈

Observe (👀) that LSRs that don't support the object, or don't support the function a particular bit in the Attributes TLV stands for, won't clear that bit when they forward the Resv. So you have to be careful defining how this object gets used on a Resv. How an individual bit in the Attributes TLV of the LSP_ATTRIBUTES object gets used 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, thanks to the C-Num 🫶

5. LSP_REQUIRED_ATTRIBUTES Object 🔥

The LSP_REQUIRED_ATTRIBUTES object signals attributes needed to support an LSP, or indicates the nature or use of an LSP, in cases where that info MUST be inspected at each transit LSR. So basically, every transit LSR MUST examine the attributes in this object and MUST NOT forward it without acting on its contents. Strict, but iconic 💀

This object also extends the Flags field in the SESSION_ATTRIBUTE object and leaves room for future complex objects through TLVs. It complements the LSP_ATTRIBUTES object 🦋

The LSP_REQUIRED_ATTRIBUTES object class is 67, in the form 0bbbbbbb. This C-Num value makes sure LSRs that 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, meaning they have to be examined 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. It may go on Path messages to share extra info about the attributes the LSP wants 🌸

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 the way Section 3 describes 💖

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, with the Error Code "Unknown Object Class" 🙅‍♀️

An LSR that doesn't recognize a TLV type code in this object MUST reject the Path message with a PathErr. The Error Code is "Unknown Attributes TLV", and the Error Value is set to the unknown TLV type code 💀

An LSR that doesn't recognize a bit set in the Attribute Flags TLV MUST reject the Path message with a PathErr. The Error Code is "Unknown Attributes Bit", and the Error Value is set to the bit number of the unknown bit in the Attribute 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 attribute 🌈

Note that this object isn't used on a Resv. If you want to report the status of an LSP, you have to use either the LSP_ATTRIBUTES object on a Resv or the Attributes subobject in the Record Route object (see Section 7). One or the other must be used 🫶

6. Inheritance Rules ✨

okay so this section is about when stuff gets passed down 🧚. sometimes when you hit an LSP region boundary, a forwarding adjacency LSP (FA-LSP; see [RFC4206]) gets set up first 🦋 so the LSP carrying the LSP_ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES objects can actually be established. in that case, if the boundary LSR supports LSP_ATTRIBUTES and LSP_REQUIRED_ATTRIBUTES processing, the FA-LSP MAY, upon local policy, inherit a subset of the Attributes TLVs. this is especially the case when the FA-LSP is in the same switching capability class as the LSP that triggered it 💅

when those conditions are met, the LSP_ATTRIBUTES and/or LSP_REQUIRED_ATTRIBUTES objects just get copied over, 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 are inheritable. no cap, if setting up the FA-LSP itself needs one or more Attributes TLVs, an 'OR' operation happens with the inherited set of values 🔥

documents that define individual bits for the LSP Attribute Flags TLV MUST specify whether or not those bits MAY be inherited, including the condition that has to be met for the inheritance to happen 👑. the exact same rule applies to any other TLV defined following 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 LSP's path 🕵️‍♀️. for example, an attribute might be requested in the LSP_ATTRIBUTES object, so LSRs that don't support the 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 to be reported 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 are likely to keep asking for more, so we need another way to report per-hop attributes 🍓

7.2. RRO Attributes Subobject

the RRO Attributes subobject can be carried in the RECORD_ROUTE object, if that object is present 🎀. it uses the standard format of an RRO subobject, so nothing wild there.

its length is variable, same as the Attribute Flags TLV 🦋. the content is the same as the Attribute Flags TLV, meaning it's a series of bit flags.

there's a one-to-one correspondence between the bits in the Attribute Flags TLV and the RRO Attributes subobject 💅. if a bit is only needed in one of the two places, it's reserved in the other place. see the procedures sections below for more info 🧚

    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

the Type is 0x05 🌸

Length

the Length is the total length of the subobject in bytes, including the Type and Length fields 📏. this length must be a multiple of four and must be at least eight.

Attribute Flags

the attribute flags recorded for that specific hop 🔥

7.3. Procedures

7.3.1. Subobject Presence Rules

as you'll see from [RFC3209], 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 pushes its IP address or link identifier. so if label recording is being used, 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 🙅‍♀️.

what this means is that an Attributes subobject is bound to the LSR identified by the subobject right before it in the RRO 🎀.

if 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 you find more than one Attributes subobject between a pair of subobjects that identify LSRs, only the first one you find (the one nearest the top of the stack) SHALL have any meaning within the context of this document 👑. all of those 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 Attribute 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 same bit in the Attributes subobject 🙈.

the requirement to report compliance MUST be specified in the document that defines the usage of any bit 📜. this basically boils down to whether hop-by-hop acknowledgement is required 💅.

7.3.3. Reporting Per-Hop Attributes

to report a per-hop attribute, an LSR sets the appropriate bit in the Attributes subobject 🦋.

the requirement to report a per-hop attribute MUST be specified in the document that defines the usage of the bit 💜.

7.3.4. Default Behavior

by default, all bits in an Attributes subobject SHOULD be set to zero 0️⃣.

if a received Attributes subobject isn't long enough to include a specific numbered bit, that bit MUST be treated as though it's present and as if it's 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 Attribute Flags TLV and the RRO Attributes subobject is identical. that means the same attribute is indicated by the same bit in both places, so only a single registry of bits gets maintained 🗂️. so clean, honestly 😭.

the consequence is a nice bit of clarity when it comes to implementation and registration ✨.

heads up, though: it's not always the case that a bit gets used in both the Attribute Flags TLV and the RRO Attributes subobject 👀. for example, an attribute might be requested using the Attribute 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 might be a requirement to report the attributes of an LSP hop-by-hop, with no matching request attribute 💀.

in those cases, a single bit number is still assigned for both the Attribute Flags TLV and the RRO Attributes subobject, even though the bit might be irrelevant in one of them 🤷‍♀️. the document that defines the usage of the new bit MUST state which places it's used in 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 too 🎀.

the order of objects in RSVP-TE messages is recommended, but implementations must be capable of receiving the objects in any meaningful order 🧠. so it's a vibe, not a rule, but everyone has to be able to handle whatever order shows up 🫶.

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 MUST be forwarded unchanged 🙃.

on a Resv message, the LSP_ATTRIBUTES object is placed in the flow descriptor and is associated with the FILTER_SPEC object that comes right 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 mentioned in the Introduction, requested LSP attributes might need to be acted on by only the egress LSR of the LSP, by certain key transit points (like ABRs and ASBRs), or by all LSRs along the LSP 🗺️. this section briefly walks through how each of those scenarios gets handled ✨. it's informational only and doesn't define any new procedures 📚.

10.1. Communicating to Egress LSRs

when you're communicating LSP attributes that only the LSP egress LSR should act on, the 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 onwards untouched) 🫶. that means the Path message won't get rejected by LSRs that don't understand the object, so the requested LSP attributes are guaranteed to reach the egress LSR 💌.

attributes get set within the LSP_ATTRIBUTES object based on which LSP attributes are needed 🧩. each attribute is defined in some RFC and comes with a statement of what the expected behavior is 📖. that behavior covers whether the attribute must be acted on by any LSR that recognizes it, or specifically by the egress LSR 🔍. so any attribute that only an egress LSR should act on is defined that way. a transit LSR that sees this attribute will either understand its semantics and ignore it (forwarding it unchanged), or won't 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 know whether the egress LSR 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 will report 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 omit 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 same way as egress LSRs 💅 the only plot twist is that the definition of the LSP attribute in the defining RFC will say the attribute must be acted on by these transit LSRs. so the rules don't change, the attribute's own spec just gets to make the call 🫶

10.3. Communicating to All LSRs 🌍

bestie, if you want to force EVERY LSR to look at the LSP attributes, you use the LSP_REQUIRED_ATTRIBUTES object 🔥 and its C-Num is set up so that any LSR that doesn't recognize the object must reject a received Path message containing it. no ghosting allowed 😭

an LSR that does recognize the LSP_REQUIRED_ATTRIBUTES object but doesn't recognize one of the attributes will reject the Path message too 💀 (rude, but fair)

and if an LSR recognizes an attribute but doesn't want to support it? it follows whatever the defining RFC says for that attribute 🎀 that could mean it just ignores the attribute and forwards it unchanged, or it might have to fail the LSP setup 😬 on top of that, the LSR may also be required to report whether it supports the attribute using the RRO Attributes subobject 📋

11. IANA Considerations 📝

the IANA allocations made for RFC 4420 [RFC4420] now apply to this document too, and they're listed here so nobody gets lost 🗺️

IANA has updated the registry entries created for RFC 4420 so they point to this document, which is now the normative reference for those entries ✨ this document doesn't make any other requests for IANA action, so that's the whole list, babe 💖

11.1. New RSVP C-Nums and C-Types 🎀

two new RSVP C-Nums are defined in this document, and IANA has assigned them 🥳

  • LSP_ATTRIBUTES object

the C-Num (value 197) is of the form 11bbbbbb, so LSRs that don't recognize the object will ignore it but still forward it, unexamined and unmodified, in all messages that result from this message 🦋

one C-Type is defined for this object, and IANA has assigned it:

  • LSP Attributes TLVs

C-Type value 1.

  • LSP_REQUIRED_ATTRIBUTES object

the C-Num (value 67) is of the form 0bbbbbbb, so LSRs that don't recognize the object will reject the message that carries it with an "Unknown Object Class" error 💀 very strict, very iconic 👑

one C-Type is defined for this object, and IANA has assigned it:

  • LSP Required Attributes TLVs

C-Type value 1.

11.2. New TLV Space 🧚

the two new objects we just talked about are built out of TLVs 🧱 each TLV has a 16-bit type identifier (the T-field), and the same T-field values work for BOTH objects ✨

IANA has created a new registry and will manage TLV type identifiers like this:

  • 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 = Attribute Flags TLV
  • allowed on LSP_ATTRIBUTES object
  • allowed on LSP_REQUIRED_ATTRIBUTES object

new TLV type values can only be allocated by an IETF Consensus action 🔒 not a vibe check, a real process 💅

11.3. Attribute Flags 🚩

this document gives out new attribute bit flags for other documents that define new RSVP-TE attributes 🌈 these flags live in the Attribute Flags TLV we just mentioned 🫶

IANA has created a new registry for the attribute bit flags, numbered in the usual IETF notation: starting at zero and going at least through 31 ✨

new bit numbers can only be allocated by 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 here's the big idea 🧠 every bit in the Attribute Flags TLV AND the RRO Attributes subobject uses the SAME bit number, even if it's only used in one of them or in both 🤯 that means you only need ONE list of bits to keep track of, which is so clean 🧼

(it would be meaningless in the context of this document for a bit to have no meaning in either the Attribute Flags TLV or the RRO Attributes subobject. no cap, that would be a total waste of a bit 💀)

11.4. New Error Codes 🚨

this document defines the following 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 🌸

a new subobject is defined for inclusion in 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 shows up in lots of RSVP messages 📬 it does not introduce any new direct security issues, so for those you should check out the security considerations in [RFC2205], [RFC3209], and [RFC3473] 🔍

now, a little side-eye moment 👀 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 to keep secret 😱 this document adds new objects for signaling the LSP attributes it wants, but it doesn't make that problem any worse 🫤 the only real fix for that is encrypting the content of the signaling message 🔒

similarly, adding attribute-recording info to the RRO could reveal details about the status of the LSP and the capabilities of individual LSRs, which operators might want to keep private 🙈 the same strategy used for other RRO subobjects also applies here 💅 BUT, heads up, there's a tension here ⚖️ telling the head end about the LSP status at transit LSRs can clash with hiding the existence or identity of those transit LSRs 🥺

13. Acknowledgements 💜

credit to the OSPF Working Group for the inspiration from their solution to a similar problem ✨ thanks to Rahul Aggarwal for his careful review and support of this work 🫶 thanks also to Raymond Zhang, Kireeti Kompella, Philip Matthews, Jim Gibson, and Alan Kullberg for their input 💖 as always, thanks to John Drake for the useful offline discussions 🍓 and thanks to Mike Shand for the Routing Directorate review and to Joel Halpern for the General Area review, since both of them caught some unclarities 👑

thanks to the OIF for noticing the discrepancy in RFC 4420 that this document fixes 🔧 and Alfred Hoenes caught several typographical errors 🙈

14. Changes from RFC 4420 to RFC 5420 🔄

this document obsoletes RFC 4420 [RFC4420] 🪦➡️✨ the only real change is in Section 3, which describes the semantics of the Length field of the Attributes TLV 📏

before the change, the Length field only covered the length of the Value field 🙃 after the change, as described in Section 3, the Length field covers the length of the WHOLE TLV 🎯 this makes the document consistent with the subobject format defined in [RFC3209] and the TLV format defined in [RFC3471] 🧩

the RFC Editor also made a bunch of editorial changes to improve the text and readability 💅 you can see them by comparing this document with [RFC4420] 👀

15. 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.

16. Informative References 🌷

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
           Label Switching Architecture", RFC 3031, January 2001.

[RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "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.

[RFC4420]  Farrel, A., Ed., Papadimitriou, D., Vasseur, J.-P., and A.
           Ayyangar, "Encoding of Attributes for Multiprotocol Label
           Switching (MPLS) Label Switched Path (LSP) Establishment
           Using Resource ReserVation Protocol-Traffic Engineering
           (RSVP-TE)", RFC 4420, February 2006.

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.net

that's the whole RFC, bestie!! 🌈✨🎀

📦 where this page comes from