idnits 2.17.1 draft-ietf-ccamp-gmpls-vcat-lcas-13.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4606, updated by this document, for RFC5378 checks: 2005-11-28) -- 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 (May 4, 2011) is 4738 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) == Missing Reference: 'ITU-T-G.7042' is mentioned on line 398, but not defined == Unused Reference: 'ITU-T-G.7043' is defined on line 881, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group G. Bernstein (ed.) 2 Internet Draft Grotto Networking 3 Updates: 4606 (if approved) D. Caviglia 4 Category: Standards Track Ericsson 5 Expires: November 2011 R. Rabbat 6 Google 7 H. van Helvoort 8 Huawei 9 May 4, 2011 11 Operating Virtual Concatenation (VCAT) and the Link Capacity 12 Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label 13 Switching (GMPLS) 15 draft-ietf-ccamp-gmpls-vcat-lcas-13.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with 20 the provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 This Internet-Draft will expire on November 4, 2011. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with 50 respect to this document. Code Components extracted from this 51 document must include Simplified BSD License text as described in 52 Section 4.e of the Trust Legal Provisions and are provided without 53 warranty as described in the Simplified BSD License. 55 Abstract 57 This document describes requirements for, and use of, the 58 Generalized Multi-Protocol Label Switching (GMPLS) control plane in 59 support of the Virtual Concatenation (VCAT) layer 1 inverse 60 multiplexing data plane mechanism and its companion Link Capacity 61 Adjustment Scheme (LCAS) which can be used for hitless dynamic 62 resizing of the inverse multiplex group. These techniques apply to 63 Optical Transport Network (OTN), Synchronous Optical Network 64 (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous 65 Digital Hierarchy (PDH) signals. This document updates RFC 4606 by 66 making modifications to the procedures for supporting virtual 67 concatenation. 69 Conventions used in this document 71 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 72 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 73 document are to be interpreted as described in RFC-2119 [RFC2119]. 75 Table of Contents 77 1. Introduction...................................................3 78 2. VCAT/LCAS Scenarios and Specific Requirements..................4 79 2.1. VCAT/LCAS Interface Capabilities..........................4 80 2.2. Member Signal Configuration Scenarios.....................4 81 2.3. VCAT Operation With or Without LCAS.......................5 82 2.4. VCGs and VCG Members......................................6 83 3. VCAT Data and Control Plane Concepts...........................6 84 4. VCGs Composed of a Single Member Set (One LSP).................7 85 4.1. One-shot VCG Setup........................................8 86 4.2. Incremental VCG Setup.....................................8 87 4.3. Procedure for VCG Reduction by Removing a Member..........9 88 4.4. Removing Multiple VCG Members in One Shot.................9 89 4.5. Teardown of Whole VCG.....................................9 90 5. VCGs Composed of Multiple Member Sets (Multiple LSPs).........10 91 5.1. Signaled VCG Service Layer Information...................11 92 5.2. CALL ATTRIBUTES Object VCAT TLV..........................11 93 5.3. Procedures for Multiple Member Sets......................13 94 5.3.1. Setting up a new VCAT call and VCG Simultaneously...14 95 5.3.2. Setting up a VCAT call + LSPs without a VCG.........14 96 5.3.3. Associating an existing VCAT call with a new VCG....14 97 5.3.4. Removing the association between a call and VCG.....15 98 5.3.5. VCG Bandwidth modification..........................15 99 6. Error Conditions and Codes....................................16 100 7. IANA Considerations...........................................16 101 7.1. RSVP CALL_ATTRIBUTE TLV..................................16 102 7.2. RSVP Error Codes and Error Values........................17 103 8. Security Considerations.......................................18 104 9. Contributors..................................................19 105 10. Acknowledgments..............................................19 106 11. References...................................................20 107 11.1. Normative References....................................20 108 11.2. Informative References..................................20 109 Authors' Addresses...............................................21 110 Intellectual Property Statement..................................22 111 Disclaimer of Validity...........................................22 112 Acknowledgment.........................Error! Bookmark not defined. 114 1. Introduction 116 The Generalized Multi-Protocol Label Switching (GMPLS) suite of 117 protocols allows for the automated control of different switching 118 technologies including Synchronous Optical Network (SONET)[ANSI- 119 T1.105], Synchronous Digital Hierarchy (SDH)[ITU-T-G.707], Optical 120 Transport Network (OTN)[ITU-T-G.709] and Plesiochronous Digital 121 Hierarchy (PDH)[ITU-T-G.704]. This document updates the procedures 122 of [RFC4606] to allow supporting additional applications of the 123 Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism 124 that has been standardized for SONET, SDH, OTN and PDH [ITU-T-G.707, 125 ITU-T-G.709, and ITU-T-G.7043] technologies along with its companion 126 Link Capacity Adjustment Scheme (LCAS) [ITU-T-G.7042]. 128 VCAT is a time division multiplexing (TDM) oriented byte striping 129 inverse multiplexing method that works with a wide range of existing 130 and emerging TDM framed signals, including very high bit rate OTN 131 and SDH/SONET signals. VCAT enables the selection of an optimal 132 signal server bandwidth (size) utilizing a group of server signals 133 and provides for efficient use of bandwidth in a mesh network. When 134 combined with LCAS, hitless dynamic resizing of bandwidth and fast 135 graceful degradation in the presence of network faults can be 136 supported. To take full advantage of VCAT/LCAS functionality, 137 additional extensions to GMPLS signaling are needed that enable the 138 setup of diversely routed signals that are members of the same VCAT 139 group. Note that the scope of this document is limited to scenarios 140 where all member signals of a VCAT group are controlled using 141 mechanisms defined in this document and related RFCs. Scenarios 142 where a subset of member signals are controlled by a management 143 plane or a proprietary control plane are outside the scope of this 144 document. 146 2. VCAT/LCAS Scenarios and Specific Requirements 148 There are a number of specific requirements for the support of 149 VCAT/LCAS in GMPLS that can be derived from the carriers' 150 applications for the use of VCAT/LCAS. These are set out in the 151 following section. 153 2.1. VCAT/LCAS Interface Capabilities 155 In general, an label switched router (LSR) can be ingress/egress of 156 one or more VCAT groups. VCAT and LCAS are data plane interface 157 capabilities. An LSR may have, for example, VCAT-capable interfaces 158 that are not LCAS-capable. It may at the same time have interfaces 159 that are neither VCAT nor LCAS-capable. 161 2.2. Member Signal Configuration Scenarios 163 We list in this section the different scenarios. Here we use the 164 [ITU-T-G.707] term "VCG" to refer to the VCAT group and the 165 terminology "set" and "subset" to refer to the subdivision of the 166 group and the individual VCAT group member signals. As noted above, 167 the scope of these scenarios is limited to scenarios where all 168 member signals are controlled using mechanisms defined in this 169 document. 171 The scenarios listed here are dependent on the terms "co-routed" and 172 "diversely routed". In the context of this document, "co-routed" 173 refers to a set of VCAT signals that all traverse the same sequence 174 of switching nodes. Furthermore, a co-routed set of signals between 175 any pair of adjacent nodes utilize a set of links that have similar 176 delay characteristics. Thus, "diversely routed" means a set of 177 signals that are not classed as "co-routed". 179 Fixed, co-routed: A fixed bandwidth VCG, transported over a co- 180 routed set of member signals. This is the case where the 181 intended bandwidth of the VCG does not change and all member 182 signals follow the same route to minimize differential delay. 183 The application here is the capability to allocate an amount of 184 bandwidth close to that required at the client layer. 186 Fixed, diversely routed: A fixed bandwidth VCG, transported over at 187 least two diversely routed subsets of member signals. In this 188 case, the subsets are link-disjoint over at least one link of the 189 route. The application here is more efficient use of network 190 resources, e.g., no unique route has the required bandwidth. 192 Fixed, member sharing: A fixed bandwidth VCG, transported over a set 193 of member signals that are allocated from a common pool of 194 available member signals without requiring member connection 195 teardown and setup. This document only covers the case where this 196 pool of "potential" member signals has been established via 197 mechanisms defined in this document. Member signals need not be 198 co-routed or be guaranteed to be diversely routed. Note that by 199 the nature of VCAT, a member signal can only belong to one VCG at 200 a time. To be used in a different VCG, a signal must first be 201 removed from any VCG to which it may belong. 203 Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or 204 decreased via the addition or removal of member signals), 205 transported over a co-routed set of members. The application 206 here is dynamic resizing and resilience of bandwidth. 208 Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased 209 or decreased via the addition or removal of member signals), 210 transported over at least two diversely routed subsets of member 211 signals. The application here is efficient use of network 212 resources, dynamic resizing and resilience of bandwidth. 214 Dynamic, member sharing: A dynamic bandwidth VCG, transported over a 215 set of member signals that are allocated from a common pool of 216 available member signals without requiring member connection 217 teardown and setup. 219 2.3. VCAT Operation With or Without LCAS 221 VCAT capabilities may be present with or without the presence of 222 LCAS. The use of LCAS is beneficial in the provisioning of flexible 223 bandwidth services, but in the absence of LCAS, VCAT is still a 224 valid technique. Therefore GMPLS mechanisms for the operation of 225 VCAT are REQUIRED for both the case where LCAS is available and the 226 case where it is not available. The GMPLS procedures for the two 227 cases SHOULD be identical. 229 . GMPLS signaling for LCAS-capable interfaces MUST support all 230 scenarios of section 2.2. with no loss of traffic. 232 . GMPLS signaling for non-LCAS-capable interfaces MUST support 233 the "fixed" scenarios of section 2.2. 235 To provide for these requirements, GMPLS signaling MUST carry the 236 following information on behalf of the VCAT endpoints: 238 . The type of the member signal that the VCG will contain, e.g., 239 VC-3, VC-4, etc. 241 . The total number of members to be in the VCG. This provides the 242 endpoints in both the LCAS and non-LCAS case with information on 243 which to accept or reject the request, and in the non-LCAS case 244 will let the receiving endpoint know when all members of the VCG 245 have been established. 247 . Identification of the VCG and its associated members. This 248 provides information that allows the endpoints to differentiate 249 multiple VCGs and to tell what members - label switched paths 250 (LSPs)- to associate with a particular VCG. 252 2.4. VCGs and VCG Members 254 The signaling solution SHOULD provide a mechanism to support these 255 scenarios: 257 . VCG members (server layer connections) may be set up prior to 258 their use in a VCG. 260 . VCG members (server layer connections) may exist after their 261 corresponding VCG has been removed. 263 However, it is not required that any arbitrarily created server 264 layer connection be supported in the above scenarios, i.e., 265 connections established without following the procedures of this 266 document. 268 3. VCAT Data and Control Plane Concepts 270 When utilizing GMPLS with VCAT/LCAS, we use a number of control and 271 data plane concepts described below. 273 VCG -- This is the group of data plane server layer signals used to 274 provide the bandwidth for the virtual concatenation link 275 connection through a network ([G7042]). 277 VCG member -- This is an individual data plane server layer signal 278 that belongs to a VCG ([G7042]). 280 Member set -- One or more VCG members (or potential members) set up 281 via the same control plane signaling exchange. Note that all 282 members in a member set follow the same route. 284 Data plane LSP -- This is an individual VCG member. 286 Control plane LSP -- A control plane entity that can control multiple 287 data plane LSPs. For our purposes here, this is equivalent to the 288 member set. 290 Call - A control plane mechanism for providing association between 291 endpoints and possibly key transit points. 293 4. VCGs Composed of a Single Member Set (One LSP) 295 In this section and the next section, we will describe the 296 procedures for supporting the applications described in Section 2. 298 This section describes the support of a single VCG composed of a 299 single member set (in support of the fixed, co-routed application 300 and the dynamic, co-routed application) using existing GMPLS 301 procedures [RFC4606]. Note that this section is included for 302 informational purposes only and does not modify [RFC4606]. It is 303 provided to show how the existing GMPLS procedures may be used. 304 [RFC4606] provides the normative definition for GMPLS processing of 305 VCGs composed of a single member set, and in the event of any 306 conflict between this section and that document, [RFC4606] takes 307 precedence. 309 The existing GMPLS signaling protocols support a VCG composed of a 310 single member set. Setup using the number of virtual components 311 (NVC) field is explained in section 2.1 of [RFC4606]. In this case, 312 one (single) control plane LSP is used in support of the VCG. 314 There are two options for setting up the VCG, depending on policy 315 preferences: one-shot setup and incremental setup. 317 The following sections explain the procedure based on an example of 318 setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v 319 SONET VCAT group) which is composed of 7 virtually concatenated VC- 320 4s (or STS-3c). 322 4.1. One-shot VCG Setup 324 This section describes establishment of an LSP that supports all VCG 325 members as part of the initial LSP establishment. To establish such 326 an LSP, an RSVP-TE Path message is sent containing the SONET/SDH 327 Traffic Parameters defined in [RFC4606]. In the case of this 328 example: 330 . Elementary signal is set to 6 (for VC-4/STS-3c_SPE). 332 . NVC is set to 7 (number of members). 334 . Per [RFC4606] a Multiplier Transform greater than 1 (say N>1) 335 may be used if the operator wants to set up N identical VCAT 336 groups (for the same LSP). 338 . SDH or SONET labels have to be assigned for each member of the 339 VCG and concatenated to form a single Generalized Label 340 constructed as an ordered list of 32-bit timeslot identifiers 341 of the same format as TDM labels. [RFC4606] requires that the 342 order of the labels reflect the order of the payloads to 343 concatenate, and not the physical order of time-slots. 345 . Refer to [RFC4606] for other traffic parameter settings. 347 4.2. Incremental VCG Setup 349 In some cases, it may be necessary or desirable to set up the VCG 350 members individually, or to add group members to an existing group. 352 One example of this need is when the local policy requires that VCAT 353 can only add VCAT members one at a time or cannot automatically 354 match the members at the ingress and egress for the purposes of 355 inverse multiplexing. Serial or incremental setup solves this 356 problem. 358 In order to accomplish incremental setup, an iterative process is 359 used to add group members. For each iteration, NVC is incremented 360 up to the final value required. A successful iteration consists of 361 the successful completion of Path and Resv signaling. At first, NVC 362 = 1 and the label includes just one timeslot identifier 364 At each of the next iterations, NVC is set to (NVC +1), one more 365 timeslot identifier is added to the ordered list in the Generalized 366 Label (in the Path or Resv message). A node that receives a Path 367 message that contains changed fields will process the full Path 368 message and, based on the new value of NVC, it will add a component 369 signal to the VCAT group, and switch the new timeslot based on the 370 new label information. 372 Following the addition of the new label (identifying the new member) 373 to the LSP, in the data plane, LCAS may be used to add the new 374 member at the end points into the existing VCAT group. LCAS (data 375 plane) signaling is described in [ITU-T-G.7042]. 377 4.3. Procedure for VCG Reduction by Removing a Member 379 The procedure to remove a component signal is similar to that used 380 to add components as described in Section 4. 2. In the data plane, 381 LCAS signaling is used first to take the component out of service 382 from the group. LCAS signaling is described in [ITU-T-G.7042]. 384 In this case, the NVC value is decremented by 1 and the timeslot 385 identifier for the dropped component is removed from the ordered 386 list in the Generalized Label. 388 Note that for interfaces that are not LCAS-capable, removing one 389 component of the VCG will result in failure detection of the member 390 at the end point and failure of the whole group (per ITU-T 391 definition). So, this is a feature that only LCAS-capable VCAT 392 interfaces can support without management intervention at the end 393 points. 395 Note if using LCAS, a VCG member can be temporarily removed from the 396 VCG due to a failure of the component signal. The LCAS data plane 397 signaling will take appropriate actions to adjust the VCG as 398 described in [ITU-T-G.7042]. 400 4.4. Removing Multiple VCG Members in One Shot 402 The procedure is similar to 4.3. In this case, the NVC value is 403 changed to the new value and all relevant timeslot identifiers for 404 the components to be torn down are removed from the ordered list in 405 the Generalized Label. This procedure is also not supported for 406 VCAT-only interfaces without management intervention as removing one 407 or more components of the VCG will tear down the whole group. 409 4.5. Teardown of Whole VCG 411 The entire LSP is deleted in a single step (i.e., all components are 412 removed in one go) using deletion procedures of [RFC3473]. 414 5. VCGs Composed of Multiple Member Sets (Multiple LSPs) 416 The motivation for VCGs composed of multiple member sets comes from 417 the requirement to support VCGs with diversely routed members. The 418 initial GMPLS specification did not support diversely routed signals 419 using the NVC construct. [RFC4606] says: 421 [...] The standard definition for virtual concatenation allows 422 each virtual concatenation components to travel over diverse 423 paths. Within GMPLS, virtual concatenation components must 424 travel over the same (component) link if they are part of the 425 same LSP. This is due to the way that labels are bound to a 426 (component) link. Note however, that the routing of 427 components on different paths is indeed equivalent to 428 establishing different LSPs, each one having its own route. 429 Several LSPs can be initiated and terminated between the same 430 nodes and their corresponding components can then be 431 associated together (i.e., virtually concatenated). 433 The setup of diversely routed VCG members requires multiple VCG 434 member sets, i.e., multiple control plane LSPs. 436 The support of a VCG with multiple VCG members sets requires being 437 able to identify separate sets of control plane LSPs with a single 438 VCG and exchange information pertaining to the VCG as a whole 439 between the endpoints. This document updates the procedures of 440 [RFC4606] to provide this capability by using the call procedures 441 and extensions described in [RFC4974]. The VCG makes use of one or 442 more calls (VCAT calls) to associate control plane LSPs in support 443 of VCG server layer connections (VCG members) in the data plane. 444 Note, the trigger for the VCG (by management plane or client layer) 445 is outside the scope of this document. These procedures provide for 446 autonomy of the client layer and server layer with respect to their 447 management. 449 In addition, by supporting the identification of a VCG (VCG ID) and 450 VCAT call identification (VCAT Call ID), support can be provided for 451 the member sharing scenarios, i.e. by explicitly separating the VCG 452 ID from the VCAT call ID. Note that per [RFC4974], LSPs 453 (connections) cannot be moved from one call to another, hence to 454 support member sharing, the procedures in this document provide 455 support by moving call(s) and their associated LSPs from one VCG to 456 another. Figure 1 below illustrates these relationships, however, 457 note, VCAT calls can exist independently of a VCG (for connection 458 pre-establishment) as will be described later in this document. 460 +-------+ +-------------+ +-------+ +------------+ 461 | |1 n| |1 n| |1 n| Data Plane | 462 | VCG |<>----| VCAT Call |<>----| LSP |<>----| Connection | 463 | | | | | | |(co-routed) | 464 +-------+ +-------------+ +-------+ +------------+ 465 . Conceptual containment relationship between VCG, VCAT 466 calls, control plane LSPs, and data plane connections. 468 5.1. Signaled VCG Service Layer Information 470 In this section, we provide a list of information that will be 471 communicated at the VCG level, i.e., between the VCG signaling 472 endpoints using the call procedures of [RFC4974]. To accommodate 473 the VCG information, a new TLV is defined in this document for the 474 CALL ATTRIBUTES Object [RFC6001] for use in the Notify message 475 [RFC4974]. The Notify message is a targeted message and does not 476 need to follow the path of LSPs through the network i.e. there is no 477 dependency on the member signaling for establishing the VCAT call 478 and does not preclude the use of external call managers as described 479 in [RFC4974]. 481 The following information is needed: 483 1. Signal Type 485 2. Number of VCG Members 487 3. LCAS requirements: 489 a. LCAS required 491 b. LCAS desired 493 c. LCAS not supported 495 4. VCG Identifier - Used to identify a particular VCG separately 496 from the call ID so that call members can be reused with 497 different VCGs per the requirements for member sharing and the 498 requirements of section 2.4. 500 5.2. CALL ATTRIBUTES Object VCAT TLV 502 This document defines a CALL_ATTRIBUTES object VCAT TLV for use in 503 the CALL_ATTRIBUTES object [RFC6001] as follows: 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Type = TBA | Length = 12 | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Signal Type | Number of Members | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 |LCR| Reserved | Action | VCG ID | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 Type, as defined in [RFC6001]. This field MUST be set to TBA (by 516 IANA). 518 Length, as defined in [RFC6001]. This field MUST be set to 12. 520 Signal Type: 16 bits 522 The signal types can never be mixed in a VCG (per ITU-T 523 definition) and hence a VCAT call contains only one signal type. 524 This field can take the following values and MUST never change 525 over the lifetime of a VCG [ANSI-T1-105, ITU-T-G.707, ITU-T-G.709, 526 ITU-T-G.7043]: 528 Value Type (Elementary Signal) 529 ----- ------------------------ 530 1 VT1.5 SPE / VC-11 531 2 VT2 SPE / VC-12 532 3 STS-1 SPE / VC-3 533 4 STS-3c SPE / VC-4 534 11 ODU1 (i.e., 2.5 Gbit/s 535 12 ODU2 (i.e., 10 Gbit/s) 536 13 ODU3 (i.e., 40 Gbit/s) 537 21 T1 (i.e., 1.544 Mbps) 538 22 E1 (i.e., 2.048 Mbps) 539 23 E3 (i.e., 34.368 Mbps) 540 24 T3 (i.e., 44.736 Mbps) 542 Number of Members: 16 bits 544 This field is an unsigned integer that MUST indicate the total 545 number of members in the VCG (not just the call). This field MUST 546 be changed (over the life of the VCG) to indicate the current 547 number of members. 549 LCR (LCAS Required): 2 bits 551 This field can take the following values and MUST NOT change over 552 the life of a VCG: 554 Value Meaning 555 ----- --------------------------------- 556 0 LCAS required 557 1 LCAS desired 558 2 LCAS not supported 560 Action: 8 bits 562 This field is used to indicate the relationship between the call 563 and the VCG and has the following values. 565 Value Meaning 566 ----- --------------------------------- 567 0 No VCG ID (set up call prior to VCG creation) 568 1 New VCG for Call 569 2 Modification of number of members (No Change in VCG ID) 570 3 Remove VCG from Call 572 VCG Identifier (ID): 16 bit 574 This field carries an unsigned integer that is used to identify a 575 particular VCG within a session. The value of the field MUST NOT 576 change over the lifetime of a VCG but MAY change over the lifetime 577 of a call. 579 5.3. Procedures for Multiple Member Sets 581 The creation of a VCG based on multiple member sets requires the 582 establishment of at least one VCAT layer call. VCAT layer calls and 583 related LSPs (connections) MUST follow the procedures as defined in 584 [RFC4974] with the addition of the inclusion of a CALL_ATTRIBUTES 585 object containing the VCAT TLV. Multiple VCAT layer calls per VCG 586 are not required to support member sets, but are needed to support 587 certain member sharing scenario. 589 The remainder of this section provides specific procedures related 590 to VCG signaling. The procedures of [RFC4974] are only modified as 591 discussed in this section. 593 When LCAS is supported, the data plane will add or decrease the 594 members per [G7042]. When LCAS is not supported across LSPs, the 595 data plane coordination across member sets, is outside the scope of 596 this document. 598 5.3.1. Setting up a new VCAT call and VCG Simultaneously 600 To simultaneously set up a VCAT call and identify it with an 601 associated VCG, a CALL_ATTRIBUTES object containing the VCAT TLV 602 MUSTbe included in the Notify message at the time of call setup. 603 The VCAT TLV Action field MUST be set to 1, which indicates that 604 this is a new VCG for this call. LSPs MUST then be added to the 605 call until the number of members reaches the number specified in the 606 VCAT TLV. 608 5.3.2. Setting up a VCAT call + LSPs without a VCG 610 To provide for pre-establishment of the server layer connections for 611 a VCG a VCAT call MAY be established without an associated VCG 612 identifier. In fact, to provide for the member sharing scenario, a 613 pool of VCAT calls with associated connections (LSPs) can be 614 established, and then one or more of these calls (with accompanying 615 connections) can be associated with a particular VCG (via the VCG 616 ID). Note that multiple calls can be associated with a single VCG 617 but that a call MUST NOT contain members used in more than one VCG. 619 To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES 620 object containing the VCAT TLV MUST be included at the time of call 621 setup in the Notify message. The VCAT TLV Action field MUST be set 622 to 0, which indicates that this is a VCAT call without an associated 623 VCG. LSPs can then be added to the call. The number of members 624 parameter in the VCAT TLV has no meaning at this point since it 625 reflects the intended number of members in a VCG and not in a call. 627 5.3.3. Associating an existing VCAT call with a new VCG 629 A VCAT call that is not otherwise associated with a VCG may be 630 associated with a VCG. To establish such an association a Notify 631 message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT 632 TLV. The TLV's Action field MUST be set to 1, the VCG Identifier 633 field MUST be set to correspond to the VCG. The number of members 634 field MUST equal the sum of all LSPs associated with the VCG. Note 635 that the total number of VCGs supported by a node may be limited and 636 hence on reception of any message with a change of VCG ID this limit 637 should be checked. Likewise the sender of a message with a change in 638 VCG ID MUST be prepared to receive an error response. Again, any 639 error in a VCG may result in the failure of the complete VCG. 641 5.3.4. Removing the association between a call and VCG 643 To reuse the server layer connections in a call in another VCG, the 644 current association between the call and a VCG MUST first be 645 removed. To do this, a Notify message MUST be sent with a 646 CALL_ATTRIBUTES object containing a VCAT TLV. The Action field of 647 the TLV MUST be set to 3 (Remove VCG from Call). The VCG ID field is 648 ignored and MAY be set to any value. The number of members field is 649 also ignored and MAY be set to any value. When the association 650 between a VCG and all existing calls has been removed then the VCG 651 is considered torn down. 653 5.3.5. VCG Bandwidth modification 655 The following cases may occur when increasing or decreasing the 656 bandwidth of a VCG: 658 1. LSPs are added to or, in the case of a decrease, removed from a 659 VCAT Call already associated with a VCG. 661 2. An existing VCAT call, and corresponding LSPs, is associated 662 with a VCG or, in the case of a decrease, has its association 663 removed. Note that in the increase case, the call MUST NOT have 664 any existing association with a VCG. 666 The following sequence SHOULD be used when modifying the bandwidth 667 of a VCG: 669 1. In both cases, prior to any other change, a Notify message MUST 670 be sent with a CALL_ATTRIBUTES object containing a VCAT TLV for each 671 of the existing VCAT calls associated with the VCG. The Action field 672 of the TLV MUST be set to 2. The VCG ID field MUST be set to match 673 the VCG. The number of members field MUST equal the sum of all LSPs 674 that are anticipated to be associated with the VCG after the 675 bandwidth change. The Notify message is otherwise formatted and 676 processed as defined under Call Establishment in [RFC4974]. If an 677 error is encountered while processing any of the Notify messages, the 678 number of members is reverted to the pre-change value and the 679 increase is aborted. The reverted number of members MUST be signaled 680 in a Notify message as described above. Failures encountered in 681 processing these Notify messages are handled per [RFC4974]. 683 2. Once the existing calls have successfully been notified of the 684 new number of members in the VCG, the bandwidth change can be made. 685 The next step is dependent on the two cases defined above. In the 686 first case defined above, the bandwidth change is made by adding (in 687 the case of increase) or removing (in the case of a decrease) LSPs 688 to the VCAT call per the procedures defined in [RFC4974]. In the 689 second case, the same procedure defined in Section 5.3.3. is 690 followed for an increase, and the procedure defined in Section 691 5.3.4. is followed for a decrease. 693 6. Error Conditions and Codes 695 VCAT Call and member LSP setup can be denied for various reasons. In 696 addition to the call procedures and related error codes described in 697 [RFC4974], below is a list of error conditions that can be 698 encountered during the procedures as defined in this document. These 699 fall under RSVP error code TBA. 701 These can occur when setting up a VCAT call or associating a VCG 702 with a VCAT call. 704 Error Value 705 ------------------------------------ -------- 706 VCG signal type not Supported 1 707 LCAS option not supported 2 708 Max number of VCGs exceeded 3 709 Max number of VCG members exceeded 4 710 LSP Type incompatible with VCAT call 5 711 Unknown LCR (LCAS required) value 6 712 Unknown or unsupported ACTION 7 714 Any failure in call or LSP establishment MUST be treated as a 715 failure of the VCG as a whole and MAY trigger the calls and LSPs 716 associated with the VCG being deleted. 718 7. IANA Considerations 720 7.1. RSVP CALL_ATTRIBUTE TLV 722 IANA has made the following assignments in the "Class Names, Class 723 Numbers, and Class Types" section of the "RSVP PARAMETERS" registry 724 located at http://www.iana.org/assignments/rsvp-parameters. 726 We request that IANA make assignments from the CALL_ATTRIBUTES TLV 727 [RFC6001] portions of this registry. 729 This document introduces a new CALL_ATTRIBUTES TLV 731 TLV Value Name Reference 732 --------- ---------------------- --------- 733 TBD VCAT_TLV This I-D 735 7.2. RSVP Error Codes and Error Values 737 A new RSVP Error Code and new Error Values are introduced. We 738 request IANA make assignments from the "RSVP Parameters" registry 739 using the sub-registry "Error Codes and Globally-Defined Error Value 740 Sub-Codes". 742 o Error Codes: 744 - VCAT Call Management (value TBD) 746 o Error Values: 748 Meaning Value 749 ------------------------------------ -------- 750 VCG signal type not Supported 1 751 LCAS option not supported 2 752 Max number of VCGs exceeded 3 753 Max number of VCG members exceeded 4 754 LSP Type incompatible with VCAT call 5 755 Unknown LCR (LCAS required) value 6 756 Unknown or unsupported ACTION 7 758 7.3. VCAT Elementary Signal Registry 760 IANA is requested to create a registry to track elementary signal 761 types as defined in Section 5.2. New allocations are by "IETF 762 Review" [RFC5226]. 764 IANA is requested to track: 766 - Value 767 - Type (Elementary Signal) 768 - RFC 769 The available range is 0 - 65535 771 The registry should be initially populated with the values shown in 772 Section 5.2 of this document. Value 0 should be marked as Reserved. 773 Other values should be marked Unassigned. 775 7.4. VCAT VCG Operation Actions 777 IANA is requested to create a registry to track VCAT VCG operation 778 actions as defined in Section 5.2. New allocations are by "IETF 779 Review" [RFC5226]. 781 IANA is requested to track: 783 - Value 784 - Meaning 785 - RFC 787 The available range is 0 - 255 789 The registry should be initially populated with the values shown in 790 Section 5.2 of this document. Other values should be marked 791 Unassigned. 793 8. Security Considerations 795 This document introduces a specific use of the Notify message and 796 admin status object for GMPLS signaling as originally specified in 797 [RFC4974]. It does not introduce any new signaling messages, nor 798 change the relationship between LSRs that are adjacent in the 799 control plane. The call information associated with diversely 800 routed control plane LSPs, in the event of an interception, may 801 indicate that these are members of the same VCAT group that take a 802 different route, and may indicate to an interceptor that the VCG 803 call desires increased reliability. 805 See [RFC5920] for additional information on GMPLS security. 807 9. Contributors 809 Wataru Imajuku (NTT) 810 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 811 Japan 813 Phone +81-46-859-4315 814 Email: imajuku.wataru@lab.ntt.co.jp 816 Julien Meuric 817 France Telecom 818 2, avenue Pierre Marzin 819 22307 Lannion Cedex 820 France 822 Phone: + 33 2 96 05 28 28 823 Email: julien.meuric@orange-ft.com 825 Lyndon Ong 826 Ciena 827 PO Box 308 828 Cupertino, CA 95015 829 United States of America 831 Phone: +1 408 705 2978 832 Email: lyong@ciena.com 834 10. Acknowledgments 836 The authors would like to thank Adrian Farrel, Maarten Vissers, 837 Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li, 838 Stephen Shew, Jonathan Saddler and Dieter Beller for extensive 839 reviews and contributions to this draft. 841 11. References 843 11.1. Normative References 845 [RFC6001] Papadimitriou, D., Vigoureux M., Shiomoto, K. 846 Brungard, D., Le Roux, JL., "Generalized Multi- 847 Protocol Label Switching (GMPLS) Protocol Extensions 848 for Multi-Layer and Multi-Region Networks (MLN/MRN)", 849 October, 2010. 851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 852 Requirement Levels", BCP 14, RFC 2119, March 1997. 854 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 855 Switching (GMPLS) Signaling Resource ReserVation 856 Protocol-Traffic Engineering (RSVP-TE) Extensions", 857 RFC 3473, January 2003. 859 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 860 Protocol Label Switching (GMPLS) Extensions for 861 Synchronous Optical Network (SONET) and Synchronous 862 Digital Hierarchy (SDH) Control", RFC 4606, December 863 2005. 865 [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS 866 (GMPLS) RSVP-TE Signaling Extensions in Support of 867 Calls", RFC 4974, August 2007. 869 11.2. Informative References 871 [ANSI-T1.105] American National Standards Institute, "Synchronous 872 Optical Network (SONET) - Basic Description including 873 Multiplex Structure, Rates, and Formats", ANSI 874 T1.105-2001, May 2001. 876 [G7042] International Telecommunications Union, "Link 877 Capacity Adjustment Scheme (LCAS) for Virtual 878 Concatenated Signals", ITU-T Recommendation G.7042, 879 March 2006. 881 [ITU-T-G.7043] International Telecommunications Union, "Virtual 882 Concatenation of Plesiochronous Digital Hierarchy 883 (PDH) Signals", ITU-T Recommendation G.7043, July 884 2004. 886 [ITU-T-G.704] International Telecommunications Union, " Synchronous 887 frame structures used at 1544, 6312, 2048, 8448 and 888 44 736 kbit/s hierarchical levels", ITU-T 889 Recommendation G.704, October 1998. 891 [ITU-T-G.707] International Telecommunications Union, "Network Node 892 Interface for the Synchronous Digital Hierarchy 893 (SDH)", ITU-T Recommendation G.707, December 2003. 895 [ITU-T-G.709] International Telecommunications Union, "Interfaces 896 for the Optical Transport Network (OTN)", ITU-T 897 Recommendation G.709, March 2003. 899 [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS 900 Networks", July 2010. 902 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an 903 IANA Considerations Section in RFCs", May 2008. 905 Authors' Addresses 907 Greg M. Bernstein (ed.) 908 Grotto Networking 909 Fremont California, USA 911 Phone: (510) 573-2237 912 Email: gregb@grotto-networking.com 914 Diego Caviglia 915 Ericsson 916 Via A. Negrone 1/A 16153 917 Genoa Italy 919 Phone: +39 010 600 3736 920 Email: diego.caviglia@(marconi.com, ericsson.com) 922 Richard Rabbat 923 Google, Inc. 924 1600 Amphitheatre Parkway 925 Mountain View, CA 94043, USA 927 Email: rabbat@alum.mit.edu 928 Huub van Helvoort 929 Huawei Technologies, Ltd. 930 Kolkgriend 38, 1356 BC Almere 931 The Netherlands 933 Phone: +31 36 5315076 934 Email: hhelvoort@huawei.com 936 Intellectual Property Statement 938 The IETF Trust takes no position regarding the validity or scope of 939 any Intellectual Property Rights or other rights that might be 940 claimed to pertain to the implementation or use of the technology 941 described in any IETF Document or the extent to which any license 942 under such rights might or might not be available; nor does it 943 represent that it has made any independent effort to identify any 944 such rights. 946 Copies of Intellectual Property disclosures made to the IETF 947 Secretariat and any assurances of licenses to be made available, or 948 the result of an attempt made to obtain a general license or 949 permission for the use of such proprietary rights by implementers or 950 users of this specification can be obtained from the IETF on-line 951 IPR repository at http://www.ietf.org/ipr 953 The IETF invites any interested party to bring to its attention any 954 copyrights, patents or patent applications, or other proprietary 955 rights that may cover technology that may be required to implement 956 any standard or specification contained in an IETF Document. Please 957 address the information to the IETF at ietf-ipr@ietf.org. 959 Disclaimer of Validity 961 All IETF Documents and the information contained therein are 962 provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION 963 HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 964 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 965 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 966 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 967 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 968 FOR A PARTICULAR PURPOSE.