GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6689

Internet Engineering Task Force (IETF) L. Berger Request for Comments: 6689 LabN Category: Informational July 2012 ISSN: 2070-1721

                Usage of the RSVP ASSOCIATION Object

Abstract

 The Resource Reservation Protocol (RSVP) ASSOCIATION object is
 defined in the context of GMPLS-controlled label switched paths
 (LSPs).  In this context, the object is used to associate recovery
 LSPs with the LSP they are protecting.  This document reviews how the
 association is to be provided in the context of GMPLS recovery.  No
 new procedures or mechanisms are defined by this document, and it is
 strictly informative in nature.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (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.
 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 Notice

 Copyright (c) 2012 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Berger Informational [Page 1] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

Table of Contents

 1. Introduction ....................................................2
 2. Background ......................................................2
    2.1. LSP Association ............................................3
    2.2. End-to-End Recovery LSP Association ........................4
    2.3. Segment Recovery LSP Association ...........................7
    2.4. Resource Sharing LSP Association ...........................8
 3. Association of GMPLS Recovery LSPs ..............................8
 4. Security Considerations ........................................10
 5. Acknowledgments ................................................10
 6. References .....................................................10
    6.1. Normative References ......................................10
    6.2. Informative References ....................................11

1. Introduction

 End-to-end and segment recovery are defined for GMPLS-controlled
 label switched paths (LSPs) in [RFC4872] and [RFC4873], respectively.
 Both definitions use the ASSOCIATION object to associate recovery
 LSPs with the LSP they are protecting.  This document provides
 additional narrative on how such associations are to be identified.
 This document does not define any new procedures or mechanisms and is
 strictly informative in nature.
 It may not be immediately obvious to the informed reader why this
 document is necessary; however, questions were repeatedly raised in
 the Common Control and Measurement Plane (CCAMP) working group on the
 proper interpretation of the ASSOCIATION object in the context of
 end-to-end and segment recovery, and the working group agreed that
 this document should be produced in order to close the matter.  This
 document formalizes the explanation provided in an e-mail to the
 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].

2. Background

 This section reviews the definition of LSP association in the
 contexts of end-to-end and segment recovery as defined in [RFC4872]
 and [RFC4873].  This section merely reiterates what has been defined;
 if differences exist between this text and [RFC4872] or [RFC4873],
 the earlier RFCs provide the authoritative text.

Berger Informational [Page 2] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

2.1. LSP Association

 [RFC4872] introduces the concept and mechanisms to support the
 association of one LSP to another LSP across different RSVP - Traffic
 Engineering (RSVP-TE) sessions.  Such association is enabled via the
 introduction of the ASSOCIATION object.  The ASSOCIATION object is
 defined in Section 16 of [RFC4872].  It is explicitly defined as
 having both general application and specific use within the context
 of recovery.  End-to-end recovery usage is defined in [RFC4872] and
 is covered in Section 2.2 of this document.  Segment recovery usage
 is defined in [RFC4873] and is covered in Section 2.3 of this
 document.  Resource sharing type LSP association is also defined in
 [RFC4873].  While strictly speaking, such association is beyond the
 scope of this document, it is covered in Section 2.4 of this document
 for completeness.  The remainder of this section covers generic usage
 of the ASSOCIATION object.
 In general, LSP association using the ASSOCIATION object can take
 place based on the values carried in the ASSOCIATION object.  This
 means that association between LSPs can take place independently of
 and across different sessions.  This is a significant enhancement
 from the association of LSPs that is possible in base MPLS [RFC3209]
 and GMPLS [RFC3473].
 When using the ASSOCIATION object, LSP association is always
 initiated by an upstream node that inserts appropriate ASSOCIATION
 objects in the Path message of LSPs that are to be associated.
 Downstream nodes then correlate LSPs based on received ASSOCIATION
 objects.  Multiple types of LSP association are supported by the
 ASSOCIATION object, and downstream correlation is made based on the
 type.
 [RFC4872] defines Class Types (C-Types) 1 and 2 of the ASSOCIATION
 object.  Both objects have essentially the same semantics, only
 differing in the type of address carried (IPv4 and IPv6).  The
 defined objects carry multiple fields.  The fields, taken together,
 enable the identification of which LSPs are in association with one
 another.  The [RFC4872]-defined fields are:
    o  Association Type:
       This field identifies the usage, or application, of the
       ASSOCIATION object.  The currently defined values are
       "Recovery" [RFC4872] and "Resource Sharing" [RFC4873].  This
       field also scopes the interpretation of the object.  In other
       words, the type field is included when matching LSPs (i.e., the
       type fields must match), and the way associations are
       identified may be type dependent.

