Internet Draft                                         Lou Berger (LabN)
Updates: 2205, 3209, 3473                   Francois Le Faucheur (Cisco)
Category: Standards Track                        Ashok Narayanan (Cisco) Informational
Expiration Date: September 14, November 1, 2011

                                                          March 14,

                                                             May 1, 2011

                  Usage of The RSVP Association Object

                   draft-ietf-ccamp-assoc-info-01.txt

                   draft-ietf-ccamp-assoc-info-02.txt

Abstract

   The RSVP ASSOCIATION object was defined in the context of GMPLS
   (Generalized Multi-Protocol Label Switching) controlled label
   switched paths (LSPs).  In this context, the object is used to
   associate recovery LSPs with the LSP they are protecting.  This
   object also has broader applicability as a mechanism to associate
   RSVP state, and this document defines how the ASSOCIATION object
   can be more generally applied.  The
   document also reviews how the association is to be provided in the context
   of GMPLS recovery.  No new new procedures or mechanisms are
   defined with respect to
   GMPLS recovery.  This by this document also defines extended ASSOCIATION
   objects which can be used and it is strictly informative in the context of Transport Profile of
   Multiprotocol Label Switching (MPLS-TP). 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
   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
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on September 14, November 1, 2011

Copyright and License Notice

   Copyright (c) 2011 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.

Table of Contents

    1      Introduction  ...........................................   3
    1.1    Conventions Used In This Document  ......................   4
    2      Background  .............................................   4   3
    2.1    LSP Association  ........................................   4   3
    2.2    End-to-End Recovery LSP Association  ....................   6   5
    2.3    Segment Recovery LSP Association  .......................   8
    2.4    Resource Sharing LSP Association  .......................   9   8
    3      Association of GMPLS Recovery LSPs  .....................  10   9
    4      Non-GMPLS Recovery Usage  ...............................  11
    4.1    Upstream Initiated Association  .........................  11
    4.1.1  Path Message Format  ....................................  12
    4.1.2  Path Message Processing  ................................  12
    4.2    Downstream Initiated Association  .......................  13
    4.2.1  Resv Message Format  ....................................  14
    4.2.2  Resv Message Processing  ................................  14
    4.3    Association Types  ......................................  15
    4.3.1  Resource Sharing Association Type  ......................  15
    5      IPv4 and IPv6 Extended ASSOCIATION Objects  .............  16
    5.1    IPv4 and IPv6 Extended ASSOCIATION Object Format  .......  17
    5.2    Processing  .............................................  18
    6      Security Considerations  ................................  20
    7  10
    5      IANA Considerations  ....................................  20
    7.1    IPv4 and IPv6 Extended ASSOCIATION Objects  .............  20
    7.2    Resource Sharing Association Type  ......................  21
    8  10
    6      Acknowledgments  ........................................  21
    9  10
    7      References  .............................................  21
    9.1  10
    7.1    Normative References  ...................................  21
    9.2  10
    7.2    Informative References  .................................  22
   10      Authors'  11
    8      Author's Addresses  .....................................  23  11

1. Introduction

   End-to-end and segment recovery are defined for GMPLS (Generalized
   Multi-Protocol Label Switching) 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.  In the context of GMPLS
   recovery, this  This document does not
   define any new procedures or mechanisms and is strictly informative
   in nature.

   In addition

   It may not be immediately obvious to the narrative, informed reader why this
   document also explicitly expands is necessary, however questions were repeatedly raised in
   the possible usage Common Control and Measurement Plane (CCAMP) working group on the
   proper interpretation of the ASSOCIATION object in other contexts.  In
   Section 4, the context of
   end-to-end and segment recovery, and the working group agreed that
   this document reviews how association should be made produced in order to close the case where matter.  This
   document formalizes the object is carried explanation provided in a Path message 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 defines
   usage with Resv messages. segment recovery, see [RFC4872] or [RFC4873].

