6780
PROPOSED STANDARD
RSVP ASSOCIATION Object Extensions
Authors: L. Berger, F. Le Faucheur, A. Narayanan
Date: October 2012
Area: rtg
Working Group: ccamp
Stream: IETF
Updates:
RFC 2205
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. [STANDARDS-TRACK]
RFC 6780
PROPOSED STANDARD
Internet Engineering Task Force (IETF) L. Berger
Request for Comments: 6780 LabN
Updates: <a href="./rfc2205">2205</a>, <a href="./rfc3209">3209</a>, <a href="./rfc3473">3473</a>, <a href="./rfc4872">4872</a> F. Le Faucheur
Category: Standards Track A. Narayanan
ISSN: 2070-1721 Cisco
October 2012
<span class="h1">RSVP ASSOCIATION Object Extensions</span>
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 <a href="./rfc2205">RFC 2205</a>, <a href="./rfc3209">RFC 3209</a>, and <a href="./rfc3473">RFC 3473</a>. It also generalizes the
definition of the Association ID field defined in <a href="./rfc4872">RFC 4872</a>.
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 <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="https://www.rfc-editor.org/info/rfc6780">http://www.rfc-editor.org/info/rfc6780</a>.
<span class="grey">Berger, et al. Standards Track [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-1.1">1.1</a>. Conventions Used in This Document ..........................<a href="#page-4">4</a>
<a href="#section-2">2</a>. Generalized Association ID Field Definition .....................<a href="#page-4">4</a>
<a href="#section-3">3</a>. Non-GMPLS and Non-Recovery Usage ................................<a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. Upstream Initiated Association .............................<a href="#page-5">5</a>
<a href="#section-3.1.1">3.1.1</a>. Path Message Format .................................<a href="#page-5">5</a>
<a href="#section-3.1.2">3.1.2</a>. Path Message Processing .............................<a href="#page-6">6</a>
<a href="#section-3.2">3.2</a>. Downstream Initiated Association ...........................<a href="#page-7">7</a>
<a href="#section-3.2.1">3.2.1</a>. Resv Message Format .................................<a href="#page-8">8</a>
<a href="#section-3.2.2">3.2.2</a>. Resv Message Processing .............................<a href="#page-8">8</a>
<a href="#section-3.3">3.3</a>. Association Types ..........................................<a href="#page-9">9</a>
<a href="#section-3.3.1">3.3.1</a>. Resource Sharing Association Type ...................<a href="#page-9">9</a>
<a href="#section-3.3.2">3.3.2</a>. Unknown Association Types ..........................<a href="#page-10">10</a>
<a href="#section-4">4</a>. IPv4 and IPv6 Extended ASSOCIATION Objects .....................<a href="#page-10">10</a>
<a href="#section-4.1">4.1</a>. IPv4 and IPv6 Extended ASSOCIATION Object Format ..........<a href="#page-11">11</a>
<a href="#section-4.2">4.2</a>. Processing ................................................<a href="#page-13">13</a>
<a href="#section-5">5</a>. Compatibility ..................................................<a href="#page-14">14</a>
<a href="#section-6">6</a>. Security Considerations ........................................<a href="#page-14">14</a>
<a href="#section-7">7</a>. IANA Considerations ............................................<a href="#page-15">15</a>
<a href="#section-7.1">7.1</a>. IPv4 and IPv6 Extended ASSOCIATION Objects ................<a href="#page-15">15</a>
<a href="#section-7.2">7.2</a>. Resource Sharing Association Type .........................<a href="#page-15">15</a>
<a href="#section-8">8</a>. Acknowledgments ................................................<a href="#page-16">16</a>
<a href="#section-9">9</a>. References .....................................................<a href="#page-16">16</a>
<a href="#section-9.1">9.1</a>. Normative References ......................................<a href="#page-16">16</a>
<a href="#section-9.2">9.2</a>. Informative References ....................................<a href="#page-16">16</a>
<span class="grey">Berger, et al. Standards Track [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
End-to-end and segment recovery are defined for GMPLS-controlled
Label Switched Paths (LSPs) in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>], 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 [<a href="./rfc6689" title=""Usage of the RSVP ASSOCIATION Object"">RFC6689</a>].
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 [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>], MPLS LSPs [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], and non-LSP
RSVP sessions [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>] [<a href="./rfc2207" title=""RSVP Extensions for IPSEC Data Flows"">RFC2207</a>] [<a href="./rfc3175" title=""Aggregation of RSVP for IPv4 and IPv6 Reservations"">RFC3175</a>] [<a href="./rfc4860" title=""Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations"">RFC4860</a>]. 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.
<span class="grey">Berger, et al. Standards Track [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
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
[<a href="./rfc5389" title=""Session Traversal Utilities for NAT (STUN)"">RFC5389</a>], 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 <a href="./rfc4872">RFC 4872</a>. 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 <a href="./rfc4872">RFC 4872</a>, 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.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Conventions Used in This Document</span>
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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Generalized Association ID Field Definition</span>
The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION
objects defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]. The [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] 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:
<span class="grey">Berger, et al. Standards Track [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
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 [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] or [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>], nor does it impact the
existing implementations of [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] or [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>].
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Non-GMPLS and Non-Recovery Usage</span>
While the ASSOCIATION object [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] is defined in the context of
GMPLS recovery, the object can have wider application. [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]
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
[<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and reviewed in [<a href="./rfc6689" title=""Usage of the RSVP ASSOCIATION Object"">RFC6689</a>], this is the case for recovery
type ASSOCIATION objects. [<a href="./rfc6689" title=""Usage of the RSVP ASSOCIATION Object"">RFC6689</a>], 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 [<a href="./rfc3473" title=""Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions"">RFC3473</a>], MPLS LSPs [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], and non-LSP RSVP sessions
[<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>] [<a href="./rfc2207" title=""RSVP Extensions for IPSEC Data Flows"">RFC2207</a>] [<a href="./rfc3175" title=""Aggregation of RSVP for IPv4 and IPv6 Reservations"">RFC3175</a>] [<a href="./rfc4860" title=""Generic Aggregate Resource ReSerVation Protocol (RSVP) Reservations"">RFC4860</a>]. 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
[<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Upstream-Initiated Association</span>
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 [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>], 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 [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]. 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 [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>], which is reviewed in <a href="./rfc6689#section-3">Section 3 of
[RFC6689]</a>. The use of an ASSOCIATION object in a single session is
not precluded.
<span class="grey">Berger, et al. Standards Track [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
<span class="h4"><a class="selflink" id="section-3.1.1" href="#section-3.1.1">3.1.1</a>. Path Message Format</span>
This section provides the Backus-Naur Form (BNF), see [<a href="./rfc5511" title=""Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications"">RFC5511</a>], 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 [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]
and can be represented based on the BNF in [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>] 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 [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>] 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.
<span class="h4"><a class="selflink" id="section-3.1.2" href="#section-3.1.2">3.1.2</a>. Path Message Processing</span>
This section is based on, and extends, the processing rules described
in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>], which is reviewed in [<a href="./rfc6689" title=""Usage of the RSVP ASSOCIATION Object"">RFC6689</a>]. 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 [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>].
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
<span class="grey">Berger, et al. Standards Track [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
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 <a href="./rfc6689#section-3">Section 3
of [RFC6689]</a> for a review of Association-Type-specific rules derived
from [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].)
When creating an ASSOCIATION object, the originator MUST format the
object as defined in <a href="./rfc4872#section-16.1">Section 16.1 of [RFC4872]</a>. 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.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Downstream-Initiated Association</span>
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 [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]. This section defines
<span class="grey">Berger, et al. Standards Track [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
cross-session association based on Resv state. This section places
no additional requirements on implementations supporting [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]
and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. Note, the use of an ASSOCIATION object in a single
session is not precluded.
<span class="h4"><a class="selflink" id="section-3.2.1" href="#section-3.2.1">3.2.1</a>. Resv Message Format</span>
This section provides the Backus-Naur Form (BNF), see [<a href="./rfc5511" title=""Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications"">RFC5511</a>], 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 [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>] and [<a href="./rfc3209" title=""RSVP-TE: Extensions to RSVP for LSP Tunnels"">RFC3209</a>]:
<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.
<span class="h4"><a class="selflink" id="section-3.2.2" href="#section-3.2.2">3.2.2</a>. Resv Message Processing</span>
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 <a href="./rfc4872#section-16.1">Section 16.1 of [RFC4872]</a>. The originator MUST
set the Association Type field based on the type of association being
<span class="grey">Berger, et al. Standards Track [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
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.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Association Types</span>
Two association types are currently defined: recovery and resource
sharing. Recovery type association is only applicable within the
context of recovery [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. Resource sharing is
applicable to any context and its general use is defined in this
section.
<span class="h4"><a class="selflink" id="section-3.3.1" href="#section-3.3.1">3.3.1</a>. Resource Sharing Association Type</span>
The Resource Sharing Association Type was defined in [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>] 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
<span class="grey">Berger, et al. Standards Track [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
type in [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>] and no changes are required by this section in
order to support [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. 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 [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>], 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 <a href="#section-3.1.2">Section 3.1.2</a> for upstream-
initiated (Path message) association and <a href="#section-3.2.1">Section 3.2.1</a> 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).
<span class="h4"><a class="selflink" id="section-3.3.2" href="#section-3.3.2">3.3.2</a>. Unknown Association Types</span>
As required by Sections <a href="#section-3.1.2">3.1.2</a> and <a href="#section-3.2.2">3.2.2</a> 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.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. IPv4 and IPv6 Extended ASSOCIATION Objects</span>
[<a id="ref-RFC4872">RFC4872</a>] 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).
<span class="grey">Berger, et al. Standards Track [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
An additional case that cannot be supported using the existing
ASSOCIATION objects is presented by MPLS-TP LSPs. Per [<a href="./rfc6370" title=""MPLS Transport Profile (MPLS-TP) Identifiers"">RFC6370</a>],
MPLS-TP LSPs can be identified based on an operator-unique global
identifier. As defined in [<a href="./rfc6370" title=""MPLS Transport Profile (MPLS-TP) Identifiers"">RFC6370</a>], "global identifier", or
Global_ID, is based on [<a href="./rfc5003" title=""Attachment Individual Identifier (AII) Types for Aggregation"">RFC5003</a>] 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.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. IPv4 and IPv6 Extended ASSOCIATION Object Format</span>
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 :
: . :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<span class="grey">Berger, et al. Standards Track [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
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 [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].
Association ID: 16 bits
Same as for IPv4 and IPv6 ASSOCIATION objects, see <a href="#section-2">Section 2</a>.
Association Source: 4 or 16 bytes
Same as for IPv4 and IPv6 ASSOCIATION objects, see [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>].
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 [<a href="./rfc6370" title=""MPLS Transport Profile (MPLS-TP) Identifiers"">RFC6370</a>] 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.
<span class="grey">Berger, et al. Standards Track [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
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.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Processing</span>
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 <a href="#section-4">Section 4</a>.
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.
<span class="grey">Berger, et al. Standards Track [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
Note: Per [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>], 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 <a href="#section-4">Section 4</a> 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.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Compatibility</span>
Per [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>], the ASSOCIATION object uses an object class number of
the form 11bbbbbb to ensure compatibility with non-supporting nodes.
Per [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>], 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 <a href="#section-3.1.2">Section 3.1.2</a>, 3.2.2, and
3.3.2.
Per [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>], 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 [<a href="./rfc2205" title=""Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification"">RFC2205</a>], 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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
A portion of this document reviews procedures defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]
and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>] and does not define new procedures. As such, no new
security considerations are introduced in this portion of the
document.
<a href="#section-3">Section 3</a> defines broader usage of the ASSOCIATION object, but does
not fundamentally expand on the association function that was
previously defined in [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>] and [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. <a href="#section-4">Section 4</a> 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
<span class="grey">Berger, et al. Standards Track [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
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 [<a href="./rfc5920" title=""Security Framework for MPLS and GMPLS Networks"">RFC5920</a>].
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. IANA Considerations</span>
IANA has assigned new values for namespaces defined in this document
and they are summarized in this section.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. IPv4 and IPv6 Extended ASSOCIATION Objects</span>
Per this document, IANA has assigned two new C-Types (which are
defined in <a href="#section-3.1">Section 3.1</a>) 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
<a href="http://www.iana">http://www.iana</a>.org/assignments/rsvp-parameters:
199 ASSOCIATION [<a href="./rfc4872" title=""RSVP-TE Extensions in Support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS) Recovery"">RFC4872</a>]
Class Types or C-Types
3 Type 3 IPv4 Extended Association [<a href="./rfc6780">RFC6780</a>]
4 Type 4 IPv6 Extended Association [<a href="./rfc6780">RFC6780</a>]
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Resource Sharing Association Type</span>
This document also broadens the potential usage of the Resource
Sharing Association Type defined in [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]. 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
<a href="http://www.iana.org/assignments/gmpls-sig-parameters/">http://www.iana.org/assignments/gmpls-sig-parameters/</a> has been
updated as follows:
OLD:
2 Resource Sharing (R) [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>]
NEW:
2 Resource Sharing (S) [<a href="./rfc4873" title=""GMPLS Segment Recovery"">RFC4873</a>][RFC6780]
There are no other IANA considerations introduced by this document.
<span class="grey">Berger, et al. Standards Track [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgments</span>
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.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. References</span>
<span class="h3"><a class="selflink" id="section-9.1" href="#section-9.1">9.1</a>. Normative References</span>
[<a id="ref-RFC2205">RFC2205</a>] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", <a href="./rfc2205">RFC 2205</a>, September 1997.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>, March 1997.
[<a id="ref-RFC3209">RFC3209</a>] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", <a href="./rfc3209">RFC 3209</a>, December 2001.
[<a id="ref-RFC3473">RFC3473</a>] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", <a href="./rfc3473">RFC</a>
<a href="./rfc3473">3473</a>, January 2003.
[<a id="ref-RFC4872">RFC4872</a>] 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", <a href="./rfc4872">RFC 4872</a>, May 2007.
[<a id="ref-RFC4873">RFC4873</a>] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel,
"GMPLS Segment Recovery", <a href="./rfc4873">RFC 4873</a>, May 2007.
[<a id="ref-RFC5511">RFC5511</a>] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", <a href="./rfc5511">RFC 5511</a>, April 2009.
<span class="h3"><a class="selflink" id="section-9.2" href="#section-9.2">9.2</a>. Informative References</span>
[<a id="ref-RFC2207">RFC2207</a>] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", <a href="./rfc2207">RFC 2207</a>, September 1997.
[<a id="ref-RFC3175">RFC3175</a>] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", <a href="./rfc3175">RFC</a>
<a href="./rfc3175">3175</a>, September 2001.
<span class="grey">Berger, et al. Standards Track [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc6780">RFC 6780</a> RSVP Extensions October 2012</span>
[<a id="ref-RFC4860">RFC4860</a>] Le Faucheur, F., Davie, B., Bose, P., Christou, C., and M.
Davenport, "Generic Aggregate Resource ReSerVation
Protocol (RSVP) Reservations", <a href="./rfc4860">RFC 4860</a>, May 2007.
[<a id="ref-RFC5003">RFC5003</a>] Metz, C., Martini, L., Balus, F., and J. Sugimoto,
"Attachment Individual Identifier (AII) Types for
Aggregation", <a href="./rfc5003">RFC 5003</a>, September 2007.
[<a id="ref-RFC5389">RFC5389</a>] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", <a href="./rfc5389">RFC 5389</a>,
October 2008.
[<a id="ref-RFC5920">RFC5920</a>] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", <a href="./rfc5920">RFC 5920</a>, July 2010.
[<a id="ref-RFC6370">RFC6370</a>] Bocci, M., Swallow, G., and E. Gray, "MPLS Transport
Profile (MPLS-TP) Identifiers", <a href="./rfc6370">RFC 6370</a>, September 2011.
[<a id="ref-RFC6689">RFC6689</a>] Berger, L., "Usage of the RSVP ASSOCIATION Object", <a href="./rfc6689">RFC</a>
<a href="./rfc6689">6689</a>, July 2012.
Authors' Addresses
Lou Berger
LabN Consulting, L.L.C.
Phone: +1-301-468-9228
EMail: [email protected]
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
EMail: [email protected]
Ashok Narayanan
Cisco Systems
300 Beaver Brook Road
Boxborough, MA 01719
United States
EMail: [email protected]
Berger, et al. Standards Track [Page 17]
Annotations
Select text to annotate