RSVP Association Object Extensions
draft-ietf-ccamp-assoc-ext-04
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 6780.
|
|
---|---|---|---|
Authors | Lou Berger , François Le Faucheur , Ashok Narayanan | ||
Last updated | 2012-08-31 (Latest revision 2012-08-14) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Telechat review
(of
-05)
by Peter Yee
Ready w/nits
GENART Last Call review
by Peter Yee
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Deborah Brungard | ||
IESG | IESG state | Became RFC 6780 (Proposed Standard) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | Adrian Farrel | ||
IESG note | |||
Send notices to | ccamp-chairs@tools.ietf.org, draft-ietf-ccamp-assoc-ext@tools.ietf.org |
draft-ietf-ccamp-assoc-ext-04
Internet Draft Lou Berger (LabN) Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco) Category: Standards Track Ashok Narayanan (Cisco) Expiration Date: February 14, 2013 August 14, 2012 RSVP Association Object Extensions draft-ietf-ccamp-assoc-ext-04.txt Abstract The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) 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, and this document defines how the ASSOCIATION object can be more generally applied. This document also defines Extended ASSOCIATION objects which, in particular, can be used in the context of the Transport Profile of Multiprotocol Label Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC 3473. It also modifies the definition of the Association ID field defined in RFC 4872. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on February 14, 2013 Berger, et al Standards Track [Page 1] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 Copyright and License 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 ........................................... 3 1.1 Conventions Used In This Document ...................... 4 2 Modified Association ID Field Definition ............... 4 3 Non-GMPLS and Non-Recovery Usage ....................... 5 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 .................................... 7 3.2.2 Resv Message Processing ................................ 8 3.3 Association Types ...................................... 9 3.3.1 Resource Sharing Association Type ...................... 9 4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10 4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10 4.2 Processing ............................................. 12 5 Security Considerations ................................ 13 6 IANA Considerations .................................... 14 6.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 14 6.2 Resource Sharing Association Type ...................... 14 7 Acknowledgments ........................................ 14 8 References ............................................. 15 8.1 Normative References ................................... 15 8.2 Informative References ................................. 15 9 Authors' Addresses ..................................... 16 Berger, et al Standards Track [Page 2] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 1. Introduction End-to-end and segment recovery are defined for GMPLS (Generalized Multi-Protocol Label Switching) 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 also provided in [RFC6689]. This document expands the possible usage of the ASSOCIATION object to non-GMPLS and non-recovery contexts. This document reviews how association should be made in the case where the object is carried in a Path message and 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 in order 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 VoIP system that models these calls as multiple P2P 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 allowing separate unicast reservations to be associated and share resources. 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 Berger, et al Standards Track [Page 3] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 case, these flows cannot share resources using RSVP, since the SESSION objects for these two flows outside the NAT have different ports. This document defines a new mechanisms to associate these flows and allow them to share resources. In order to support the more general usage of the ASSOCIATION object, this document modifies the definition of the Association ID field defined in RFC 4872. This modification has no impact on existing implementations. This document also defines the Extended ASSOCIATION objects which can be used in the context of the Transport Profile of Multiprotocol Label Switching (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. Modified 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 modified to accommodate such usage. This document defines the Association ID field of the IPv4 and IPv6 ASSOCIATION objects as: A value assigned by the 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 [RFC4872] or [RFC4873] defined procedures or mechanisms, nor does it impact existing implementations of [RFC4872] or [RFC4873]. Berger, et al Standards Track [Page 4] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 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] and [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 a RSVP SESSION object, and multiple LSPs may be represented within a single tunnel.) Cross-session 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], and which is reviewed in Section 3 of [RFC6689]. The use of an ASSOCIATION object in a single session is not precluded. 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 format for MPLS and GMPLS sessions is unmodified from [RFC4872], and can be represented based on the BNF in [RFC3209] as: Berger, et al Standards Track [Page 5] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 <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 the processing rules described in [RFC4872] and [RFC4873], and which is reviewed in [RFC6689]. These procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. 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 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 sessions to be associated 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 Berger, et al Standards Track [Page 6] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 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 see if it 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. 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-session association based on Path state is defined in [RFC4872]. This section defines 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 format for MPLS, GMPLS and non-LSP sessions are identical, and is represented based on the BNF in [RFC2205] and [RFC3209]: Berger, et al Standards Track [Page 7] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 <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 apply 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 identified. The Association ID field MUST be set to a value that uniquely identifies the sessions to be associated 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 see if it 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 Berger, et al Standards Track [Page 8] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 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. 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] and [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 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 4.1.2 for upstream (Path message) initiated association and Section 4.2.1 for downstream (Resv message) initiated 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 admission control function is outside the scope of RSVP, we observe that how resource sharing is actually reflected Berger, et al Standards Track [Page 9] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 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). 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. The combination of the Association Source and the Association ID uniquely identifies the 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, which therefore may be involved in a large number of associations.) 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. The [RFC6370] defined "global identifier", or Global_ID, is based on [RFC5003] and includes the operator's Autonomous System Number (ASN). This sections defines new ASSOCIATION objects to support extended identification in order to address the limitations described above. 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 described above. 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 = TBA) has the format: Berger, et al Standards Track [Page 10] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 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 (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Association Type | Association ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Global Association Source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : . : : Extended Association ID : : . : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The IPv6 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb with value = 199, C-Type = TBA) 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 (TBA) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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]. Berger, et al Standards Track [Page 11] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 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 of zero indicates that no global identifier is present. Use of the special value of zero SHOULD be limited to entities contained within a single operator. If the Global Association Source field value is derived from a 2-octet AS number, then the two high-order octets of this 4-octet field MUST be set to zero. Note, as stated in [RFC6370], "the use of the Global_ID is not related to the use of the ASN in protocols such as BGP." This field is based on the definition of Global_ID defined in [RFC5003] and used by [RFC6370]. 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 zero length or be 4-byte aligned. A zero length indicates that this field is omitted. 4.2. Processing The processing of a IPv4 or IPv6 Extended ASSOCIATION object MUST be identical to the processing of a IPv4 or IPv6 ASSOCIATION object as described above 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). Berger, et al Standards Track [Page 12] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 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 sessions to be associated. 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. Note: per [RFC2205], the object Length field is set to the total object length in bytes, and is always a multiple of 4, and at least 4. Identification of association is not modified by this section. It is important to note that Section 4 defines association identification based on ASSOCIATION object matching, and that such matching is based on the comparison of all fields in a ASSOCIATION object (unless type- specific comparison rules are defined). This applies equally to ASSOCIATION objects and Extended ASSOCIATION objects. 5. Security Considerations A portion of this document reviews procedures defined in [RFC4872] and [RFC4873] and does not define any new procedures. As such, no new security considerations are introduced in this portion. Section 2 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 3 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, see the MPLS/GMPLS security framework [RFC5920]. Berger, et al Standards Track [Page 13] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 6. IANA Considerations IANA is requested to administer assignment of new values for namespaces defined in this document and summarized in this section. 6.1. IPv4 and IPv6 Extended ASSOCIATION Objects Upon approval of this document, IANA will make the assignment of 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 [this document] 4 Type 4 IPv6 Extended Association [this document] 6.2. Resource Sharing Association Type This document also broadens the potential usage of the Resource Sharing Association Type defined in [RFC4873]. As such, IANA is requested to change the Reference of the Resource Sharing Association Type included in the associate registry. This document also directs IANA to correct the duplicate usage of '(R)' in this Registry. In particular, the Association Type registry found at http://www.iana.org/assignments/gmpls-sig-parameters/ should be updated as follows: OLD: 2 Resource Sharing (R) [RFC4873] NEW 2 Resource Sharing (S) [RFC4873][this-document] There are no other IANA considerations introduced by this document. 7. Acknowledgments Valuable comments and input was 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. Berger, et al Standards Track [Page 14] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 8. References 8.1. Normative References [RFC2205] Braden, R., 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., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "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., Farrel, A., "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 8.2. Informative References [RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997. [RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001. [RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M., "Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations", RFC 4860, May 2007. Berger, et al Standards Track [Page 15] Internet-Draft draft-ietf-ccamp-assoc-ext-04.txt August 14, 2012 [RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J., "Attachment Individual Identifier (AII) Types for Aggregation", RFC 5003, September 2007. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC5920] Fang, L., et al, "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. [RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers", RFC 6370, June 2011. [RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC 6689, July 2012. 9. 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 16] Generated on: Tue, Aug 14, 2012 9:39:19 AM