RFC 6780
RSVP ASSOCIATION Object Extensions
RFC 6780: RSVP ASSOCIATION Object Extensions 🎀
Part 1 of 4 🦋
Okay so this is RFC 6780 from the IETF (Internet Engineering Task Force), and it's all about RSVP ASSOCIATION Object Extensions 💖 Here's the title-block tea:
- Authors: L. Berger (LabN), F. Le Faucheur, and A. Narayanan (Cisco) 🧚
- Category: Standards Track 💜
- Date: October 2012 🍓
- ISSN: 2070-1721 ✨
- Updates: RFC 2205, RFC 3209, RFC 3473, and RFC 4872 🔥
- Obsoletes: none listed 🙈
Abstract ✨
Bestie, the RSVP ASSOCIATION object was first defined for GMPLS-controlled Label Switched Paths (LSPs) 🛤️ In that setting, it links recovery LSPs to the LSP they're protecting, which is so iconic. But it's giving way more potential than that, because it can also be a general way to associate RSVP state 🌈
This document explains how the ASSOCIATION object can be applied more broadly, and it defines Extended ASSOCIATION objects that are especially handy for the MPLS Transport Profile (MPLS-TP) 💅 It updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the Association ID field that RFC 4872 defined 🫶
Status of This Memo 📋
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 5741 🦋
For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc6780 💜
Copyright Notice ⚖️
Copyright (c) 2012 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 🌸
Table of Contents 🗺️
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................4
2. Generalized Association ID Field Definition .....................4
3. Non-GMPLS and Non-Recovery Usage ................................4
3.1. Upstream Initiated Association .............................5
3.1.1. Path Message Format .................................5
3.1.2. Path Message Processing .............................6
3.2. Downstream Initiated Association ...........................7
3.2.1. Resv Message Format .................................8
3.2.2. Resv Message Processing .............................8
3.3. Association Types ..........................................9
3.3.1. Resource Sharing Association Type ...................9
3.3.2. Unknown Association Types ..........................10
4. IPv4 and IPv6 Extended ASSOCIATION Objects .....................10
4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format ..........11
4.2. Processing ................................................13
5. Compatibility ..................................................14
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. IPv4 and IPv6 Extended ASSOCIATION Objects ................15
7.2. Resource Sharing Association Type .........................15
8. Acknowledgments ................................................16
9. References .....................................................16
9.1. Normative References ......................................16
9.2. Informative References ....................................161. Introduction 🌟
Okay so End-to-end and segment recovery are defined for GMPLS-controlled Label Switched Paths (LSPs) in [RFC4872] and [RFC4873], respectively 🛤️ Both definitions use the ASSOCIATION object to link recovery LSPs with the LSP they're protecting. If you want more narrative on how these associations get identified, check out [RFC6689] 📚
This document expands the ways you can use the ASSOCIATION object, going beyond non-GMPLS and non-recovery contexts 🦋 The expanded usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP RSVP sessions [RFC2205] [RFC2207] [RFC3175] [RFC4860]. It also looks at how associations should be made when the object is carried in a Path message, and it defines usage with Resv messages too. This section also talks about using the ASSOCIATION object outside of GMPLS LSPs 💅
Here are some examples of non-LSP association being used to enable resource sharing:
- Voice Call-Waiting: 📞
A bidirectional voice call between two endpoints, A and B, is signaled using two separate unidirectional RSVP reservations, one for the flows A->B and one for B->A. If endpoint A wants to put the A-B call on hold and join a separate A-C call, it's desirable that network resources on common links get shared between the A-B and A-C calls. The B->A and C->A subflows of the call can share resources using existing RSVP sharing mechanisms, but only if they use the same destination IP addresses and ports. By definition, the RSVP reservations for the subflows A->B and A->C of the call must have different IP addresses in the SESSION objects. So this document defines a brand-new mechanism to associate the subflows and let them share resources 🫶
- Voice Shared Line: ☎️
A voice shared line is a single number that rings multiple endpoints (which may be geographically diverse), like the phone lines on a manager's desk and their assistant's desk. A Voice over IP (VoIP) system that models these calls as multiple point-to-point unicast pre-ring reservations would end up significantly over-counting bandwidth on shared links, because RSVP unicast reservations to different endpoints cannot share bandwidth. So a new mechanism is defined in this document to let separate unicast reservations be associated and share resources 🍓
- Symmetric NAT: 🌐
RSVP permits sharing of resources between multiple flows addressed to the same destination D, even when they come from different senders S1 and S2. However, if D is behind a NAT operating in symmetric mode [RFC5389], the destination port of the flows S1->D and S2->D may be different outside the NAT. In that case, these flows can't share resources using RSVP, because the SESSION objects for these two flows outside the NAT have different destination ports 😭 This document defines a new mechanism to associate these flows and allow them to share resources ✨
In order to support the wider usage of the ASSOCIATION object, this document generalizes the definition of the Association ID field that RFC 4872 defined. This generalization has no impact on existing implementations 🌸 When you use the procedures defined below, association is identified based on exact ASSOCIATION object matching. Some of the other matching mechanisms defined in RFC 4872, for example matching based on Session IDs, are not generalized. This document allows for association type-specific processing, but it doesn't specify any 🧚
This document also defines the Extended ASSOCIATION objects that can be used in the context of MPLS-TP. The scope of the Extended ASSOCIATION objects is not limited to MPLS-TP 👑
1.1. Conventions Used in This Document 📖
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]. Those are the official BCP 14 vibes, so read them carefully 💀
2. Generalized Association ID Field Definition 🦋
The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION objects defined in [RFC4872]. The [RFC4872] definition of the field reads:
A value assigned by the LSP head-end. When combined with the
Association Type and Association Source, this value uniquely
identifies an association.This document allows ASSOCIATION objects to be originated by nodes other than "the LSP head-end". So the definition of the Association ID field needs to be generalized to accommodate that kind of usage 🌈 This document defines the Association ID field of the IPv4 and IPv6 ASSOCIATION objects as:
A value assigned by the node that originated the association.
When combined with the other fields carried in the object, this
value uniquely identifies an association.This change in definition does not impact the procedures or mechanisms defined in [RFC4872] or [RFC4873], and it doesn't impact existing implementations of [RFC4872] or [RFC4873] either. No drama, just vibes ✨
3. Non-GMPLS and Non-Recovery Usage 💜
Okay so while the ASSOCIATION object [RFC4872] is defined in the context of GMPLS recovery, the object can have wider application 🌸 [RFC4872] defines the object to be used to "associate LSPs with each other", and then defines an Association Type field to identify the type of association being identified. It also specifies that the Association Type field is to be considered when determining association, which means there may be type-specific association rules. As defined by [RFC4872] and reviewed in [RFC6689], this is the case for recovery type ASSOCIATION objects. The text in [RFC6689] about resource sharing types can also be used as the foundation for a generic method of associating LSPs when there's no type-specific association defined 🧚
The rest of this section sets out the general rules to follow when processing ASSOCIATION objects. Usage in both Path and Resv messages is discussed. The usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209], and non-LSP RSVP sessions [RFC2205] [RFC2207] [RFC3175] [RFC4860]. As described below, association is always done by matching either Path state to Path state, or Resv state to Resv state, but never Path state to Resv State. This section applies to the ASSOCIATION objects defined in [RFC4872] 🔥
3.1. Upstream-Initiated Association 🦋
Upstream-initiated association is represented in ASSOCIATION objects carried in Path messages, and it can be used to associate RSVP Path state across MPLS Tunnels / RSVP sessions. (Quick note, per [RFC3209], an MPLS tunnel is represented by an RSVP SESSION object, and multiple LSPs may be represented within a single tunnel 💅) Cross-LSP association based on Path state is defined in [RFC4872]. This section extends that definition by specifying generic association rules and usage for non-LSP uses. This section does not modify the processing required to support [RFC4872] and [RFC4873], which is reviewed in Section 3 of [RFC6689]. Using an ASSOCIATION object in a single session is not precluded 🫶
3.1.1. Path Message Format 💌
okay so this bit gives you the BNF (see [RFC5511] 💅) for Path messages carrying ASSOCIATION objects. It covers both MPLS and non-LSP session usage. The regular RSVP message formats and some optional objects aren't listed, because they're already defined elsewhere.
The MPLS and GMPLS formats are unchanged from [RFC4872]. You can represent them using the BNF in [RFC3209] like this:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
<sender descriptor>The non-LSP format, based on the BNF in [RFC2205], looks like this:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]Generally speaking, the order of ASSOCIATION objects doesn't matter, either compared to each other or to other objects 🙈. The one exception is that ASSOCIATION objects of the same type SHOULD keep their relative order when transit nodes pass them along 🫶.
3.1.2. Path Message Processing 🔥
This section builds on the processing rules in [RFC4872] and [RFC4873], which are reviewed in [RFC6689] ✨. It applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session state. As mentioned earlier, this section doesn't change any processing needed to support [RFC4872] and [RFC4873] 💖.
A node sending a Path message decides when to include an ASSOCIATION object in the outgoing message 🎀. To show that multiple sessions are associated, a suitable ASSOCIATION object MUST go into the outgoing Path messages for each of those sessions. If there aren't any Association-Type-specific rules for spotting an association, the ASSOCIATION objects you include MUST be identical. If an Association-Type-specific definition does exist, it SHOULD allow association based on identical ASSOCIATION objects 🦋. This document doesn't define any Association-Type-specific rules. (Check out Section 3 of [RFC6689] for a rundown of the Association-Type-specific rules that come from [RFC4872] 📚.)
When you create an ASSOCIATION object, the originator MUST format it the way Section 16.1 of [RFC4872] describes 💅. The originator MUST set the Association Type field to match the kind of association it's identifying. The Association ID field MUST be set to a value that uniquely identifies that specific association within the context of the Association Source field 🌸. The Association Source field MUST be set to a unique address assigned to the node that originated the association 👑.
A downstream node can spot an upstream-initiated association by running these checks 🕵️♀️. When a node receives a Path message, it MUST check each ASSOCIATION object in that message to see whether the object has an Association Type field value the node supports. For each ASSOCIATION object with a supported association type, the node MUST then check whether that object matches an ASSOCIATION object received in any other Path message. To do the matching, a node MUST examine the Path state of all other sessions and compare the fields in the newly received ASSOCIATION object with the fields in the ASSOCIATION objects stored in that Path state. An association is considered to exist when every field in the ASSOCIATION objects being compared carries the same values 🥹. Processing that depends on the type of ASSOCIATION object is outside the scope of this document.
Keep in mind that more than one association can exist at a time, so the matching MUST keep going after a match is found, and it MUST be performed against all local Path state 🧚. It's also possible that no match is found at all 🤷♀️.
Unless there are type-specific processing rules, downstream nodes MUST forward all ASSOCIATION objects received in a Path message, without modification, in any corresponding outgoing Path messages 🍓. This MUST be followed for unknown Association Type field values too ✨.
3.2. Downstream-Initiated Association 🌈
Downstream-initiated association is carried in ASSOCIATION objects inside Resv messages, and it can be used to associate RSVP Resv state across MPLS Tunnels/RSVP sessions 💜. Cross-LSP association, which is based on Path state, is defined in [RFC4872]. This section defines cross-session association based on Resv state. It doesn't add any extra requirements for implementations that support [RFC4872] and [RFC4873] 🫶. Also, using an ASSOCIATION object within a single session isn't ruled out ⭐.
3.2.1. Resv Message Format 🎀
This section gives the Backus-Naur Form (BNF), see [RFC5511], for Resv messages that contain ASSOCIATION objects. It covers both MPLS and non-LSP session usage. Regular RSVP message formats and some optional objects aren't listed here.
The MPLS, GMPLS, and non-LSP formats are all identical, and they're represented using the BNF in [RFC2205] and [RFC3209]:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>The relative order of ASSOCIATION objects, both among themselves and compared to other objects, isn't currently significant 🦋. ASSOCIATION objects of the same type SHOULD still keep their relative order when transit nodes forward them 🌸.
3.2.2. Resv Message Processing 💅
This section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session state 🔥.
A node sending a Resv message decides when to include an ASSOCIATION object in the outgoing message 💖. A node that wants to let upstream nodes associate Resv state across RSVP sessions MUST include an ASSOCIATION object in the outgoing Resv messages for the RSVP sessions being associated 👑. If there aren't any Association-Type-specific rules for identifying association, the included ASSOCIATION objects MUST be identical. If an Association-Type-specific definition of association rules exists, it SHOULD allow association based on identical ASSOCIATION objects. This document doesn't define any Association-Type-specific rules 🧚.
When you create an ASSOCIATION object, the originator MUST format it the way Section 16.1 of [RFC4872] defines 🎀. The originator MUST set the Association Type field based on the type of association being identified. The Association ID field MUST be set to a value that uniquely identifies the specific association within the context of the Association Source field. The Association Source field MUST be set to a unique address assigned to the node that originated the association 🦋.
An upstream node can spot a downstream-initiated association by running these checks 🕵️♀️. When a node receives a Resv message, it MUST check each ASSOCIATION object in that message to see whether the object has an Association Type field value the node supports. For each ASSOCIATION object with a supported association type, the node MUST then check whether that object matches an ASSOCIATION object received in any other Resv message. To do the matching, a node MUST examine the Resv state of all other sessions and compare the fields in the newly received ASSOCIATION object with the fields in the ASSOCIATION objects stored in that Resv state. An association is considered to exist when every field in the ASSOCIATION objects being compared carries the same values 🥹. Processing that depends on the type of ASSOCIATION object is outside the scope of this document.
Again, more than one association can exist, so the matching MUST keep going after a match is found, and it MUST be performed against all local Resv state 🌈. It's also possible that no match gets identified 🤷♀️.
Unless there are type-specific processing rules, upstream nodes MUST forward all ASSOCIATION objects received in a Resv message, without modification, in any corresponding outgoing Resv messages 🍓. This MUST be followed for unknown Association Type field values too ✨.
3.3. Association Types 💜
Two association types are defined right now: recovery and resource sharing 🎀. Recovery type association only makes sense within the context of recovery [RFC4872] [RFC4873]. Resource sharing applies to any context, and its general use is defined in this section 👑.
3.3.1. Resource Sharing Association Type 🫶
The Resource Sharing Association Type was defined in [RFC4873], and that definition was made within the context of GMPLS and upstream-initiated association 🦋. This section presents a definition of resource sharing association that works with any RSVP session type and in both Path and Resv messages 🔥. The definition is consistent with the one for the resource sharing association type in [RFC4873], and this section doesn't require any changes to support [RFC4873] 💅. The Resource Sharing Association Type MUST be supported by any implementation compliant with this document 🌸.
The Resource Sharing Association Type is used to enable resource sharing across RSVP sessions. Per [RFC4873], resource sharing uses an Association Type field value of 2 🧚. ASSOCIATION objects with the Resource Sharing association type value MAY be carried in Path and Resv messages 💖. Association for the Resource Sharing type MUST follow the procedures defined in Section 3.1.2 for upstream-initiated (Path message) association and Section 3.2.1 for downstream-initiated (Resv message) association. There are no type-specific association rules, processing rules, or ordering requirements. Also, as always with association enabled by this document, no associations are made across Path and Resv state ⭐.
Once an association is identified, resources MUST be considered as shared across the identified sessions by the admission-control function 🌈. The admission-control function is outside the scope of RSVP, so we just note that how resource sharing actually shows up can vary between implementations. For example, it might depend on the specific admission-control and resource-management algorithm, or on how local policy is taken into account 🙈.
3.3.2. Unknown Association Types 🌸
As Sections 3.1.2 and 3.2.2 above require, a node that receives an ASSOCIATION object with an unknown ASSOCIATION type forwards all received ASSOCIATION objects as defined above 🍓. The node MAY also identify associations using the defined processing, for example to make that information available through a management interface 👑.
4. IPv4 and IPv6 Extended ASSOCIATION Objects ✨
okay so bestie, [RFC4872] gave us the IPv4 ASSOCIATION object and the IPv6 ASSOCIATION object 💅 Each one has an Association Source field and a 16-bit Association ID field, and together those contents uniquely identify an association. But a 16-bit field only has room for 65536 associations per association source, and that's it 😭 Sometimes that just isn't enough. Picture a fairly centralized entity that's part of tons and tons of associations. It's giving "not enough space" 💀
MPLS-TP LSPs are a whole other problem the old objects can't handle 🦋 According to [RFC6370], MPLS-TP LSPs can be identified using an operator-unique global identifier. That "global identifier", or Global_ID, is based on [RFC5003] and includes the operator's Autonomous System Number (ASN) 🌸
So this section defines new ASSOCIATION objects to fix both problems ✨ The IPv4 Extended ASSOCIATION object and the IPv6 Extended ASSOCIATION object are defined below, and both can hold more fields for identifying a bigger pool of associations plus the MPLS-TP identification stuff. Iconic 👑
The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION object SHOULD be supported by an implementation compliant with this document 🫶 The processing rules are based on the rules for the regular IPv4 and IPv6 ASSOCIATION objects we already covered, so you're not starting from zero, promise 🎀
4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format
The IPv4 Extended ASSOCIATION object uses a Class-Num in the form 11bbbbbb with value = 199, and C-Type = 3. Here's the layout 🧚
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The IPv6 Extended ASSOCIATION object is the same idea, just with Class-Num 11bbbbbb = 199 and C-Type = 4, and a bigger 16-byte source. Check it out 🌈
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| IPv6 Association Source |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Now the fields, one by one 💖
Association Type: 16 bits
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
Association ID: 16 bits
Same as for IPv4 and IPv6 ASSOCIATION objects, see Section 2.
Association Source: 4 or 16 bytes
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
Global Association Source: 4 bytes
This one's the MPLS-TP glow-up 🔥 It holds a unique global identifier or the special value zero (0). When it's non-zero and local policy doesn't override it, the Global_ID as defined in [RFC6370] SHALL be used. Zero means no global identifier is present, and using that special zero SHOULD be limited to entities inside a single operator.
If the Global Association Source field is derived from a 2-octet ASN, then the two high-order octets of this 4-octet field MUST be set to zero 🙈
Extended Association ID: variable, 4-byte aligned
This is the extra info that helps with unique identification 🍓 Its length and contents are scoped by the Association Source. The length comes from the object Length field, so it MUST have a length of zero or be 4-byte aligned. A length of zero means the field is omitted.
4.2. Processing
The processing of an IPv4 or IPv6 Extended ASSOCIATION object MUST be identical to the processing of an IPv4 or IPv6 ASSOCIATION object as previously described, except as extended by this section. This section applies to ASSOCIATION objects included in both Path and Resv messages 🌸
Here are the modified procedures for Extended ASSOCIATION object processing:
- When creating an Extended ASSOCIATION object, the originator MUST format the object as defined in this document.
- The originator MUST set the Association Type, Association ID, and Association Source fields as described in Section 4.
- When ASN-based global identification of the Association Source is desired, the originator MUST set the Global Association Source field. When ASN-based global identification is not desired, the originator MUST set the Global Association Source field to zero (0).
- The Extended ASSOCIATION object originator MAY include the Extended Association ID field. The field is included based on local policy. The field MUST be included when the Association ID field is insufficient to uniquely identify association within the scope of the source of the association. When included, this field MUST be set to a value that, when taken together with the other fields in the object, uniquely identifies the association being identified.
- The object Length field is set based on the length of the Extended Association ID field. When the Extended Association ID field is omitted, the object Length field MUST be set to 16 or 28 for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the Extended Association ID field is present, the object Length field MUST be set to indicate the additional bytes carried in the Extended Association ID field, including pad bytes.
Note: Per [RFC2205], the object Length field is set to the total object length in bytes, is always a multiple of 4, and is at least 4.
The procedures related to association identification are not modified by this section 🦋 It's important to note that Section 4 defines the identification of associations based on ASSOCIATION object matching, and that such matching, in the absence of type-specific comparison rules, is based on the comparison of all fields in an ASSOCIATION object. This applies equally to ASSOCIATION objects and Extended ASSOCIATION objects. Main character energy ✨
5. Compatibility
Per [RFC4872], the ASSOCIATION object uses an object class number of the form 11bbbbbb to ensure compatibility with non-supporting nodes. Per [RFC2205], such nodes will ignore the object but forward it without modification. This is also the action taken for unknown association types as discussed above in Section 3.1.2, 3.2.2, and 3.3.2 🫶
Per [RFC4872], transit nodes that support the ASSOCIATION object but not the Extended Association C-Types will "transmit, without modification, any received ASSOCIATION object in the corresponding outgoing Path message". Per [RFC2205], an egress node that supports the ASSOCIATION object but not the Extended Association C-Types may generate an "Unknown object C-Type" error. That error will propagate to the ingress node for standard error processing 😭
Operators who want to use a function supported by a particular association type should ensure that the type is supported on any node that is expected to act on the association 🎀
6. Security Considerations
A portion of this document reviews procedures defined in [RFC4872] and [RFC4873] and does not define new procedures. As such, no new security considerations are introduced in this portion of the document 💜
Section 3 defines broader usage of the ASSOCIATION object, but does not fundamentally expand on the association function that was previously defined in [RFC4872] and [RFC4873]. Section 4 increases the number of bits that are carried in an ASSOCIATION object (by 32), and similarly does not expand on the association function that was previously defined. This broader definition does allow for additional information to be conveyed, but this information is not fundamentally different from the information that is already carried in RSVP. Therefore, there are no new risks or security considerations introduced by this document 🔥
For a general discussion on MPLS- and GMPLS-related security issues, including RSVP's chain of trust security model, see the MPLS/GMPLS security framework [RFC5920] 👑
7. IANA Considerations
IANA has assigned new values for namespaces defined in this document, and they are summarized in this section 🌈
7.1. IPv4 and IPv6 Extended ASSOCIATION Objects
Per this document, IANA has assigned two new C-Types (which are defined in Section 3.1) for the existing ASSOCIATION object in the "Class Names, Class Numbers, and Class Types" section of the "Resource Reservation Protocol (RSVP) Parameters" registry located at http://www.iana.org/assignments/rsvp-parameters:
199 ASSOCIATION [RFC4872]
Class Types or C-Types
3 Type 3 IPv4 Extended Association [RFC6780]
4 Type 4 IPv6 Extended Association [RFC6780]7.2. Resource Sharing Association Type 🦋
okay so this document also broadens how the Resource Sharing Association Type from [RFC4873] can be used 🔥 which means IANA had to update the reference for it in the registry. they also fixed the duplicate '(R)' mess in that same registry 💅 bestie this is the tea. the "Association Type" registry at http://www.iana.org/assignments/gmpls-sig-parameters/ now looks like this:
OLD:
2 Resource Sharing (R) [RFC4873]
NEW:
2 Resource Sharing (S) [RFC4873][RFC6780]and that's literally the only IANA change this doc makes 🎀 no other IANA considerations come from this document ✨
8. Acknowledgments 🫶
huge thank you to Dimitri Papadimitriou, Fei Zhang, and Adrian Farrel for giving such valuable comments and input 💖 and a special shoutout to Subha Dhesikan for her early work on sharing resources across RSVP reservations 🌸 the real MVPs 👑
9. References 📚
9.1. Normative References
[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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 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.
[RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003.
[RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Ed., "RSVP-TE Extensions in Support of End-to-End
Generalized Multi-Protocol Label Switching (GMPLS)
Recovery", RFC 4872, May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009.9.2. Informative References 🧚
[RFC2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
3175, September 2001.
[RFC4860] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", RFC 4860, May 2007.
[RFC5003] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, September 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
[RFC6370] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC
6689, July 2012.Authors' Addresses 💌
Lou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: lberger@labn.net
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
EMail: flefauch@cisco.com
Ashok Narayanan
Cisco Systems
300 Beaver Brook Road
Boxborough, MA 01719
United States
EMail: ashokn@cisco.comthat's the whole doc, bestie 🌈✨ thank you for staying with me through all four parts 💜 💅
📦 where this page comes from
- ietf: rfc6780 2012-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms