Movatterモバイル変換

Internet Engineering Task Force (IETF)                         L. BergerRequest for Comments: 6689                                          LabNCategory: Informational                                        July 2012ISSN: 2070-1721Usage of the RSVP ASSOCIATION ObjectAbstract   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; seeSection 2 of RFC 5741.   Information about the current status of this document, any   errata, and how to provide feedback on it may be obtained athttp://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 toBCP 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 2012Table of Contents1. Introduction ....................................................22. Background ......................................................22.1. LSP Association ............................................32.2. End-to-End Recovery LSP Association ........................42.3. Segment Recovery LSP Association ...........................72.4. Resource Sharing LSP Association ...........................83. Association of GMPLS Recovery LSPs ..............................84. Security Considerations ........................................105. Acknowledgments ................................................106. References .....................................................106.1. Normative References ......................................106.2. Informative References ....................................111.  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 20122.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 inSection 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 inSection 2.2 of this document.  Segment recovery usage   is defined in [RFC4873] and is covered inSection 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 inSection 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 inSection 16.2 of [RFC4872].  There are also several   additional related conformance statements (i.e., use of [RFC2119]   defined key words) in Sections7.3,8.3,9.3, and11.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 inSection 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 thatSection 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:     oSection 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     oSection 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.     oSection 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.     oSection 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 consideredBerger                        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 AssociationSection 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 inSection 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 isBerger                        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 inSection 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, seeSection 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 toBerger                        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 inSection 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.  References6.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",RFC3473, January 2003.Berger                        Informational                    [Page 10]

RFC 6689              RSVP ASSOCIATION Object Usage            July 20126.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.netBerger                        Informational                    [Page 11]