GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools

Problem, Formatting or Query -  Send Feedback

Was this page helpful?-10+1


rfc:rfc6780

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6780.txt · Last modified: 2012/10/27 01:55 (external edit)