--- 1/draft-ietf-ccamp-assoc-ext-05.txt 2012-09-21 16:14:31.421842178 +0200 +++ 2/draft-ietf-ccamp-assoc-ext-06.txt 2012-09-21 16:14:31.457842035 +0200 @@ -1,20 +1,20 @@ Internet Draft Lou Berger (LabN) Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco) Category: Standards Track Ashok Narayanan (Cisco) -Expiration Date: March 5, 2013 +Expiration Date: March 21, 2013 - September 5, 2012 + September 21, 2012 RSVP Association Object Extensions - draft-ietf-ccamp-assoc-ext-05.txt + draft-ietf-ccamp-assoc-ext-06.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 @@ -38,21 +38,21 @@ 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 March 5, 2013 + This Internet-Draft will expire on March 21, 2013 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 @@ -72,29 +72,29 @@ 3.1.1 Path Message Format .................................... 6 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 ............................................. 12 - 5 Compatibility .......................................... 13 + 4.2 Processing ............................................. 13 + 5 Compatibility .......................................... 14 6 Security Considerations ................................ 14 - 7 IANA Considerations .................................... 14 - 7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 14 + 7 IANA Considerations .................................... 15 + 7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 15 7.2 Resource Sharing Association Type ...................... 15 - 8 Acknowledgments ........................................ 15 - 9 References ............................................. 15 - 9.1 Normative References ................................... 15 + 8 Acknowledgments ........................................ 16 + 9 References ............................................. 16 + 9.1 Normative References ................................... 16 9.2 Informative References ................................. 16 10 Authors' Addresses ..................................... 17 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 @@ -313,20 +313,22 @@ 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, without modification, in any corresponding outgoing Path messages. + 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 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 @@ -396,21 +398,23 @@ 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, without - modification, in any corresponding outgoing Resv messages. + modification, in any corresponding outgoing Resv messages. 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] 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 @@ -441,32 +445,32 @@ 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 - A node that receives an ASSOCIATION object with an unknown - ASSOCIATION type MUST forward 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. + 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 - described above, the contents of the object uniquely identifies an + described above, 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, 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 @@ -611,28 +615,41 @@ 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 essentially also the action taken for - unknown association types as discussed above in Section 3.3.2. + 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 particular - association type should ensure that the type is supported on any node - which is expected to act on the association. + association type should ensure that the type is supported on any + node which 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 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 @@ -772,11 +789,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: Wed, Sep 05, 2012 5:37:17 PM +Generated on: Fri, Sep 21, 2012 9:36:09 AM