Berger Informational [Page 3] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

    o  Association Source:
       This field is used to provide global scope (within the address
       space) to the identified association.  There are no specific
       rules in the general case for which an address should be used
       by a node creating an ASSOCIATION object beyond that the
       address is "associated to the node that originated the
       association", see [RFC4872].
    o  Association ID:
       This field provides an "identifier" that further scopes an
       association.  Again, this field is combined with the other
       ASSOCIATION object fields to support identification of
       associated LSPs.  The generic definition does not provide any
       specific rules on how matching is to be done, so such rules are
       governed by the Association Type.  Note that the definition
       permits the association of an arbitrary number of LSPs.
 As defined, the ASSOCIATION object may only be carried in a Path
 message, so LSP association takes place based on the Path state.  The
 definition permits one or more objects to be present.  The support
 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
 ASSOCIATION object to associate the LSP with another LSP for
 end-to-end recovery, and at the same time carry a second ASSOCIATION
 object to associate the LSP with another LSP for segment recovery,
 and at the same time carry a third ASSOCIATION object to associate
 the LSP with yet another LSP for resource sharing.

2.2. End-to-End Recovery LSP Association

 The association of LSPs in support of end-to-end LSP recovery is
 defined in Section 16.2 of [RFC4872].  There are also several
 additional related conformance statements (i.e., use of [RFC2119]
 defined key words) in Sections 7.3, 8.3, 9.3, and 11.1 of [RFC4872].
 When analyzing the definition, as with any Standards Track RFC, it is
 critical to note and differentiate which statements are made using
 [RFC2119] defined key words, which relate to conformance, and which
 statements are made without such key words, and are thereby only
 informative in nature.
 As defined in Section 16.2, end-to-end recovery-related LSP
 association may take place in two distinct forms:
    a. Between multiple (one or more) working LSPs and a single shared
       (associated) recovery LSP.  This form essentially matches the
       shared 1:N (N >= 1) recovery type described in the other
       sections of [RFC4872].

