draft-ietf-ccamp-assoc-ext-00.txt   draft-ietf-ccamp-assoc-ext-01.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco) Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco)
Category: Standards Track Ashok Narayanan (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 RSVP Association Object Extensions
draft-ietf-ccamp-assoc-ext-00.txt draft-ietf-ccamp-assoc-ext-01.txt
Abstract Abstract
The RSVP ASSOCIATION object was defined in the context of GMPLS The RSVP ASSOCIATION object was defined in the context of GMPLS
(Generalized Multi-Protocol Label Switching) controlled label (Generalized Multi-Protocol Label Switching) controlled label
switched paths (LSPs). In this context, the object is used to switched paths (LSPs). In this context, the object is used to
associate recovery LSPs with the LSP they are protecting. This associate recovery LSPs with the LSP they are protecting. This
object also has broader applicability as a mechanism to associate object also has broader applicability as a mechanism to associate
RSVP state, and this document defines how the ASSOCIATION object RSVP state, and this document defines how the ASSOCIATION object
can be more generally applied. This document also defines can be more generally applied. This document also defines
skipping to change at page 1, line 48 skipping to change at page 1, line 48
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html 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 and License Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2 Non-GMPLS Recovery Usage ............................... 4 2 Non-GMPLS Recovery Usage ............................... 4
2.1 Upstream Initiated Association ......................... 4 2.1 Upstream Initiated Association ......................... 4
2.1.1 Path Message Format .................................... 5 2.1.1 Path Message Format .................................... 5
2.1.2 Path Message Processing ................................ 5 2.1.2 Path Message Processing ................................ 5
2.2 Downstream Initiated Association ....................... 6 2.2 Downstream Initiated Association ....................... 6
2.2.1 Resv Message Format .................................... 7 2.2.1 Resv Message Format .................................... 7
2.2.2 Resv Message Processing ................................ 7 2.2.2 Resv Message Processing ................................ 7
2.3 Association Types ...................................... 8 2.3 Association Types ...................................... 8
2.3.1 Resource Sharing Association Type ...................... 8 2.3.1 Resource Sharing Association Type ...................... 8
3 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 9 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 3.2 Processing ............................................. 11
4 Security Considerations ................................ 13 4 Security Considerations ................................ 12
5 IANA Considerations .................................... 13 5 IANA Considerations .................................... 13
5.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 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 6 Acknowledgments ........................................ 14
7 References ............................................. 14 7 References ............................................. 14
7.1 Normative References ................................... 14 7.1 Normative References ................................... 14
7.2 Informative References ................................. 15 7.2 Informative References ................................. 14
8 Authors' Addresses ..................................... 15 8 Authors' Addresses ..................................... 15
1. Introduction 1. Introduction
End-to-end and segment recovery are defined for GMPLS (Generalized End-to-end and segment recovery are defined for GMPLS (Generalized
Multi-Protocol Label Switching) controlled label switched paths Multi-Protocol Label Switching) controlled label switched paths
(LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use (LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use
the ASSOCIATION object to associate recovery LSPs with the LSP they the ASSOCIATION object to associate recovery LSPs with the LSP they
are protecting. Additional narrative on how such associations are to are protecting. Additional narrative on how such associations are to
be identified is also provided in [ASSOC-INFO]. be identified is also provided in [ASSOC-INFO].
skipping to change at page 5, line 37 skipping to change at page 5, line 37
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <ASSOCIATION> ... ] [ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
[ <sender descriptor> ] [ <sender descriptor> ]
In general, relative ordering of ASSOCIATION objects with respect to In general, relative ordering of ASSOCIATION objects with respect to
each other as well as with respect to other objects is not each other as well as with respect to other objects is not
significant. Relative ordering of ASSOCIATION objects of the same significant. Relative ordering of ASSOCIATION objects of the same
type SHOULD be preserved by transit nodes. Association type specific type SHOULD be preserved by transit nodes.
ordering requirements MAY be defined in the future.
2.1.2. Path Message Processing 2.1.2. Path Message Processing
This section is based on the processing rules described in [RFC4872] This section is based on the processing rules described in [RFC4872]
and [RFC4873], and which is reviewed in [ASSOC-INFO]. These and [RFC4873], and which is reviewed in [ASSOC-INFO]. These
procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session
state. state.
A node that wishes to allow downstream nodes to associate Path state A node that wishes to allow downstream nodes to associate Path state
across RSVP sessions MUST include an ASSOCIATION object in the across RSVP sessions MUST include an ASSOCIATION object in the
skipping to change at page 9, line 25 skipping to change at page 9, line 25
Association Source field and a 16-bit Association ID field. The Association Source field and a 16-bit Association ID field. The
combination of the Association Source and the Association ID uniquely combination of the Association Source and the Association ID uniquely
identifies the association. Because the association-ID field is a identifies the association. Because the association-ID field is a
16-bit field, an association source can allocate up to 65536 16-bit field, an association source can allocate up to 65536
different associations and no more. There are scenarios where this different associations and no more. There are scenarios where this
number is insufficient. (For example where the association number is insufficient. (For example where the association
identification is best known and identified by a fairly centralized identification is best known and identified by a fairly centralized
entity, which therefore may be involved in a large number of entity, which therefore may be involved in a large number of
associations.) associations.)
Furthermore, per [TP-IDENTIFIERS], MPLS-TP LSPs can be identified in An additional case that cannot be supported using the existing
two forms that cannot be supported using the existing ASSOCIATION ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370],
objects. The first form is a global identifier and the second uses MPLS-TP LSPs can be identified based on an operator unique global
an ITU Carrier Code (ICC). The [TP-IDENTIFIERS] defined "global identifier. The [RFC6370] defined "global identifier", or Global_ID,
identifier", or Global_ID, is based on [RFC5003] and includes the is based on [RFC5003] and includes the operator's Autonomous System
operator's Autonomous System Number (ASN). [TP-IDENTIFIERS] Number (ASN).
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."
This sections defines new ASSOCIATION objects to support extended This sections defines new ASSOCIATION objects to support extended
identification in order to address the limitations described above. identification in order to address the limitations described above.
Specifically, the IPv4 Extended ASSOCIATION object and IPv6 Extended Specifically, the IPv4 Extended ASSOCIATION object and IPv6 Extended
ASSOCIATION object are defined below. Both new objects include the ASSOCIATION object are defined below. Both new objects include the
fields necessary to enable identification of a larger number of fields necessary to enable identification of a larger number of
associations, as well as MPLS-TP required identification. associations, as well as MPLS-TP required identification.
The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION
object SHOULD be supported by an implementation compliant with this object SHOULD be supported by an implementation compliant with this
skipping to change at page 11, line 24 skipping to change at page 11, line 20
the global identifier will be derived from the globally unique ASN the global identifier will be derived from the globally unique ASN
of the autonomous system hosting the Association Source. The of the autonomous system hosting the Association Source. The
special value of zero (0) indicates that no global identifier is special value of zero (0) indicates that no global identifier is
present. Note that a Global Association Source of zero SHOULD be present. Note that a Global Association Source of zero SHOULD be
limited to entities contained within a single operator. limited to entities contained within a single operator.
If the Global Association Source field value is derived from a 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 2-octet AS number, then the two high-order octets of this 4-octet
field MUST be set to zero. 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 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. 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 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 Extended Association ID: variable, 4-byte aligned
This field contains data that is additional information to support This field contains data that is additional information to support
unique identification. The length and contents of this field is unique identification. The length and contents of this field is
determined by the Association Source. This field MAY be omitted, determined by the Association Source. This field MAY be omitted,
i.e., have a zero length. This field MUST be padded with zeros i.e., have a zero length. This field MUST be padded with zeros
(0s) to ensure 32-bit alignment. (0s) to ensure 32-bit alignment.
3.2. Processing 3.2. Processing
skipping to change at page 12, line 23 skipping to change at page 12, line 20
o The Extended ASSOCIATION object originator MAY include the o The Extended ASSOCIATION object originator MAY include the
Extended Association ID field. The field is included based on Extended Association ID field. The field is included based on
local policy. The field MUST be included when the Association ID local policy. The field MUST be included when the Association ID
field is insufficient to uniquely identify association within the field is insufficient to uniquely identify association within the
scope of the source of the association. When included, this scope of the source of the association. When included, this
field MUST be set to a value that, when taken together with the field MUST be set to a value that, when taken together with the
other fields in the object, uniquely identifies the sessions to other fields in the object, uniquely identifies the sessions to
be associated. 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 o The object Length field is set based on the length of the
Extended Association ID field. When the Extended Association ID Extended Association ID field. When the Extended Association ID
field is omitted, the object Length field MUST be set to 16 or 28 field is omitted, the object Length field MUST be set to 16 or 28
for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the
Extended Association ID field is present, the object Length field Extended Association ID field is present, the object Length field
MUST be set to indicate the additional bytes carried in the MUST be set to indicate the additional bytes carried in the
Extended Association ID field, including pad bytes. Extended Association ID field, including pad bytes.
Note: per [RFC2205], the object Length field is set to the total 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 object length in bytes, and is always a multiple of 4, and at
skipping to change at page 15, line 41 skipping to change at page 15, line 22
[RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J., [RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J.,
"Attachment Individual Identifier (AII) Types for "Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, September 2007. Aggregation", RFC 5003, September 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session
Traversal Utilities for NAT (STUN)", RFC 5389, October Traversal Utilities for NAT (STUN)", RFC 5389, October
2008. 2008.
[RFC5920] Fang, L., et al, "Security Framework for MPLS and [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 [RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers",
Identifiers", work in progress, RFC 6370, June 2011.
draft-ietf-mpls-tp-identifiers.
8. Authors' Addresses 8. Authors' Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
Ashok Narayanan Ashok Narayanan
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
skipping to change at line 725 skipping to change at line 712
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
Ashok Narayanan Ashok Narayanan
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
United States United States
Email: ashokn@cisco.com Email: ashokn@cisco.com
Generated on: Mon, May 02, 2011 10:17:58 AM Generated on: Fri, Oct 28, 2011 8:00:39 AM
 End of changes. 17 change blocks. 
34 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/