draft-ietf-ccamp-assoc-ext-01.txt   draft-ietf-ccamp-assoc-ext-02.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: April 28, 2012 Expiration Date: August 16, 2012
October 28, 2011 February 16, 2012
RSVP Association Object Extensions RSVP Association Object Extensions
draft-ietf-ccamp-assoc-ext-01.txt draft-ietf-ccamp-assoc-ext-02.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 April 28, 2012 This Internet-Draft will expire on August 16, 2012
Copyright and License Notice 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. 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
1.1 Conventions Used In This Document ...................... 4 1.1 Conventions Used In This Document ...................... 4
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 ....................... 7
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 ....... 9 3.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10
3.2 Processing ............................................. 11 3.2 Processing ............................................. 11
4 Security Considerations ................................ 12 4 Security Considerations ................................ 13
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 ...................... 13 5.2 Resource Sharing Association Type ...................... 14
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 ................................. 14 7.2 Informative References ................................. 15
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 4, line 24 skipping to change at page 4, line 24
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Non-GMPLS Recovery Usage 2. Non-GMPLS Recovery Usage
While the ASSOCIATION object, [RFC4872], is defined in the context of While the ASSOCIATION object, [RFC4872], is defined in the context of
GMPLS Recovery, the object can have wider application. [RFC4872] GMPLS Recovery, the object can have wider application. [RFC4872]
defines the object to be used to "associate LSPs with each other", defines the object to be used to "associate LSPs with each other",
and then defines an Association Type field to identify the type of and then defines an Association Type field to identify the type of
association being identified. It also defines that the Association association being identified. It also defines that the Association
Type field is to be considered when determining association, i.e., Type field is to be considered when determining association, i.e.,
there may be type-specific association rules. As discussed above, there may be type-specific association rules. As defined by
this is the case for Recovery type association objects. The text [RFC4872] and reviewed in [ASSOC-INFO], this is the case for Recovery
above, notably the text related to resource sharing types, can also type association objects. [ASSOC-INFO], notably the text related to
be used as the foundation for a generic method for associating LSPs resource sharing types, can also be used as the foundation for a
when there is no type-specific association defined. generic method for associating LSPs when there is no type-specific
association defined.
The remainder of this section defines the general rules to be The remainder of this section defines the general rules to be
followed when processing ASSOCIATION objects. Object usage in both followed when processing ASSOCIATION objects. Object usage in both
Path and Resv messages is discussed. The usage applies equally to Path and Resv messages is discussed. The usage applies equally to
GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions
[RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described below,
below,association is always done based on matching either Path state association is always done based on matching either Path state to
to Path state, or Resv state to Resv state, but not Path state to Path state, or Resv state to Resv state, but not Path state to Resv
Resv State. This section applies to the ASSOCIATION objects defined State. Note that there are times when no matching state is found,
in [RFC4872]. 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 2.1. Upstream Initiated Association
Upstream initiated association is represented in ASSOCIATION objects Upstream initiated association is represented in ASSOCIATION objects
carried in Path messages and can be used to associate RSVP Path state 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 tunnel is represented by a RSVP SESSION object, and multiple LSPs may
be represented within a single tunnel.) Cross-session association be represented within a single tunnel.) Cross-session association
based on Path state is defined in [RFC4872]. This definition is based on Path state is defined in [RFC4872]. This definition is
extended by this section, which defined generic association rules and extended by this section, which defined generic association rules and
usage for non-LSP uses. This section does not modify processing usage for non-LSP uses. This section does not modify processing
required to support [RFC4872] and [RFC4873], and which is reviewed required to support [RFC4872] and [RFC4873], and which is reviewed in
above in Section 3 of [ASSOC-INFO]. Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a
single session is not precluded.
2.1.1. Path Message Format 2.1.1. Path Message Format
This section provides the Backus-Naur Form (BNF), see [RFC5511], for This section provides the Backus-Naur Form (BNF), see [RFC5511], for
Path messages containing ASSOCIATION objects. BNF is provided for Path messages containing ASSOCIATION objects. BNF is provided for
both MPLS and for non-LSP session usage. Unmodified RSVP message both MPLS and for non-LSP session usage. Unmodified RSVP message
formats and some optional objects are not listed. formats and some optional objects are not listed.
The format for MPLS and GMPLS sessions is unmodified from [RFC4872], The format for MPLS and GMPLS sessions is unmodified from [RFC4872],
and can be represented based on the BNF in [RFC3209] as: and can be represented based on the BNF in [RFC3209] as:
skipping to change at page 5, line 46 skipping to change at page 5, line 50
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. type SHOULD be preserved by transit nodes.
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 initiating a Path message chooses when an ASSOCIATION object
across RSVP sessions MUST include an ASSOCIATION object in the is to be included in the outgoing Path message. A node that wishes
outgoing Path messages corresponding to the RSVP sessions to be to allow downstream nodes to associate Path state across RSVP
associated. In the absence of Association Type-specific rules for sessions MUST include an ASSOCIATION object in the outgoing Path
identifying association, the included ASSOCIATION objects MUST be messages corresponding to the RSVP sessions to be associated. In the
identical. When there is an Association Type-specific definition of absence of Association Type-specific rules for identifying
association rules, the definition SHOULD allow for association based association, the included ASSOCIATION objects MUST be identical
on identical ASSOCIATION objects. This document does not define any across all associated sessions. When there is an Association Type-
Association Type-specific rules. (See Section 3 for a discussion of specific definition of association rules, the definition SHOULD allow
an example of Association Type-specific rules which are derived from for association based on identical ASSOCIATION objects. This
[RFC4872].) 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 When creating an ASSOCIATION object, the originator MUST format the
object as defined in Section 16.1 of [RFC4872]. The originator MUST object as defined in Section 16.1 of [RFC4872]. The originator MUST
set the Association Type field based on the type of association being set the Association Type field based on the type of association being
identified. The Association ID field MUST be set to a value that identified. The Association ID field MUST be set to a value that
uniquely identifies the sessions to be associated within the context uniquely identifies the sessions to be associated within the context
of the Association Source field. The Association Source field MUST of the Association Source field. The Association Source field MUST
be set to a unique address assigned to the node originating the be set to a unique address assigned to the node originating the
association. association.
skipping to change at page 6, line 28 skipping to change at page 6, line 36
it MUST check each ASSOCIATION object received in the Path message to it MUST check each ASSOCIATION object received in the Path message to
see if it contains an Association Type field value supported by the see if it contains an Association Type field value supported by the
node. For each ASSOCIATION object containing a supported association node. For each ASSOCIATION object containing a supported association
type, the node MUST then check to see if the object matches an type, the node MUST then check to see if the object matches an
ASSOCIATION object received in any other Path message. To perform ASSOCIATION object received in any other Path message. To perform
this matching, a node MUST examine the Path state of all other this matching, a node MUST examine the Path state of all other
sessions and compare the fields contained in the newly received sessions and compare the fields contained in the newly received
ASSOCIATION object with the fields contained in the Path state's ASSOCIATION object with the fields contained in the Path state's
ASSOCIATION objects. An association is deemed to exist when the same ASSOCIATION objects. An association is deemed to exist when the same
values are carried in all fields of the ASSOCIATION objects being values are carried in all fields of the ASSOCIATION objects being
compared. Processing once an association is identified is type compared. Type-specific processing of ASSOCIATION objects is outside
specific and 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 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 Unless there are type-specific processing rules, downstream nodes
MUST forward all ASSOCIATION objects received in a Path message in MUST forward all ASSOCIATION objects received in a Path message in
any corresponding outgoing Path messages. any corresponding outgoing Path messages.
2.2. Downstream Initiated Association 2.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-session Resv state across MPLS Tunnels / RSVP sessions. Cross-session
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]. [RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a
single session is not precluded.
2.2.1. Resv Message Format 2.2.1. Resv Message Format
This section provides the Backus-Naur Form (BNF), see [RFC5511], for This section provides the Backus-Naur Form (BNF), see [RFC5511], for
Resv messages containing ASSOCIATION objects. BNF is provided for Resv messages containing ASSOCIATION objects. BNF is provided for
both MPLS and for non-LSP session usage. Unmodified RSVP message both MPLS and for non-LSP session usage. Unmodified RSVP message
formats and some optional objects are not listed. formats and some optional objects are not listed.
The format for MPLS, GMPLS and non-LSP sessions are identical, and is The format for MPLS, GMPLS and non-LSP sessions are identical, and is
represented based on the BNF in [RFC2205] and [RFC3209]: represented based on the BNF in [RFC2205] and [RFC3209]:
skipping to change at page 7, line 34 skipping to change at page 7, line 45
as well as with respect to other objects is not currently as well as with respect to other objects is not currently
significant. Relative ordering of ASSOCIATION objects of the same significant. Relative ordering of ASSOCIATION objects of the same
type MUST be preserved by transit nodes. Association type specific type MUST be preserved by transit nodes. Association type specific
ordering requirements MAY be defined in the future. ordering requirements MAY be defined in the future.
2.2.2. Resv Message Processing 2.2.2. Resv Message Processing
This section apply equally to GMPLS LSPs, MPLS LSPs and non-LSP This section apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
session state. session state.
A node that wishes to allow upstream nodes to associate Resv state A node initiating a Resv message chooses when an ASSOCIATION object
across RSVP sessions MUST include an ASSOCIATION object in the is to be included in the outgoing Resv message. A node that wishes
outgoing Resv messages corresponding to the RSVP sessions to be to allow upstream nodes to associate Resv state across RSVP sessions
associated. In the absence of Association Type-specific rules for MUST include an ASSOCIATION object in the outgoing Resv messages
identifying association, the included ASSOCIATION objects MUST be corresponding to the RSVP sessions to be associated. In the absence
identical. When there is an Association Type-specific definition of of Association Type-specific rules for identifying association, the
association rules, the definition SHOULD allow for association based included ASSOCIATION objects MUST be identical. When there is an
on identical ASSOCIATION objects. This document does not define any Association Type-specific definition of association rules, the
Association Type-specific rules. 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 When creating an ASSOCIATION object, the originator MUST format the
object as defined in Section 16.1 of [RFC4872]. The originator MUST object as defined in Section 16.1 of [RFC4872]. The originator MUST
set the Association Type field based on the type of association being set the Association Type field based on the type of association being
identified. The Association ID field MUST be set to a value that identified. The Association ID field MUST be set to a value that
uniquely identifies the sessions to be associated within the context uniquely identifies the sessions to be associated within the context
of the Association Source field. The Association Source field MUST of the Association Source field. The Association Source field MUST
be set to a unique address assigned to the node originating the be set to a unique address assigned to the node originating the
association. association.
skipping to change at page 8, line 14 skipping to change at page 8, line 28
it MUST check each ASSOCIATION object received in the Resv message to it MUST check each ASSOCIATION object received in the Resv message to
see if it contains an Association Type field value supported by the see if it contains an Association Type field value supported by the
node. For each ASSOCIATION object containing a supported association node. For each ASSOCIATION object containing a supported association
type, the node MUST then check to see if the object matches an type, the node MUST then check to see if the object matches an
ASSOCIATION object received in any other Resv message. To perform ASSOCIATION object received in any other Resv message. To perform
this matching, a node MUST examine the Resv state of all other this matching, a node MUST examine the Resv state of all other
sessions and compare the fields contained in the newly received sessions and compare the fields contained in the newly received
ASSOCIATION object with the fields contained in the Resv state's ASSOCIATION object with the fields contained in the Resv state's
ASSOCIATION objects. An association is deemed to exist when the same ASSOCIATION objects. An association is deemed to exist when the same
values are carried in all fields of the ASSOCIATION objects being values are carried in all fields of the ASSOCIATION objects being
compared. Processing once an association is identified is type compared. Type-specific processing of ASSOCIATION objects is outside
specific and 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. 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 Unless there are type-specific processing rules, upstream nodes MUST
forward all ASSOCIATION objects received in a Resv message in any forward all ASSOCIATION objects received in a Resv message in any
corresponding outgoing Resv messages. corresponding outgoing Resv messages.
2.3. Association Types 2.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
skipping to change at page 11, line 20 skipping to change at page 11, line 32
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 [RFC6370], the use of the Note, as stated in [RFC6370], "the use of the Global_ID is not
provider's ASN as a global identifier DOES NOT have anything at related to 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 [RFC6370]. [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
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 identical to the processing of a IPv4 or IPv6 ASSOCIATION object as
described above except as extended by this section. This section described above except as extended by this section. This section
applies to both upstream-initiated (Path message) and downstream- applies to ASSOCIATION objects included in both Path and Resv
initiated (Resv message) association. messages.
The following are the modified procedures for Extended ASSOCIATION The following are the modified procedures for Extended ASSOCIATION
object processing: object processing:
o When creating an Extended ASSOCIATION object, the originator MUST o When creating an Extended ASSOCIATION object, the originator MUST
format the object as defined in this document. format the object as defined in this document.
o The originator MUST set the Association Type, Association ID and o The originator MUST set the Association Type, Association ID and
Association Source fields as described in Section 4. Association Source fields as described in Section 4.
skipping to change at page 12, line 45 skipping to change at page 13, line 11
on the comparison of all fields in a ASSOCIATION object (unless type- on the comparison of all fields in a ASSOCIATION object (unless type-
specific comparison rules are defined). This applies equally to specific comparison rules are defined). This applies equally to
ASSOCIATION objects and Extended ASSOCIATION objects. ASSOCIATION objects and Extended ASSOCIATION objects.
4. Security Considerations 4. 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 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 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), the number of bits that are carried in an ASSOCIATION object (by 32),
and similarly does not expand on the association function that was and similarly does not expand on the association function that was
previously defined. This broader definition does allow for previously defined. This broader definition does allow for
additional information to be conveyed, but this information is not additional information to be conveyed, but this information is not
fundamentally different from the information that is already carried fundamentally different from the information that is already carried
in RSVP. Therefore there are no new risks or security considerations in RSVP. Therefore there are no new risks or security considerations
introduced by this document. introduced by this document.
For a general discussion on MPLS and GMPLS related security issues, For a general discussion on MPLS and GMPLS related security issues,
see the MPLS/GMPLS security framework [RFC5920]. see the MPLS/GMPLS security framework [RFC5920].
5. IANA Considerations 5. IANA Considerations
IANA is requested to administer assignment of new values for IANA is requested to administer assignment of new values for
namespaces defined in this document and summarized in this section. namespaces defined in this document and summarized in this section.
5.1. IPv4 and IPv6 Extended ASSOCIATION Objects 5.1. IPv4 and IPv6 Extended ASSOCIATION Objects
Upon approval of this document, IANA will make the assignment of two 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 ASSOCIATION object in the "Class Names, Class Numbers, and Class
Types" section of the "Resource Reservation Protocol (RSVP) Types" section of the "Resource Reservation Protocol (RSVP)
Parameters" registry located at http://www.iana.org/assignments/rsvp- Parameters" registry located at http://www.iana.org/assignments/rsvp-
parameters: parameters:
199 ASSOCIATION [RFC4872] 199 ASSOCIATION [RFC4872]
Class Types or C-Types Class Types or C-Types
3 Type 3 IPv4 Extended Association [this document] 3 Type 3 IPv4 Extended Association [this document]
skipping to change at page 14, line 7 skipping to change at page 14, line 25
OLD: OLD:
2 Resource Sharing (R) [RFC4873] 2 Resource Sharing (R) [RFC4873]
NEW NEW
2 Resource Sharing (S) [RFC4873][this-document] 2 Resource Sharing (S) [RFC4873][this-document]
There are no other IANA considerations introduced by this document. There are no other IANA considerations introduced by this document.
6. Acknowledgments 6. Acknowledgments
Valuable comments and input was received from Dimitri Papadimitriou. Valuable comments and input was received from Dimitri Papadimitriou
We thank Subha Dhesikan for her contribution to the early work on and Fei Zhang. We thank Subha Dhesikan for her contribution to the
sharing of resources across RSVP reservations. early work on sharing of resources across RSVP reservations.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReSerVation Protocol (RSVP) -- S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205, Version 1, Functional Specification", RFC 2205,
September 1997. September 1997.
skipping to change at page 14, line 46 skipping to change at page 15, line 16
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January Engineering (RSVP-TE) Extensions", RFC 3473, January
2003. 2003.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009 Specifications", RFC 5511, April 2009
7.2. Informative References 7.2. Informative References
[ASSOC-INFO] Berger, L., Faucheur, F., Narayanan, A., "Usage of [ASSOC-INFO] Berger, L.., "Usage of The RSVP Association Object",
The RSVP Association Object", work in progress, work in progress, draft-ietf-ccamp-assoc-info.
draft-ietf-ccamp-assoc-info.
[RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC [RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC
RSVP Extensions for IPSEC Data Flows", RFC 2207, September RSVP Extensions for IPSEC Data Flows", RFC 2207, September
1997. 1997.
[RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation [RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation
of RSVP for IPv4 and IPv6 Reservations", RFC 3175, of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001. September 2001.
[RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M., [RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M.,
skipping to change at line 712 skipping to change at line 721
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: Fri, Oct 28, 2011 8:00:39 AM Generated on: Wed, Feb 15, 2012 12:33:04 PM
 End of changes. 30 change blocks. 
65 lines changed or deleted 75 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/