idnits 2.17.1 draft-ietf-ccamp-assoc-ext-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4872, but the abstract doesn't seem to directly say this. It does mention RFC4872 though, so this could be OK. -- The draft header indicates that this document updates RFC3473, but the abstract doesn't seem to directly say this. It does mention RFC3473 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2205, updated by this document, for RFC5378 checks: 1997-09-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 21, 2012) is 4228 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 5389 (Obsoleted by RFC 8489) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Lou Berger (LabN) 2 Updates: 2205, 3209, 3473, 4872 Francois Le Faucheur (Cisco) 3 Category: Standards Track Ashok Narayanan (Cisco) 4 Expiration Date: March 21, 2013 6 September 21, 2012 8 RSVP Association Object Extensions 10 draft-ietf-ccamp-assoc-ext-06.txt 12 Abstract 14 The RSVP ASSOCIATION object was defined in the context of GMPLS 15 (Generalized Multi-Protocol Label Switching) controlled label 16 switched paths (LSPs). In this context, the object is used to 17 associate recovery LSPs with the LSP they are protecting. This 18 object also has broader applicability as a mechanism to associate 19 RSVP state, and this document defines how the ASSOCIATION object 20 can be more generally applied. This document also defines 21 Extended ASSOCIATION objects which, in particular, can be used in 22 the context of the Transport Profile of Multiprotocol Label 23 Switching (MPLS-TP). This document updates RFC 2205, RFC 3209, 24 and RFC 3473. It also generalizes the definition of the Association 25 ID field defined in RFC 4872. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on March 21, 2013 50 Copyright and License Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1 Introduction ........................................... 3 68 1.1 Conventions Used In This Document ...................... 4 69 2 Generalized Association ID Field Definition ............ 4 70 3 Non-GMPLS and Non-Recovery Usage ....................... 5 71 3.1 Upstream Initiated Association ......................... 5 72 3.1.1 Path Message Format .................................... 6 73 3.1.2 Path Message Processing ................................ 6 74 3.2 Downstream Initiated Association ....................... 7 75 3.2.1 Resv Message Format .................................... 8 76 3.2.2 Resv Message Processing ................................ 8 77 3.3 Association Types ...................................... 9 78 3.3.1 Resource Sharing Association Type ...................... 9 79 3.3.2 Unknown Association Types .............................. 10 80 4 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 10 81 4.1 IPv4 and IPv6 Extended ASSOCIATION Object Format ....... 11 82 4.2 Processing ............................................. 13 83 5 Compatibility .......................................... 14 84 6 Security Considerations ................................ 14 85 7 IANA Considerations .................................... 15 86 7.1 IPv4 and IPv6 Extended ASSOCIATION Objects ............. 15 87 7.2 Resource Sharing Association Type ...................... 15 88 8 Acknowledgments ........................................ 16 89 9 References ............................................. 16 90 9.1 Normative References ................................... 16 91 9.2 Informative References ................................. 16 92 10 Authors' Addresses ..................................... 17 94 1. Introduction 96 End-to-end and segment recovery are defined for GMPLS (Generalized 97 Multi-Protocol Label Switching) controlled label switched paths 98 (LSPs) in [RFC4872] and [RFC4873] respectively. Both definitions use 99 the ASSOCIATION object to associate recovery LSPs with the LSP they 100 are protecting. Additional narrative on how such associations are to 101 be identified is also provided in [RFC6689]. 103 This document expands the possible usage of the ASSOCIATION object to 104 non-GMPLS and non-recovery contexts. The expanded usage applies 105 equally to GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP 106 sessions [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. This 107 document also reviews how association should be made in the case 108 where the object is carried in a Path message and defines usage with 109 Resv messages. This section also discusses usage of the ASSOCIATION 110 object outside the context of GMPLS LSPs. 112 Some examples of non-LSP association in order to enable resource 113 sharing are: 115 o Voice Call-Waiting: 116 A bidirectional voice call between two endpoints A and B is 117 signaled using two separate unidirectional RSVP reservations for 118 the flows A->B and B->A. If endpoint A wishes to put the A-B call 119 on hold and join a separate A-C call, it is desirable that 120 network resources on common links be shared between the A-B and 121 A-C calls. The B->A and C->A subflows of the call can share 122 resources using existing RSVP sharing mechanisms, but only if 123 they use the same destination IP addresses and ports. Since, by 124 definition, the RSVP reservations for the subflows A->B and A->C 125 of the call must have different IP addresses in the SESSION 126 objects, this document defines a new mechanism to associate the 127 subflows and allow them to share resources. 129 o Voice Shared Line: 130 A voice shared line is a single number that rings multiple 131 endpoints (which may be geographically diverse), such as phone 132 lines to a manager's desk and to their assistant. A VoIP system 133 that models these calls as multiple P2P unicast pre-ring 134 reservations would result in significantly over-counting 135 bandwidth on shared links, since RSVP unicast reservations to 136 different endpoints cannot share bandwidth. So a new mechanism 137 is defined in this document allowing separate unicast 138 reservations to be associated and share resources. 140 o Symmetric NAT: 141 RSVP permits sharing of resources between multiple flows 142 addressed to the same destination D, even from different senders 143 S1 and S2. However, if D is behind a NAT operating in symmetric 144 mode [RFC5389], it is possible that the destination port of the 145 flows S1->D and S2->D may be different outside the NAT. In this 146 case, these flows cannot share resources using RSVP, since the 147 SESSION objects for these two flows outside the NAT have 148 different destination ports. This document defines a new 149 mechanism to associate these flows and allow them to share 150 resources. 152 In order to support the wider usage of the ASSOCIATION object, this 153 document generalizes the definition of the Association ID field 154 defined in RFC 4872. This generalization has no impact on existing 155 implementations. When using the procedures defined below, 156 association is identified based on exact ASSOCIATION object matching. 157 Some of the other matching mechanisms defined in RFC 4872, e.g., 158 matching based on Session IDs, are not generalized. This document 159 allows for, but does not specify, association type-specific 160 processing. 162 This document also defines the Extended ASSOCIATION objects which can 163 be used in the context of the Transport Profile of Multiprotocol 164 Label Switching (MPLS-TP). The scope of the Extended ASSOCIATION 165 objects is not limited to MPLS-TP. 167 1.1. Conventions Used In This Document 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119]. 173 2. Generalized Association ID Field Definition 175 The Association ID field is carried in the IPv4 and IPv6 ASSOCIATION 176 objects defined in [RFC4872]. The [RFC4872] definition of the field 177 reads: 179 A value assigned by the LSP head-end. When combined with the 180 Association Type and Association Source, this value uniquely 181 identifies an association. 183 This document allows for the origination of ASSOCIATION objects by 184 nodes other than "the LSP head-end". As such, the definition of the 185 Association ID field needs to be generalized to accommodate such 186 usage. This document defines the Association ID field of the IPv4 187 and IPv6 ASSOCIATION objects as: 189 A value assigned by the node that originated the association. 190 When combined with the other fields carried in the object, this 191 value uniquely identifies an association. 193 This change in definition does not impact [RFC4872] or [RFC4873] 194 defined procedures or mechanisms, nor does it impact existing 195 implementations of [RFC4872] or [RFC4873]. 197 3. Non-GMPLS and Non-Recovery Usage 199 While the ASSOCIATION object, [RFC4872], is defined in the context of 200 GMPLS Recovery, the object can have wider application. [RFC4872] 201 defines the object to be used to "associate LSPs with each other", 202 and then defines an Association Type field to identify the type of 203 association being identified. It also specifies that the Association 204 Type field is to be considered when determining association, i.e., 205 there may be type-specific association rules. As defined by 206 [RFC4872] and reviewed in [RFC6689], this is the case for Recovery 207 type association objects. [RFC6689], notably the text related to 208 resource sharing types, can also be used as the foundation for a 209 generic method for associating LSPs when there is no type-specific 210 association defined. 212 The remainder of this section defines the general rules to be 213 followed when processing ASSOCIATION objects. Object usage in both 214 Path and Resv messages is discussed. The usage applies equally to 215 GMPLS LSPs [RFC3473], MPLS LSPs [RFC3209] and non-LSP RSVP sessions 216 [RFC2205], [RFC2207], [RFC3175] and [RFC4860]. As described below, 217 association is always done based on matching either Path state to 218 Path state, or Resv state to Resv state, but not Path state to Resv 219 State. This section applies to the ASSOCIATION objects defined in 220 [RFC4872]. 222 3.1. Upstream Initiated Association 224 Upstream initiated association is represented in ASSOCIATION objects 225 carried in Path messages and can be used to associate RSVP Path state 226 across MPLS Tunnels / RSVP sessions. (Note, per [RFC3209], an MPLS 227 tunnel is represented by a RSVP SESSION object, and multiple LSPs may 228 be represented within a single tunnel.) Cross-LSP association based 229 on Path state is defined in [RFC4872]. This section extends that 230 definition by specifying generic association rules and usage for non- 231 LSP uses. This section does not modify processing required to 232 support [RFC4872] and [RFC4873], and which is reviewed in Section 3 233 of [RFC6689]. The use of an ASSOCIATION object in a single session 234 is not precluded. 236 3.1.1. Path Message Format 238 This section provides the Backus-Naur Form (BNF), see [RFC5511], for 239 Path messages containing ASSOCIATION objects. BNF is provided for 240 both MPLS and for non-LSP session usage. Unmodified RSVP message 241 formats and some optional objects are not listed. 243 The formats for MPLS and GMPLS sessions are unmodified from 244 [RFC4872], and can be represented based on the BNF in [RFC3209] as: 246 ::= [ ] 247 248 249 [ ] 250 251 [ ] 252 [ ... ] 253 [ ... ] 254 256 The format for non-LSP sessions as based on the BNF in [RFC2205] is: 258 ::= [ ] 259 260 261 [ ... ] 262 [ ... ] 263 [ ] 265 In general, relative ordering of ASSOCIATION objects with respect to 266 each other as well as with respect to other objects is not 267 significant. Relative ordering of ASSOCIATION objects of the same 268 type SHOULD be preserved by transit nodes. 270 3.1.2. Path Message Processing 272 This section is based on, and extends, the processing rules described 273 in [RFC4872] and [RFC4873], and which is reviewed in [RFC6689]. This 274 section applies equally to GMPLS LSPs, MPLS LSPs and non-LSP session 275 state. Note, as previously stated, this section does not modify 276 processing required to support [RFC4872] and [RFC4873]. 278 A node sending a Path message chooses when an ASSOCIATION object is 279 to be included in the outgoing Path message. To indicate association 280 between multiple sessions, an appropriate ASSOCIATION object MUST be 281 included in the outgoing Path messages corresponding to each of the 282 associated sessions. In the absence of Association Type-specific 283 rules for identifying association, the included ASSOCIATION object 284 MUST be identical. When there is an Association Type-specific 285 definition of association rules, the definition SHOULD allow for 286 association based on identical ASSOCIATION objects. This document 287 does not define any Association Type-specific rules. (See Section 3 288 of [RFC6689] for a review of Association Type-specific rules derived 289 from [RFC4872].) 291 When creating an ASSOCIATION object, the originator MUST format the 292 object as defined in Section 16.1 of [RFC4872]. The originator MUST 293 set the Association Type field based on the type of association being 294 identified. The Association ID field MUST be set to a value that 295 uniquely identifies the association being identified within the 296 context of the Association Source field. The Association Source 297 field MUST be set to a unique address assigned to the node 298 originating the association. 300 A downstream node can identify an upstream initiated association by 301 performing the following checks. When a node receives a Path message 302 it MUST check each ASSOCIATION object received in the Path message to 303 see if it contains an Association Type field value supported by the 304 node. For each ASSOCIATION object containing a supported association 305 type, the node MUST then check to see if the object matches an 306 ASSOCIATION object received in any other Path message. To perform 307 this matching, a node MUST examine the Path state of all other 308 sessions and compare the fields contained in the newly received 309 ASSOCIATION object with the fields contained in the Path state's 310 ASSOCIATION objects. An association is deemed to exist when the same 311 values are carried in all fields of the ASSOCIATION objects being 312 compared. Type-specific processing of ASSOCIATION objects is outside 313 the scope of this document. 315 Note that as more than one association may exist, the described 316 matching MUST continue after a match is identified, and MUST be 317 performed against all local Path state. It is also possible for 318 there to be no match identified. 320 Unless there are type-specific processing rules, downstream nodes 321 MUST forward all ASSOCIATION objects received in a Path message, 322 without modification, in any corresponding outgoing Path messages. 323 This processing MUST be followed for unknown Association Type field 324 values. 326 3.2. Downstream Initiated Association 328 Downstream initiated association is represented in ASSOCIATION 329 objects carried in Resv messages and can be used to associate RSVP 330 Resv state across MPLS Tunnels / RSVP sessions. Cross-LSP 331 association based on Path state is defined in [RFC4872]. This section 332 defines cross-session association based on Resv state. This section 333 places no additional requirements on implementations supporting 334 [RFC4872] and [RFC4873]. Note, the use of an ASSOCIATION object in a 335 single session is not precluded. 337 3.2.1. Resv Message Format 339 This section provides the Backus-Naur Form (BNF), see [RFC5511], for 340 Resv messages containing ASSOCIATION objects. BNF is provided for 341 both MPLS and for non-LSP session usage. Unmodified RSVP message 342 formats and some optional objects are not listed. 344 The formats for MPLS, GMPLS and non-LSP sessions are identical, and 345 is represented based on the BNF in [RFC2205] and [RFC3209]: 347 ::= [ ] 348 349 350 [ ] [ ] 351 [ ... ] 352 [ ... ] 353