diff options
Diffstat (limited to 'doc/rfc/rfc6780.txt')
| -rw-r--r-- | doc/rfc/rfc6780.txt | 955 |
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc6780.txt b/doc/rfc/rfc6780.txt new file mode 100644 index 0000000..972d623 --- /dev/null +++ b/doc/rfc/rfc6780.txt @@ -0,0 +1,955 @@ + + + + + + +Internet Engineering Task Force (IETF) L. Berger +Request for Comments: 6780 LabN +Updates: 2205, 3209, 3473, 4872 F. Le Faucheur +Category: Standards Track A. Narayanan +ISSN: 2070-1721 Cisco + October 2012 + + + RSVP ASSOCIATION Object Extensions + +Abstract + + The RSVP ASSOCIATION object was defined in the context of GMPLS- + controlled Label Switched Paths (LSPs). In this context, the object + is used to associate recovery LSPs with the LSP they are protecting. + This object also has broader applicability as a mechanism to + associate RSVP state. This document defines how the ASSOCIATION + object can be more generally applied. This document also defines + Extended ASSOCIATION objects that, in particular, can be used in the + context of the MPLS Transport Profile (MPLS-TP). This document + updates RFC 2205, RFC 3209, and RFC 3473. It also generalizes the + definition of the Association ID field defined in RFC 4872. + +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). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6780. + + + + + + + + + + + + + + + +Berger, et al. Standards Track [Page 1] + +RFC 6780 RSVP Extensions October 2012 + + +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 ....................................16 + + + + + + + + + +Berger, et al. Standards Track [Page 2] + +RFC 6780 RSVP Extensions October 2012 + + +1. Introduction + + 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 associate recovery + LSPs with the LSP they are protecting. Additional narrative on how + such associations are to be identified is provided in [RFC6689]. + + This document expands the possible usage of the ASSOCIATION object to + 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]. This document + also reviews how associations should be made in the case in which the + object is carried in a Path message; additionally, it defines usage + with Resv messages. This section also discusses usage of the + ASSOCIATION object outside the context of GMPLS LSPs. + + Some examples of non-LSP association being used to enable resource + sharing are: + + o Voice Call-Waiting: + + A bidirectional voice call between two endpoints, A and B, is + signaled using two separate unidirectional RSVP reservations for + the flows A->B and B->A. If endpoint A wishes to put the A-B call + on hold and join a separate A-C call, it is desirable that network + resources on common links be 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. Since 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, this document + defines a new mechanism to associate the subflows and allow them + to share resources. + + o Voice Shared Line: + + A voice shared line is a single number that rings multiple + endpoints (which may be geographically diverse), such as phone + lines to a manager's desk and to their assistant. A Voice over IP + (VoIP) system that models these calls as multiple point-to-point + unicast pre-ring reservations would result in significantly over- + counting bandwidth on shared links, since RSVP unicast + reservations to different endpoints cannot share bandwidth. So, a + new mechanism is defined in this document to allow separate + unicast reservations to be associated and to share resources. + + + + + +Berger, et al. Standards Track [Page 3] + +RFC 6780 RSVP Extensions October 2012 + + + o Symmetric NAT: + + RSVP permits sharing of resources between multiple flows addressed + to the same destination D, even from different senders S1 and S2. + However, if D is behind a NAT operating in symmetric mode + [RFC5389], it is possible that the destination port of the flows + S1->D and S2->D may be different outside the NAT. In this case, + these flows cannot share resources using RSVP, since 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 + defined in RFC 4872. This generalization has no impact on existing + implementations. When using the procedures defined below, + association is identified based on exact ASSOCIATION object matching. + Some of the other matching mechanisms defined in RFC 4872, e.g., + matching based on Session IDs, are not generalized. This document + allows for, but does not specify, association type-specific + processing. + + 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]. + +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 for the origination of ASSOCIATION objects by + nodes other than "the LSP head-end". As such, the definition of the + Association ID field needs to be generalized to accommodate such + usage. This document defines the Association ID field of the IPv4 + and IPv6 ASSOCIATION objects as: + + + + +Berger, et al. Standards Track [Page 4] + +RFC 6780 RSVP Extensions October 2012 + + + 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], nor does it impact the + existing implementations of [RFC4872] or [RFC4873]. + +3. Non-GMPLS and Non-Recovery Usage + + 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, i.e., + there may be type-specific association rules. As defined by + [RFC4872] and reviewed in [RFC6689], this is the case for recovery + type ASSOCIATION objects. [RFC6689], notably the text related to + resource sharing types, can also be used as the foundation for a + generic method for associating LSPs when there is no type-specific + association defined. + + The remainder of this section defines the general rules to be + followed when processing ASSOCIATION objects. Object 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 based on matching either Path state to + Path state, or Resv state to Resv state, but not 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 can be used to associate RSVP Path state + across MPLS Tunnels / RSVP sessions. (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 processing required to + support [RFC4872] and [RFC4873], which is reviewed in Section 3 of + [RFC6689]. The use of an ASSOCIATION object in a single session is + not precluded. + + + + + +Berger, et al. Standards Track [Page 5] + +RFC 6780 RSVP Extensions October 2012 + + +3.1.1. Path Message Format + + This section provides the Backus-Naur Form (BNF), see [RFC5511], for + Path messages containing ASSOCIATION objects. BNF is provided for + both MPLS and for non-LSP session usage. Unmodified RSVP message + formats and some optional objects are not listed. + + The formats for MPLS and GMPLS sessions are unmodified from [RFC4872] + and can be represented based on the BNF in [RFC3209] as: + + <Path Message> ::= <Common Header> [ <INTEGRITY> ] + <SESSION> <RSVP_HOP> + <TIME_VALUES> + [ <EXPLICIT_ROUTE> ] + <LABEL_REQUEST> + [ <SESSION_ATTRIBUTE> ] + [ <ASSOCIATION> ... ] + [ <POLICY_DATA> ... ] + <sender descriptor> + + The format for non-LSP sessions as based on the BNF in [RFC2205] is: + + <Path Message> ::= <Common Header> [ <INTEGRITY> ] + <SESSION> <RSVP_HOP> + <TIME_VALUES> + [ <ASSOCIATION> ... ] + [ <POLICY_DATA> ... ] + [ <sender descriptor> ] + + In general, relative ordering of ASSOCIATION objects with respect to + each other, as well as with respect to other objects, is not + significant. Relative ordering of ASSOCIATION objects of the same + type SHOULD be preserved by transit nodes. + +3.1.2. Path Message Processing + + This section is based on, and extends, the processing rules described + in [RFC4872] and [RFC4873], which is reviewed in [RFC6689]. This + section applies equally to GMPLS LSPs, MPLS LSPs, and non-LSP session + state. Note, as previously stated, this section does not modify + processing required to support [RFC4872] and [RFC4873]. + + A node sending a Path message chooses when an ASSOCIATION object is + to be included in the outgoing Path message. To indicate association + between multiple sessions, an appropriate ASSOCIATION object MUST be + included in the outgoing Path messages corresponding to each of the + associated sessions. In the absence of Association-Type-specific + rules for identifying association, the included ASSOCIATION object + + + +Berger, et al. Standards Track [Page 6] + +RFC 6780 RSVP Extensions October 2012 + + + MUST be identical. When there is an Association-Type-specific + definition of association rules, the definition SHOULD allow for + association based on identical ASSOCIATION objects. This document + does not define any Association-Type-specific rules. (See Section 3 + of [RFC6689] for a review of Association-Type-specific rules derived + from [RFC4872].) + + When creating an ASSOCIATION object, the originator MUST format the + object as defined in Section 16.1 of [RFC4872]. 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 originating the + association. + + A downstream node can identify an upstream-initiated association by + performing the following checks. When a node receives a Path + message, it MUST check each ASSOCIATION object received in the Path + message to determine if the object contains an Association Type field + value supported by the node. For each ASSOCIATION object containing + a supported association type, the node MUST then check to see if the + object matches an ASSOCIATION object received in any other Path + message. To perform this matching, a node MUST examine the Path + state of all other sessions and compare the fields contained in the + newly received ASSOCIATION object with the fields contained in the + Path state's ASSOCIATION objects. An association is deemed to exist + when the same values are carried in all fields of the ASSOCIATION + objects being compared. Type-specific processing of ASSOCIATION + objects is outside the scope of this document. + + Note that as more than one association may exist, the described + matching MUST continue after a match is identified and MUST be + performed against all local Path state. It is also possible for + there to be no match identified. + + Unless there are type-specific processing rules, downstream nodes + MUST forward all ASSOCIATION objects received in a Path message in + any corresponding outgoing Path messages without modification. This + processing MUST be followed for unknown Association Type field + values. + +3.2. Downstream-Initiated Association + + Downstream-initiated association is represented in ASSOCIATION + objects carried in Resv messages and can be used to associate RSVP + Resv state across MPLS Tunnels/RSVP sessions. Cross-LSP association, + based on Path state, is defined in [RFC4872]. This section defines + + + +Berger, et al. Standards Track [Page 7] + +RFC 6780 RSVP Extensions October 2012 + + + cross-session association based on Resv state. This section places + no additional requirements on implementations supporting [RFC4872] + and [RFC4873]. Note, the use of an ASSOCIATION object in a single + session is not precluded. + +3.2.1. Resv Message Format + + This section provides the Backus-Naur Form (BNF), see [RFC5511], for + Resv messages containing ASSOCIATION objects. BNF is provided for + both MPLS and for non-LSP session usage. Unmodified RSVP message + formats and some optional objects are not listed. + + The formats for MPLS, GMPLS, and non-LSP sessions are identical and + are represented based on 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> + + Relative ordering of ASSOCIATION objects with respect to each other, + as well as with respect to other objects, is not currently + significant. Relative ordering of ASSOCIATION objects of the same + type SHOULD be preserved by transit nodes. + +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 chooses when an ASSOCIATION object is + to be included in the outgoing Resv message. A node that wishes to + allow upstream nodes to associate Resv state across RSVP sessions + MUST include an ASSOCIATION object in the outgoing Resv messages + corresponding to the RSVP sessions to be associated. In the absence + of Association-Type-specific rules for identifying association, the + included ASSOCIATION objects MUST be identical. When there is an + Association-Type-specific definition of association rules, the + definition SHOULD allow for association based on identical + ASSOCIATION objects. This document does not define any Association- + Type-specific rules. + + When creating an ASSOCIATION object, the originator MUST format the + object as defined in Section 16.1 of [RFC4872]. The originator MUST + set the Association Type field based on the type of association being + + + +Berger, et al. Standards Track [Page 8] + +RFC 6780 RSVP Extensions October 2012 + + + 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 originating the + association. + + An upstream node can identify a downstream-initiated association by + performing the following checks. When a node receives a Resv + message, it MUST check each ASSOCIATION object received in the Resv + message to determine if the object contains an Association Type field + value supported by the node. For each ASSOCIATION object containing + a supported association type, the node MUST then check to see if the + object matches an ASSOCIATION object received in any other Resv + message. To perform this matching, a node MUST examine the Resv + state of all other sessions and compare the fields contained in the + newly received ASSOCIATION object with the fields contained in the + Resv state's ASSOCIATION objects. An association is deemed to exist + when the same values are carried in all fields of the ASSOCIATION + objects being compared. Type-specific processing of ASSOCIATION + objects is outside the scope of this document. + + Note that as more than one association may exist, the described + matching MUST continue after a match is identified and MUST be + performed against all local Resv state. It is also possible for + there to be no match identified. + + Unless there are type-specific processing rules, upstream nodes MUST + forward all ASSOCIATION objects received in a Resv message in any + corresponding outgoing Resv messages without modification. This + processing MUST be followed for unknown Association Type field + values. + +3.3. Association Types + + Two association types are currently defined: recovery and resource + sharing. Recovery type association is only applicable within the + context of recovery [RFC4872] [RFC4873]. Resource sharing is + applicable 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 + was defined within the context of GMPLS and upstream-initiated + association. This section presents a definition of the resource + sharing association that allows for its use with any RSVP session + type and in both Path and Resv messages. This definition is + consistent with the definition of the resource sharing association + + + +Berger, et al. Standards Track [Page 9] + +RFC 6780 RSVP Extensions October 2012 + + + type in [RFC4873] and no changes are required by this section in + order 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 + the Association Type field value of 2. ASSOCIATION objects with an + Association Type with the value Resource Sharing 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. Note that, as is always the case with association as + 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. Since the implementation specifics of the admission- + control function is outside the scope of RSVP, we observe that how + resource sharing is actually reflected may vary according to specific + implementations (e.g., depending 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 required by Sections 3.1.2 and 3.2.2 above, a node that receives + an ASSOCIATION object containing an unknown ASSOCIATION type forwards + all received ASSOCIATION objects as defined above. The node MAY also + identify associations per the defined processing, e.g., to make this + information available via a management interface. + +4. IPv4 and IPv6 Extended ASSOCIATION Objects + + [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 + ASSOCIATION object. As defined, these objects each contain an + Association Source field and a 16-bit Association ID field. As + previously described, the contents of the object uniquely identify an + association. Because the Association ID field is a 16-bit field, an + association source can allocate up to 65536 different associations + and no more. There are scenarios where this number is insufficient + (for example, where the association identification is best known and + identified by a fairly centralized entity, and therefore may be + involved in a large number of associations). + + + + + +Berger, et al. Standards Track [Page 10] + +RFC 6780 RSVP Extensions October 2012 + + + An additional case that cannot be supported using the existing + ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370], + MPLS-TP LSPs can be identified based on an operator-unique global + identifier. As defined in [RFC6370], "global identifier", or + Global_ID, is based on [RFC5003] and includes the operator's + Autonomous System Number (ASN). + + This section defines new ASSOCIATION objects to support extended + identification in order to address the previously described + limitations. Specifically, the IPv4 Extended ASSOCIATION object and + IPv6 Extended ASSOCIATION object are defined below. Both new objects + include the fields necessary to enable identification of a larger + number of associations as well as MPLS-TP-required identification. + + The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION + object SHOULD be supported by an implementation compliant with this + document. The processing rules for the IPv4 and IPv6 Extended + ASSOCIATION object are described below and are based on the rules for + the IPv4 and IPv6 ASSOCIATION objects as previously described. + +4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format + + The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb + with value = 199, C-Type = 3) has the format: + + 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 : + : . : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + + + + + + + + +Berger, et al. Standards Track [Page 11] + +RFC 6780 RSVP Extensions October 2012 + + + The IPv6 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb + with value = 199, C-Type = 4) has the format: + + 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 : + : . : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 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 field contains a value that is a unique global identifier or + the special value zero (0). When non-zero and not overridden by + local policy, the Global_ID as defined in [RFC6370] SHALL be used. + The special value zero indicates that no global identifier is + present. Use of the special value zero SHOULD be limited to + entities contained within a single operator. + + If the Global Association Source field value is derived from a + 2-octet ASN, then the two high-order octets of this 4-octet field + MUST be set to zero. + + + + + +Berger, et al. Standards Track [Page 12] + +RFC 6780 RSVP Extensions October 2012 + + + Extended Association ID: variable, 4-byte aligned + + This field contains data that is additional information to support + unique identification. The length and contents of this field is + scoped by the Association Source. The length of this field is + derived from the object Length field and as such MUST have a + length of zero or be 4-byte aligned. A length of zero indicates + that this 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. + + The following are the modified procedures for Extended ASSOCIATION + object processing: + + o When creating an Extended ASSOCIATION object, the originator MUST + format the object as defined in this document. + + o The originator MUST set the Association Type, Association ID, and + Association Source fields as described in Section 4. + + o 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). + + o 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. + + o 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. + + + +Berger, et al. Standards Track [Page 13] + +RFC 6780 RSVP Extensions October 2012 + + + 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 is 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. + +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. This error will propagate + to the ingress node for standard error processing. + + Operators wishing 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 + + + +Berger, et al. Standards Track [Page 14] + +RFC 6780 RSVP Extensions October 2012 + + + 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 + + This document also broadens the potential usage of the Resource + Sharing Association Type defined in [RFC4873]. As such, IANA has + updated the reference of the Resource Sharing Association Type + included in the associated registry. Per this document, IANA has + also corrected the duplicate usage of '(R)' in this registry. In + particular, the "Association Type" registry found at + http://www.iana.org/assignments/gmpls-sig-parameters/ has been + updated as follows: + + OLD: + 2 Resource Sharing (R) [RFC4873] + + NEW: + 2 Resource Sharing (S) [RFC4873][RFC6780] + + There are no other IANA considerations introduced by this document. + + + + + + +Berger, et al. Standards Track [Page 15] + +RFC 6780 RSVP Extensions October 2012 + + +8. Acknowledgments + + Valuable comments and input were received from Dimitri Papadimitriou, + Fei Zhang, and Adrian Farrel. We thank Subha Dhesikan for her + contribution to the early work on sharing of resources across RSVP + reservations. + +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. + + + + +Berger, et al. Standards Track [Page 16] + +RFC 6780 RSVP Extensions October 2012 + + + [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.com + + + + + + + + + + +Berger, et al. Standards Track [Page 17] + |