2. Background

   This section also discusses usage of the
   ASSOCIATION object outside reviews the context of GMPLS LSPs.

   Some examples definition of non-LSP association in order to enable resource
   sharing are:

     o Voice Call-Waiting:
       A bidirectional voice call between two endpoints A and B is
       signaled using two separate unidirectional RSVP reservations for
       the flows A->B and B->A. If endpoint A wishes to put the A-B call
       on hold and join a separate A-C call, it is desirable that
       network resources on common links be shared between the A-B and
       A-C calls.  The B->A and C->A subflows of the call can share
       resources using existing RSVP sharing mechanisms, but only if
       they use the same destination IP addresses and ports.  However,
       there is no way in RSVP today to share the resources between the
       A->B and A->C subflows of the call since by definition the RSVP
       reservations for these subflows must have different IP addresses
       in the SESSION objects.

     o Voice Shared Line:
       A single number that rings multiple endpoints (which may be
       geographically diverse), such as phone lines on a manager's desk
       and their assistant.  A VoIP system that models these calls as
       multiple P2P unicast pre-ring reservations would result in
       significantly over-counting bandwidth on shared links, since
       today unicast reservations to different endpoints cannot share
       bandwidth.

     o Symmetric NAT:
       RSVP permits sharing of resources between multiple flows
       addressed to the same destination D, even from different senders
       S1 and S2.  However, if D is behind a NAT operating in symmetric
       mode [RFC5389], it is possible that the destination port of the
       flows S1->D and S2->D may be different outside the NAT.  In this
       case, these flows cannot share resources using RSVP today, since
       the SESSION objects for these two flows outside the NAT would
       have different ports.

   Section 5 of this document defines the extended ASSOCIATION objects
   which can be used in the context of Transport Profile of
   Multiprotocol Label Switching (MPLS-TP).  Although, the scope of the
   extended ASSOCIATION objects is not limited to MPLS-TP.

1.1. Conventions Used In This Document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2. Background

   This section reviews the definition of LSP 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.

2.1. LSP Association

   [RFC4872] introduces the concept and mechanisms to support the
   association of one LSP to another LSP across different 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.  Segment recovery usage is defined in [RFC4873] and is covered
   in Section 2.3.  Resource sharing LSP association is also defined in
   [RFC4873], while strictly speaking such association is beyond the
   scope of this document, for completeness it is covered in Section
   2.4.  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 independent from
   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 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 is supported by the ASSOCIATION object, and
   downstream correlation is made based on the type.

   [RFC4872] defines 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 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.

     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 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 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, 11.1.  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, which are 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].

      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 3 values:
     - The LSP ID of the LSP being protected.
     - The LSP ID of the LSP protecting an 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.  But this is only an option, and is
   neither required (i.e., "MUST") nor recommended (i.e., "SHOULD").  It
   should be noted that the document does not describe when such a
   change should be initiated, or the procedures for 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.

      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 how often it will occur.  Some believe that
   this case is 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 a
   [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 3 additional requirements.  In general, the narrative
   highlights case 3 identified above but does not preclude the other
   cases.  The 3 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 3 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), more than one LSP to be protected.

     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 the Rerouting without Extra-
       Traffic type of recovery 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 the Shared-Mesh Restoration type
       of recovery 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 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 and furthermore that 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 was considered
   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 which 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 was possible, see [RFC3209].

   Resource sharing is indicated using a new Association Type value.  As
   the Association Type field value is not the same as is used in
   Recovery LSP association, the semantics used for the association of
   LSPs using an ASSOCIATION object containing the new type differs from
   Recovery LSP association.

   Section 3.2.2 of [RFC4873] states the following rules for the
   construction of an ASSOCIATION object in support of resource sharing
   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 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 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 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 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. Non-GMPLS Recovery Usage

   While the ASSOCIATION object, [RFC4872], is Security Considerations

   This document reviews procedures defined in the context of
   GMPLS Recovery, the object can have wider application. [RFC4872]
   defines the object to be used to "associate LSPs with each other", and then defines an Association Type field to identify the type of
   association being identified.  It also defines that the Association
   Type field is to be considered when determining association, i.e.,
   there may be type-specific association rules.  As discussed above,
   this is the case for Recovery type association objects.  The text
   above, notably the text related to resource sharing types, can also
   be used as the foundation for a generic method for associating LSPs
   when there is no type-specific association defined.

   The remainder of this section defines the general rules to be
   followed when processing ASSOCIATION objects.  Object usage in both
   Path and Resv messages is discussed.  The usage applies equally to
   GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions
   [RFC2205], [RFC2207], [RFC3175] and [RFC4860].  As described below,
   association is always done based on matching either Path state or
   Resv state, but not Path state to Resv State.  This section applies
   to the ASSOCIATION objects defined in [RFC4872].

