RSVP ASSOCIATION Object Extensions
draft-ietf-ccamp-assoc-ext-06

Internet Draft                                         Lou Berger (LabN)
Updates: 2205, 3209, 3473, 4872             Francois Le Faucheur (Cisco)
Category: Standards Track                        Ashok Narayanan (Cisco)
Expiration Date: March 21, 2013

                                                      September 21, 2012

                   RSVP Association Object Extensions

                   draft-ietf-ccamp-assoc-ext-06.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.  This document also defines
   Extended ASSOCIATION objects which, in particular, can be used in
   the context of the Transport Profile of Multiprotocol Label
   Switching (MPLS-TP).  This document updates RFC 2205, RFC 3209,
   and RFC 3473. It also generalizes the definition of the Association
   ID field defined in RFC 4872.

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 March 21, 2013

Berger, et al                Standards Track                    [Page 1]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

Copyright and License 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.

Table of Contents

    1      Introduction  ...........................................   3
    1.1    Conventions Used In This Document  ......................   4
    2      Generalized Association ID Field Definition  ............   4
    3      Non-GMPLS and Non-Recovery Usage  .......................   5
    3.1    Upstream Initiated Association  .........................   5
    3.1.1  Path Message Format  ....................................   6
    3.1.2  Path Message Processing  ................................   6
    3.2    Downstream Initiated Association  .......................   7
    3.2.1  Resv Message Format  ....................................   8
    3.2.2  Resv Message Processing  ................................   8
    3.3    Association Types  ......................................   9
    3.3.1  Resource Sharing Association Type  ......................   9
    3.3.2  Unknown Association Types  ..............................  10
    4      IPv4 and IPv6 Extended ASSOCIATION Objects  .............  10
    4.1    IPv4 and IPv6 Extended ASSOCIATION Object Format  .......  11
    4.2    Processing  .............................................  13
    5      Compatibility  ..........................................  14
    6      Security Considerations  ................................  14
    7      IANA Considerations  ....................................  15
    7.1    IPv4 and IPv6 Extended ASSOCIATION Objects  .............  15
    7.2    Resource Sharing Association Type  ......................  15
    8      Acknowledgments  ........................................  16
    9      References  .............................................  16
    9.1    Normative References  ...................................  16
    9.2    Informative References  .................................  16
   10      Authors' Addresses  .....................................  17

Berger, et al                Standards Track                    [Page 2]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

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.  Additional narrative on how such associations are to
   be identified is also provided in [RFC6689].

   This document expands the possible usage of the ASSOCIATION object to
   non-GMPLS and non-recovery contexts.  The expanded usage applies
   equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP
   sessions [RFC2205], [RFC2207], [RFC3175] and [RFC4860].  This
   document also reviews how association should be made in the case
   where the object is carried in a Path message and defines usage with
   Resv messages.  This section also discusses usage of the ASSOCIATION
   object outside the context of GMPLS LSPs.

   Some examples 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.  Since, by
       definition, the RSVP reservations for the subflows A->B and A->C
       of the call must have different IP addresses in the SESSION
       objects, this document defines a new mechanism to associate the
       subflows and allow them to share resources.

     o Voice Shared Line:
       A voice shared line is a single number that rings multiple
       endpoints (which may be geographically diverse), such as phone
       lines to a manager's desk and to 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 RSVP unicast reservations to
       different endpoints cannot share bandwidth.  So a new mechanism
       is defined in this document allowing separate unicast
       reservations to be associated and share resources.

     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

Berger, et al                Standards Track                    [Page 3]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

       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, since the
       SESSION objects for these two flows outside the NAT have
       different destination ports.  This document defines a new
       mechanism to associate these flows and allow them to share
       resources.

   In order to support the wider usage of the ASSOCIATION object, this
   document generalizes the definition of the Association ID field
   defined in RFC 4872.  This generalization has no impact on existing
   implementations.  When using the procedures defined below,
   association is identified based on exact ASSOCIATION object matching.
   Some of the other matching mechanisms defined in RFC 4872, e.g.,
   matching based on Session IDs, are not generalized.  This document
   allows for, but does not specify, association type-specific
   processing.

   This document also defines the Extended ASSOCIATION objects which can
   be used in the context of the Transport Profile of Multiprotocol
   Label Switching (MPLS-TP).  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. Generalized Association ID Field Definition

   The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION
   objects defined in [RFC4872].  The [RFC4872] definition of the field
   reads:

      A value assigned by the LSP head-end.  When combined with the
      Association Type and Association Source, this value uniquely
      identifies an association.

   This document allows for the origination of ASSOCIATION objects by
   nodes other than "the LSP head-end".  As such, the definition of the
   Association ID field needs to be generalized to accommodate such
   usage.  This document defines the Association ID field of the IPv4
   and IPv6 ASSOCIATION objects as:

      A value assigned by the node that originated the association.
      When combined with the other fields carried in the object, this
      value uniquely identifies an association.