Berger Informational [Page 4] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

    b. Between a single working LSP and multiple (one or more)
       recovery LSPs.  This form essentially matches all other
       recovery types described in [RFC4872].
 Both forms share the same Association Type (Recovery) and the same
 Association Source (the working LSP's tunnel sender address).  They
 also share the same definition of the Association ID, which is
 (quoting [RFC4872]):
    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,
    this value is set to its own signaled LSP_ID value (default).
    Also, the value of the Association ID MAY change during the
    lifetime of the LSP.
 The interpretation of the above is fairly straightforward.  The
 Association ID carries one of three values:
    -  The LSP ID of the LSP being protected.
    -  The LSP ID of the protection LSP.
    -  In the case where the matching LSP is not yet known (i.e.,
       initiated), the LSP ID value of the LSP itself.
 The text also explicitly allows for changing the Association ID
 during the lifetime of an LSP.  However, this is only an option, and
 is neither required (i.e., "MUST") nor recommended (i.e., "SHOULD").
 It should be noted that [RFC4872] does not describe when such a
 change should be initiated or the procedures for executing such a
 change.  Clearly, care needs to be taken when changing the
 Association ID to ensure that the old association is not lost during
 the transition to a new association.
 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
 originated without any ASSOCIATION objects.  Again, this is a case
 that is not explicitly discussed in [RFC4872].
 From the above, this means that the following combinations may occur:
    Case 1. When the ASSOCIATION object of the LSP being protected is
            initialized before the ASSOCIATION objects of any recovery
            LSPs are initialized, the Association ID in the LSP being
            protected and any recovery LSPs will carry the same value,
            and this value will be the LSP ID value of the LSP being
            protected.

Berger Informational [Page 5] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

    Case 2. When the ASSOCIATION object of a recovery LSP is
            initialized before the ASSOCIATION object of any protected
            LSP is initialized, the Association ID in the recovery LSP
            and any LSPs being protected by that LSP will carry the
            same value, and this value will be the LSP ID value of the
            recovery LSP.
    Case 3. When the ASSOCIATION objects of both the LSP being
            protected and the recovery LSP are concurrently
            initialized, the value of the Association ID carried in
            the LSP being protected is the LSP ID value of the
            recovery LSP, and the value of the Association ID carried
            in the recovery LSP is the LSP ID value of the LSP being
            protected.  As this case can only be applied to LSPs with
            matching tunnel sender addresses, the scope of this case
            is limited to end-to-end recovery.  Note that this is
            implicit in [RFC4872], as its scope is limited to end-to-
            end recovery.
 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
 other end-to-end recovery types.  Case 3 is allowed, and it is
 subject to interpretation as to how often it will occur.  Some
 believe that this will be the common case and, furthermore, that
 working and recovery LSPs will often first be initiated without any
 ASSOCIATION objects, and then Case 3 objects will be added once the
 LSPs are established.  Others believe that Case 3 will rarely, if
 ever occur.  Such perspectives have little impact on
 interoperability, as an [RFC4872]-compliant implementation needs to
 properly handle (identify associations for) all three cases.
 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
 selected.  The other sections of the document do provide further
 narrative and three additional requirements.  In general, the
 narrative highlights Case 3 identified above but does not preclude
 the other cases.  The three additional requirements are, by [RFC4872]
 section number:
   o Section 7.3 -- "The Association ID MUST be set by default to the
     LSP ID of the protected LSP corresponding to N = 1."
     When considering this statement together with the three cases
     enumerated above, it can be seen that this statement clarifies
     which LSP ID value should be used when a single shared protection
     LSP is established simultaneously with Case 3, or after Case 2,
     and with more than one LSP to be protected.

Berger Informational [Page 6] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

   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
     the ASSOCIATION object, the Association ID to the associated
     primary working LSP_ID, which MUST be known before signaling of
     the secondary LSP."
     This requirement clarifies that when using the "Rerouting without
     Extra-Traffic" type of recovery, it is required to follow either
     Case 1 or 3, but not 2, as enumerated above.
   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
     the ASSOCIATION object, the Association ID to the associated
     primary working LSP_ID, which MUST be known before signaling of
     the secondary LSP."
     This requirement clarifies that when using the "Shared-Mesh
     Restoration" type of recovery, it is required to follow either
     Case 1 or 3, but not 2, as enumerated above.
   o Section 11.1 -- "In both cases, the Association ID of the
     ASSOCIATION object MUST be set to the LSP ID value of the
     signaled LSP."
     This requirement clarifies that when using the "LSP Rerouting"
     type of recovery, it is required to follow either Case 1 or 3,
     but not 2, as enumerated above.

2.3. Segment Recovery LSP Association

 GMPLS segment recovery is defined in [RFC4873].  Segment recovery
 reuses the LSP association mechanisms, including the Association Type
 field value, defined in [RFC4872].  The primary text to this effect
 in [RFC4873] is:
    3.2.1.  Recovery Type Processing
    Recovery type processing procedures are the same as those defined
    in [RFC4872], but processing and identification occur with respect
    to segment recovery LSPs.  Note that this means that multiple
    ASSOCIATION objects of type recovery may be present on an LSP.
 This statement means that Case 2, as enumerated above, is to be
 followed; furthermore, the Association Source is set to the tunnel
 sender address of the segment recovery LSPs.  The explicit exclusion
 of Case 3 is not listed, as its non-applicability is considered

Berger Informational [Page 7] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

 obvious to the informed reader.  (Perhaps having this exclusion
 explicitly identified would have obviated the need for this
 document.)

2.4. Resource Sharing LSP Association

 Section 3.2.2 of [RFC4873] defines an additional type of LSP
 association that is used for "Resource Sharing".  Resource sharing
 enables the sharing of resources across LSPs with different SESSION
 objects.  Without this object, only sharing across LSPs with a shared
 SESSION object is possible, see [RFC3209].
 Resource sharing is indicated using a new Association Type value.  As
 the Association Type field value is not the same as what is used in
 recovery type LSP association, the semantics used for the association
 of LSPs using an ASSOCIATION object containing the new type differs
 from recovery type LSP association.
 Section 3.2.2 of [RFC4873] states the following rules for the
 construction of an ASSOCIATION object in support of resource sharing
 type LSP association:
    o  The Association Type value is set to "Resource Sharing".
    o  Association Source is set to the originating node's router
       address.
    o  The Association ID is set to a value that uniquely identifies
       the set of LSPs to be associated.
       The setting of the Association ID value to the working LSP's
       LSP ID value is mentioned, but using the "MAY" key word.  Per
       [RFC2119], this translates to the use of the LSP ID value as
       being completely optional and that the choice of Association ID
       is truly up to the originating node.
 Additionally, the identical ASSOCIATION object is used for all LSPs
 that should be associated using Resource Sharing.  This differs from
 recovery type LSP association where it is possible for the LSPs to
 carry different Association ID fields and still be associated (see
 Case 3 in Section 2.2).

3. Association of GMPLS Recovery LSPs

 The previous section reviews the construction of an ASSOCIATION
 object, including the selection of the value used in the Association
 ID field, as defined in [RFC4872] and [RFC4873].  This section
 reviews how a downstream receiver identifies that one LSP is

Berger Informational [Page 8] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

 associated within another LSP based on ASSOCIATION objects.  Note
 that this section in no way modifies the normative definitions of
 end-to-end and segment recovery, see [RFC4872] or [RFC4873].
 As the ASSOCIATION object is only carried in Path messages, such
 identification only takes place based on Path state.  In order to
 support the identification of the recovery type association between
 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
 associated LSPs will carry the identical ASSOCIATION object.  This is
 also always true for resource sharing type LSP association, see
 Section 2.4.  Case 3 is more complicated, as it is possible for the
 LSPs to carry different Association ID fields and still be
 associated.  The receiver also needs to allow for changes in the set
 of ASSOCIATION objects included in an LSP.
 Based on the [RFC4872] and [RFC4873] definitions related to the
 ASSOCIATION object, the following behavior can be followed to ensure
 that a receiver always properly identifies the association between
 LSPs:
    o  Covering Cases 1 and 2 and resource sharing type LSP
       association:
       For ASSOCIATION objects with the Association Type field values
       of "Recovery" (1) and "Resource Sharing" (2), the association
       between LSPs is identified by comparing all fields of each of
       the ASSOCIATION objects carried in the Path messages associated
       with each LSP.  An association is deemed to exist when the same
       values are carried in all fields of an ASSOCIATION object
       carried in each LSP's Path message.  As more than one
       association may exist (e.g., in support of different
       association types or end-to-end and segment recovery), all
       carried ASSOCIATION objects need to be examined.
    o  Covering Case 3:
       Any ASSOCIATION object with the Association Type field value of
       "Recovery" (1) that does not yield an association in the prior
       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 first step is to locate any other LSPs with the identical
       SESSION object fields and the identical tunnel sender address
       fields as the LSP carrying the ASSOCIATION object.  If such
       LSPs exist, a case 3 association is identified by comparing the
       value of the Association ID field with the LSP ID field of the
       other LSP.  If the values are identical, then an end-to-end
       recovery association exists.  As this behavior only applies to

Berger Informational [Page 9] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

       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
 set of ASSOCIATION objects included in an LSP, as long as the change
 represents either a new association or a change in identifiers made
 as described in Section 2.2.

4. Security Considerations

 This document reviews procedures defined in [RFC4872] and [RFC4873]
 and does not define any new procedures.  As such, no new security
 considerations are introduced in this document.

5. Acknowledgments

 This document formalizes the explanation provided in an e-mail to the
 working group authored by Adrian Farrel, see [AF-EMAIL].  This
 document was written in response to questions raised in the CCAMP
 working group by Nic Neate <nhn@dataconnection.com>.  Valuable
 comments and input were also received from Dimitri Papadimitriou,
 Francois Le Faucheur, and Ashok Narayanan.

6. References

6.1. Normative References

 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC4872]  Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
            Ed., "RSVP-TE Extensions in Support of End-to-End
            Generalized Multi-Protocol Label Switching (GMPLS)
            Recovery", RFC 4872, May 2007.  Lang, J., Rekhter, Y., and
            Papadimitriou, D., "RSVP-TE
 [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
            "GMPLS Segment Recovery", RFC 4873, May 2007.
 [RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
            and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
            Tunnels", RFC 3209, December 2001.
 [RFC3473]  Berger, L., Ed., "Generalized Multi-Protocol Label
            Switching (GMPLS) Signaling Resource ReserVation
            Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
            3473, January 2003.

Berger Informational [Page 10] RFC 6689 RSVP ASSOCIATION Object Usage July 2012

6.2. Informative References

 [AF-EMAIL] Farrel, A. "Re: Clearing up your misunderstanding of the
            Association ID", CCAMP working group mailing list,
            http://www.ietf.org/mail-archive/web/ccamp/
            current/msg00644.html, November 18, 2008.

Author's Address

 Lou Berger
 LabN Consulting, L.L.C.
 Phone: +1-301-468-9228
 EMail: lberger@labn.net

Berger Informational [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6689.txt · Last modified: 2012/07/26 20:16 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki