draft-ietf-ccamp-assoc-info-03.txt   rfc6689.txt 
Internet Draft Lou Berger (LabN)
Category: Informational
Expiration Date: April 25, 2012
October 25, 2011
Usage of The RSVP Association Object Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6689 LabN
Category: Informational July 2012
ISSN: 2070-1721
draft-ietf-ccamp-assoc-info-03.txt Usage of the RSVP ASSOCIATION Object
Abstract Abstract
The RSVP ASSOCIATION object was defined in the context of GMPLS The Resource Reservation Protocol (RSVP) ASSOCIATION object is
(Generalized Multi-Protocol Label Switching) controlled label defined in the context of GMPLS-controlled label switched paths
switched paths (LSPs). In this context, the object is used to (LSPs). In this context, the object is used to associate recovery
associate recovery LSPs with the LSP they are protecting. This LSPs with the LSP they are protecting. This document reviews how the
document reviews how association is to be provided in the context association is to be provided in the context of GMPLS recovery. No
of GMPLS recovery. No new procedures or mechanisms are new procedures or mechanisms are defined by this document, and it is
defined by this document and it is strictly informative in nature. strictly informative in nature.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Status of This Memo
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is not an Internet Standards Track specification; it is
http://www.ietf.org/1id-abstracts.html published for informational purposes.
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
This Internet-Draft will expire on April 25, 2012 Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6689.
Copyright and License Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction ........................................... 3 1. Introduction ....................................................2
2 Background ............................................. 3 2. Background ......................................................2
2.1 LSP Association ........................................ 3 2.1. LSP Association ............................................3
2.2 End-to-End Recovery LSP Association .................... 5 2.2. End-to-End Recovery LSP Association ........................4
2.3 Segment Recovery LSP Association ....................... 8 2.3. Segment Recovery LSP Association ...........................7
2.4 Resource Sharing LSP Association ....................... 8 2.4. Resource Sharing LSP Association ...........................8
3 Association of GMPLS Recovery LSPs ..................... 9 3. Association of GMPLS Recovery LSPs ..............................8
4 Security Considerations ................................ 10 4. Security Considerations ........................................10
5 IANA Considerations .................................... 10 5. Acknowledgments ................................................10
6 Acknowledgments ........................................ 10 6. References .....................................................10
7 References ............................................. 10 6.1. Normative References ......................................10
7.1 Normative References ................................... 10 6.2. Informative References ....................................11
7.2 Informative References ................................. 11
8 Author's Addresses ..................................... 11
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-controlled
Multi-Protocol Label Switching) controlled label switched paths label switched paths (LSPs) in [RFC4872] and [RFC4873], respectively.
(LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use Both definitions use the ASSOCIATION object to associate recovery
the ASSOCIATION object to associate recovery LSPs with the LSP they LSPs with the LSP they are protecting. This document provides
are protecting. This document provides additional narrative on how additional narrative on how such associations are to be identified.
such associations are to be identified. This document does not This document does not define any new procedures or mechanisms and is
define any new procedures or mechanisms and is strictly informative strictly informative in nature.
in nature.
It may not be immediately obvious to the informed reader why this It may not be immediately obvious to the informed reader why this
document is necessary, however questions were repeatedly raised in document is necessary; however, questions were repeatedly raised in
the Common Control and Measurement Plane (CCAMP) working group on the the Common Control and Measurement Plane (CCAMP) working group on the
proper interpretation of the ASSOCIATION object in the context of proper interpretation of the ASSOCIATION object in the context of
end-to-end and segment recovery, and the working group agreed that end-to-end and segment recovery, and the working group agreed that
this document should be produced in order to close the matter. This this document should be produced in order to close the matter. This
document formalizes the explanation provided in an e-mail to the document formalizes the explanation provided in an e-mail to the
working group authored by Adrian Farrel, see [AF-EMAIL]. This working group authored by Adrian Farrel, see [AF-EMAIL]. This
document in no way modifies the normative definitions of end-to-end document in no way modifies the normative definitions of end-to-end
and segment recovery, see [RFC4872] or [RFC4873]. and segment recovery, see [RFC4872] or [RFC4873].
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]
and [RFC4873]. This section merely reiterates what has been defined, and [RFC4873]. This section merely reiterates what has been defined;
if differences exist between this text and [RFC4872] or [RFC4873], if differences exist between this text and [RFC4872] or [RFC4873],
the earlier RFCs provide the authoritative text. the earlier RFCs provide the authoritative text.
2.1. LSP Association 2.1. LSP Association
[RFC4872] introduces the concept and mechanisms to support the [RFC4872] introduces the concept and mechanisms to support the
association of one LSP to another LSP across different RSVP-TE association of one LSP to another LSP across different RSVP - Traffic
sessions. Such association is enabled via the introduction of the Engineering (RSVP-TE) sessions. Such association is enabled via the
ASSOCIATION object. The ASSOCIATION object is defined in Section 16 introduction of the ASSOCIATION object. The ASSOCIATION object is
of [RFC4872]. It is explicitly defined as having both general defined in Section 16 of [RFC4872]. It is explicitly defined as
application and specific use within the context of recovery. End-to- having both general application and specific use within the context
end recovery usage is defined in [RFC4872] and is covered in Section of recovery. End-to-end recovery usage is defined in [RFC4872] and
2.2. Segment recovery usage is defined in [RFC4873] and is covered is covered in Section 2.2 of this document. Segment recovery usage
in Section 2.3. Resource sharing LSP association is also defined in is defined in [RFC4873] and is covered in Section 2.3 of this
[RFC4873], while strictly speaking such association is beyond the document. Resource sharing type LSP association is also defined in
scope of this document, for completeness it is covered in Section [RFC4873]. While strictly speaking, such association is beyond the
2.4. The remainder of this section covers generic usage of the scope of this document, it is covered in Section 2.4 of this document
ASSOCIATION object. for completeness. The remainder of this section covers generic usage
of the ASSOCIATION object.
In general, LSP association using the ASSOCIATION object can take In general, LSP association using the ASSOCIATION object can take
place based on the values carried in the ASSOCIATION object. This place based on the values carried in the ASSOCIATION object. This
means that association between LSPs can take place independent from means that association between LSPs can take place independently of
and across different sessions. This is a significant enhancement and across different sessions. This is a significant enhancement
from the association of LSPs that is possible in base MPLS [RFC3209] from the association of LSPs that is possible in base MPLS [RFC3209]
and GMPLS [RFC3473]. and GMPLS [RFC3473].
When using ASSOCIATION object, LSP association is always initiated by When using the ASSOCIATION object, LSP association is always
an upstream node that inserts appropriate ASSOCIATION objects in the initiated by an upstream node that inserts appropriate ASSOCIATION
Path message of LSPs that are to be associated. Downstream nodes objects in the Path message of LSPs that are to be associated.
then correlate LSPs based on received ASSOCIATION objects. Multiple Downstream nodes then correlate LSPs based on received ASSOCIATION
types of LSP association is supported by the ASSOCIATION object, and objects. Multiple types of LSP association are supported by the
downstream correlation is made based on the type. ASSOCIATION object, and downstream correlation is made based on the
type.
[RFC4872] defines C-Types 1 and 2 of the ASSOCIATION object. Both [RFC4872] defines Class Types (C-Types) 1 and 2 of the ASSOCIATION
objects have essentially the same semantics, only differing in the object. Both objects have essentially the same semantics, only
type of address carried (IPv4 and IPv6). The defined objects carry differing in the type of address carried (IPv4 and IPv6). The
multiple fields. The fields, taken together, enable the defined objects carry multiple fields. The fields, taken together,
identification of which LSPs are association with one another. The enable the identification of which LSPs are in association with one
[RFC4872] defined fields are: another. The [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
[RFC4872] and Resource Sharing [RFC4873]. This field also scopes "Recovery" [RFC4872] and "Resource Sharing" [RFC4873]. This
the interpretation of the object. In other words, the type field field also scopes the interpretation of the object. In other
is included when matching LSPs (i.e., the type fields must words, the type field is included when matching LSPs (i.e., the
match), and the way associations are identified may be type type fields must match), and the way associations are
dependent. identified may be type dependent.
o Association Source: o Association Source:
This field is used to provide global scope (within the address This field is used to provide global scope (within the address
space) to the identified association. There are no specific space) to the identified association. There are no specific
rules in the general case for which address should be used by a rules in the general case for which an address should be used
node creating an ASSOCIATION object beyond that the address is by a node creating an ASSOCIATION object beyond that the
"associated to the node that originated the association", see address is "associated to the node that originated the
[RFC4872]. association", see [RFC4872].
o Association ID: o Association ID:
This field provides an "identifier" that further scopes an This field provides an "identifier" that further scopes an
association. Again, this field is combined with the other association. Again, this field is combined with the other
ASSOCIATION object fields to support identification of associated ASSOCIATION object fields to support identification of
LSPs. The generic definition does not provide any specific rules associated LSPs. The generic definition does not provide any
on how matching is to be done, so such rules are governed by the specific rules on how matching is to be done, so such rules are
Association Type. Note that the definition permits the governed by the Association Type. Note that the definition
association of an arbitrary number of LSPs. permits the association of an arbitrary number of LSPs.
As defined, the ASSOCIATION object may only be carried in a Path As defined, the ASSOCIATION object may only be carried in a Path
message, so LSP association takes place based on Path state. The message, so LSP association takes place based on the Path state. The
definition permits one or more objects to be present. The support definition permits one or more objects to be present. The support
for multiple objects enables an LSP to be associated with other LSPs for multiple objects enables an LSP to be associated with other LSPs
in more than one way at a time. For example, an LSP may carry one in more than one way at a time. For example, an LSP may carry one
ASSOCIATION object to associate the LSP with another LSP for end-to- ASSOCIATION object to associate the LSP with another LSP for
end recovery, and at the same time carry a second ASSOCIATION object end-to-end recovery, and at the same time carry a second ASSOCIATION
to associate the LSP with another LSP for segment recovery, and at object to associate the LSP with another LSP for segment recovery,
the same time carry a third ASSOCIATION object to associate the LSP and at the same time carry a third ASSOCIATION object to associate
with yet another LSP for resource sharing. the LSP with yet another LSP for resource sharing.
2.2. End-to-End Recovery LSP Association 2.2. End-to-End Recovery LSP Association
The association of LSPs in support of end-to-end LSP recovery is The association of LSPs in support of end-to-end LSP recovery is
defined in Section 16.2 of [RFC4872]. There are also several defined in Section 16.2 of [RFC4872]. There are also several
additional related conformance statements (i.e., use of [RFC2119] additional related conformance statements (i.e., use of [RFC2119]
defined key words) in Sections 7.3, 8.3, 9.3, 11.1. When analyzing defined key words) in Sections 7.3, 8.3, 9.3, and 11.1 of [RFC4872].
the definition, as with any Standards Track RFC, it is critical to When analyzing the definition, as with any Standards Track RFC, it is
note and differentiate which statements are made using [RFC2119] critical to note and differentiate which statements are made using
defined key words, which relate to conformance, and which statements [RFC2119] defined key words, which relate to conformance, and which
are made without such key words, which are only informative in statements are made without such key words, and are thereby only
nature. informative in nature.
As defined in Section 16.2, end-to-end recovery related LSP As defined in Section 16.2, end-to-end recovery-related LSP
association may take place in two distinct forms: association may take place in two distinct forms:
a. Between multiple (one or more) working LSPs and a single shared a. Between multiple (one or more) working LSPs and a single shared
(associated) recovery LSP. This form essentially matches the (associated) recovery LSP. This form essentially matches the
shared 1:N (N >= 1) recovery type described in the other shared 1:N (N >= 1) recovery type described in the other
sections of [RFC4872]. sections of [RFC4872].
b. Between a single working LSP and multiple (one or more) b. Between a single working LSP and multiple (one or more)
recovery LSPs. This form essentially matches all other recovery LSPs. This form essentially matches all other
recovery types described in [RFC4872]. recovery types described in [RFC4872].
Both forms share the same Association Type (Recovery) and the same Both forms share the same Association Type (Recovery) and the same
Association Source (the working LSP's tunnel sender address). They Association Source (the working LSP's tunnel sender address). They
also share the same definition of the Association ID, which is also share the same definition of the Association ID, which is
(quoting [RFC4872]): (quoting [RFC4872]):
"The Association ID MUST be set to the LSP ID of the LSP being The Association ID MUST be set to the LSP ID of the LSP being
protected by this LSP or the LSP protecting this LSP. If unknown, protected by this LSP or the LSP protecting this LSP. If unknown,
this value is set to its own signaled LSP ID value (default). this value is set to its own signaled LSP_ID value (default).
Also, the value of the Association ID MAY change during the Also, the value of the Association ID MAY change during the
lifetime of the LSP." lifetime of the LSP.
The interpretation of the above is fairly straightforward. The The interpretation of the above is fairly straightforward. The
Association ID carries one of 3 values: Association ID carries one of three values:
- The LSP ID of the LSP being protected. - The LSP ID of the LSP being protected.
- The LSP ID of the LSP protecting an LSP. - The LSP ID of the protection LSP.
- In the case where the matching LSP is not yet known (i.e., - In the case where the matching LSP is not yet known (i.e.,
initiated), the LSP ID value of the LSP itself. initiated), the LSP ID value of the LSP itself.
The text also explicitly allows for changing the Association ID The text also explicitly allows for changing the Association ID
during the lifetime of an LSP. But this is only an option, and is during the lifetime of an LSP. However, this is only an option, and
neither required (i.e., "MUST") nor recommended (i.e., "SHOULD"). It is neither required (i.e., "MUST") nor recommended (i.e., "SHOULD").
should be noted that the document does not describe when such a It should be noted that [RFC4872] does not describe when such a
change should be initiated, or the procedures for such a change. change should be initiated or the procedures for executing such a
Clearly care needs to be taken when changing the Association ID to change. Clearly, care needs to be taken when changing the
ensure that the old association is not lost during the transition to Association ID to ensure that the old association is not lost during
a new association. the transition to a new association.
The text does not preclude, and it is therefore assumed, that one or The text does not preclude, and it is therefore assumed, that one or
more ASSOCIATION objects may also be added to an LSP that was more ASSOCIATION objects may also be added to an LSP that was
originated without any ASSOCIATION objects. Again this is a case originated without any ASSOCIATION objects. Again, this is a case
that is not explicitly discussed in [RFC4872]. that is not explicitly discussed in [RFC4872].
From the above, this means that the following combinations may occur: From the above, this means that the following combinations may occur:
Case 1. When the ASSOCIATION object of the LSP being protected is Case 1. When the ASSOCIATION object of the LSP being protected is
initialized before the ASSOCIATION objects of any recovery initialized before the ASSOCIATION objects of any recovery
LSPs are initialized, the Association ID in the LSP being LSPs are initialized, the Association ID in the LSP being
protected and any recovery LSPs will carry the same value protected and any recovery LSPs will carry the same value,
and this value will be the LSP ID value of the LSP being and this value will be the LSP ID value of the LSP being
protected. protected.
Case 2. When the ASSOCIATION object of a recovery LSP is Case 2. When the ASSOCIATION object of a recovery LSP is
initialized before the ASSOCIATION object of any protected initialized before the ASSOCIATION object of any protected
LSP is initialized, the Association ID in the recovery LSP LSP is initialized, the Association ID in the recovery LSP
and any LSPs being protected by that LSP will carry the and any LSPs being protected by that LSP will carry the
same value and this value will be the LSP ID value of the same value, and this value will be the LSP ID value of the
recovery LSP. recovery LSP.
Case 3. When the ASSOCIATION objects of both the LSP being Case 3. When the ASSOCIATION objects of both the LSP being
protected and the recovery LSP are concurrently protected and the recovery LSP are concurrently
initialized, the value of the Association ID carried in initialized, the value of the Association ID carried in
the LSP being protected is the LSP ID value of the the LSP being protected is the LSP ID value of the
recovery LSP, and the value of the Association ID carried recovery LSP, and the value of the Association ID carried
in the recovery LSP is the LSP ID value of the LSP being in the recovery LSP is the LSP ID value of the LSP being
protected. As this case can only be applied to LSPs with protected. As this case can only be applied to LSPs with
matching tunnel sender addresses, the scope of this case matching tunnel sender addresses, the scope of this case
is limited to end-to-end recovery. Note that this is is limited to end-to-end recovery. Note that this is
implicit in [RFC4872] as its scope is limited to end-to- implicit in [RFC4872], as its scope is limited to end-to-
end recovery. end recovery.
In practical terms, case 2 will only occur when using the shared 1:N In practical terms, Case 2 will only occur when using the shared 1:N
(N >= 1) end-to-end recovery type and case 1 will occur with all (N >= 1) end-to-end recovery type, and Case 1 will occur with all
other end-to-end recovery types. Case 3 is allowed, and it is other end-to-end recovery types. Case 3 is allowed, and it is
subject to interpretation how often it will occur. Some believe that subject to interpretation as to how often it will occur. Some
this case is the common case and, furthermore, that working and believe that this will be the common case and, furthermore, that
recovery LSPs will often first be initiated without any ASSOCIATION working and recovery LSPs will often first be initiated without any
objects and then case 3 objects will be added once the LSPs are ASSOCIATION objects, and then Case 3 objects will be added once the
established. Others believe that case 3 will rarely if ever occur. LSPs are established. Others believe that Case 3 will rarely, if
Such perspectives have little impact on interoperability as a ever occur. Such perspectives have little impact on
[RFC4872] compliant implementation needs to properly handle (identify interoperability, as an [RFC4872]-compliant implementation needs to
associations for) all three cases. properly handle (identify associations for) all three cases.
It is important to note that Section 16.2 of [RFC4872] provides no It is important to note that Section 16.2 of [RFC4872] provides no
further requirements on how or when the Association ID value is to be further requirements on how or when the Association ID value is to be
selected. The other sections of the document do provide further selected. The other sections of the document do provide further
narrative and 3 additional requirements. In general, the narrative narrative and three additional requirements. In general, the
highlights case 3 identified above but does not preclude the other narrative highlights Case 3 identified above but does not preclude
cases. The 3 additional requirements are, by [RFC4872] Section the other cases. The three additional requirements are, by [RFC4872]
number: section number:
o Section 7.3 -- "The Association ID MUST be set by default to the o Section 7.3 -- "The Association ID MUST be set by default to the
LSP ID of the protected LSP corresponding to N = 1." LSP ID of the protected LSP corresponding to N = 1."
When considering this statement together with the 3 cases When considering this statement together with the three cases
enumerated above, it can be seen that this statement clarifies enumerated above, it can be seen that this statement clarifies
which LSP ID value should be used when a single shared protection which LSP ID value should be used when a single shared protection
LSP is established simultaneously with (case 3), or after (case LSP is established simultaneously with Case 3, or after Case 2,
2), and more than one LSP to be protected. and with more than one LSP to be protected.
o Section 8.3 -- "Secondary protecting LSPs are signaled by setting o Section 8.3 -- "Secondary protecting LSPs are signaled by setting
in the new PROTECTION object the S bit and the P bit to 1, and in in the new PROTECTION object the S bit and the P bit to 1, and in
the ASSOCIATION object, the Association ID to the associated the ASSOCIATION object, the Association ID to the associated
primary working LSP ID, which MUST be known before signaling of primary working LSP_ID, which MUST be known before signaling of
the secondary LSP." the secondary LSP."
This requirement clarifies that when using the Rerouting without This requirement clarifies that when using the "Rerouting without
Extra-Traffic type of recovery it is required to follow either Extra-Traffic" type of recovery, it is required to follow either
case 1 or 3, but not 2, as enumerated above. Case 1 or 3, but not 2, as enumerated above.
o Section 9.3 -- "Secondary protecting LSPs are signaled by setting o Section 9.3 -- "Secondary protecting LSPs are signaled by setting
in the new PROTECTION object the S bit and the P bit to 1, and in in the new PROTECTION object the S bit and the P bit to 1, and in
the ASSOCIATION object, the Association ID to the associated the ASSOCIATION object, the Association ID to the associated
primary working LSP ID, which MUST be known before signaling of primary working LSP_ID, which MUST be known before signaling of
the secondary LSP." the secondary LSP."
This requirement clarifies that when using the Shared-Mesh This requirement clarifies that when using the "Shared-Mesh
Restoration type of recovery it is required to follow either case Restoration" type of recovery, it is required to follow either
1 or 3, but not 2, as enumerated above. Case 1 or 3, but not 2, as enumerated above.
o Section 11.1 -- "In both cases, the Association ID of the o Section 11.1 -- "In both cases, the Association ID of the
ASSOCIATION object MUST be set to the LSP ID value of the ASSOCIATION object MUST be set to the LSP ID value of the
signaled LSP." signaled LSP."
This requirement clarifies that when using the LSP Rerouting type This requirement clarifies that when using the "LSP Rerouting"
of recovery it is required to follow either case 1 or 3, but not type of recovery, it is required to follow either Case 1 or 3,
2, as enumerated above. but not 2, as enumerated above.
2.3. Segment Recovery LSP Association 2.3. Segment Recovery LSP Association
GMPLS segment recovery is defined in [RFC4873]. Segment recovery GMPLS segment recovery is defined in [RFC4873]. Segment recovery
reuses the LSP association mechanisms, including the Association Type reuses the LSP association mechanisms, including the Association Type
field value, defined in [RFC4872]. The primary text to this effect field value, defined in [RFC4872]. The primary text to this effect
in [RFC4873] is: in [RFC4873] is:
3.2.1. Recovery Type Processing 3.2.1. Recovery Type Processing
Recovery type processing procedures are the same as those Recovery type processing procedures are the same as those defined
defined in [RFC4872], but processing and identification occur in [RFC4872], but processing and identification occur with respect
with respect to segment recovery LSPs. Note that this means to segment recovery LSPs. Note that this means that multiple
that multiple ASSOCIATION objects of type recovery may be ASSOCIATION objects of type recovery may be present on an LSP.
present on an LSP.
This statement means that case 2 as enumerated above is to be This statement means that Case 2, as enumerated above, is to be
followed and furthermore that Association Source is set to the tunnel followed; furthermore, the Association Source is set to the tunnel
sender address of the segment recovery LSPs. The explicit exclusion sender address of the segment recovery LSPs. The explicit exclusion
of case 3 is not listed as its non-applicability was considered of Case 3 is not listed, as its non-applicability is considered
obvious to the informed reader. (Perhaps having this exclusion obvious to the informed reader. (Perhaps having this exclusion
explicitly identified would have obviated the need for this explicitly identified would have obviated the need for this
document.) document.)
2.4. Resource Sharing LSP Association 2.4. Resource Sharing LSP Association
Section 3.2.2 of [RFC4873] defines an additional type of LSP Section 3.2.2 of [RFC4873] defines an additional type of LSP
association which is used for "Resource Sharing". Resource sharing association that is used for "Resource Sharing". Resource sharing
enables the sharing of resources across LSPs with different SESSION enables the sharing of resources across LSPs with different SESSION
objects. Without this object only sharing across LSPs with a shared objects. Without this object, only sharing across LSPs with a shared
SESSION object was possible, see [RFC3209]. SESSION object is possible, see [RFC3209].
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 what is used in
Recovery LSP association, the semantics used for the association of recovery type LSP association, the semantics used for the association
LSPs using an ASSOCIATION object containing the new type differs from of LSPs using an ASSOCIATION object containing the new type differs
Recovery LSP association. from recovery type 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: type LSP association:
o The Association Type value is set to "Resource Sharing". o The Association Type value is set to "Resource Sharing".
o Association Source is set to the originating node's router o Association Source is set to the originating node's router
address. address.
o The Association ID is set to a value that uniquely identifies the o The Association ID is set to a value that uniquely identifies
set of LSPs to be associated. the 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
ID value is mentioned, but using the "MAY" key word. Per LSP 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 the LSP ID value as
completely optional and that the choice of Association ID is being completely optional and that the choice of Association ID
truly up to the originating node. is 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 type LSP association where it is possible for the LSPs to
different Association ID fields and still be associated (see case 3 carry different Association ID fields and still be associated (see
in Section 2.2). Case 3 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
how a downstream receiver identifies that one LSP is associated reviews how a downstream receiver identifies that one LSP is
within another LSP based on ASSOCIATION objects. Note that this associated within another LSP based on ASSOCIATION objects. Note
section in no way modifies the normative definitions of end-to-end that this section in no way modifies the normative definitions of
and segment recovery, see [RFC4872] or [RFC4873]. end-to-end 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
associated. The receiver also needs to allow for changes in the set associated. The receiver also needs to allow for changes in the set
of ASSOCIATION objects included in an LSP. of ASSOCIATION objects included in an LSP.
Based on the [RFC4872] and [RFC4873] definitions related to the Based on the [RFC4872] and [RFC4873] definitions related to the
ASSOCIATION object, the following behavior can be followed to ensure ASSOCIATION object, the following behavior can be followed to ensure
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
"Recovery" (1) and "Resource Sharing" (2), the association of "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
ASSOCIATION objects carried in the Path messages associated with the ASSOCIATION objects carried in the Path messages associated
each LSP. An association is deemed to exist when the same values with each LSP. An association is deemed to exist when the same
are carried in all fields of an ASSOCIATION object carried in values are carried in all fields of an ASSOCIATION object
each LSP's Path message. As more than one association may exist carried in each LSP's Path message. As more than one
(e.g., in support of different association types or end-to-end association may exist (e.g., in support of different
and segment recovery), all carried ASSOCIATION objects need to be association types or end-to-end and segment recovery), all
examined. carried ASSOCIATION objects need to be 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
indicated. As this case only applies to end-to-end recovery, the is indicated. As this case only applies to end-to-end recovery,
first step is to locate any other LSPs with the identical SESSION the first step is to locate any other LSPs with the identical
object fields and the identical tunnel sender address fields as SESSION object fields and the identical tunnel sender address
the LSP carrying the ASSOCIATION object. If such LSPs exist, a fields as the LSP carrying the ASSOCIATION object. If such
case 3 association is identified by comparing the value of the LSPs exist, a case 3 association is identified by comparing the
Association ID field with the LSP ID field of the other LSP. If value of the Association ID field with the LSP ID field of the
the values are identical, then an end-to-end recovery association other LSP. If the values are identical, then an end-to-end
exists. As this behavior only applies to end-to-end recovery, recovery association exists. As this behavior only applies to
this check need only be performed at the egress. end-to-end recovery, 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. Security Considerations 4. Security Considerations
This document reviews procedures defined in [RFC4872] and [RFC4873] This document reviews procedures defined in [RFC4872] and [RFC4873]
and does not define any new procedures. As such, no new security and does not define any new procedures. As such, no new security
considerations are introduced in this document. considerations are introduced in this document.
5. IANA Considerations 5. Acknowledgments
There are no new IANA considerations introduced by this document.
6. Acknowledgments
This document formalizes the explanation provided in an e-mail to the This document formalizes the explanation provided in an e-mail to the
working group authored by Adrian Farrel, see [AF-EMAIL]. This working group authored by Adrian Farrel, see [AF-EMAIL]. This
document was written in response to questions raised in the CCAMP document was written in response to questions raised in the CCAMP
working group by Nic Neate <nhn@dataconnection.com>. Valuable working group by Nic Neate <nhn@dataconnection.com>. Valuable
comments and input was also received from Dimitri Papadimitriou, comments and input were also received from Dimitri Papadimitriou,
Francois Le Faucheur and Ashok Narayanan. Francois Le Faucheur, and Ashok Narayanan.
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4872] Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE [RFC4872] Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
Extensions in Support of End-to-End Generalized Multi- Ed., "RSVP-TE Extensions in Support of End-to-End
Protocol Label Switching (GMPLS) Recovery", RFC 4872, Generalized Multi-Protocol Label Switching (GMPLS)
May 2007. Recovery", RFC 4872, May 2007. Lang, J., Rekhter, Y., and
Papadimitriou, D., "RSVP-TE
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", RFC 4873, May 2007. "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
(GMPLS) Signaling Resource ReserVation Protocol-Traffic Switching (GMPLS) Signaling Resource ReserVation
Engineering (RSVP-TE) Extensions", RFC 3473, January Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
2003. 3473, January 2003.
7.2. Informative References 6.2. Informative References
[AF-EMAIL] Farrel, A. "Re: Clearing up your misunderstanding of [AF-EMAIL] Farrel, A. "Re: Clearing up your misunderstanding of the
the Association ID", CCAMP working group mailing list, Association ID", CCAMP working group mailing list,
http://www.ietf.org/mail-archive/web/ccamp/current/msg00644.html, http://www.ietf.org/mail-archive/web/ccamp/
November 18, 2008. current/msg00644.html, November 18, 2008.
8. Author's Addresses Author's Address
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
Generated on: Tue, Oct 25, 2011 4:01:38 PM
 End of changes. 87 change blocks. 
266 lines changed or deleted 254 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/