doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6780.txt b/doc/rfc/rfc6780.txt
new file mode 100644
index 0000000..972d623
--- /dev/null
+++ b/doc/rfc/rfc6780.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+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:
+
+         <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], 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]:
+
+         <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
+
+
+
+Berger, et al.               Standards Track                    [Page 8]
+
+RFC 6780                     RSVP Extensions                October 2012
+
+
+   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.
+
+   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 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 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 in any
+   corresponding outgoing Resv messages without modification.  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] [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
+
+
+
+Berger, et al.               Standards Track                    [Page 9]
+
+RFC 6780                     RSVP Extensions                October 2012
+
+
+   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 3.1.2 for upstream-
+   initiated (Path message) association and Section 3.2.1 for
+   downstream-initiated (Resv message) 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
+   previously described, 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, and therefore may be
+   involved in a large number of associations).
+
+
+
+
+
+Berger, et al.               Standards Track                   [Page 10]
+
+RFC 6780                     RSVP Extensions                October 2012
+
+
+   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.  As defined in [RFC6370], "global identifier", or
+   Global_ID, is based on [RFC5003] and includes the operator's
+   Autonomous System Number (ASN).
+
+   This section defines new ASSOCIATION objects to support extended
+   identification in order to address the previously described
+   limitations.  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 previously described.
+
+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 = 3) 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 (3)   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       Association Type        |       Association ID          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                    IPv4 Association Source                    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                   Global Association Source                   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      :                               .                               :
+      :                    Extended Association ID                    :
+      :                               .                               :
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.               Standards Track                   [Page 11]
+
+RFC 6780                     RSVP Extensions                October 2012
+
+
+   The IPv6 Extended ASSOCIATION object (Class-Num of the form 11bbbbbb
+   with value = 199, C-Type = 4) 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 (4)   |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       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 zero indicates that no global identifier is
+      present.  Use of the special value zero SHOULD be limited to
+      entities contained within a single operator.
+
+      If the Global Association Source field value is derived from a
+      2-octet ASN, then the two high-order octets of this 4-octet field
+      MUST be set to zero.
+
+
+
+
+
+Berger, et al.               Standards Track                   [Page 12]
+
+RFC 6780                     RSVP Extensions                October 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
+      length of zero or be 4-byte aligned.  A length of zero 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
+   previously described, 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.
+
+
+
+Berger, et al.               Standards Track                   [Page 13]
+
+RFC 6780                     RSVP Extensions                October 2012
+
+
+      Note: Per [RFC2205], the object Length field is set to the total
+      object length in bytes, is always a multiple of 4, and is 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 a particular
+   association type should ensure that the type is supported on any node
+   that 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 new procedures.  As such, no new
+   security considerations are introduced in this portion of the
+   document.
+
+   Section 3 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 4 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]
+
+RFC 6780                     RSVP Extensions                October 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 has assigned new values for namespaces defined in this document
+   and they are summarized in this section.
+
+7.1.  IPv4 and IPv6 Extended ASSOCIATION Objects
+
+   Per this document, IANA has assigned 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   [RFC6780]
+           4   Type 4 IPv6 Extended Association   [RFC6780]
+
+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 has
+   updated the reference of the Resource Sharing Association Type
+   included in the associated registry.  Per this document, IANA has
+   also corrected the duplicate usage of '(R)' in this registry.  In
+   particular, the "Association Type" registry found at
+   http://www.iana.org/assignments/gmpls-sig-parameters/ has been
+   updated as follows:
+
+      OLD:
+        2         Resource Sharing (R)      [RFC4873]
+
+      NEW:
+        2         Resource Sharing (S)      [RFC4873][RFC6780]
+
+   There are no other IANA considerations introduced by this document.
+
+
+
+
+
+
+Berger, et al.               Standards Track                   [Page 15]
+
+RFC 6780                     RSVP Extensions                October 2012
+
+
+8.  Acknowledgments
+
+   Valuable comments and input were 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., Ed., 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., Ed., "Generalized Multi-Protocol Label
+              Switching (GMPLS) Signaling Resource ReserVation
+              Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+              3473, January 2003.
+
+   [RFC4872]  Lang, J., Ed., Rekhter, Y., Ed., and D. Papadimitriou,
+              Ed., "RSVP-TE Extensions in Support of End-to-End
+              Generalized Multi-Protocol Label Switching (GMPLS)
+              Recovery", RFC 4872, May 2007.
+
+   [RFC4873]  Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
+              "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. and T. O'Malley, "RSVP Extensions for IPSEC
+              Data Flows", RFC 2207, September 1997.
+
+   [RFC3175]  Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
+              "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
+              3175, September 2001.
+
+
+
+
+Berger, et al.               Standards Track                   [Page 16]
+
+RFC 6780                     RSVP Extensions                October 2012
+
+
+   [RFC4860]  Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
+              Davenport, "Generic Aggregate Resource ReSerVation
+              Protocol (RSVP) Reservations", RFC 4860, May 2007.
+
+   [RFC5003]  Metz, C., Martini, L., Balus, F., and J. Sugimoto,
+              "Attachment Individual Identifier (AII) Types for
+              Aggregation", RFC 5003, September 2007.
+
+   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
+              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
+              October 2008.
+
+   [RFC5920]  Fang, L., Ed., "Security Framework for MPLS and GMPLS
+              Networks", RFC 5920, July 2010.
+
+   [RFC6370]  Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
+              Profile (MPLS-TP) Identifiers", RFC 6370, September 2011.
+
+   [RFC6689]  Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC
+              6689, July 2012.
+
+Authors' 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
+
+
+
+
+
+
+
+
+
+
+Berger, et al.               Standards Track                   [Page 17]
+