draft-ietf-ccamp-assoc-info-00.txt   draft-ietf-ccamp-assoc-info-01.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco) Updates: 2205, 3209, 3473 Francois Le Faucheur (Cisco)
Category: Standards Track Ashok Narayanan (Cisco) Category: Standards Track Ashok Narayanan (Cisco)
Expiration Date: April 14, 2011 Expiration Date: September 14, 2011
October 14, 2010 March 14, 2011
Usage of The RSVP Association Object Usage of The RSVP Association Object
draft-ietf-ccamp-assoc-info-00.txt draft-ietf-ccamp-assoc-info-01.txt
Abstract Abstract
The RSVP ASSOCIATION object was defined in the context of GMPLS The RSVP ASSOCIATION object was defined in the context of GMPLS
(Generalized Multi-Protocol Label Switching) controlled label (Generalized Multi-Protocol Label Switching) controlled label
switched paths (LSPs). In this context, the object is used to switched paths (LSPs). In this context, the object is used to
associate recovery LSPs with the LSP they are protecting. This associate recovery LSPs with the LSP they are protecting. This
object also has broader applicability as a mechanism to associate object also has broader applicability as a mechanism to associate
RSVP state, and this document defines how the ASSOCIATION object RSVP state, and this document defines how the ASSOCIATION object
can be more generally applied. The document also reviews how the can be more generally applied. The document also reviews how the
association is to be provided in the context of GMPLS recovery. association is to be provided in the context of GMPLS recovery.
No new new procedures or mechanisms are defined with respect to No new new procedures or mechanisms are defined with respect to
GMPLS recovery. GMPLS recovery. This document also defines extended ASSOCIATION
objects which can be used in the context of Transport Profile of
Multiprotocol Label Switching (MPLS-TP).
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 47 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 April 14, 2011 This Internet-Draft will expire on September 14, 2011
Copyright and License Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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 Background ............................................. 4 2 Background ............................................. 4
2.1 LSP Association ........................................ 4 2.1 LSP Association ........................................ 4
2.2 End-to-End Recovery LSP Association .................... 6 2.2 End-to-End Recovery LSP Association .................... 6
2.3 Segment Recovery LSP Association ....................... 8 2.3 Segment Recovery LSP Association ....................... 8
2.4 Resource Sharing LSP Association ....................... 9 2.4 Resource Sharing LSP Association ....................... 9
3 Association of GMPLS Recovery LSPs ..................... 10 3 Association of GMPLS Recovery LSPs ..................... 10
4 Non-Recovery Usage ..................................... 11 4 Non-GMPLS Recovery Usage ............................... 11
4.1 Upstream Initiated Association ......................... 11 4.1 Upstream Initiated Association ......................... 11
4.1.1 Path Message Format .................................... 12 4.1.1 Path Message Format .................................... 12
4.1.2 Path Message Processing ................................ 12 4.1.2 Path Message Processing ................................ 12
4.2 Downstream Initiated Association ....................... 13 4.2 Downstream Initiated Association ....................... 13
4.2.1 Resv Message Format .................................... 14 4.2.1 Resv Message Format .................................... 14
4.2.2 Resv Message Processing ................................ 14 4.2.2 Resv Message Processing ................................ 14
4.3 Association Types ...................................... 15 4.3 Association Types ...................................... 15
4.3.1 Resource Sharing Association Type ...................... 15 4.3.1 Resource Sharing Association Type ...................... 15
5 Extended IPv4 and IPv6 ASSOCIATION Objects ............. 16 5 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 16
5.1 Extended IPv4 and IPv6 ASSOCIATION Object Format ....... 16 5.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 17
6 Security Considerations ................................ 18 5.2 Processing ............................................. 18
7 IANA Considerations .................................... 18 6 Security Considerations ................................ 20
7.1 Extended IPv4 and IPv6 ASSOCIATION Objects ............. 18 7 IANA Considerations .................................... 20
7.2 Resource Sharing Association Type ...................... 19 7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 20
8 Acknowledgments ........................................ 19 7.2 Resource Sharing Association Type ...................... 21
9 References ............................................. 19 8 Acknowledgments ........................................ 21
9.1 Normative References ................................... 19 9 References ............................................. 21
9.2 Informative References ................................. 20 9.1 Normative References ................................... 21
10 Authors' Addresses ..................................... 20 9.2 Informative References ................................. 22
10 Authors' Addresses ..................................... 23
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. This document provides additional narrative on how are protecting. This document provides additional narrative on how
such associations are to be identified. In the context of GMPLS such associations are to be identified. In the context of GMPLS
recovery, this document does not define any new procedures or recovery, this document does not define any new procedures or
mechanisms and is strictly informative in nature. In this context, mechanisms and is strictly informative in nature.
this document formalizes the explanation provided in an e-mail to the
Common Control and Measurement Plane (CCAMP) working group authored
by Adrian Farrel, see [AF-EMAIL]. This document in no way modifies
the normative definitions of end-to-end and segment recovery, see
[RFC4872] or [RFC4873].
In addition to the narrative, this document also explicitly expands In addition to the narrative, this document also explicitly expands
the possible usage of the ASSOCIATION object in other contexts. In the possible usage of the ASSOCIATION object in other contexts. In
Section 4, this document reviews how association should be made in Section 4, this document reviews how association should be made in
the case where the object is carried in a Path message and defines the case where the object is carried in a Path message and defines
usage with Resv messages. This section also discusses usage of the usage with Resv messages. This section also discusses usage of the
ASSOCIATION object outside the context of GMPLS LSPs. ASSOCIATION object outside the context of 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:
skipping to change at page 4, line 15 skipping to change at page 4, line 7
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.
Section 5 of this document defines the extended ASSOCIATION objects
which can be used in the context of Transport Profile of
Multiprotocol Label Switching (MPLS-TP). Although, the scope of the
extended ASSOCIATION 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. Background 2. Background
This section reviews the definition of LSP association in the This section reviews the definition of LSP association in the
contexts of end-to-end and segment recovery as defined in [RFC4872] contexts of end-to-end and segment recovery as defined in [RFC4872]
skipping to change at page 5, line 13 skipping to change at page 5, line 11
When using ASSOCIATION object, LSP association is always initiated by When using ASSOCIATION object, LSP association is always initiated by
an upstream node that inserts appropriate ASSOCIATION objects in the an upstream node that inserts appropriate ASSOCIATION objects in the
Path message of LSPs that are to be associated. Downstream nodes Path message of LSPs that are to be associated. Downstream nodes
then correlate LSPs based on received ASSOCIATION objects. Multiple then correlate LSPs based on received ASSOCIATION objects. Multiple
types of LSP association is supported by the ASSOCIATION object, and types of LSP association is supported by the ASSOCIATION object, and
downstream correlation is made based on the type. downstream correlation is made based on the type.
[RFC4872] defines C-Types 1 and 2 of the ASSOCIATION object. Both [RFC4872] defines C-Types 1 and 2 of the ASSOCIATION object. Both
objects have essentially the same semantics, only differing in the objects have essentially the same semantics, only differing in the
type of address carried (IPv4 and IPv6). The defined objects carry type of address carried (IPv4 and IPv6). The defined objects carry
three fields. The three fields taken together enable the multiple fields. The fields, taken together, enable the
identification of which LSPs are association with one another. The identification of which LSPs are association with one another. The
three defined fields are: [RFC4872] defined fields are:
o Association Type: o Association Type:
This field identifies the usage, or application, of the This field identifies the usage, or application, of the
association object. The currently defined values are Recovery association object. The currently defined values are Recovery
[RFC4872] and Resource Sharing [RFC4873]. This field also scopes [RFC4872] and Resource Sharing [RFC4873]. This field also scopes
the interpretation of the object. In other words, the type field the interpretation of the object. In other words, the type field
is included when matching LSPs (i.e., the type fields must is included when matching LSPs (i.e., the type fields must
match), and the way associations are identified may be type match), and the way associations are identified may be type
dependent. dependent.
skipping to change at page 9, line 34 skipping to change at page 9, line 34
Resource sharing is indicated using a new Association Type value. As Resource sharing is indicated using a new Association Type value. As
the Association Type field value is not the same as is used in the Association Type field value is not the same as is used in
Recovery LSP association, the semantics used for the association of Recovery LSP association, the semantics used for the association of
LSPs using an ASSOCIATION object containing the new type differs from LSPs using an ASSOCIATION object containing the new type differs from
Recovery LSP association. Recovery LSP association.
Section 3.2.2 of [RFC4873] states the following rules for the Section 3.2.2 of [RFC4873] states the following rules for the
construction of an ASSOCIATION object in support of resource sharing construction of an ASSOCIATION object in support of resource sharing
LSP association: LSP association:
- The Association Type value is set to "Resource Sharing". o The Association Type value is set to "Resource Sharing".
- Association Source is set to the originating node's router o Association Source is set to the originating node's router
address. address.
- The Association ID is set to a value that uniquely identifies the o The Association ID is set to a value that uniquely identifies the
set of LSPs to be associated. set of LSPs to be associated.
The setting of the Association ID value to the working LSP's LSP The setting of the Association ID value to the working LSP's LSP
ID value is mentioned, but using the "MAY" key word. Per ID value is mentioned, but using the "MAY" key word. Per
[RFC2119], this translates to the use of LSP ID value as being [RFC2119], this translates to the use of LSP ID value as being
completely optional and that the choice of Association ID is completely optional and that the choice of Association ID is
truly up to the originating node. truly up to the originating node.
Additionally, the identical ASSOCIATION object is used for all LSPs Additionally, the identical ASSOCIATION object is used for all LSPs
that should be associated using Resource Sharing. This differs from that should be associated using Resource Sharing. This differs from
recovery LSP association where it is possible for the LSPs to carry recovery LSP association where it is possible for the LSPs to carry
different Association ID fields and still be associated (see case 3 different Association ID fields and still be associated (see case 3
in Section 2.2). in Section 2.2).
3. Association of GMPLS Recovery LSPs 3. Association of GMPLS Recovery LSPs
The previous section reviews the construction of an ASSOCIATION The previous section reviews the construction of an ASSOCIATION
object, including the selection of the value used in the Association object, including the selection of the value used in the Association
ID field, as defined in [RFC4872] and [RFC4873]. This section reviews ID field, as defined in [RFC4872] and [RFC4873]. This section reviews
how a downstream receiver identifies that one LSP is associated how a downstream receiver identifies that one LSP is associated
within another LSP based on ASSOCIATION objects. Note that in no way within another LSP based on ASSOCIATION objects. Note that this
does this section modify the normative definitions of end-to-end and section in no way modifies the normative definitions of end-to-end
segment recovery, see [RFC4872] or [RFC4873]. and segment recovery, see [RFC4872] or [RFC4873].
As the ASSOCIATION object is only carried in Path messages, such As the ASSOCIATION object is only carried in Path messages, such
identification only takes place based on Path state. In order to identification only takes place based on Path state. In order to
support the identification of the recovery type association between support the identification of the recovery type association between
LSPs, a downstream receiver needs to be able to handle all three LSPs, a downstream receiver needs to be able to handle all three
cases identified in Section 2.2. Cases 1 and 2 are simple as the cases identified in Section 2.2. Cases 1 and 2 are simple as the
associated LSPs will carry the identical ASSOCIATION object. This is associated LSPs will carry the identical ASSOCIATION object. This is
also always true for resource sharing type LSP association, see also always true for resource sharing type LSP association, see
Section 2.4. Case 3 is more complicated as it is possible for the Section 2.4. Case 3 is more complicated as it is possible for the
LSPs to carry different Association ID fields and still be LSPs to carry different Association ID fields and still be
skipping to change at page 10, line 39 skipping to change at page 10, line 39
that a receiver always properly identifies the association between that a receiver always properly identifies the association between
LSPs: LSPs:
o Covering cases 1 and 2 and resource sharing type LSP association: o Covering cases 1 and 2 and resource sharing type LSP association:
For ASSOCIATION objects with the Association Type field values of For ASSOCIATION objects with the Association Type field values of
"Recovery" (1) and "Resource Sharing" (2), the association "Recovery" (1) and "Resource Sharing" (2), the association
between LSPs is identified by comparing all fields of each of the between LSPs is identified by comparing all fields of each of the
ASSOCIATION objects carried in the Path messages associated with ASSOCIATION objects carried in the Path messages associated with
each LSP. An association is deemed to exist when the same values each LSP. An association is deemed to exist when the same values
are carried in all three fields of an ASSOCIATION object carried are carried in all fields of an ASSOCIATION object carried in
in each LSP's Path message. As more than one association may each LSP's Path message. As more than one association may exist
exist (e.g., in support of different association types or end-to- (e.g., in support of different association types or end-to-end
end and segment recovery), all carried ASSOCIATION objects need and segment recovery), all carried ASSOCIATION objects need to be
to be examined. examined.
o Covering case 3: o Covering case 3:
Any ASSOCIATION object with the Association Type field value of Any ASSOCIATION object with the Association Type field value of
"Recovery" (1) that does not yield an association in the prior "Recovery" (1) that does not yield an association in the prior
comparison needs to be checked to see if a case 3 association is comparison needs to be checked to see if a case 3 association is
indicated. As this case only applies to end-to-end recovery, the indicated. As this case only applies to end-to-end recovery, the
first step is to locate any other LSPs with the identical SESSION first step is to locate any other LSPs with the identical SESSION
object fields and the identical tunnel sender address fields as object fields and the identical tunnel sender address fields as
the LSP carrying the ASSOCIATION object. If such LSPs exist, a the LSP carrying the ASSOCIATION object. If such LSPs exist, a
skipping to change at page 11, line 13 skipping to change at page 11, line 13
Association ID field with the LSP ID field of the other LSP. If Association ID field with the LSP ID field of the other LSP. If
the values are identical, then an end-to-end recovery association the values are identical, then an end-to-end recovery association
exists. As this behavior only applies to end-to-end recovery, exists. As this behavior only applies to end-to-end recovery,
this check need only be performed at the egress. this check need only be performed at the egress.
No additional behavior is needed in order to support changes in the No additional behavior is needed in order to support changes in the
set of ASSOCIATION objects included in an LSP, as long as the change set of ASSOCIATION objects included in an LSP, as long as the change
represents either a new association or a change in identifiers made represents either a new association or a change in identifiers made
as described in Section 2.2. as described in Section 2.2.
4. Non-Recovery Usage 4. 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
Recovery, the object can have wider application. [RFC4872] defines GMPLS Recovery, the object can have wider application. [RFC4872]
the object to be used to "associate LSPs with each other", and then defines the object to be used to "associate LSPs with each other",
defines an Association Type field to identify the type of association and then defines an Association Type field to identify the type of
being identified. It also defines that the Association Type field is association being identified. It also defines that the Association
to be considered when determining association, i.e., there may be Type field is to be considered when determining association, i.e.,
type-specific association rules. As discussed above, this is the there may be type-specific association rules. As discussed above,
case for Recovery type association objects. The text above, notably this is the case for Recovery type association objects. The text
the text related to resource sharing types, can also be used as the above, notably the text related to resource sharing types, can also
foundation for a generic method for associating LSPs when there is no be used as the foundation for a generic method for associating LSPs
type-specific association defined. 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 below [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described below,
association is always done based on matching either Path state or association is always done based on matching either Path state or
Resv state, but not Path state to Resv State. Resv state, but not Path state to Resv State. This section applies
to the ASSOCIATION objects defined in [RFC4872].
4.1. Upstream Initiated Association 4.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
skipping to change at page 13, line 27 skipping to change at page 13, line 27
performing the following checks. When a node receives a Path message performing the following checks. When a node receives a Path message
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 three fields of the ASSOCIATION objects values are carried in all fields of the ASSOCIATION objects being
being compared. Processing once an association is identified is type compared. Processing once an association is identified is type
specific and is outside the scope of this document. specific and is outside the scope of this document.
Note that as more than one association may exist, all ASSOCIATION Note that as more than one association may exist, all ASSOCIATION
objects carried in a received Path message which have supported objects carried in a received Path message which have supported
association types MUST be compared against all Path state. association types MUST be compared against all Path state.
Unless there is 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 with MUST forward all ASSOCIATION objects received in a Path message with
any corresponding outgoing Path messages. any corresponding outgoing Path messages.
4.2. Downstream Initiated Association 4.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
skipping to change at page 15, line 13 skipping to change at page 15, line 13
performing the following checks. When a node receives a Resv message performing the following checks. When a node receives a Resv message
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 three fields of the ASSOCIATION objects values are carried in all fields of the ASSOCIATION objects being
being compared. Processing once an association is identified is type compared. Processing once an association is identified is type
specific and is outside the scope of this document. specific and is outside the scope of this document.
Note that as more than one association may exist, all ASSOCIATION Note that as more than one association may exist, all ASSOCIATION
objects with support Association Types carried in a received Resv objects with support Association Types carried in a received Resv
message MUST be compared against all Resv state. message MUST be compared against all Resv state.
Unless there is are type-specific processing rules, upstream nodes Unless there are type-specific processing rules, upstream nodes MUST
MUST forward all ASSOCIATION objects received in a Resv message with forward all ASSOCIATION objects received in a Resv message with any
any corresponding outgoing Resv messages. corresponding outgoing Resv messages.
4.3. Association Types 4.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.
4.3.1. Resource Sharing Association Type 4.3.1. Resource Sharing Association Type
skipping to change at page 16, line 7 skipping to change at page 16, line 7
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 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].
5. Extended IPv4 and IPv6 ASSOCIATION Objects 5. 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.)
This sections defines new ASSOCIATION objects to address this Furthermore, per [TP-IDENTIFIERS], MPLS-TP LSPs can be identified in
limitation. Specifically, the Extended IPv4 ASSOCIATION object and two forms that cannot be supported using the existing ASSOCIATION
Extended IPv6 ASSOCIATION object are defined below. Both new objects objects. The first form is a global identifier and the second uses
include an extended association ID field, which allows identification an ITU Carrier Code (ICC). The [TP-IDENTIFIERS] defined "global
of a larger number of associations scoped within a given association identifier", or Global_ID, is based on [RFC5003] and includes the
source IP address. operator's Autonomous System Number (ASN). [TP-IDENTIFIERS]
identifies the ICC as "a string of one to six characters, each
character being either alphabetic (i.e. A-Z) or numeric (i.e. 0-9)
characters. Alphabetic characters in the ICC SHOULD be represented
with upper case letters."
The Extended IPv4 ASSOCIATION object and Extended IPv6 ASSOCIATION This sections defines new ASSOCIATION objects to support extended
identification in order to address the limitations described above.
Specifically, the IPv4 Extended ASSOCIATION object and IPv6 Extended
ASSOCIATION object are defined below. Both new objects include the
fields necessary to enable identification of a larger number of
associations, as well as MPLS-TP required identification.
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 Extended IPv4 and IPv6 document. The processing rules for the IPv4 and IPv6 Extended
ASSOCIATION object are identical to those of the existing IPv4 and ASSOCIATION object are described below, and are based on the rules
IPv6 ASSOCIATION objects. for the IPv4 and IPv6 ASSOCIATION objects as described above.
5.1. Extended IPv4 and IPv6 ASSOCIATION Object Format 5.1. IPv4 and IPv6 Extended ASSOCIATION Object Format
The Extended IPv4 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID (Continued) | | IPv4 Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Association Source | | Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: Extended Association ID :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Extended IPv6 ASSOCIATION object (Class-Num of the form 11bbbbbb The IPv6 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Association ID (Continued) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| IPv6 Association Source | | IPv6 Association Source |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Association Source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: . :
: 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: 48 bits Association ID: 16 bits
Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872]. Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].
(Only the size of this field differs from the [RFC4872]
definition.)
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
This field contains a value that is unique to the provider, i.e.,
a global identifier. This field MAY contain the 2-octet or
4-octet value of the provider's Autonomous System Number (ASN).
It is expected that the global identifier will be derived from the
globally unique ASN of the autonomous system hosting the
Association Source. The special value of zero (0) indicates that
no global identifier is 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
2-octet AS number, then the two high-order octets of this 4-octet
field MUST be set to zero.
Please note that, as stated in [TP-IDENTIFIERS], the use of the
provider's ASN as a global identifier DOES NOT have anything at
all to do with the use of the ASN in protocols such as BGP.
This field is based on the definition of Global_ID defined in
[RFC5003] and used by [TP-IDENTIFIERS].
Extended Association ID: variable, 4-byte aligned
This field contains data that is additional information to support
unique identification. The length and contents of this field is
determined by the Association Source. This field MAY be omitted,
i.e., have a zero length. This field MUST be padded with zeros
(0s) to ensure 32-bit alignment.
5.2. Processing
The processing of a IPv4 or IPv6 Extended ASSOCIATION object MUST
identical to the processing of a IPv4 or IPv6 ASSOCIATION object as
described above in Section 4 except as extended by this section. This
section applies to both upstream-initiated (Path message) and
downstream-initiated (Resv message) association.
The following are the modified procedures for Extended ASSOCIATION
object processing:
o When creating an Extended ASSOCIATION object, the originator MUST
format the object as defined in this document.
o The originator MUST set the Association Type, Association ID and
Association Source fields as described in Section 4.
o When ASN-based global identification of the Association Source is
desired, the originator MUST set the Global Association Source
field. When ASN-based global identification is not desired, the
originator MUST set the Global Association Source field to zero
(0).
o The Extended ASSOCIATION object originator MAY include the
Extended Association ID field. The field is included based on
local policy. The field MUST be included when the Association ID
field is insufficient to uniquely identify association within the
scope of the source of the association. When included, this
field MUST be set to a value that, when taken together with the
other fields in the object, uniquely identifies the sessions to
be associated.
When used in support of ICC identified (MPLS-TP) LSPs, this field
MUST be at least eight (8) bytes long, and MAY be longer; the
first six (6) bytes MUST be set to the ICC as defined in Section
3.2 of [TP-IDENTIFIERS] and the next two bytes MUST be set to
zero (0). For non-ICC identified MPLS-TP LSPs, this field MUST
either be omitted, or MUST have the first 6 bytes set to all
zeros (0s).
o The object Length field is set based on the length of the
Extended Association ID field. When the Extended Association ID
field is omitted, the object Length field MUST be set to 16 or 28
for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the
Extended Association ID field is present, the object Length field
MUST be set to indicate the additional bytes carried in the
Extended Association ID field, including pad bytes.
Note: per [RFC2205], the object Length field is set to the total
object length in bytes, and is always a multiple of 4, and at
least 4.
Identification of association is not modified by this section. It is
important to note that Section 4 defines association identification
based on ASSOCIATION object matching, and that such matching is based
on the comparison of all fields in a ASSOCIATION object (unless type-
specific comparison rules are defined). This applies equally to
ASSOCIATION objects and Extended ASSOCIATION objects.
6. Security Considerations 6. Security Considerations
A portion of this document reviews procedures defined in [RFC4872] A portion of this document reviews procedures defined in [RFC4872]
and [RFC4873] and does not define any new procedures. As such, no and [RFC4873] and does not define any new procedures. As such, no
new security considerations are introduced in this portion. new security considerations are introduced in this portion.
Section 4 defines broader usage of the ASSOCIATION object, but does Section 4 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 5 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),
skipping to change at page 18, line 30 skipping to change at page 20, line 30
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].
7. IANA Considerations 7. 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.
7.1. Extended IPv4 and IPv6 ASSOCIATION Objects 7.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 5.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 Extended IPv4 Association [this document] 3 Type 3 IPv4 Extended Association [this document]
4 Type 4 Extended IPv6 Association [this document] 4 Type 4 IPv6 Extended Association [this document]
7.2. Resource Sharing Association Type 7.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
skipping to change at page 19, line 25 skipping to change at page 21, 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.
8. Acknowledgments 8. Acknowledgments
This document formalizes the explanation provided in an e-mail to the Sections 2 and 3 of this document formalizes the explanation provided
working group authored by Adrian Farrel, see [AF-EMAIL]. The document in an e-mail to the working group authored by Adrian Farrel, see [AF-
was written in response to questions raised in the CCAMP working EMAIL]. This portion of the document was written in response to
group by Nic Neate <nhn@dataconnection.com>. Valuable comments and questions raised in the CCAMP working group by Nic Neate
input was also received from Dimitri Papadimitriou. <nhn@dataconnection.com>. Valuable comments and input was also
received from Dimitri Papadimitriou.
We thank Subha Dhesikan for her contribution to the early work on We thank Subha Dhesikan for her contribution to the early work on
sharing of resources across RSVP reservations. sharing of resources across RSVP reservations.
9. References 9. References
9.1. Normative References 9.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) --
skipping to change at page 20, line 37 skipping to change at page 22, line 40
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)
Reservations", RFC 4860, May 2007. Reservations", RFC 4860, May 2007.
[RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J.,
"Attachment Individual Identifier (AII) Types for
Aggregation", RFC 5003, September 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session
Traversal Utilities for NAT (STUN)", RFC 5389, October Traversal Utilities for NAT (STUN)", RFC 5389, October
2008. 2008.
[RFC5920] Fang, L., et al, "Security Framework for MPLS and [RFC5920] Fang, L., et al, "Security Framework for MPLS and
GMPLS Networks", work in progress, RFC 5920, July 2010. GMPLS Networks", work in progress, RFC 5920, July 2010.
[TP-IDENTIFIERS] Bocci, M., Swallow, G., Gray, E., "MPLS-TP
Identifiers", work in progress,
draft-ietf-mpls-tp-identifiers.
10. Authors' Addresses 10. 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 964 skipping to change at line 1085
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: Thu, Oct 14, 2010 3:20:05 PM Generated on: Mon, Mar 14, 2011 7:36:53 AM
 End of changes. 48 change blocks. 
89 lines changed or deleted 210 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/