--- 1/draft-ietf-ccamp-assoc-ext-03.txt 2012-08-14 16:14:42.537758605 +0200 +++ 2/draft-ietf-ccamp-assoc-ext-04.txt 2012-08-14 16:14:42.569758546 +0200 @@ -1,35 +1,35 @@ Internet Draft Lou Berger (LabN) Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco) Category: Standards Track Ashok Narayanan (Cisco) -Expiration Date: September 9, 2012 +Expiration Date: February 14, 2013 - March 9, 2012 + August 14, 2012 RSVP Association Object Extensions - draft-ietf-ccamp-assoc-ext-03.txt + draft-ietf-ccamp-assoc-ext-04.txt Abstract The RSVP ASSOCIATION object was defined in the context of GMPLS (Generalized Multi-Protocol Label Switching) 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, and this document defines how the ASSOCIATION object can be more generally applied. This document also defines - extended ASSOCIATION objects which, in particular, can be used in - the context of Transport Profile of Multiprotocol Label Switching - (MPLS-TP). This document updates RFC 2205, RFC 3209, and RFC - 3473. It also modifies the definition of the Association ID field - defined in RFC 4872. + Extended ASSOCIATION objects which, in particular, can be used in + the context of the Transport Profile of Multiprotocol Label + Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, + and RFC 3473. It also modifies the definition of the Association + ID field defined in RFC 4872. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -38,21 +38,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html - This Internet-Draft will expire on September 9, 2012 + This Internet-Draft will expire on February 14, 2013 Copyright and License Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -60,21 +60,21 @@ to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1 Introduction ........................................... 3 1.1 Conventions Used In This Document ...................... 4 2 Modified Association ID Field Definition ............... 4 - 3 Non-GMPLS Recovery Usage ............................... 5 + 3 Non-GMPLS and Non-Recovery Usage ....................... 5 3.1 Upstream Initiated Association ......................... 5 3.1.1 Path Message Format .................................... 5 3.1.2 Path Message Processing ................................ 6 3.2 Downstream Initiated Association ....................... 7 3.2.1 Resv Message Format .................................... 7 3.2.2 Resv Message Processing ................................ 8 3.3 Association Types ...................................... 9 3.3.1 Resource Sharing Association Type ...................... 9 4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10 4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 10 @@ -89,73 +89,76 @@ 8.2 Informative References ................................. 15 9 Authors' Addresses ..................................... 16 1. Introduction End-to-end and segment recovery are defined for GMPLS (Generalized Multi-Protocol Label Switching) controlled label switched paths (LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use the ASSOCIATION object to associate recovery LSPs with the LSP they are protecting. Additional narrative on how such associations are to - be identified is also provided in [ASSOC-INFO]. + be identified is also provided in [RFC6689]. This document expands the possible usage of the ASSOCIATION object to - non-GMPLS recovery contexts. This document reviews how association - should be made in the case 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 + non-GMPLS and non-recovery contexts. This document reviews how + association should be made in the case 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 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. However, - there is no way in RSVP today to share the resources between the - A->B and A->C subflows of the call since by definition the RSVP - reservations for these subflows must have different IP addresses - in the SESSION objects. + 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 single number that rings multiple endpoints (which may be - geographically diverse), such as phone lines on a manager's desk - and their assistant. A VoIP system that models these calls as - multiple P2P unicast pre-ring reservations would result in - significantly over-counting bandwidth on shared links, since - today unicast reservations to different endpoints cannot share - bandwidth. + 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 VoIP system + that models these calls as multiple P2P 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 allowing separate unicast + reservations to be associated and share resources. o Symmetric NAT: RSVP permits sharing of resources between multiple flows addressed to the same destination D, even from different senders S1 and S2. However, if D is behind a NAT operating in symmetric mode [RFC5389], it is possible that the destination port of the flows S1->D and S2->D may be different outside the NAT. In this - case, these flows cannot share resources using RSVP today, since - the SESSION objects for these two flows outside the NAT would - have different ports. + case, these flows cannot share resources using RSVP, since the + SESSION objects for these two flows outside the NAT have + different ports. This document defines a new mechanisms to + associate these flows and allow them to share resources. In order to support the more general usage of the ASSOCIATION object, this document modifies the definition of the Association ID field defined in RFC 4872. This modification has no impact on existing implementations. - This document also defines the extended ASSOCIATION objects which can - be used in the context of Transport Profile of Multiprotocol Label - Switching (MPLS-TP). Although, the scope of the extended ASSOCIATION + This document also defines the Extended ASSOCIATION objects which can + be used in the context of the Transport Profile of Multiprotocol + Label Switching (MPLS-TP). The scope of the Extended ASSOCIATION objects is not limited to MPLS-TP. 1.1. Conventions Used In This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. Modified Association ID Field Definition @@ -174,61 +177,58 @@ ASSOCIATION objects as: A value assigned by the 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 [RFC4872] or [RFC4873] defined procedures or mechanisms, nor does it impact existing implementations of [RFC4872] or [RFC4873]. -3. Non-GMPLS Recovery Usage +3. Non-GMPLS and Non-Recovery Usage While the ASSOCIATION object, [RFC4872], is defined in the context of GMPLS Recovery, the object can have wider application. [RFC4872] defines the object to be used to "associate LSPs with each other", and then defines an Association Type field to identify the type of - association being identified. It also defines that the Association + association being identified. It also specifies that the Association Type field is to be considered when determining association, i.e., there may be type-specific association rules. As defined by - [RFC4872] and reviewed in [ASSOC-INFO], this is the case for Recovery - type association objects. [ASSOC-INFO], notably the text related to + [RFC4872] and reviewed in [RFC6689], this is the case for Recovery + type association objects. [RFC6689], notably the text related to resource sharing types, can also be used as the foundation for a generic method for associating LSPs when there is no type-specific association defined. The remainder of this section defines the general rules to be followed when processing ASSOCIATION objects. Object usage in both Path and Resv messages is discussed. The usage applies equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described below, association is always done based on matching either Path state to Path state, or Resv state to Resv state, but not Path state to Resv - State. Note that there are times when no matching state is found, - e.g., when processing an initial LSP or when the ASSOCIATION object - contains otherwise useful information, and such cases do not alter - the processing defined below. This section applies to the - ASSOCIATION objects defined in [RFC4872]. + State. This section applies to the ASSOCIATION objects defined in + [RFC4872]. 3.1. Upstream Initiated Association Upstream initiated association is represented in ASSOCIATION objects carried in Path messages and can be used to associate RSVP Path state across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS tunnel is represented by a RSVP SESSION object, and multiple LSPs may be represented within a single tunnel.) Cross-session association - based on Path state is defined in [RFC4872]. This definition is - extended by this section, which defined generic association rules and - usage for non-LSP uses. This section does not modify processing - required to support [RFC4872] and [RFC4873], and which is reviewed in - Section 3 of [ASSOC-INFO]. The use of an ASSOCIATION object in a - single session is not precluded. + based on Path state is defined in [RFC4872]. This section extends + that definition by specifying generic association rules and usage for + non-LSP uses. This section does not modify processing required to + support [RFC4872] and [RFC4873], and which is reviewed in Section 3 + of [RFC6689]. The use of an ASSOCIATION object in a single session + is not precluded. 3.1.1. Path Message Format This section provides the Backus-Naur Form (BNF), see [RFC5511], for Path messages containing ASSOCIATION objects. BNF is provided for both MPLS and for non-LSP session usage. Unmodified RSVP message formats and some optional objects are not listed. The format for MPLS and GMPLS sessions is unmodified from [RFC4872], and can be represented based on the BNF in [RFC3209] as: @@ -253,36 +253,35 @@ [ ] In general, relative ordering of ASSOCIATION objects with respect to each other as well as with respect to other objects is not significant. Relative ordering of ASSOCIATION objects of the same type SHOULD be preserved by transit nodes. 3.1.2. Path Message Processing This section is based on the processing rules described in [RFC4872] - and [RFC4873], and which is reviewed in [ASSOC-INFO]. These - procedures apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session - state. + and [RFC4873], and which is reviewed in [RFC6689]. These procedures + apply equally to GMPLS LSPs, MPLS LSPs and non-LSP session state. A node sending a Path message chooses when an ASSOCIATION object is - to be included in the outgoing Path message. A node that wishes to - allow downstream nodes to associate Path state across RSVP sessions - MUST include an ASSOCIATION object in the outgoing Path 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 across all associated - sessions. When there is an Association Type-specific definition of - association rules, the definition SHOULD allow for association based - on identical ASSOCIATION objects. This document does not define any - Association Type-specific rules. (See Section 3 of [ASSOC-INFO] for - a review of Association Type-specific rules derived from [RFC4872].) + 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 + MUST be identical. When there is an Association Type-specific + definition of association rules, the definition SHOULD allow for + association based on identical ASSOCIATION objects. This document + does not define any Association Type-specific rules. (See Section 3 + of [RFC6689] for a review of Association Type-specific rules derived + from [RFC4872].) When creating an ASSOCIATION object, the originator MUST format the object as defined in Section 16.1 of [RFC4872]. The originator MUST set the Association Type field based on the type of association being identified. The Association ID field MUST be set to a value that uniquely identifies the sessions to be associated 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. @@ -335,22 +334,21 @@ [ ] [ ] [ ... ] [ ... ]