4.1. Upstream Initiated Association

   Upstream initiated association is represented in ASSOCIATION objects
   carried in Path messages and can be used to associate RSVP Path state
   across MPLS Tunnels / RSVP sessions.  (Note, per [RFC3209] an MPLS
   tunnel is represented by a RSVP SESSION object, and multiple LSPs may
   be represented within a single tunnel.)  Cross-session association
   based on Path state is defined in [RFC4872]. This definition is
   extended by this section, which defined generic association rules and
   usage for non-LSP uses.  This section does not modify processing
   required to support [RFC4872] and [RFC4873], which is reviewed above
   in Section 3.

4.1.1. Path Message Format

   This section provides the Backus-Naur Form (BNF), see [RFC5511], for
   Path messages containing ASSOCIATION objects.  BNF is provided for
   both MPLS and for non-LSP session usage.  Unmodified RSVP message
   formats and some optional objects are not listed.

   The format for MPLS and GMPLS sessions is unmodified from [RFC4872],
   and can be represented based on the BNF in [RFC3209] as:

      <Path Message> ::= <Common Header> [ <INTEGRITY> ]
                         <SESSION> <RSVP_HOP>
                         <TIME_VALUES>
                         [ <EXPLICIT_ROUTE> ]
                         <LABEL_REQUEST>
                         [ <SESSION_ATTRIBUTE> ]
                         [ <ASSOCIATION> ... ]
                         [ <POLICY_DATA> ... ]
                         <sender descriptor>

   The format for non-LSP sessions as based on the BNF in [RFC2205] is:

      <Path Message> ::= <Common Header> [ <INTEGRITY> ]
                         <SESSION> <RSVP_HOP>
                         <TIME_VALUES>
                        [ <ASSOCIATION> ... ]
                        [ <POLICY_DATA> ... ]
                        [ <sender descriptor> ]

   In general, relative ordering of ASSOCIATION objects with respect to
   each other as well as with respect to other objects is not
   significant.  Relative ordering of ASSOCIATION objects of the same
   type SHOULD be preserved by transit nodes.  Association type specific
   ordering requirements MAY be defined in the future.

4.1.2. Path Message Processing

   This section is based on the processing rules described in [RFC4872]
   and [RFC4873], which is reviewed above.  These procedures apply
   equally to GMPLS LSPs, MPLS LSPs and non-LSP session state.

   A node that wishes to allow downstream nodes to associate Path state
   across RSVP sessions MUST include an ASSOCIATION object in the
   outgoing Path messages corresponding to the RSVP sessions to be
   associated.  In the absence of Association Type-specific rules for
   identifying association, the included ASSOCIATION objects MUST be
   identical.  When there is an Association Type-specific definition of
   association rules, the definition SHOULD allow for association based
   on identical ASSOCIATION objects.  This document does not define any
   Association Type-specific rules.  (See Section 3 for a discussion of
   an example of Association Type-specific rules which are derived from
   [RFC4872].)

   When creating an ASSOCIATION object, the originator MUST format the
   object as defined in Section 16.1 of [RFC4872].  The originator MUST
   set the Association Type field based on the type of association being
   identified.  The Association ID field MUST be set to a value that
   uniquely identifies the sessions to be associated within the context
   of the Association Source field.  The Association Source field MUST
   be set to a unique address assigned to the node originating the
   association.

   A downstream node can identify an upstream initiated association by
   performing the following checks.  When a node receives a Path message
   it MUST check each ASSOCIATION object received in the Path message to
   see if it contains an Association Type field value supported by the
   node.  For each ASSOCIATION object containing a supported association
   type, the node MUST then check to see if the object matches an
   ASSOCIATION object received in any other Path message.  To perform
   this matching, a node MUST examine the Path state of all other
   sessions and compare the fields contained in the newly received
   ASSOCIATION object with the fields contained in the Path state's
   ASSOCIATION objects.  An association is deemed to exist when the same
   values are carried in all fields of the ASSOCIATION objects being
   compared.  Processing once an association is identified is type
   specific and is outside the scope of this document.

   Note that as more than one association may exist, all ASSOCIATION
   objects carried in a received Path message which have supported
   association types MUST be compared against all Path state.

   Unless there are type-specific processing rules, downstream nodes
   MUST forward all ASSOCIATION objects received in a Path message with
   any corresponding outgoing Path messages.

