draft-ietf-ccamp-assoc-ext-03.txt   draft-ietf-ccamp-assoc-ext-04.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: September 9, 2012 Expiration Date: February 14, 2013
March 9, 2012 August 14, 2012
RSVP Association Object Extensions RSVP Association Object Extensions
draft-ietf-ccamp-assoc-ext-03.txt draft-ietf-ccamp-assoc-ext-04.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 the Transport Profile of Multiprotocol Label
(MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC Switching (MPLS-TP). This document updates RFC 2205, RFC 3209,
3473. It also modifies the definition of the Association ID field and RFC 3473. It also modifies the definition of the Association
defined in RFC 4872. 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 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 September 9, 2012 This Internet-Draft will expire on February 14, 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 25 skipping to change at page 2, line 25
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 Modified Association ID Field Definition ............... 4 2 Modified Association ID Field Definition ............... 4
3 Non-GMPLS Recovery Usage ............................... 5 3 Non-GMPLS and Non-Recovery Usage ....................... 5
3.1 Upstream Initiated Association ......................... 5 3.1 Upstream Initiated Association ......................... 5
3.1.1 Path Message Format .................................... 5 3.1.1 Path Message Format .................................... 5
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 .................................... 7 3.2.1 Resv Message Format .................................... 7
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
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 ....... 10 4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10
skipping to change at page 3, line 12 skipping to change at page 3, line 12
8.2 Informative References ................................. 15 8.2 Informative References ................................. 15
9 Authors' Addresses ..................................... 16 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 [RFC6689].
This document expands the possible usage of the ASSOCIATION object to This document expands the possible usage of the ASSOCIATION object to
non-GMPLS recovery contexts. This document reviews how association non-GMPLS and non-recovery contexts. This document reviews how
should be made in the case where the object is carried in a Path association should be made in the case where the object is carried in
message and defines usage with Resv messages. This section also a Path message and defines usage with Resv messages. This section
discusses usage of the ASSOCIATION object outside the context of also discusses usage of the ASSOCIATION object outside the context of
GMPLS LSPs. GMPLS LSPs.
Some examples of non-LSP association in order to enable resource Some examples of non-LSP association in order to enable resource
sharing are: sharing are:
o Voice Call-Waiting: o Voice Call-Waiting:
A bidirectional voice call between two endpoints A and B is A bidirectional voice call between two endpoints A and B is
signaled using two separate unidirectional RSVP reservations for signaled using two separate unidirectional RSVP reservations for
the flows A->B and B->A. If endpoint A wishes to put the A-B call the flows A->B and B->A. If endpoint A wishes to put the A-B call
on hold and join a separate A-C call, it is desirable that on hold and join a separate A-C call, it is desirable that
network resources on common links be shared between the A-B and network resources on common links be shared between the A-B and
A-C calls. The B->A and C->A subflows of the call can share A-C calls. The B->A and C->A subflows of the call can share
resources using existing RSVP sharing mechanisms, but only if resources using existing RSVP sharing mechanisms, but only if
they use the same destination IP addresses and ports. However, they use the same destination IP addresses and ports. Since, by
there is no way in RSVP today to share the resources between the definition, the RSVP reservations for the subflows A->B and A->C
A->B and A->C subflows of the call since by definition the RSVP of the call must have different IP addresses in the SESSION
reservations for these subflows must have different IP addresses objects, this document defines a new mechanism to associate the
in the SESSION objects. subflows and allow them to share resources.
o Voice Shared Line: o Voice Shared Line:
A single number that rings multiple endpoints (which may be A voice shared line is a single number that rings multiple
geographically diverse), such as phone lines on a manager's desk endpoints (which may be geographically diverse), such as phone
and their assistant. A VoIP system that models these calls as lines to a manager's desk and to their assistant. A VoIP system
multiple P2P unicast pre-ring reservations would result in that models these calls as multiple P2P unicast pre-ring
significantly over-counting bandwidth on shared links, since reservations would result in significantly over-counting
today unicast reservations to different endpoints cannot share bandwidth on shared links, since RSVP unicast reservations to
bandwidth. different endpoints cannot share bandwidth. So a new mechanism
is defined in this document allowing separate unicast
reservations to be associated and share resources.
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, since the
the SESSION objects for these two flows outside the NAT would SESSION objects for these two flows outside the NAT have
have different ports. different ports. This document defines a new mechanisms to
associate these flows and allow them to share resources.
In order to support the more general usage of the ASSOCIATION object, In order to support the more general usage of the ASSOCIATION object,
this document modifies the definition of the Association ID field this document modifies the definition of the Association ID field
defined in RFC 4872. This modification has no impact on existing defined in RFC 4872. This modification has no impact on existing
implementations. 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 the Transport Profile of Multiprotocol
Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION Label Switching (MPLS-TP). 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. Modified Association ID Field Definition 2. Modified Association ID Field Definition
skipping to change at page 5, line 5 skipping to change at page 5, line 5
ASSOCIATION objects as: ASSOCIATION objects as:
A value assigned by the the node that originated the association. A value assigned by the the node that originated the association.
When combined with the other fields carried in the object, this When combined with the other fields carried in the object, this
value uniquely identifies an association. value uniquely identifies an association.
This change in definition does not impact [RFC4872] or [RFC4873] This change in definition does not impact [RFC4872] or [RFC4873]
defined procedures or mechanisms, nor does it impact existing defined procedures or mechanisms, nor does it impact existing
implementations of [RFC4872] or [RFC4873]. implementations of [RFC4872] or [RFC4873].
3. Non-GMPLS Recovery Usage 3. Non-GMPLS and Non-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 specifies 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 [RFC6689], this is the case for Recovery
type association objects. [ASSOC-INFO], notably the text related to type association objects. [RFC6689], notably the text related to
resource sharing types, can also be used as the foundation for a resource sharing types, can also be used as the foundation for a
generic method for associating LSPs when there is no type-specific generic method for associating LSPs when there is no type-specific
association defined. 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 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. This section applies to the ASSOCIATION objects defined in
e.g., when processing an initial LSP or when the ASSOCIATION object [RFC4872].
contains otherwise useful information, and such cases do not alter
the processing defined below. This section applies to the
ASSOCIATION objects defined in [RFC4872].
3.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 section extends
extended by this section, which defined generic association rules and that definition by specifying generic association rules and usage for
usage for non-LSP uses. This section does not modify processing non-LSP uses. This section does not modify processing required to
required to support [RFC4872] and [RFC4873], and which is reviewed in support [RFC4872] and [RFC4873], and which is reviewed in Section 3
Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a of [RFC6689]. The use of an ASSOCIATION object in a single session
single session is not precluded. is not precluded.
3.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:
skipping to change at page 6, line 35 skipping to change at page 6, line 32
[ <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.
3.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 [RFC6689]. These procedures
procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state.
state.
A node sending a Path message chooses when an ASSOCIATION object is A node sending a Path message chooses when an ASSOCIATION object is
to be included in the outgoing Path message. A node that wishes to to be included in the outgoing Path message. To indicate association
allow downstream nodes to associate Path state across RSVP sessions between multiple sessions, an appropriate ASSOCIATION object MUST be
MUST include an ASSOCIATION object in the outgoing Path messages included in the outgoing Path messages corresponding to each of the
corresponding to the RSVP sessions to be associated. In the absence associated sessions. In the absence of Association Type-specific
of Association Type-specific rules for identifying association, the rules for identifying association, the included ASSOCIATION object
included ASSOCIATION objects MUST be identical across all associated MUST be identical. When there is an Association Type-specific
sessions. When there is an Association Type-specific definition of definition of association rules, the definition SHOULD allow for
association rules, the definition SHOULD allow for association based association based on identical ASSOCIATION objects. This document
on identical ASSOCIATION objects. This document does not define any does not define any Association Type-specific rules. (See Section 3
Association Type-specific rules. (See Section 3 of [ASSOC-INFO] for of [RFC6689] for a review of Association Type-specific rules derived
a review of Association Type-specific rules derived from [RFC4872].) 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 8, line 17 skipping to change at page 8, line 16
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <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 SHOULD be preserved by transit nodes.
ordering requirements MAY be defined in the future.
3.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 sending a Resv message chooses when an ASSOCIATION object is A node sending a Resv message chooses when an ASSOCIATION object is
to be included in the outgoing Resv message. A node that wishes to to be included in the outgoing Resv message. A node that wishes 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
skipping to change at page 9, line 25 skipping to change at page 9, line 22
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.
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
generally useful and its general use is defined in this section. applicable to any context and its general use is defined in this
section.
3.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
skipping to change at page 9, line 51 skipping to change at page 9, line 49
the Association Type field value of 2. ASSOCIATION objects with an the Association Type field value of 2. ASSOCIATION objects with an
Association Type with the value Resource Sharing MAY be carried in Association Type with the value Resource Sharing MAY be carried in
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 MUST be considered as
the identified sessions. Resource sharing is discussed in general in shared across the identified sessions by the admission control
function. Since the admission control function is outside the scope
[RFC2205] and within the context of LSPs in [RFC3209]. of RSVP, we observe that how resource sharing is actually reflected
may vary according to specific implementations (e.g. depending on the
specific admission control and resource management algorithm, or on
how local policy is taken into account).
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. The Association Source field and a 16-bit Association ID field. The
combination of the Association Source and the Association ID uniquely combination of the Association Source and the Association ID uniquely
identifies the association. Because the association-ID field is a identifies the association. Because the Association ID field is a
16-bit field, an association source can allocate up to 65536 16-bit field, an association source can allocate up to 65536
different associations and no more. There are scenarios where this different associations and no more. There are scenarios where this
number is insufficient. (For example where the association number is insufficient. (For example where the association
identification is best known and identified by a fairly centralized identification is best known and identified by a fairly centralized
entity, which therefore may be involved in a large number of entity, which therefore may be involved in a large number of
associations.) associations.)
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 12, line 7 skipping to change at page 12, line 7
Association ID: 16 bits Association ID: 16 bits
Same as for IPv4 and IPv6 ASSOCIATION objects, see Section 2. 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 or
This field MAY contain the 2-octet or 4-octet value of the the special value zero (0). When non-zero and not overridden by
provider's Autonomous System Number (ASN). It is expected that local policy, the Global_ID as defined in [RFC6370] SHALL be used.
the global identifier will be derived from the globally unique ASN The special value of zero indicates that no global identifier is
of the autonomous system hosting the Association Source. The present. Use of the special value of zero SHOULD be limited to
special value of zero (0) indicates that no global identifier is entities contained within a single operator.
present. Note that a Global Association Source of zero SHOULD be
limited to entities contained within a single operator.
If the Global Association Source field value is derived from a 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.
Note, as stated in [RFC6370], "the use of the Global_ID is not Note, as stated in [RFC6370], "the use of the Global_ID is not
related to the use of the ASN in protocols such as BGP." related to 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, scoped by the Association Source. The length of this field is
i.e., have a zero length. This field MUST be padded with zeros derived from the object Length field and as such MUST have a zero
(0s) to ensure 32-bit alignment. length or be 4-byte aligned. A zero length indicates that this
field is omitted.
4.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
skipping to change at page 14, line 46 skipping to change at page 14, line 46
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.
7. 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 Fei Zhang and Adrian Farrel. We thank Subha Dhesikan for her
early work on sharing of resources across RSVP reservations. contribution to the early work on sharing of resources across RSVP
reservations.
8. References 8. References
8.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.
skipping to change at page 15, line 40 skipping to change at page 15, line 40
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
"GMPLS Segment Recovery", RFC 4873, May 2007. "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
8.2. Informative References 8.2. Informative References
[ASSOC-INFO] Berger, L.., "Usage of The RSVP Association Object",
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,
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.,
"Generic Aggregate Resource ReSerVation Protocol (RSVP) "Generic Aggregate Resource ReSerVation Protocol (RSVP)
skipping to change at page 16, line 19 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.
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC
6689, July 2012.
9. 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
skipping to change at line 753 skipping to change at line 755
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
Ashok Narayanan Ashok Narayanan
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
United States United States
Email: ashokn@cisco.com Email: ashokn@cisco.com
Generated on: Mon, Feb 27, 2012 10:30:59 AM Generated on: Tue, Aug 14, 2012 9:39:19 AM
 End of changes. 29 change blocks. 
87 lines changed or deleted 89 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/