draft-ietf-ccamp-assoc-ext-05.txt   draft-ietf-ccamp-assoc-ext-06.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco) Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco)
Category: Standards Track Ashok Narayanan (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 RSVP Association Object Extensions
draft-ietf-ccamp-assoc-ext-05.txt draft-ietf-ccamp-assoc-ext-06.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 49 skipping to change at page 1, line 49
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 March 5, 2013 This Internet-Draft will expire on March 21, 2013
Copyright and License Notice Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 37 skipping to change at page 2, line 37
3.1.1 Path Message Format .................................... 6 3.1.1 Path Message Format .................................... 6
3.1.2 Path Message Processing ................................ 6 3.1.2 Path Message Processing ................................ 6
3.2 Downstream Initiated Association ....................... 7 3.2 Downstream Initiated Association ....................... 7
3.2.1 Resv Message Format .................................... 8 3.2.1 Resv Message Format .................................... 8
3.2.2 Resv Message Processing ................................ 8 3.2.2 Resv Message Processing ................................ 8
3.3 Association Types ...................................... 9 3.3 Association Types ...................................... 9
3.3.1 Resource Sharing Association Type ...................... 9 3.3.1 Resource Sharing Association Type ...................... 9
3.3.2 Unknown Association Types .............................. 10 3.3.2 Unknown Association Types .............................. 10
4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10 4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10
4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 11 4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 11
4.2 Processing ............................................. 12 4.2 Processing ............................................. 13
5 Compatibility .......................................... 13 5 Compatibility .......................................... 14
6 Security Considerations ................................ 14 6 Security Considerations ................................ 14
7 IANA Considerations .................................... 14 7 IANA Considerations .................................... 15
7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 14 7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 15
7.2 Resource Sharing Association Type ...................... 15 7.2 Resource Sharing Association Type ...................... 15
8 Acknowledgments ........................................ 15 8 Acknowledgments ........................................ 16
9 References ............................................. 15 9 References ............................................. 16
9.1 Normative References ................................... 15 9.1 Normative References ................................... 16
9.2 Informative References ................................. 16 9.2 Informative References ................................. 16
10 Authors' Addresses ..................................... 17 10 Authors' Addresses ..................................... 17
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
skipping to change at page 7, line 41 skipping to change at page 7, line 41
the scope of this document. the scope of this document.
Note that as more than one association may exist, the described Note that as more than one association may exist, the described
matching MUST continue after a match is identified, and MUST be matching MUST continue after a match is identified, and MUST be
performed against all local Path state. It is also possible for performed against all local Path state. It is also possible for
there to be no match identified. there to be no match identified.
Unless there are type-specific processing rules, downstream nodes Unless there are type-specific processing rules, downstream nodes
MUST forward all ASSOCIATION objects received in a Path message, MUST forward all ASSOCIATION objects received in a Path message,
without modification, in any corresponding outgoing Path messages. without modification, in any corresponding outgoing Path messages.
This processing MUST be followed for unknown Association Type field
values.
3.2. Downstream Initiated Association 3.2. Downstream Initiated Association
Downstream initiated association is represented in ASSOCIATION Downstream initiated association is represented in ASSOCIATION
objects carried in Resv messages and can be used to associate RSVP objects carried in Resv messages and can be used to associate RSVP
Resv state across MPLS Tunnels / RSVP sessions. Cross-LSP Resv state across MPLS Tunnels / RSVP sessions. Cross-LSP
association based on Path state is defined in [RFC4872]. This section association based on Path state is defined in [RFC4872]. This section
defines cross-session association based on Resv state. This section defines cross-session association based on Resv state. This section
places no additional requirements on implementations supporting places no additional requirements on implementations supporting
[RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a [RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a
skipping to change at page 9, line 25 skipping to change at page 9, line 25
compared. Type-specific processing of ASSOCIATION objects is outside compared. Type-specific processing of ASSOCIATION objects is outside
the scope of this document. the scope of this document.
Note that as more than one association may exist, the described Note that as more than one association may exist, the described
matching MUST continue after a match is identified, and MUST be matching MUST continue after a match is identified, and MUST be
performed against all local Resv state. It is also possible for there performed against all local Resv state. It is also possible for there
to be no match identified. to be no match identified.
Unless there are type-specific processing rules, upstream nodes MUST Unless there are type-specific processing rules, upstream nodes MUST
forward all ASSOCIATION objects received in a Resv message, without 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 3.3. Association Types
Two association types are currently defined: recovery and resource Two association types are currently defined: recovery and resource
sharing. Recovery type association is only applicable within the sharing. Recovery type association is only applicable within the
context of recovery, [RFC4872] and [RFC4873]. Resource sharing is context of recovery, [RFC4872] and [RFC4873]. Resource sharing is
applicable to any context and its general use is defined in this applicable to any context and its general use is defined in this
section. section.
3.3.1. Resource Sharing Association Type 3.3.1. Resource Sharing Association Type
skipping to change at page 10, line 21 skipping to change at page 10, line 23
shared across the identified sessions by the admission control shared across the identified sessions by the admission control
function. Since the implementation specifics of the admission control function. Since the implementation specifics of the admission control
function is outside the scope of RSVP, we observe that how resource function is outside the scope of RSVP, we observe that how resource
sharing is actually reflected may vary according to specific sharing is actually reflected may vary according to specific
implementations (e.g. depending on the specific admission control and implementations (e.g. depending on the specific admission control and
resource management algorithm, or on how local policy is taken into resource management algorithm, or on how local policy is taken into
account). account).
3.3.2. Unknown Association Types 3.3.2. Unknown Association Types
A node that receives an ASSOCIATION object with an unknown As required by Sections 3.1.2 and 3.2.2 above, a node that receives
ASSOCIATION type MUST forward all received ASSOCIATION objects as an ASSOCIATION object containing an unknown ASSOCIATION type forwards
defined above. The node MAY also identify associations per the all received ASSOCIATION objects as defined above. The node MAY also
defined processing, e.g., to make this information available via a identify associations per the defined processing, e.g., to make this
management interface. information available via a management interface.
4. IPv4 and IPv6 Extended ASSOCIATION Objects 4. IPv4 and IPv6 Extended ASSOCIATION Objects
[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6
ASSOCIATION object. As defined, these objects each contain an ASSOCIATION object. As defined, these objects each contain an
Association Source field and a 16-bit Association ID field. As 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. Because the Association ID field is a 16-bit field, an
association source can allocate up to 65536 different associations association source can allocate up to 65536 different associations
and no more. There are scenarios where this number is insufficient. and no more. There are scenarios where this number is insufficient.
(For example where the association identification is best known and (For example where the association identification is best known and
identified by a fairly centralized entity, which therefore may be identified by a fairly centralized entity, which therefore may be
involved in a large number of associations.) involved in a large number of associations.)
An additional case that cannot be supported using the existing An additional case that cannot be supported using the existing
ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370], ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370],
MPLS-TP LSPs can be identified based on an operator unique global MPLS-TP LSPs can be identified based on an operator unique global
skipping to change at page 13, line 45 skipping to change at page 14, line 17
The procedures related to association identification are not modified The procedures related to association identification are not modified
by this section. It is important to note that Section 4 defines the by this section. It is important to note that Section 4 defines the
identification of associations based on ASSOCIATION object matching identification of associations based on ASSOCIATION object matching
and that such matching, in the absence of type-specific comparison and that such matching, in the absence of type-specific comparison
rules, is based on the comparison of all fields in an ASSOCIATION rules, is based on the comparison of all fields in an ASSOCIATION
object. This applies equally to ASSOCIATION objects and Extended object. This applies equally to ASSOCIATION objects and Extended
ASSOCIATION objects. ASSOCIATION objects.
5. Compatibility 5. Compatibility
Per [RFC4872], the ASSOCIATION object uses an object class number of Per [RFC4872], the ASSOCIATION object uses an object class number
the form 11bbbbbb to ensure compatibility with non- supporting nodes. of the form 11bbbbbb to ensure compatibility with non-supporting
Per [RFC2205], such nodes will ignore the object but forward it nodes. Per [RFC2205], such nodes will ignore the object but
without modification. This is essentially also the action taken for forward it without modification. This is also the action taken
unknown association types as discussed above in Section 3.3.2. for unknown association types as discussed above in Section
Operators wishing to use a function supported by particular 3.1.2,
association type should ensure that the type is supported on any node 3.2.2, and 3.3.2.
which is expected to act on the association.
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.
6. Security Considerations 6. Security Considerations
A portion of this document reviews procedures defined in [RFC4872] A portion of this document reviews procedures defined in [RFC4872]
and [RFC4873] and does not define any new procedures. As such, no and [RFC4873] and does not define any new procedures. As such, no
new security considerations are introduced in this portion. new security considerations are introduced in this portion.
Section 2 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 not fundamentally expand on the association function that was
previously defined in [RFC4872] and [RFC4873]. Section 3 increases previously defined in [RFC4872] and [RFC4873]. Section 3 increases
skipping to change at line 782 skipping to change at line 799
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: Wed, Sep 05, 2012 5:37:17 PM Generated on: Fri, Sep 21, 2012 9:36:09 AM
 End of changes. 13 change blocks. 
26 lines changed or deleted 43 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/