Berger, et al                Standards Track                    [Page 4]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

   This change in definition does not impact [RFC4872] or [RFC4873]
   defined procedures or mechanisms, nor does it impact existing
   implementations of [RFC4872] or [RFC4873].

3. Non-GMPLS and Non-Recovery Usage

   While the ASSOCIATION object, [RFC4872], is 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 specifies that the Association
   Type field is to be considered when determining association, i.e.,
   there may be type-specific association rules.  As defined by
   [RFC4872] and reviewed in [RFC6689], this is the case for Recovery
   type association objects.  [RFC6689], 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 to
   Path state, or Resv state to Resv state, but not Path state to Resv
   State. This section applies to the ASSOCIATION objects defined in
   [RFC4872].

3.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-LSP association based
   on Path state is defined in [RFC4872].  This section extends that
   definition by specifying generic association rules and usage for non-
   LSP uses.  This section does not modify processing required to
   support [RFC4872] and [RFC4873], and which is reviewed in Section 3
   of [RFC6689].  The use of an ASSOCIATION object in a single session
   is not precluded.

Berger, et al                Standards Track                    [Page 5]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

3.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 formats for MPLS and GMPLS sessions are 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.

3.1.2. Path Message Processing

   This section is based on, and extends, the processing rules described
   in [RFC4872] and [RFC4873], and which is reviewed in [RFC6689].  This
   section applies equally to GMPLS LSPs, MPLS LSPs and non-LSP session
   state.  Note, as previously stated, this section does not modify
   processing required to support [RFC4872] and [RFC4873].

   A node sending a Path message chooses when an ASSOCIATION object is
   to be included in the outgoing Path message.  To indicate association
   between multiple sessions, an appropriate ASSOCIATION object MUST be
   included in the outgoing Path messages corresponding to each of the
   associated sessions.  In the absence of Association Type-specific
   rules for identifying association, the included ASSOCIATION object
   MUST be identical.  When there is an Association Type-specific
   definition of association rules, the definition SHOULD allow for

Berger, et al                Standards Track                    [Page 6]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

   association based on identical ASSOCIATION objects.  This document
   does not define any Association Type-specific rules.  (See Section 3
   of [RFC6689] for a review of Association Type-specific rules 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 association being identified 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.  Type-specific processing of ASSOCIATION objects is outside
   the scope of this document.

   Note that as more than one association may exist, the described
   matching MUST continue after a match is identified, and MUST be
   performed against all local Path state.  It is also possible for
   there to be no match identified.

   Unless there are type-specific processing rules, downstream nodes
   MUST forward all ASSOCIATION objects received in a Path message,
   without modification, in any corresponding outgoing Path messages.
   This processing MUST be followed for unknown Association Type field
   values.

3.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-LSP
   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].  Note, the use of an ASSOCIATION object in a
   single session is not precluded.

Berger, et al                Standards Track                    [Page 7]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

3.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 formats 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 SHOULD be preserved by transit nodes.

3.2.2. Resv Message Processing

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

   A node sending a Resv message chooses when an ASSOCIATION object is
   to be included in the outgoing Resv message.  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 association being identified 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

Berger, et al                Standards Track                    [Page 8]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

   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.  Type-specific processing of ASSOCIATION objects is outside
   the scope of this document.

   Note that as more than one association may exist, the described
   matching MUST continue after a match is identified, and MUST be
   performed against all local Resv state. It is also possible for there
   to be no match identified.

   Unless there are type-specific processing rules, upstream nodes MUST
   forward all ASSOCIATION objects received in a Resv message, without
   modification, in any corresponding outgoing Resv messages.  This
   processing MUST be followed for unknown Association Type field
   values.

3.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
   applicable to any context and its general use is defined in this
   section.

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

Berger, et al                Standards Track                    [Page 9]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

   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 MUST be considered as
   shared across the identified sessions by the admission control
   function. Since the implementation specifics of the admission control
   function is outside the scope of RSVP, we observe that how resource
   sharing is actually reflected may vary according to specific
   implementations (e.g. depending on the specific admission control and
   resource management algorithm, or on how local policy is taken into
   account).

