draft-ietf-ccamp-assoc-ext-02.txt   draft-ietf-ccamp-assoc-ext-03.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 2205, 3209, 3473 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: August 16, 2012 Expiration Date: September 9, 2012
February 16, 2012 March 9, 2012
RSVP Association Object Extensions RSVP Association Object Extensions
draft-ietf-ccamp-assoc-ext-02.txt draft-ietf-ccamp-assoc-ext-03.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
extended ASSOCIATION objects which, in particular, can be used in extended ASSOCIATION objects which, in particular, can be used in
the context of Transport Profile of Multiprotocol Label Switching the context of Transport Profile of Multiprotocol Label Switching
(MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC
3473. 3473. It also modifies the definition of the Association ID field
defined in RFC 4872.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 48 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 August 16, 2012 This Internet-Draft will expire on September 9, 2012
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
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 Modified Association ID Field Definition ............... 4
2.1 Upstream Initiated Association ......................... 4 3 Non-GMPLS Recovery Usage ............................... 5
2.1.1 Path Message Format .................................... 5 3.1 Upstream Initiated Association ......................... 5
2.1.2 Path Message Processing ................................ 5 3.1.1 Path Message Format .................................... 5
2.2 Downstream Initiated Association ....................... 7 3.1.2 Path Message Processing ................................ 6
2.2.1 Resv Message Format .................................... 7 3.2 Downstream Initiated Association ....................... 7
2.2.2 Resv Message Processing ................................ 7 3.2.1 Resv Message Format .................................... 7
2.3 Association Types ...................................... 8 3.2.2 Resv Message Processing ................................ 8
2.3.1 Resource Sharing Association Type ...................... 8 3.3 Association Types ...................................... 9
3 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 9 3.3.1 Resource Sharing Association Type ...................... 9
3.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10 4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10
3.2 Processing ............................................. 11 4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10
4 Security Considerations ................................ 13 4.2 Processing ............................................. 12
5 IANA Considerations .................................... 13 5 Security Considerations ................................ 13
5.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 13 6 IANA Considerations .................................... 14
5.2 Resource Sharing Association Type ...................... 14 6.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 14
6 Acknowledgments ........................................ 14 6.2 Resource Sharing Association Type ...................... 14
7 References ............................................. 14 7 Acknowledgments ........................................ 14
7.1 Normative References ................................... 14 8 References ............................................. 15
7.2 Informative References ................................. 15 8.1 Normative References ................................... 15
8 Authors' Addresses ..................................... 15 8.2 Informative References ................................. 15
9 Authors' Addresses ..................................... 16
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 5 skipping to change at page 4, line 5
o Symmetric NAT: o Symmetric NAT:
RSVP permits sharing of resources between multiple flows RSVP permits sharing of resources between multiple flows
addressed to the same destination D, even from different senders addressed to the same destination D, even from different senders
S1 and S2. However, if D is behind a NAT operating in symmetric S1 and S2. However, if D is behind a NAT operating in symmetric
mode [RFC5389], it is possible that the destination port of the mode [RFC5389], it is possible that the destination port of the
flows S1->D and S2->D may be different outside the NAT. In this flows S1->D and S2->D may be different outside the NAT. In this
case, these flows cannot share resources using RSVP today, since case, these flows cannot share resources using RSVP today, since
the SESSION objects for these two flows outside the NAT would the SESSION objects for these two flows outside the NAT would
have different ports. have different ports.
In order to support the more general usage of the ASSOCIATION object,
this document modifies the definition of the Association ID field
defined in RFC 4872. This modification has no impact on existing
implementations.
This document also defines the extended ASSOCIATION objects which can This document also defines the extended ASSOCIATION objects which can
be used in the context of Transport Profile of Multiprotocol Label be used in the context of Transport Profile of Multiprotocol Label
Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION
objects is not limited to MPLS-TP. objects is not limited to MPLS-TP.
1.1. Conventions Used In This Document 1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Non-GMPLS Recovery Usage 2. Modified Association ID Field Definition
The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION
objects defined in [RFC4872]. The [RFC4872] definition of the field
reads:
A value assigned by the LSP head-end. When combined with the
Association Type and Association Source, this value uniquely
identifies an association.
This document allows for the origination of ASSOCIATION objects by
nodes other than "the LSP head-end". As such, the definition of the
Association ID field needs to be modified to accommodate such usage.
This document defines the Association ID field of the IPv4 and IPv6
ASSOCIATION objects as:
A value assigned by the the node that originated the association.
When combined with the other fields carried in the object, this
value uniquely identifies an association.
This change in definition does not impact [RFC4872] or [RFC4873]
defined procedures or mechanisms, nor does it impact existing
implementations of [RFC4872] or [RFC4873].
3. 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 defined by there may be type-specific association rules. As defined by
[RFC4872] and reviewed in [ASSOC-INFO], this is the case for Recovery [RFC4872] and reviewed in [ASSOC-INFO], this is the case for Recovery
type association objects. [ASSOC-INFO], notably the text related to type association objects. [ASSOC-INFO], notably the text related to
skipping to change at page 4, line 44 skipping to change at page 5, line 33
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 below, [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described below,
association is always done based on matching either Path state to association is always done based on matching either Path state to
Path state, or Resv state to Resv state, but not Path state to Resv Path state, or Resv state to Resv state, but not Path state to Resv
State. Note that there are times when no matching state is found, State. Note that there are times when no matching state is found,
e.g., when processing an initial LSP or when the ASSOCIATION object e.g., when processing an initial LSP or when the ASSOCIATION object
contains otherwise useful information, and such cases do not alter contains otherwise useful information, and such cases do not alter
the processing defined below. This section applies to the the processing defined below. This section applies to the
ASSOCIATION objects defined in [RFC4872]. ASSOCIATION objects defined in [RFC4872].
2.1. Upstream Initiated Association 3.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 in required to support [RFC4872] and [RFC4873], and which is reviewed in
Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a
single session is not precluded. single session is not precluded.
2.1.1. Path Message Format 3.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:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
skipping to change at page 5, line 43 skipping to change at page 6, line 32
<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. type SHOULD be preserved by transit nodes.
2.1.2. Path Message Processing 3.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 initiating a Path message chooses when an ASSOCIATION object A node sending a Path message chooses when an ASSOCIATION object is
is to be included in the outgoing Path message. A node that wishes to be included in the outgoing Path message. A node that wishes to
to allow downstream nodes to associate Path state across RSVP allow downstream nodes to associate Path state across RSVP sessions
sessions MUST include an ASSOCIATION object in the outgoing Path MUST include an ASSOCIATION object in the outgoing Path messages
messages corresponding to the RSVP sessions to be associated. In the corresponding to the RSVP sessions to be associated. In the absence
absence of Association Type-specific rules for identifying of Association Type-specific rules for identifying association, the
association, the included ASSOCIATION objects MUST be identical included ASSOCIATION objects MUST be identical across all associated
across all associated sessions. When there is an Association Type- sessions. When there is an Association Type-specific definition of
specific definition of association rules, the definition SHOULD allow association rules, the definition SHOULD allow for association based
for association based on identical ASSOCIATION objects. This on identical ASSOCIATION objects. This document does not define any
document does not define any Association Type-specific rules. (See Association Type-specific rules. (See Section 3 of [ASSOC-INFO] for
Section 3 of [ASSOC-INFO] for a review of Association Type-specific a review of Association Type-specific rules derived from [RFC4872].)
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 7, line 5 skipping to change at page 7, line 34
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 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 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-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]. Note, the use of an ASSOCIATION object in a [RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a
single session is not precluded. single session is not precluded.
2.2.1. Resv Message Format 3.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]:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
skipping to change at page 7, line 40 skipping to change at page 8, line 20
[ <ASSOCIATION> ... ] [ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
Relative ordering of ASSOCIATION objects with respect to each other Relative ordering of ASSOCIATION objects with respect to each other
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 3.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 initiating a Resv message chooses when an ASSOCIATION object A node sending a Resv message chooses when an ASSOCIATION object is
is to be included in the outgoing Resv message. A node that wishes to be included in the outgoing Resv message. A node that wishes to
to allow upstream nodes to associate Resv state across RSVP sessions allow upstream nodes to associate Resv state across RSVP sessions
MUST include an ASSOCIATION object in the outgoing Resv messages MUST include an ASSOCIATION object in the outgoing Resv messages
corresponding to the RSVP sessions to be associated. In the absence corresponding to the RSVP sessions to be associated. In the absence
of Association Type-specific rules for identifying association, the of Association Type-specific rules for identifying association, the
included ASSOCIATION objects MUST be identical. When there is an included ASSOCIATION objects MUST be identical. When there is an
Association Type-specific definition of association rules, the Association Type-specific definition of association rules, the
definition SHOULD allow for association based on identical definition SHOULD allow for association based on identical
ASSOCIATION objects. This document does not define any Association ASSOCIATION objects. This document does not define any Association
Type-specific rules. Type-specific rules.
When creating an ASSOCIATION object, the originator MUST format the When creating an ASSOCIATION object, the originator MUST format the
skipping to change at page 8, line 40 skipping to change at page 9, line 20
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 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 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
generally useful and its general use is defined in this section. generally useful and its general use is defined in this section.
2.3.1. Resource Sharing Association Type 3.3.1. Resource Sharing Association Type
The resource sharing association type was defined in [RFC4873] and The resource sharing association type was defined in [RFC4873] and
was defined within the context of GMPLS and upstream initiated was defined within the context of GMPLS and upstream initiated
association. This section presents a definition of the resource association. This section presents a definition of the resource
sharing association that allows for its use with any RSVP session sharing association that allows for its use with any RSVP session
type and in both Path and Resv messages. This definition is type and in both Path and Resv messages. This definition is
consistent with the definition of the resource sharing association consistent with the definition of the resource sharing association
type in [RFC4873] and no changes are required by this section in type in [RFC4873] and no changes are required by this section in
order to support [RFC4873]. The Resource Sharing Association Type order to support [RFC4873]. The Resource Sharing Association Type
MUST be supported by any implementation compliant with this document. MUST be supported by any implementation compliant with this document.
skipping to change at page 9, line 24 skipping to change at page 10, line 4
Path and Resv messages. Association for the Resource Sharing type Path and Resv messages. Association for the Resource Sharing type
MUST follow the procedures defined in Section 4.1.2 for upstream MUST follow the procedures defined in Section 4.1.2 for upstream
(Path message) initiated association and Section 4.2.1 for downstream (Path message) initiated association and Section 4.2.1 for downstream
(Resv message) initiated association. There are no type-specific (Resv message) initiated association. There are no type-specific
association rules, processing rules, or ordering requirements. Note association rules, processing rules, or ordering requirements. Note
that as is always the case with association as enabled by this that as is always the case with association as enabled by this
document, no associations are made across Path and Resv state. document, no associations are made across Path and Resv state.
Once an association is identified, resources SHOULD be shared across Once an association is identified, resources SHOULD be shared across
the identified sessions. Resource sharing is discussed in general in the identified sessions. Resource sharing is discussed in general in
[RFC2205] and within the context of LSPs in [RFC3209]. [RFC2205] and within the context of LSPs in [RFC3209].
3. 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. 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
skipping to change at page 10, line 11 skipping to change at page 10, line 41
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
document. The processing rules for the IPv4 and IPv6 Extended document. The processing rules for the IPv4 and IPv6 Extended
ASSOCIATION object are described below, and are based on the rules ASSOCIATION object are described below, and are based on the rules
for the IPv4 and IPv6 ASSOCIATION objects as described above. for the IPv4 and IPv6 ASSOCIATION objects as described above.
3.1. IPv4 and IPv6 Extended ASSOCIATION Object Format 4.1. IPv4 and IPv6 Extended ASSOCIATION Object Format
The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb
with value = 199, C-Type = TBA) has the format: with value = 199, C-Type = TBA) has the format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Class-Num(199)| C-Type (TBA) | | Length | Class-Num(199)| C-Type (TBA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association Type | Association ID | | Association Type | Association ID |
skipping to change at page 11, line 11 skipping to change at page 11, line 49
: Extended Association ID : : Extended Association ID :
: . : : . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Association Type: 16 bits Association Type: 16 bits
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
Association ID: 16 bits Association ID: 16 bits
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. Same as for IPv4 and IPv6 ASSOCIATION objects, see Section 2.
Association Source: 4 or 16 bytes Association Source: 4 or 16 bytes
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
Global Association Source: 4 bytes Global Association Source: 4 bytes
This field contains a value that is a unique global identifier. This field contains a value that is a unique global identifier.
This field MAY contain the 2-octet or 4-octet value of the This field MAY contain the 2-octet or 4-octet value of the
provider's Autonomous System Number (ASN). It is expected that provider's Autonomous System Number (ASN). It is expected that
skipping to change at page 11, line 46 skipping to change at page 12, line 34
[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 4.2. Processing
The processing of a IPv4 or IPv6 Extended ASSOCIATION object MUST be 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 ASSOCIATION objects included in both Path and Resv applies to ASSOCIATION objects included in both Path and Resv
messages. messages.
The following are the modified procedures for Extended ASSOCIATION The following are the modified procedures for Extended ASSOCIATION
object processing: object processing:
skipping to change at page 13, line 5 skipping to change at page 13, line 34
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
least 4. least 4.
Identification of association is not modified by this section. It is Identification of association is not modified by this section. It is
important to note that Section 4 defines association identification important to note that Section 4 defines association identification
based on ASSOCIATION object matching, and that such matching is based based on ASSOCIATION object matching, and that such matching is based
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 5. 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
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 6. 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 6.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 3.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]
4 Type 4 IPv6 Extended Association [this document] 4 Type 4 IPv6 Extended Association [this document]
5.2. Resource Sharing Association Type 6.2. Resource Sharing Association Type
This document also broadens the potential usage of the Resource This document also broadens the potential usage of the Resource
Sharing Association Type defined in [RFC4873]. As such, IANA is Sharing Association Type defined in [RFC4873]. As such, IANA is
requested to change the Reference of the Resource Sharing Association requested to change the Reference of the Resource Sharing Association
Type included in the associate registry. This document also directs Type included in the associate registry. This document also directs
IANA to correct the duplicate usage of '(R)' in this Registry. In IANA to correct the duplicate usage of '(R)' in this Registry. In
particular, the Association Type registry found at particular, the Association Type registry found at
http://www.iana.org/assignments/gmpls-sig-parameters/ should be http://www.iana.org/assignments/gmpls-sig-parameters/ should be
updated as follows: updated as follows:
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 7. Acknowledgments
Valuable comments and input was received from Dimitri Papadimitriou Valuable comments and input was received from Dimitri Papadimitriou
and Fei Zhang. We thank Subha Dhesikan for her contribution to the and Fei Zhang. We thank Subha Dhesikan for her contribution to the
early work on sharing of resources across RSVP reservations. early work on sharing of resources across RSVP reservations.
7. References 8. References
7.1. Normative References 8.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.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching
(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.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
Extensions in Support of End-to-End Generalized Multi-
Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
"GMPLS Segment Recovery", RFC 4873, May 2007.
[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 8.2. Informative References
[ASSOC-INFO] Berger, L.., "Usage of The RSVP Association Object", [ASSOC-INFO] Berger, L.., "Usage of The RSVP Association Object",
work in progress, draft-ietf-ccamp-assoc-info. work in progress, 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,
skipping to change at page 15, line 45 skipping to change at page 16, line 19
[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", RFC 5920, July 2010. GMPLS Networks", RFC 5920, July 2010.
[RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers", [RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers",
RFC 6370, June 2011. RFC 6370, June 2011.
8. Authors' Addresses 9. 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 721 skipping to change at line 753
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, Feb 15, 2012 12:33:04 PM Generated on: Mon, Feb 27, 2012 10:30:59 AM
 End of changes. 37 change blocks. 
73 lines changed or deleted 105 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/