GOPHERSPACE.DE - P H O X Y
gophering on gopher.fnord.one






Internet Engineering Task Force (IETF)                         L. Berger
Request for Comments: 6780                                          LabN
Updates: 2205, 3209, 3473, 4872                           F. Le Faucheur
Category: Standards Track                                   A. Narayanan
ISSN: 2070-1721                                                    Cisco
                                                            October 2012


                   RSVP ASSOCIATION Object Extensions

Abstract

   The RSVP ASSOCIATION object was defined in the context of GMPLS-
   controlled Label Switched Paths (LSPs).  In this context, the object
   is used to associate recovery LSPs with the LSP they are protecting.
   This object also has broader applicability as a mechanism to
   associate RSVP state.  This document defines how the ASSOCIATION
   object can be more generally applied.  This document also defines
   Extended ASSOCIATION objects that, in particular, can be used in the
   context of the MPLS Transport Profile (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 is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6780.















Berger, et al.               Standards Track                    [Page 1]

RFC 6780                     RSVP Extensions                October 2012


Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

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

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................4
   2. Generalized Association ID Field Definition .....................4
   3. Non-GMPLS and Non-Recovery Usage ................................4
      3.1. Upstream Initiated Association .............................5
           3.1.1. Path Message Format .................................5
           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









Berger, et al.               Standards Track                    [Page 2]

RFC 6780                     RSVP Extensions                October 2012


1.  Introduction

   End-to-end and segment recovery are defined for GMPLS-controlled
   Label Switched Paths (LSPs) in [RFC4872] and [RFC4873], respectively.
   Both definitions use the ASSOCIATION object to associate recovery
   LSPs with the LSP they are protecting.  Additional narrative on how
   such associations are to be identified is 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] [RFC4860].  This document
   also reviews how associations should be made in the case in which the
   object is carried in a Path message; additionally, it 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 being used 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 Voice over IP
      (VoIP) system that models these calls as multiple point-to-point
      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 to allow separate
      unicast reservations to be associated and to share resources.





Berger, et al.               Standards Track                    [Page 3]

RFC 6780                     RSVP Extensions                October 2012


   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, 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 that can
   be used in the context of 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:




Berger, et al.               Standards Track                    [Page 4]

RFC 6780                     RSVP Extensions                October 2012


      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.

   This change in definition does not impact the procedures or
   mechanisms defined in [RFC4872] or [RFC4873], nor does it impact the
   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] [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 an 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], 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]

RFC 6780                     RSVP Extensions                October 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:

          ::=  [  ]
                             
                            
                            [  ]
                            
                            [  ]
                            [  ... ]
                            [  ... ]
                            

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

          ::=  [  ]
                             
                            
                           [  ... ]
                           [  ... ]
                           [  ]

   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], 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



Berger, et al.               Standards Track                    [Page 6]

RFC 6780                     RSVP Extensions                October 2012


   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
   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 specific association 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 determine if the object 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 in
   any corresponding outgoing Path messages without modification.  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



Berger, et al.               Standards Track                    [Page 7]

RFC 6780                     RSVP Extensions                October 2012


   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.

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
   are represented based on the BNF in [RFC2205] and [RFC3209]:

          ::=  [  ]
                              
                            
                            [  ]  [  ]
                            [  ... ]
                            [  ... ]