3.3.2. Unknown Association Types

   As required by Sections 3.1.2 and 3.2.2 above, a node that receives
   an ASSOCIATION object containing an unknown ASSOCIATION type forwards
   all received ASSOCIATION objects as defined above.  The node MAY also
   identify associations per the defined processing, e.g., to make this
   information available via a management interface.

4. 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.  As
   described above, the contents of the object uniquely identify an
   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.)

   An additional case that cannot be supported using the existing
   ASSOCIATION objects is presented by MPLS-TP LSPs.  Per [RFC6370],
   MPLS-TP LSPs can be identified based on an operator unique global
   identifier.  The [RFC6370] defined "global identifier", or Global_ID,
   is based on [RFC5003] and includes the operator's Autonomous System
   Number (ASN).

   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

Berger, et al                Standards Track                   [Page 10]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

   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.

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

Berger, et al                Standards Track                   [Page 11]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

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

   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 a unique global identifier or
      the special value zero (0).  When non-zero and not overridden by
      local policy, the Global_ID as defined in [RFC6370] SHALL be used.
      The special value of zero indicates that no global identifier is
      present. Use of the special value 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.

Berger, et al                Standards Track                   [Page 12]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

   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
      scoped by the Association Source.  The length of this field is
      derived from the object Length field and as such MUST have a zero
      length or be 4-byte aligned.  A zero length indicates that this
      field is omitted.

4.2. Processing

   The processing of an IPv4 or IPv6 Extended ASSOCIATION object MUST be
   identical to the processing of an IPv4 or IPv6 ASSOCIATION object as
   described above except as extended by this section. This section
   applies to ASSOCIATION objects included in both Path and Resv
   messages.

   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 association
       being identified.

     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

Berger, et al                Standards Track                   [Page 13]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

       object length in bytes, and is always a multiple of 4, and at
       least 4.

   The procedures related to association identification are not modified
   by this section.  It is important to note that Section 4 defines the
   identification of associations based on ASSOCIATION object matching
   and that such matching, in the absence of type-specific comparison
   rules, is based on the comparison of all fields in an ASSOCIATION
   object.  This applies equally to ASSOCIATION objects and Extended
   ASSOCIATION objects.

5. Compatibility

       Per [RFC4872], the ASSOCIATION object uses an object class number
       of the form 11bbbbbb to ensure compatibility with non-supporting
       nodes. Per [RFC2205], such nodes will ignore the object but
       forward it without modification.  This is also the action taken
       for unknown association types as discussed above in Section
   3.1.2,
       3.2.2, and 3.3.2.

       Per [RFC4872], transit nodes that support the ASSOCIATION object,
       but not the Extended Association C-Types, will "transmit, without
       modification, any received ASSOCIATION object in the
   corresponding
       outgoing Path message."  Per [RFC2205], an egress node that
   supports
       the ASSOCIATION object, but not the Extended Association C-Types
       may generate an "Unknown object C-Type" error. This error will
       propagate to the ingress node for standard error processing.

       Operators wishing to use a function supported by particular
       association type should ensure that the type is supported on any
       node which is expected to act on the association.

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 2 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 3 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 does allow for
   additional information to be conveyed, but this information is not
   fundamentally different from the information that is already carried

Berger, et al                Standards Track                   [Page 14]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

   in RSVP.  Therefore there are no new risks or security considerations
   introduced by this document.

   For a general discussion on MPLS and GMPLS related security issues,
   including RSVP's chain of trust security model, 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 3.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
   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]

   There are no other IANA considerations introduced by this document.

Berger, et al                Standards Track                   [Page 15]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

8. Acknowledgments

   Valuable comments and input was received from Dimitri Papadimitriou,
   Fei Zhang and Adrian Farrel.  We thank Subha Dhesikan for her
   contribution to the early work on sharing of resources across RSVP
   reservations.

9. References

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

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

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

   [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. Informative References

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

Berger, et al                Standards Track                   [Page 16]
Internet-Draft      draft-ietf-ccamp-assoc-ext-06.txt  September 21, 2012

   [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", RFC 5920, July 2010.

   [RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers",
             RFC 6370, June 2011.

   [RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC
             6689, July 2012.

10. Authors' Addresses

   Lou Berger
   LabN Consulting, L.L.C.
   Phone: +1-301-468-9228
   Email: [email protected]

   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   France
   Email: [email protected]

   Ashok Narayanan
   Cisco Systems
   300 Beaver Brook Road
   Boxborough, MA  01719
   United States
   Email: [email protected]

Berger, et al                Standards Track                   [Page 17]
Generated on: Fri, Sep 21, 2012 9:36:09 AM