--- 1/draft-ietf-ccamp-assoc-ext-01.txt 2012-02-17 22:13:57.430671078 +0100 +++ 2/draft-ietf-ccamp-assoc-ext-02.txt 2012-02-17 22:13:57.458670904 +0100 @@ -1,20 +1,20 @@ Internet Draft Lou Berger (LabN) Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco) Category: Standards Track Ashok Narayanan (Cisco) -Expiration Date: April 28, 2012 +Expiration Date: August 16, 2012 - October 28, 2011 + February 16, 2012 RSVP Association Object Extensions - draft-ietf-ccamp-assoc-ext-01.txt + draft-ietf-ccamp-assoc-ext-02.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 @@ -37,61 +37,61 @@ 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 April 28, 2012 + This Internet-Draft will expire on August 16, 2012 Copyright and License Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + 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 Non-GMPLS Recovery Usage ............................... 4 2.1 Upstream Initiated Association ......................... 4 2.1.1 Path Message Format .................................... 5 2.1.2 Path Message Processing ................................ 5 - 2.2 Downstream Initiated Association ....................... 6 + 2.2 Downstream Initiated Association ....................... 7 2.2.1 Resv Message Format .................................... 7 2.2.2 Resv Message Processing ................................ 7 2.3 Association Types ...................................... 8 2.3.1 Resource Sharing Association Type ...................... 8 3 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 9 - 3.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 9 + 3.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10 3.2 Processing ............................................. 11 - 4 Security Considerations ................................ 12 + 4 Security Considerations ................................ 13 5 IANA Considerations .................................... 13 5.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 13 - 5.2 Resource Sharing Association Type ...................... 13 + 5.2 Resource Sharing Association Type ...................... 14 6 Acknowledgments ........................................ 14 7 References ............................................. 14 7.1 Normative References ................................... 14 - 7.2 Informative References ................................. 14 + 7.2 Informative References ................................. 15 8 Authors' Addresses ..................................... 15 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 [ASSOC-INFO]. @@ -151,48 +151,53 @@ document are to be interpreted as described in [RFC2119]. 2. Non-GMPLS 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 defines that the Association Type field is to be considered when determining association, i.e., - there may be type-specific association rules. As discussed above, - this is the case for Recovery type association objects. The text - above, 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. + there may be type-specific association rules. As defined by + [RFC4872] and reviewed in [ASSOC-INFO], this is the case for Recovery + type association objects. [ASSOC-INFO], 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]. + [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. Note that there are times when no matching state is found, + e.g., when processing an initial LSP or when the ASSOCIATION object + contains otherwise useful information, and such cases do not alter + the processing defined below. This section applies to the + ASSOCIATION objects defined in [RFC4872]. 2.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 + 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 definition is extended by this section, which defined 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 - above in Section 3 of [ASSOC-INFO]. + required to support [RFC4872] and [RFC4873], and which is reviewed in + Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a + single session is not precluded. 2.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: @@ -221,31 +226,33 @@ significant. Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes. 2.1.2. Path Message Processing This section is based on the processing rules described in [RFC4872] and [RFC4873], and which is reviewed in [ASSOC-INFO]. These procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. - A node that wishes to allow downstream nodes to associate Path state - across RSVP sessions MUST include an ASSOCIATION object in the - outgoing Path 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. (See Section 3 for a discussion of - an example of Association Type-specific rules which are derived from - [RFC4872].) + A node initiating a Path message chooses when an ASSOCIATION object + is to be included in the outgoing Path message. A node that wishes + to allow downstream nodes to associate Path state across RSVP + sessions MUST include an ASSOCIATION object in the outgoing Path + 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 + across all associated sessions. 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 [ASSOC-INFO] 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 association. @@ -254,40 +261,42 @@ 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. Processing once an association is identified is type - specific and is outside the scope of this document. + 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. + 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. 2.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]. + [RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a + single session is not precluded. 2.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]: @@ -304,29 +313,31 @@ as well as with respect to other objects is not currently significant. Relative ordering of ASSOCIATION objects of the same type MUST be preserved by transit nodes. Association type specific ordering requirements MAY be defined in the future. 2.2.2. Resv Message Processing This section apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. - 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. + A node initiating 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. @@ -335,26 +346,27 @@ 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 values are carried in all fields of the ASSOCIATION objects being - compared. Processing once an association is identified is type - specific and is outside the scope of this document. + 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. + 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. 2.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 @@ -485,42 +497,41 @@ the global identifier will be derived from the globally unique ASN of the autonomous system hosting the Association Source. The special value of zero (0) indicates that no global identifier is present. Note that a Global Association Source 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. - Please note that, as stated in [RFC6370], the use of the - provider's ASN as a global identifier DOES NOT have anything at - all to do with the use of the ASN in protocols such as BGP. + 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 determined by the Association Source. This field MAY be omitted, i.e., have a zero length. This field MUST be padded with zeros (0s) to ensure 32-bit alignment. 3.2. Processing - The processing of a IPv4 or IPv6 Extended ASSOCIATION object MUST + 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 both upstream-initiated (Path message) and downstream- - initiated (Resv message) association. + 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. @@ -557,43 +568,43 @@ 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. 4. 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 4 defines broader usage of the ASSOCIATION object, but does + 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 5 increases + 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]. 5. IANA Considerations IANA is requested to administer assignment of new values for namespaces defined in this document and summarized in this section. 5.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 5.1) for the existing + 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] @@ -612,23 +623,23 @@ OLD: 2 Resource Sharing (R) [RFC4873] NEW 2 Resource Sharing (S) [RFC4873][this-document] There are no other IANA considerations introduced by this document. 6. Acknowledgments - Valuable comments and input was received from Dimitri Papadimitriou. - We thank Subha Dhesikan for her contribution to the early work on - sharing of resources across RSVP reservations. + Valuable comments and input was received from Dimitri Papadimitriou + and Fei Zhang. We thank Subha Dhesikan for her contribution to the + early work on sharing of resources across RSVP reservations. 7. References 7.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. @@ -651,23 +662,22 @@ (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009 7.2. Informative References - [ASSOC-INFO] Berger, L., Faucheur, F., Narayanan, A., "Usage of - The RSVP Association Object", work in progress, - draft-ietf-ccamp-assoc-info. + [ASSOC-INFO] Berger, L.., "Usage of The RSVP Association Object", + work in progress, draft-ietf-ccamp-assoc-info. [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., @@ -702,11 +711,11 @@ France Email: flefauch@cisco.com Ashok Narayanan Cisco Systems 300 Beaver Brook Road Boxborough, MA 01719 United States Email: ashokn@cisco.com -Generated on: Fri, Oct 28, 2011 8:00:39 AM +Generated on: Wed, Feb 15, 2012 12:33:04 PM