4.2. Downstream Initiated Association

   Downstream initiated association is represented in ASSOCIATION
   objects carried in Resv messages and can be used to associate RSVP
   Resv state across MPLS Tunnels / RSVP sessions.  Cross-session
   association based on Path state is defined in [RFC4872]. This section
   defines cross-session association based on Resv state.  This section
   places no additional requirements on implementations supporting
   [RFC4872] and [RFC4873].

4.2.1. Resv Message Format

   This section provides the Backus-Naur Form (BNF), see [RFC5511], for
   Resv messages containing ASSOCIATION objects.  BNF is provided for
   both MPLS and for non-LSP session usage.  Unmodified RSVP message
   formats and some optional objects are not listed.

   The format for MPLS, GMPLS and non-LSP sessions are identical, and is
   represented based on the BNF in [RFC2205] and [RFC3209]:

      <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
                         <SESSION>  <RSVP_HOP>
                         <TIME_VALUES>
                         [ <RESV_CONFIRM> ]  [ <SCOPE> ]
                         [ <ASSOCIATION> ... ]
                         [ <POLICY_DATA> ... ]
                         <STYLE> <flow descriptor list>

   Relative ordering of ASSOCIATION objects with respect to each other
   as well as with respect to other objects is not currently
   significant.  Relative ordering of ASSOCIATION objects of the same
   type MUST be preserved by transit nodes.  Association type specific
   ordering requirements MAY be defined in the future.

4.2.2. Resv Message Processing

   This section apply equally to GMPLS LSPs, MPLS LSPs and non-LSP
   session state.

   A node that wishes to allow upstream nodes to associate Resv state
   across RSVP sessions MUST include an ASSOCIATION object in the
   outgoing Resv messages corresponding to the RSVP sessions to be
   associated.  In the absence of Association Type-specific rules for
   identifying association, the included ASSOCIATION objects MUST be
   identical.  When there is an Association Type-specific definition of
   association rules, the definition SHOULD allow for association based
   on identical ASSOCIATION objects.  This document does not define any
   Association Type-specific rules.

   When creating an ASSOCIATION object, the originator MUST format the
   object as defined in Section 16.1 of [RFC4872].  The originator MUST
   set the Association Type field based on the type of association being
   identified.  The Association ID field MUST be set to a value that
   uniquely identifies the sessions to be associated within the context
   of the Association Source field.  The Association Source field MUST
   be set to a unique address assigned to the node originating the
   association.

   An upstream node can identify a downstream initiated association by
   performing the following checks.  When a node receives a Resv message
   it MUST check each ASSOCIATION object received in the Resv message to
   see if it contains an Association Type field value supported by the
   node.  For each ASSOCIATION object containing a supported association
   type, the node MUST then check to see if the object matches an
   ASSOCIATION object received in any other Resv message.  To perform
   this matching, a node MUST examine the Resv state of all other
   sessions and compare the fields contained in the newly received
   ASSOCIATION object with the fields contained in the Resv state's
   ASSOCIATION objects.  An association is deemed to exist when the same
   values are carried in all fields of the ASSOCIATION objects being
   compared.  Processing once an association is identified is type
   specific and is outside the scope of this document.

   Note that as more than one association may exist, all ASSOCIATION
   objects with support Association Types carried in a received Resv
   message MUST be compared against all Resv state.

   Unless there are type-specific processing rules, upstream nodes MUST
   forward all ASSOCIATION objects received in a Resv message with any
   corresponding outgoing Resv messages.

