--- 1/draft-ietf-ccamp-assoc-ext-00.txt 2011-10-28 14:14:03.927119472 +0200 +++ 2/draft-ietf-ccamp-assoc-ext-01.txt 2011-10-28 14:14:03.959087497 +0200 @@ -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: November 1, 2011 +Expiration Date: April 28, 2012 - May 1, 2011 + October 28, 2011 RSVP Association Object Extensions - draft-ietf-ccamp-assoc-ext-00.txt + draft-ietf-ccamp-assoc-ext-01.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,21 +37,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 November 1, 2011 + This Internet-Draft will expire on April 28, 2012 Copyright and License Notice Copyright (c) 2011 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 @@ -68,30 +68,30 @@ 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.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 ....... 10 + 3.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 9 3.2 Processing ............................................. 11 - 4 Security Considerations ................................ 13 + 4 Security Considerations ................................ 12 5 IANA Considerations .................................... 13 5.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 13 - 5.2 Resource Sharing Association Type ...................... 14 + 5.2 Resource Sharing Association Type ...................... 13 6 Acknowledgments ........................................ 14 7 References ............................................. 14 7.1 Normative References ................................... 14 - 7.2 Informative References ................................. 15 + 7.2 Informative References ................................. 14 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]. @@ -212,22 +212,21 @@ ::= [ ] [ ... ] [ ... ] [ ] 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. Association type specific - ordering requirements MAY be defined in the future. + 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 @@ -396,30 +395,26 @@ 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.) - Furthermore, per [TP-IDENTIFIERS], MPLS-TP LSPs can be identified in - two forms that cannot be supported using the existing ASSOCIATION - objects. The first form is a global identifier and the second uses - an ITU Carrier Code (ICC). The [TP-IDENTIFIERS] defined "global - identifier", or Global_ID, is based on [RFC5003] and includes the - operator's Autonomous System Number (ASN). [TP-IDENTIFIERS] - identifies the ICC as "a string of one to six characters, each - character being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9) - characters. Alphabetic characters in the ICC SHOULD be represented - with upper case letters." + 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 @@ -490,26 +485,26 @@ 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 [TP-IDENTIFIERS], the use of the + 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. This field is based on the definition of Global_ID defined in - [RFC5003] and used by [TP-IDENTIFIERS]. + [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 @@ -537,28 +532,20 @@ 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. - When used in support of ICC identified (MPLS-TP) LSPs, this field - MUST be at least eight (8) bytes long, and MAY be longer; the - first six (6) bytes MUST be set to the ICC as defined in Section - 3.2 of [TP-IDENTIFIERS] and the next two bytes MUST be set to - zero (0). For non-ICC identified MPLS-TP LSPs, this field MUST - either be omitted, or MUST have the first 6 bytes set to all - zeros (0s). - 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 @@ -689,32 +676,32 @@ [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", work in progress, RFC 5920, July 2010. + GMPLS Networks", RFC 5920, July 2010. - [TP-IDENTIFIERS] Bocci, M., Swallow, G., Gray, E., "MPLS-TP - Identifiers", work in progress, - draft-ietf-mpls-tp-identifiers. + [RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers", + RFC 6370, June 2011. 8. 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 @@ -715,11 +702,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: Mon, May 02, 2011 10:17:58 AM +Generated on: Fri, Oct 28, 2011 8:00:39 AM