draft-ietf-ccamp-assoc-ext-04.txt   draft-ietf-ccamp-assoc-ext-05.txt 
Internet Draft Lou Berger (LabN) Internet Draft Lou Berger (LabN)
Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco) Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco)
Category: Standards Track Ashok Narayanan (Cisco) Category: Standards Track Ashok Narayanan (Cisco)
Expiration Date: February 14, 2013 Expiration Date: March 5, 2013
August 14, 2012 September 5, 2012
RSVP Association Object Extensions RSVP Association Object Extensions
draft-ietf-ccamp-assoc-ext-04.txt draft-ietf-ccamp-assoc-ext-05.txt
Abstract Abstract
The RSVP ASSOCIATION object was defined in the context of GMPLS The RSVP ASSOCIATION object was defined in the context of GMPLS
(Generalized Multi-Protocol Label Switching) controlled label (Generalized Multi-Protocol Label Switching) controlled label
switched paths (LSPs). In this context, the object is used to switched paths (LSPs). In this context, the object is used to
associate recovery LSPs with the LSP they are protecting. This associate recovery LSPs with the LSP they are protecting. This
object also has broader applicability as a mechanism to associate object also has broader applicability as a mechanism to associate
RSVP state, and this document defines how the ASSOCIATION object RSVP state, and this document defines how the ASSOCIATION object
can be more generally applied. This document also defines can be more generally applied. This document also defines
Extended ASSOCIATION objects which, in particular, can be used in Extended ASSOCIATION objects which, in particular, can be used in
the context of the Transport Profile of Multiprotocol Label the context of the Transport Profile of Multiprotocol Label
Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, Switching (MPLS-TP). This document updates RFC 2205, RFC 3209,
and RFC 3473. It also modifies the definition of the Association and RFC 3473. It also generalizes the definition of the Association
ID field defined in RFC 4872. ID field defined in RFC 4872.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
skipping to change at page 1, line 49 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on February 14, 2013 This Internet-Draft will expire on March 5, 2013
Copyright and License Notice Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction ........................................... 3 1 Introduction ........................................... 3
1.1 Conventions Used In This Document ...................... 4 1.1 Conventions Used In This Document ...................... 4
2 Modified Association ID Field Definition ............... 4 2 Generalized Association ID Field Definition ............ 4
3 Non-GMPLS and Non-Recovery Usage ....................... 5 3 Non-GMPLS and Non-Recovery Usage ....................... 5
3.1 Upstream Initiated Association ......................... 5 3.1 Upstream Initiated Association ......................... 5
3.1.1 Path Message Format .................................... 5 3.1.1 Path Message Format .................................... 6
3.1.2 Path Message Processing ................................ 6 3.1.2 Path Message Processing ................................ 6
3.2 Downstream Initiated Association ....................... 7 3.2 Downstream Initiated Association ....................... 7
3.2.1 Resv Message Format .................................... 7 3.2.1 Resv Message Format .................................... 8
3.2.2 Resv Message Processing ................................ 8 3.2.2 Resv Message Processing ................................ 8
3.3 Association Types ...................................... 9 3.3 Association Types ...................................... 9
3.3.1 Resource Sharing Association Type ...................... 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 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10
4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10 4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 11
4.2 Processing ............................................. 12 4.2 Processing ............................................. 12
5 Security Considerations ................................ 13 5 Compatibility .......................................... 13
6 IANA Considerations .................................... 14 6 Security Considerations ................................ 14
6.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 14 7 IANA Considerations .................................... 14
6.2 Resource Sharing Association Type ...................... 14 7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 14
7 Acknowledgments ........................................ 14 7.2 Resource Sharing Association Type ...................... 15
8 References ............................................. 15 8 Acknowledgments ........................................ 15
8.1 Normative References ................................... 15 9 References ............................................. 15
8.2 Informative References ................................. 15 9.1 Normative References ................................... 15
9 Authors' Addresses ..................................... 16 9.2 Informative References ................................. 16
10 Authors' Addresses ..................................... 17
1. Introduction 1. Introduction
End-to-end and segment recovery are defined for GMPLS (Generalized End-to-end and segment recovery are defined for GMPLS (Generalized
Multi-Protocol Label Switching) controlled label switched paths Multi-Protocol Label Switching) controlled label switched paths
(LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use (LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use
the ASSOCIATION object to associate recovery LSPs with the LSP they the ASSOCIATION object to associate recovery LSPs with the LSP they
are protecting. Additional narrative on how such associations are to are protecting. Additional narrative on how such associations are to
be identified is also provided in [RFC6689]. be identified is also provided in [RFC6689].
This document expands the possible usage of the ASSOCIATION object to This document expands the possible usage of the ASSOCIATION object to
non-GMPLS and non-recovery contexts. This document reviews how non-GMPLS and non-recovery contexts. The expanded usage applies
association should be made in the case where the object is carried in equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP
a Path message and defines usage with Resv messages. This section sessions [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. This
also discusses usage of the ASSOCIATION object outside the context of document also reviews how association should be made in the case
GMPLS LSPs. where the object is carried in a Path message and defines usage with
Resv messages. This section also discusses usage of the ASSOCIATION
object outside the context of GMPLS LSPs.
Some examples of non-LSP association in order to enable resource Some examples of non-LSP association in order to enable resource
sharing are: sharing are:
o Voice Call-Waiting: o Voice Call-Waiting:
A bidirectional voice call between two endpoints A and B is A bidirectional voice call between two endpoints A and B is
signaled using two separate unidirectional RSVP reservations for 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 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 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 network resources on common links be shared between the A-B and
skipping to change at page 4, line 6 skipping to change at page 4, line 8
reservations to be associated and share resources. reservations to be associated and share resources.
o Symmetric NAT: o Symmetric NAT:
RSVP permits sharing of resources between multiple flows RSVP permits sharing of resources between multiple flows
addressed to the same destination D, even from different senders addressed to the same destination D, even from different senders
S1 and S2. However, if D is behind a NAT operating in symmetric S1 and S2. However, if D is behind a NAT operating in symmetric
mode [RFC5389], it is possible that the destination port of the 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 flows S1->D and S2->D may be different outside the NAT. In this
case, these flows cannot share resources using RSVP, since the case, these flows cannot share resources using RSVP, since the
SESSION objects for these two flows outside the NAT have SESSION objects for these two flows outside the NAT have
different ports. This document defines a new mechanisms to different destination ports. This document defines a new
associate these flows and allow them to share resources. mechanism to associate these flows and allow them to share
resources.
In order to support the more general usage of the ASSOCIATION object, In order to support the wider usage of the ASSOCIATION object, this
this document modifies the definition of the Association ID field document generalizes the definition of the Association ID field
defined in RFC 4872. This modification has no impact on existing defined in RFC 4872. This generalization has no impact on existing
implementations. implementations. When using the procedures defined below,
association is identified based on exact ASSOCIATION object matching.
Some of the other matching mechanisms defined in RFC 4872, e.g.,
matching based on Session IDs, are not generalized. This document
allows for, but does not specify, association type-specific
processing.
This document also defines the Extended ASSOCIATION objects which can This document also defines the Extended ASSOCIATION objects which can
be used in the context of the Transport Profile of Multiprotocol be used in the context of the Transport Profile of Multiprotocol
Label Switching (MPLS-TP). The scope of the Extended ASSOCIATION Label Switching (MPLS-TP). The scope of the Extended ASSOCIATION
objects is not limited to MPLS-TP. objects is not limited to MPLS-TP.
1.1. Conventions Used In This Document 1.1. Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Modified Association ID Field Definition 2. Generalized Association ID Field Definition
The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION
objects defined in [RFC4872]. The [RFC4872] definition of the field objects defined in [RFC4872]. The [RFC4872] definition of the field
reads: reads:
A value assigned by the LSP head-end. When combined with the A value assigned by the LSP head-end. When combined with the
Association Type and Association Source, this value uniquely Association Type and Association Source, this value uniquely
identifies an association. identifies an association.
This document allows for the origination of ASSOCIATION objects by This document allows for the origination of ASSOCIATION objects by
nodes other than "the LSP head-end". As such, the definition of the nodes other than "the LSP head-end". As such, the definition of the
Association ID field needs to be modified to accommodate such usage. Association ID field needs to be generalized to accommodate such
This document defines the Association ID field of the IPv4 and IPv6 usage. This document defines the Association ID field of the IPv4
ASSOCIATION objects as: and IPv6 ASSOCIATION objects as:
A value assigned by the the node that originated the association. A value assigned by the node that originated the association.
When combined with the other fields carried in the object, this When combined with the other fields carried in the object, this
value uniquely identifies an association. value uniquely identifies an association.
This change in definition does not impact [RFC4872] or [RFC4873] This change in definition does not impact [RFC4872] or [RFC4873]
defined procedures or mechanisms, nor does it impact existing defined procedures or mechanisms, nor does it impact existing
implementations of [RFC4872] or [RFC4873]. implementations of [RFC4872] or [RFC4873].
3. Non-GMPLS and Non-Recovery Usage 3. Non-GMPLS and Non-Recovery Usage
While the ASSOCIATION object, [RFC4872], is defined in the context of While the ASSOCIATION object, [RFC4872], is defined in the context of
skipping to change at page 5, line 36 skipping to change at page 5, line 40
Path state, or Resv state to Resv state, but not Path state to Resv Path state, or Resv state to Resv state, but not Path state to Resv
State. This section applies to the ASSOCIATION objects defined in State. This section applies to the ASSOCIATION objects defined in
[RFC4872]. [RFC4872].
3.1. Upstream Initiated Association 3.1. Upstream Initiated Association
Upstream initiated association is represented in ASSOCIATION objects Upstream initiated association is represented in ASSOCIATION objects
carried in Path messages and can be used to associate RSVP Path state carried in Path messages and can be used to associate RSVP Path state
across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS
tunnel is represented by a RSVP SESSION object, and multiple LSPs may tunnel is represented by a RSVP SESSION object, and multiple LSPs may
be represented within a single tunnel.) Cross-session association be represented within a single tunnel.) Cross-LSP association based
based on Path state is defined in [RFC4872]. This section extends on Path state is defined in [RFC4872]. This section extends that
that definition by specifying generic association rules and usage for definition by specifying generic association rules and usage for non-
non-LSP uses. This section does not modify processing required to LSP uses. This section does not modify processing required to
support [RFC4872] and [RFC4873], and which is reviewed in Section 3 support [RFC4872] and [RFC4873], and which is reviewed in Section 3
of [RFC6689]. The use of an ASSOCIATION object in a single session of [RFC6689]. The use of an ASSOCIATION object in a single session
is not precluded. is not precluded.
3.1.1. Path Message Format 3.1.1. Path Message Format
This section provides the Backus-Naur Form (BNF), see [RFC5511], for This section provides the Backus-Naur Form (BNF), see [RFC5511], for
Path messages containing ASSOCIATION objects. BNF is provided for Path messages containing ASSOCIATION objects. BNF is provided for
both MPLS and for non-LSP session usage. Unmodified RSVP message both MPLS and for non-LSP session usage. Unmodified RSVP message
formats and some optional objects are not listed. formats and some optional objects are not listed.
The format for MPLS and GMPLS sessions is unmodified from [RFC4872], The formats for MPLS and GMPLS sessions are unmodified from
and can be represented based on the BNF in [RFC3209] as: [RFC4872], and can be represented based on the BNF in [RFC3209] as:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <ASSOCIATION> ... ] [ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<sender descriptor> <sender descriptor>
skipping to change at page 6, line 31 skipping to change at page 6, line 41
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
[ <sender descriptor> ] [ <sender descriptor> ]
In general, relative ordering of ASSOCIATION objects with respect to In general, relative ordering of ASSOCIATION objects with respect to
each other as well as with respect to other objects is not each other as well as with respect to other objects is not
significant. Relative ordering of ASSOCIATION objects of the same significant. Relative ordering of ASSOCIATION objects of the same
type SHOULD be preserved by transit nodes. type SHOULD be preserved by transit nodes.
3.1.2. Path Message Processing 3.1.2. Path Message Processing
This section is based on the processing rules described in [RFC4872] This section is based on, and extends, the processing rules described
and [RFC4873], and which is reviewed in [RFC6689]. These procedures in [RFC4872] and [RFC4873], and which is reviewed in [RFC6689]. This
apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. 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 A node sending a Path message chooses when an ASSOCIATION object is
to be included in the outgoing Path message. To indicate association to be included in the outgoing Path message. To indicate association
between multiple sessions, an appropriate ASSOCIATION object MUST be between multiple sessions, an appropriate ASSOCIATION object MUST be
included in the outgoing Path messages corresponding to each of the included in the outgoing Path messages corresponding to each of the
associated sessions. In the absence of Association Type-specific associated sessions. In the absence of Association Type-specific
rules for identifying association, the included ASSOCIATION object rules for identifying association, the included ASSOCIATION object
MUST be identical. When there is an Association Type-specific MUST be identical. When there is an Association Type-specific
definition of association rules, the definition SHOULD allow for definition of association rules, the definition SHOULD allow for
association based on identical ASSOCIATION objects. This document association based on identical ASSOCIATION objects. This document
does not define any Association Type-specific rules. (See Section 3 does not define any Association Type-specific rules. (See Section 3
of [RFC6689] for a review of Association Type-specific rules derived of [RFC6689] for a review of Association Type-specific rules derived
from [RFC4872].) from [RFC4872].)
When creating an ASSOCIATION object, the originator MUST format the When creating an ASSOCIATION object, the originator MUST format the
object as defined in Section 16.1 of [RFC4872]. The originator MUST object as defined in Section 16.1 of [RFC4872]. The originator MUST
set the Association Type field based on the type of association being set the Association Type field based on the type of association being
identified. The Association ID field MUST be set to a value that identified. The Association ID field MUST be set to a value that
uniquely identifies the sessions to be associated within the context uniquely identifies the association being identified within the
of the Association Source field. The Association Source field MUST context of the Association Source field. The Association Source
be set to a unique address assigned to the node originating the field MUST be set to a unique address assigned to the node
association. originating the association.
A downstream node can identify an upstream initiated association by A downstream node can identify an upstream initiated association by
performing the following checks. When a node receives a Path message performing the following checks. When a node receives a Path message
it MUST check each ASSOCIATION object received in the Path message to it MUST check each ASSOCIATION object received in the Path message to
see if it contains an Association Type field value supported by the see if it contains an Association Type field value supported by the
node. For each ASSOCIATION object containing a supported association node. For each ASSOCIATION object containing a supported association
type, the node MUST then check to see if the object matches an type, the node MUST then check to see if the object matches an
ASSOCIATION object received in any other Path message. To perform ASSOCIATION object received in any other Path message. To perform
this matching, a node MUST examine the Path state of all other this matching, a node MUST examine the Path state of all other
sessions and compare the fields contained in the newly received sessions and compare the fields contained in the newly received
skipping to change at page 7, line 27 skipping to change at page 7, line 39
values are carried in all fields of the ASSOCIATION objects being values are carried in all fields of the ASSOCIATION objects being
compared. Type-specific processing of ASSOCIATION objects is outside compared. Type-specific processing of ASSOCIATION objects is outside
the scope of this document. the scope of this document.
Note that as more than one association may exist, the described Note that as more than one association may exist, the described
matching MUST continue after a match is identified, and MUST be matching MUST continue after a match is identified, and MUST be
performed against all local Path state. It is also possible for performed against all local Path state. It is also possible for
there to be no match identified. there to be no match identified.
Unless there are type-specific processing rules, downstream nodes Unless there are type-specific processing rules, downstream nodes
MUST forward all ASSOCIATION objects received in a Path message in MUST forward all ASSOCIATION objects received in a Path message,
any corresponding outgoing Path messages. without modification, in any corresponding outgoing Path messages.
3.2. Downstream Initiated Association 3.2. Downstream Initiated Association
Downstream initiated association is represented in ASSOCIATION Downstream initiated association is represented in ASSOCIATION
objects carried in Resv messages and can be used to associate RSVP objects carried in Resv messages and can be used to associate RSVP
Resv state across MPLS Tunnels / RSVP sessions. Cross-session Resv state across MPLS Tunnels / RSVP sessions. Cross-LSP
association based on Path state is defined in [RFC4872]. This section association based on Path state is defined in [RFC4872]. This section
defines cross-session association based on Resv state. This section defines cross-session association based on Resv state. This section
places no additional requirements on implementations supporting places no additional requirements on implementations supporting
[RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a [RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a
single session is not precluded. single session is not precluded.
3.2.1. Resv Message Format 3.2.1. Resv Message Format
This section provides the Backus-Naur Form (BNF), see [RFC5511], for This section provides the Backus-Naur Form (BNF), see [RFC5511], for
Resv messages containing ASSOCIATION objects. BNF is provided for Resv messages containing ASSOCIATION objects. BNF is provided for
both MPLS and for non-LSP session usage. Unmodified RSVP message both MPLS and for non-LSP session usage. Unmodified RSVP message
formats and some optional objects are not listed. formats and some optional objects are not listed.
The format for MPLS, GMPLS and non-LSP sessions are identical, and is The formats for MPLS, GMPLS and non-LSP sessions are identical, and
represented based on the BNF in [RFC2205] and [RFC3209]: is represented based on the BNF in [RFC2205] and [RFC3209]:
<Resv Message> ::= <Common Header> [ <INTEGRITY> ] <Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ] [ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <ASSOCIATION> ... ] [ <ASSOCIATION> ... ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list> <STYLE> <flow descriptor list>
Relative ordering of ASSOCIATION objects with respect to each other Relative ordering of ASSOCIATION objects with respect to each other
as well as with respect to other objects is not currently as well as with respect to other objects is not currently
significant. Relative ordering of ASSOCIATION objects of the same significant. Relative ordering of ASSOCIATION objects of the same
type SHOULD be preserved by transit nodes. type SHOULD be preserved by transit nodes.
3.2.2. Resv Message Processing 3.2.2. Resv Message Processing
This section apply equally to GMPLS LSPs, MPLS LSPs and non-LSP This section applies equally to GMPLS LSPs, MPLS LSPs and non-LSP
session state. session state.
A node sending a Resv message chooses when an ASSOCIATION object is 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 to be included in the outgoing Resv message. A node that wishes to
allow upstream nodes to associate Resv state across RSVP sessions allow upstream nodes to associate Resv state across RSVP sessions
MUST include an ASSOCIATION object in the outgoing Resv messages MUST include an ASSOCIATION object in the outgoing Resv messages
corresponding to the RSVP sessions to be associated. In the absence corresponding to the RSVP sessions to be associated. In the absence
of Association Type-specific rules for identifying association, the of Association Type-specific rules for identifying association, the
included ASSOCIATION objects MUST be identical. When there is an included ASSOCIATION objects MUST be identical. When there is an
Association Type-specific definition of association rules, the Association Type-specific definition of association rules, the
definition SHOULD allow for association based on identical definition SHOULD allow for association based on identical
ASSOCIATION objects. This document does not define any Association ASSOCIATION objects. This document does not define any Association
Type-specific rules. Type-specific rules.
When creating an ASSOCIATION object, the originator MUST format the When creating an ASSOCIATION object, the originator MUST format the
object as defined in Section 16.1 of [RFC4872]. The originator MUST object as defined in Section 16.1 of [RFC4872]. The originator MUST
set the Association Type field based on the type of association being set the Association Type field based on the type of association being
identified. The Association ID field MUST be set to a value that identified. The Association ID field MUST be set to a value that
uniquely identifies the sessions to be associated within the context uniquely identifies the association being identified within the
of the Association Source field. The Association Source field MUST context of the Association Source field. The Association Source
be set to a unique address assigned to the node originating the field MUST be set to a unique address assigned to the node
association. originating the association.
An upstream node can identify a downstream initiated association by An upstream node can identify a downstream initiated association by
performing the following checks. When a node receives a Resv message performing the following checks. When a node receives a Resv message
it MUST check each ASSOCIATION object received in the Resv message to it MUST check each ASSOCIATION object received in the Resv message to
see if it contains an Association Type field value supported by the see if it contains an Association Type field value supported by the
node. For each ASSOCIATION object containing a supported association node. For each ASSOCIATION object containing a supported association
type, the node MUST then check to see if the object matches an type, the node MUST then check to see if the object matches an
ASSOCIATION object received in any other Resv message. To perform ASSOCIATION object received in any other Resv message. To perform
this matching, a node MUST examine the Resv state of all other this matching, a node MUST examine the Resv state of all other
sessions and compare the fields contained in the newly received sessions and compare the fields contained in the newly received
skipping to change at page 9, line 14 skipping to change at page 9, line 24
values are carried in all fields of the ASSOCIATION objects being values are carried in all fields of the ASSOCIATION objects being
compared. Type-specific processing of ASSOCIATION objects is outside compared. Type-specific processing of ASSOCIATION objects is outside
the scope of this document. the scope of this document.
Note that as more than one association may exist, the described Note that as more than one association may exist, the described
matching MUST continue after a match is identified, and MUST be matching MUST continue after a match is identified, and MUST be
performed against all local Resv state. It is also possible for there performed against all local Resv state. It is also possible for there
to be no match identified. to be no match identified.
Unless there are type-specific processing rules, upstream nodes MUST Unless there are type-specific processing rules, upstream nodes MUST
forward all ASSOCIATION objects received in a Resv message in any forward all ASSOCIATION objects received in a Resv message, without
corresponding outgoing Resv messages. modification, in any corresponding outgoing Resv messages.
3.3. Association Types 3.3. Association Types
Two association types are currently defined: recovery and resource Two association types are currently defined: recovery and resource
sharing. Recovery type association is only applicable within the sharing. Recovery type association is only applicable within the
context of recovery, [RFC4872] and [RFC4873]. Resource sharing is context of recovery, [RFC4872] and [RFC4873]. Resource sharing is
applicable to any context and its general use is defined in this applicable to any context and its general use is defined in this
section. section.
3.3.1. Resource Sharing Association Type 3.3.1. Resource Sharing Association Type
skipping to change at page 9, line 51 skipping to change at page 10, line 12
Path and Resv messages. Association for the Resource Sharing type Path and Resv messages. Association for the Resource Sharing type
MUST follow the procedures defined in Section 4.1.2 for upstream MUST follow the procedures defined in Section 4.1.2 for upstream
(Path message) initiated association and Section 4.2.1 for downstream (Path message) initiated association and Section 4.2.1 for downstream
(Resv message) initiated association. There are no type-specific (Resv message) initiated association. There are no type-specific
association rules, processing rules, or ordering requirements. Note association rules, processing rules, or ordering requirements. Note
that as is always the case with association as enabled by this that as is always the case with association as enabled by this
document, no associations are made across Path and Resv state. document, no associations are made across Path and Resv state.
Once an association is identified, resources MUST be considered as Once an association is identified, resources MUST be considered as
shared across the identified sessions by the admission control shared across the identified sessions by the admission control
function. Since the admission control function is outside the scope function. Since the implementation specifics of the admission control
of RSVP, we observe that how resource sharing is actually reflected function is outside the scope of RSVP, we observe that how resource
may vary according to specific implementations (e.g. depending on the sharing is actually reflected may vary according to specific
specific admission control and resource management algorithm, or on implementations (e.g. depending on the specific admission control and
how local policy is taken into account). resource management algorithm, or on how local policy is taken into
account).
3.3.2. Unknown Association Types
A node that receives an ASSOCIATION object with an unknown
ASSOCIATION type MUST forward 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 4. IPv4 and IPv6 Extended ASSOCIATION Objects
[RFC4872] defines the IPv4 ASSOCIATION object and the IPv6 [RFC4872] defines the IPv4 ASSOCIATION object and the IPv6
ASSOCIATION object. As defined, these objects each contain an ASSOCIATION object. As defined, these objects each contain an
Association Source field and a 16-bit Association ID field. The Association Source field and a 16-bit Association ID field. As
combination of the Association Source and the Association ID uniquely described above, the contents of the object uniquely identifies an
identifies the association. Because the Association ID field is a association. Because the Association ID field is a 16-bit field, an
16-bit field, an association source can allocate up to 65536 association source can allocate up to 65536 different associations
different associations and no more. There are scenarios where this and no more. There are scenarios where this number is insufficient.
number is insufficient. (For example where the association (For example where the association identification is best known and
identification is best known and identified by a fairly centralized identified by a fairly centralized entity, which therefore may be
entity, which therefore may be involved in a large number of involved in a large number of associations.)
associations.)
An additional case that cannot be supported using the existing An additional case that cannot be supported using the existing
ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370], ASSOCIATION objects is presented by MPLS-TP LSPs. Per [RFC6370],
MPLS-TP LSPs can be identified based on an operator unique global MPLS-TP LSPs can be identified based on an operator unique global
identifier. The [RFC6370] defined "global identifier", or Global_ID, identifier. The [RFC6370] defined "global identifier", or Global_ID,
is based on [RFC5003] and includes the operator's Autonomous System is based on [RFC5003] and includes the operator's Autonomous System
Number (ASN). Number (ASN).
This sections defines new ASSOCIATION objects to support extended This sections defines new ASSOCIATION objects to support extended
identification in order to address the limitations described above. identification in order to address the limitations described above.
skipping to change at page 12, line 18 skipping to change at page 12, line 30
the special value zero (0). When non-zero and not overridden by the special value zero (0). When non-zero and not overridden by
local policy, the Global_ID as defined in [RFC6370] SHALL be used. local policy, the Global_ID as defined in [RFC6370] SHALL be used.
The special value of zero indicates that no global identifier is The special value of zero indicates that no global identifier is
present. Use of the special value of zero SHOULD be limited to present. Use of the special value of zero SHOULD be limited to
entities contained within a single operator. entities contained within a single operator.
If the Global Association Source field value is derived from a If the Global Association Source field value is derived from a
2-octet AS number, then the two high-order octets of this 4-octet 2-octet AS number, then the two high-order octets of this 4-octet
field MUST be set to zero. field MUST be set to zero.
Note, as stated in [RFC6370], "the use of the Global_ID is not
related to the use of the ASN in protocols such as BGP."
This field is based on the definition of Global_ID defined in
[RFC5003] and used by [RFC6370].
Extended Association ID: variable, 4-byte aligned Extended Association ID: variable, 4-byte aligned
This field contains data that is additional information to support This field contains data that is additional information to support
unique identification. The length and contents of this field is unique identification. The length and contents of this field is
scoped by the Association Source. The length of this field is scoped by the Association Source. The length of this field is
derived from the object Length field and as such MUST have a zero derived from the object Length field and as such MUST have a zero
length or be 4-byte aligned. A zero length indicates that this length or be 4-byte aligned. A zero length indicates that this
field is omitted. field is omitted.
4.2. Processing 4.2. Processing
The processing of a IPv4 or IPv6 Extended ASSOCIATION object MUST be The processing of an IPv4 or IPv6 Extended ASSOCIATION object MUST be
identical to the processing of a IPv4 or IPv6 ASSOCIATION object as identical to the processing of an IPv4 or IPv6 ASSOCIATION object as
described above except as extended by this section. This section described above except as extended by this section. This section
applies to ASSOCIATION objects included in both Path and Resv applies to ASSOCIATION objects included in both Path and Resv
messages. messages.
The following are the modified procedures for Extended ASSOCIATION The following are the modified procedures for Extended ASSOCIATION
object processing: object processing:
o When creating an Extended ASSOCIATION object, the originator MUST o When creating an Extended ASSOCIATION object, the originator MUST
format the object as defined in this document. format the object as defined in this document.
skipping to change at page 13, line 11 skipping to change at page 13, line 20
field. When ASN-based global identification is not desired, the field. When ASN-based global identification is not desired, the
originator MUST set the Global Association Source field to zero originator MUST set the Global Association Source field to zero
(0). (0).
o The Extended ASSOCIATION object originator MAY include the o The Extended ASSOCIATION object originator MAY include the
Extended Association ID field. The field is included based on Extended Association ID field. The field is included based on
local policy. The field MUST be included when the Association ID local policy. The field MUST be included when the Association ID
field is insufficient to uniquely identify association within the field is insufficient to uniquely identify association within the
scope of the source of the association. When included, this scope of the source of the association. When included, this
field MUST be set to a value that, when taken together with the field MUST be set to a value that, when taken together with the
other fields in the object, uniquely identifies the sessions to other fields in the object, uniquely identifies the association
be associated. being identified.
o The object Length field is set based on the length of the o The object Length field is set based on the length of the
Extended Association ID field. When the Extended Association ID Extended Association ID field. When the Extended Association ID
field is omitted, the object Length field MUST be set to 16 or 28 field is omitted, the object Length field MUST be set to 16 or 28
for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the for the IPv4 and IPv6 ASSOCIATION objects, respectively. When the
Extended Association ID field is present, the object Length field Extended Association ID field is present, the object Length field
MUST be set to indicate the additional bytes carried in the MUST be set to indicate the additional bytes carried in the
Extended Association ID field, including pad bytes. Extended Association ID field, including pad bytes.
Note: per [RFC2205], the object Length field is set to the total Note: per [RFC2205], the object Length field is set to the total
object length in bytes, and is always a multiple of 4, and at object length in bytes, and is always a multiple of 4, and at
least 4. least 4.
Identification of association is not modified by this section. It is The procedures related to association identification are not modified
important to note that Section 4 defines association identification by this section. It is important to note that Section 4 defines the
based on ASSOCIATION object matching, and that such matching is based identification of associations based on ASSOCIATION object matching
on the comparison of all fields in a ASSOCIATION object (unless type- and that such matching, in the absence of type-specific comparison
specific comparison rules are defined). This applies equally to rules, is based on the comparison of all fields in an ASSOCIATION
ASSOCIATION objects and Extended ASSOCIATION objects. object. This applies equally to ASSOCIATION objects and Extended
ASSOCIATION objects.
5. Security Considerations 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 essentially also the action taken for
unknown association types as discussed above in Section 3.3.2.
Operators wishing to use a function supported by particular
association type should ensure that the type is supported on any node
which is expected to act on the association.
6. Security Considerations
A portion of this document reviews procedures defined in [RFC4872] A portion of this document reviews procedures defined in [RFC4872]
and [RFC4873] and does not define any new procedures. As such, no and [RFC4873] and does not define any new procedures. As such, no
new security considerations are introduced in this portion. new security considerations are introduced in this portion.
Section 2 defines broader usage of the ASSOCIATION object, but does Section 2 defines broader usage of the ASSOCIATION object, but does
not fundamentally expand on the association function that was not fundamentally expand on the association function that was
previously defined in [RFC4872] and [RFC4873]. Section 3 increases previously defined in [RFC4872] and [RFC4873]. Section 3 increases
the number of bits that are carried in an ASSOCIATION object (by 32), the number of bits that are carried in an ASSOCIATION object (by 32),
and similarly does not expand on the association function that was and similarly does not expand on the association function that was
previously defined. This broader definition does allow for previously defined. This broader definition does allow for
additional information to be conveyed, but this information is not additional information to be conveyed, but this information is not
fundamentally different from the information that is already carried fundamentally different from the information that is already carried
in RSVP. Therefore there are no new risks or security considerations in RSVP. Therefore there are no new risks or security considerations
introduced by this document. introduced by this document.
For a general discussion on MPLS and GMPLS related security issues, For a general discussion on MPLS and GMPLS related security issues,
see the MPLS/GMPLS security framework [RFC5920]. including RSVP's chain of trust security model, see the MPLS/GMPLS
security framework [RFC5920].
6. IANA Considerations 7. IANA Considerations
IANA is requested to administer assignment of new values for IANA is requested to administer assignment of new values for
namespaces defined in this document and summarized in this section. namespaces defined in this document and summarized in this section.
6.1. IPv4 and IPv6 Extended ASSOCIATION Objects 7.1. IPv4 and IPv6 Extended ASSOCIATION Objects
Upon approval of this document, IANA will make the assignment of two Upon approval of this document, IANA will make the assignment of two
new C-Types (which are defined in section 3.1) for the existing new C-Types (which are defined in section 3.1) for the existing
ASSOCIATION object in the "Class Names, Class Numbers, and Class ASSOCIATION object in the "Class Names, Class Numbers, and Class
Types" section of the "Resource Reservation Protocol (RSVP) Types" section of the "Resource Reservation Protocol (RSVP)
Parameters" registry located at http://www.iana.org/assignments/rsvp- Parameters" registry located at http://www.iana.org/assignments/rsvp-
parameters: parameters:
199 ASSOCIATION [RFC4872] 199 ASSOCIATION [RFC4872]
Class Types or C-Types Class Types or C-Types
3 Type 3 IPv4 Extended Association [this document] 3 Type 3 IPv4 Extended Association [this document]
4 Type 4 IPv6 Extended Association [this document] 4 Type 4 IPv6 Extended Association [this document]
6.2. Resource Sharing Association Type 7.2. Resource Sharing Association Type
This document also broadens the potential usage of the Resource This document also broadens the potential usage of the Resource
Sharing Association Type defined in [RFC4873]. As such, IANA is Sharing Association Type defined in [RFC4873]. As such, IANA is
requested to change the Reference of the Resource Sharing Association requested to change the Reference of the Resource Sharing Association
Type included in the associate registry. This document also directs Type included in the associate registry. This document also directs
IANA to correct the duplicate usage of '(R)' in this Registry. In IANA to correct the duplicate usage of '(R)' in this Registry. In
particular, the Association Type registry found at particular, the Association Type registry found at
http://www.iana.org/assignments/gmpls-sig-parameters/ should be http://www.iana.org/assignments/gmpls-sig-parameters/ should be
updated as follows: updated as follows:
OLD: OLD:
2 Resource Sharing (R) [RFC4873] 2 Resource Sharing (R) [RFC4873]
NEW NEW
2 Resource Sharing (S) [RFC4873][this-document] 2 Resource Sharing (S) [RFC4873][this-document]
There are no other IANA considerations introduced by this document. There are no other IANA considerations introduced by this document.
7. Acknowledgments 8. Acknowledgments
Valuable comments and input was received from Dimitri Papadimitriou, Valuable comments and input was received from Dimitri Papadimitriou,
Fei Zhang and Adrian Farrel. We thank Subha Dhesikan for her Fei Zhang and Adrian Farrel. We thank Subha Dhesikan for her
contribution to the early work on sharing of resources across RSVP contribution to the early work on sharing of resources across RSVP
reservations. reservations.
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and
S. Jamin, "Resource ReSerVation Protocol (RSVP) -- S. Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1, Functional Specification", RFC 2205, Version 1, Functional Specification", RFC 2205,
September 1997. September 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
skipping to change at page 15, line 38 skipping to change at page 16, line 17
Protocol Label Switching (GMPLS) Recovery", RFC 4872, Protocol Label Switching (GMPLS) Recovery", RFC 4872,
May 2007. May 2007.
[RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A., [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., Farrel, A.,
"GMPLS Segment Recovery", RFC 4873, May 2007. "GMPLS Segment Recovery", RFC 4873, May 2007.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, April 2009 Specifications", RFC 5511, April 2009
8.2. Informative References 9.2. Informative References
[RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC [RFC2207] Berger., L., O'Malley., T., "RSVP Extensions for IPSEC
RSVP Extensions for IPSEC Data Flows", RFC 2207, September RSVP Extensions for IPSEC Data Flows", RFC 2207, September
1997. 1997.
[RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation [RFC3175] Baker, F., Iturralde, C., Le, F., Davie, B., "Aggregation
of RSVP for IPv4 and IPv6 Reservations", RFC 3175, of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001. September 2001.
[RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M., [RFC4860] Le, F., Davie, B., Bose, P., Christou, C., Davenport, M.,
skipping to change at page 16, line 22 skipping to change at page 17, line 5
[RFC5920] Fang, L., et al, "Security Framework for MPLS and [RFC5920] Fang, L., et al, "Security Framework for MPLS and
GMPLS Networks", RFC 5920, July 2010. GMPLS Networks", RFC 5920, July 2010.
[RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers", [RFC6370] Bocci, M., Swallow, G., Gray, E., "MPLS-TP Identifiers",
RFC 6370, June 2011. RFC 6370, June 2011.
[RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC [RFC6689] Berger, L., "Usage of the RSVP ASSOCIATION Object", RFC
6689, July 2012. 6689, July 2012.
9. Authors' Addresses 10. Authors' Addresses
Lou Berger Lou Berger
LabN Consulting, L.L.C. LabN Consulting, L.L.C.
Phone: +1-301-468-9228 Phone: +1-301-468-9228
Email: lberger@labn.net Email: lberger@labn.net
Francois Le Faucheur Francois Le Faucheur
Cisco Systems Cisco Systems
Greenside, 400 Avenue de Roumanille Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410 Sophia Antipolis 06410
France France
Email: flefauch@cisco.com Email: flefauch@cisco.com
Ashok Narayanan Ashok Narayanan
Cisco Systems Cisco Systems
300 Beaver Brook Road 300 Beaver Brook Road
Boxborough, MA 01719 Boxborough, MA 01719
United States United States
Email: ashokn@cisco.com Email: ashokn@cisco.com
Generated on: Tue, Aug 14, 2012 9:39:19 AM Generated on: Wed, Sep 05, 2012 5:37:17 PM
 End of changes. 44 change blocks. 
99 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/