4.3. Association Types

   Two association types are currently defined: recovery and resource
   sharing.  Recovery type association is only applicable within the
   context of recovery, [RFC4872] and [RFC4873].  Resource sharing is
   generally useful and its general use is defined in this section.

4.3.1. Resource Sharing Association Type

   The resource sharing association type was defined in [RFC4873] and
   was defined within the context of GMPLS and upstream initiated
   association.  This section presents a definition of the resource
   sharing association that allows for its use with any RSVP session
   type and in both Path and Resv messages.  This definition is
   consistent with the definition of the resource sharing association
   type in [RFC4873] and no changes are required by this section in
   order to support [RFC4873].  The Resource Sharing Association Type
   MUST be supported by any implementation compliant with this document.

   The Resource Sharing Association Type is used to enable resource
   sharing across RSVP sessions.  Per [RFC4873], Resource Sharing uses
   the Association Type field value of 2.  ASSOCIATION objects with an
   Association Type with the value Resource Sharing MAY be carried in
   Path and Resv messages.  Association for the Resource Sharing type
   MUST follow the procedures defined in Section 4.1.2 for upstream
   (Path message) initiated association and Section 4.2.1 for downstream
   (Resv message) initiated association.  There are no type-specific
   association rules, processing rules, or ordering requirements.  Note
   that as is always the case with association as enabled by this
   document, no associations are made across Path and Resv state.

   Once an association is identified, resources SHOULD be shared across
   the identified sessions.  Resource sharing is discussed in general in
   [RFC2205] and within the context of LSPs in [RFC3209].

5. IPv4 and IPv6 Extended ASSOCIATION Objects

   [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6
   ASSOCIATION object.  As defined, these objects each contain an
   Association Source field and a 16-bit Association ID field. The
   combination of the Association Source and the Association ID uniquely
   identifies the association.  Because the association-ID field is a
   16-bit field, an association source can allocate up to 65536
   different associations and no more.  There are scenarios where this
   number is insufficient.  (For example where the association
   identification is best known and identified by a fairly centralized
   entity, which therefore may be involved in a large number of
   associations.)

   Furthermore, per [TP-IDENTIFIERS], MPLS-TP LSPs can be identified in
   two forms that cannot be supported using the existing ASSOCIATION
   objects.  The first form is a global identifier and the second uses
   an ITU Carrier Code (ICC). The [TP-IDENTIFIERS] defined "global
   identifier", or Global_ID, is based on [RFC5003] and includes the
   operator's Autonomous System Number (ASN).  [TP-IDENTIFIERS]
   identifies the ICC as "a string of one to six characters, each
   character being either alphabetic (i.e.  A-Z) or numeric (i.e. 0-9)
   characters.  Alphabetic characters in the ICC SHOULD be represented
   with upper case letters."

   This sections defines new ASSOCIATION objects to support extended
   identification in order to address the limitations described above.
   Specifically, the IPv4 Extended ASSOCIATION object and IPv6 Extended
   ASSOCIATION object are defined below. Both new objects include the
   fields necessary to enable identification of a larger number of
   associations, as well as MPLS-TP required identification.

   The IPv4 Extended ASSOCIATION object and IPv6 Extended ASSOCIATION
   object SHOULD be supported by an implementation compliant with this
   document.  The processing rules for the IPv4 and IPv6 Extended
   ASSOCIATION object are described below, and are based on the rules
   for the IPv4 and IPv6 ASSOCIATION objects as described above.

5.1. IPv4 and IPv6 Extended ASSOCIATION Object Format

   The IPv4 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb
   with value = 199, C-Type = TBA) has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             | Class-Num(199)|  C-Type (TBA) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Association Type        |       Association ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    IPv4 Association Source                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Global Association Source                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               .                               :
      :                    Extended Association ID                    :
      :                               .                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The IPv6 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb
   with value = 199, C-Type = TBA) has the format:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Length             | Class-Num(199)|  C-Type (TBA) |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Association Type        |       Association ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                    IPv6 Association Source                    |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Global Association Source                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               .                               :
      :                    Extended Association ID                    :
      :                               .                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Association Type: 16 bits

      Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].

   Association ID: 16 bits

      Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].

   Association Source: 4 or 16 bytes

      Same as for IPv4 and IPv6 ASSOCIATION objects, see [RFC4872].

   Global Association Source: 4 bytes

      This field contains a value that is unique to the provider, i.e.,
      a global identifier.  This field MAY contain the 2-octet or
      4-octet value of the provider's Autonomous System Number (ASN).
      It is expected that the global identifier will be derived from the
      globally unique ASN of the autonomous system hosting the
      Association Source.  The special value of zero (0) indicates that
      no global identifier is present. Note that a Global Association
      Source of zero SHOULD be limited to entities contained within a
      single operator.

      If the Global Association Source field value is derived from a
      2-octet AS number, then the two high-order octets of this 4-octet
      field MUST be set to zero.

      Please note that, as stated in [TP-IDENTIFIERS], the use of the
      provider's ASN as a global identifier DOES NOT have anything at
      all to do with the use of the ASN in protocols such as BGP.

      This field is based on the definition of Global_ID defined in
      [RFC5003] and used by [TP-IDENTIFIERS].

   Extended Association ID: variable, 4-byte aligned

      This field contains data that is additional information to support
      unique identification.  The length and contents of this field is
      determined by the Association Source.  This field MAY be omitted,
      i.e., have a zero length.  This field MUST be padded with zeros
      (0s) to ensure 32-bit alignment.

5.2. Processing

   The processing of a IPv4 or IPv6 Extended ASSOCIATION object MUST
   identical to the processing of a IPv4 or IPv6 ASSOCIATION object as
   described above in Section 4 except as extended by this section. This
   section applies to both upstream-initiated (Path message) and
   downstream-initiated (Resv message) association.

   The following are the modified procedures for Extended ASSOCIATION
   object processing:

     o When creating an Extended ASSOCIATION object, the originator MUST
       format the object as defined in this document.

     o The originator MUST set the Association Type, Association ID and
       Association Source fields as described in Section 4.

     o When ASN-based global identification of the Association Source is
       desired, the originator MUST set the Global Association Source
       field.  When ASN-based global identification is not desired, the
       originator MUST set the Global Association Source field to zero
       (0).

     o The Extended ASSOCIATION object originator MAY include the
       Extended Association ID field.  The field is included based on
       local policy.  The field MUST be included when the Association ID
       field is insufficient to uniquely identify association within the
       scope of the source of the association.  When included, this
       field MUST be set to a value that, when taken together with the
       other fields in the object, uniquely identifies the sessions to
       be associated.

       When used in support of ICC identified (MPLS-TP) LSPs, this field
       MUST be at least eight (8) bytes long, and MAY be longer; the
       first six (6) bytes MUST be set to the ICC as defined in Section
       3.2 of [TP-IDENTIFIERS] and the next two bytes MUST be set to
       zero (0). For non-ICC identified MPLS-TP LSPs, this field MUST
       either be omitted, or MUST have the first 6 bytes set to all
       zeros (0s).

     o The object Length field is set based on the length of the
       Extended Association ID field.  When the Extended Association ID
       field is omitted, the object Length field MUST be set to 16 or 28
       for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the
       Extended Association ID field is present, the object Length field
       MUST be set to indicate the additional bytes carried in the
       Extended Association ID field, including pad bytes.

       Note: per [RFC2205], the object Length field is set to the total
       object length in bytes, and is always a multiple of 4, and at
       least 4.

   Identification of association is not modified by this section.  It is
   important to note that Section 4 defines association identification
   based on ASSOCIATION object matching, and that such matching is based
   on the comparison of all fields in a ASSOCIATION object (unless type-
   specific comparison rules are defined).  This applies equally to
   ASSOCIATION objects and Extended ASSOCIATION objects.

6. Security Considerations

   A portion of 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 portion.

   Section 4 defines broader usage of the ASSOCIATION object, but does
   not fundamentally expand on the association function that was
   previously defined in [RFC4872] and [RFC4873].  Section 5 increases
   the number of bits that are carried in an ASSOCIATION object (by 32),
   and similarly does not expand on the association function that was
   previously defined.  This broader definition [RFC4873]
   and does allow for
   additional information to be conveyed, but this information is not
   fundamentally different from the information that is already carried
   in RSVP.  Therefore there are define any new procedures.  As such, no new risks or security
   considerations are introduced by this document.

   For a general discussion on MPLS and GMPLS related security issues,
   see the MPLS/GMPLS security framework [RFC5920].

7. IANA Considerations

   IANA is requested to administer assignment of new values for
   namespaces defined in this document and summarized in this section.

7.1. IPv4 and IPv6 Extended ASSOCIATION Objects

   Upon approval of this document, IANA will make the assignment of two
   new C-Types (which are defined in section 5.1) for the existing
   ASSOCIATION object in the "Class Names, Class Numbers, and Class
   Types" section of the "Resource Reservation Protocol (RSVP)
   Parameters" registry located at http://www.iana.org/assignments/rsvp-
   parameters:

   199  ASSOCIATION                           [RFC4872]

        Class Types or C-Types

           3   Type 3 IPv4 Extended Association   [this document]
           4   Type 4 IPv6 Extended Association   [this document]

7.2. Resource Sharing Association Type

   This document also broadens the potential usage of the Resource
   Sharing Association Type defined in [RFC4873].  As such, IANA is
   requested to change the Reference of the Resource Sharing Association
   Type included in the associate registry.  This document also directs document..

5. IANA to correct the duplicate usage of '(R)' in this Registry.  In
   particular, the Association Type registry found at
   http://www.iana.org/assignments/gmpls-sig-parameters/ should be
   updated as follows:

      OLD:
        2         Resource Sharing (R)      [RFC4873]
      NEW
        2         Resource Sharing (S)      [RFC4873][this-document] Considerations

   There are no other new IANA considerations introduced by this document.

8.

6. Acknowledgments

   Sections 2 and 3 of this

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

   We thank Subha Dhesikan for her contribution to the early work on
   sharing of resources across RSVP reservations.

9. Papadimitriou,
   Francois Le Faucheur and Ashok Narayanan.

7. References

9.1.

7.1. Normative References

   [RFC2205]  Braden, R., Zhang, L., Berson, S., Herzog, S. and
              S. Jamin, "Resource ReSerVation Protocol (RSVP) --
              Version 1, Functional Specification", RFC 2205,
              September 1997.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4872]  Lang, J., Rekhter, Y., and Papadimitriou, D., "RSVP-TE
              Extensions in Support of End-to-End Generalized Multi-
              Protocol Label Switching (GMPLS) Recovery", RFC 4872,
              May 2007.

   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
              "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., "Generalized Multi-Protocol Label Switching
              (GMPLS) Signaling Resource ReserVation Protocol-Traffic
              Engineering (RSVP-TE) Extensions", RFC 3473, January
              2003.

   [RFC5511]  Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
              Used to Form Encoding Rules in Various Routing Protocol
              Specifications", RFC 5511, April 2009

9.2.

7.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.

   [RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC
             RSVP Extensions for IPSEC Data Flows", RFC 2207, September
             1997.

   [RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation
             of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
             September 2001.

   [RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M.,
             "Generic Aggregate Resource ReSerVation Protocol (RSVP)
             Reservations", RFC 4860, May 2007.

   [RFC5003] Metz, C., Martini, L., Balus, F., Sugimoto, J.,
             "Attachment Individual Identifier (AII) Types for
             Aggregation", RFC 5003, September 2007.

   [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., Wing, D., "Session
             Traversal Utilities for NAT (STUN)", RFC 5389, October
             2008.

   [RFC5920] Fang, L., et al, "Security Framework for MPLS and
             GMPLS Networks", work in progress, RFC 5920, July 2010.

   [TP-IDENTIFIERS] Bocci, M., Swallow, G., Gray, E., "MPLS-TP
                    Identifiers", work in progress,
                    draft-ietf-mpls-tp-identifiers.

10. Authors'

8. Author's Addresses

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

   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   France
   Email: flefauch@cisco.com

   Ashok Narayanan
   Cisco Systems
   300 Beaver Brook Road
   Boxborough, MA  01719
   United States
   Email: ashokn@cisco.com

Generated on: Mon, Mar 14, May 02, 2011 7:36:53 10:15:27 AM