idnits 2.17.1 draft-ietf-ccamp-gmpls-vcat-lcas-11.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 abstract seems to contain references ([RFC4606]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document updates RFC4606, but the abstract doesn't seem to directly say this. It does mention RFC4606 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 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 (March 9, 2011) is 4790 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 378, but not defined == Missing Reference: 'ANSI-T1-105' is mentioned on line 503, but not defined Summary: 1 error (**), 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 D. Caviglia 4 Category: Standards Track Ericsson 5 Expires: September 2011 R. Rabbat 6 Google 7 H. van Helvoort 8 Huawei 9 March 9, 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-11.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 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 months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 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 September 9, 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 respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Abstract 57 This document describes requirements for, and use of, the Generalized 58 Multi-Protocol Label Switching (GMPLS) control plane in support of 59 the Virtual Concatenation (VCAT) layer 1 inverse multiplexing data 60 plane mechanism and its companion Link Capacity Adjustment Scheme 61 (LCAS) which can be used for hitless dynamic resizing of the inverse 62 multiplex group. These techniques apply to Optical Transport Network 63 (OTN), Synchronous Optical Network (SONET), Synchronous Digital 64 Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. 65 This document updates the procedures for supporting virtual 66 concatenation in [RFC4606]. 68 Conventions used in this document 70 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 71 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 72 document are to be interpreted as described in RFC-2119 [RFC2119]. 74 Table of Contents 76 1. Introduction...................................................3 77 2. VCAT/LCAS Scenarios and Specific Requirements..................4 78 2.1. VCAT/LCAS Interface Capabilities..........................4 79 2.2. Member Signal Configuration Scenarios.....................4 80 2.3. VCAT Operation With or Without LCAS.......................5 81 2.4. VCGs and VCG Members......................................6 82 3. VCAT Data and Control Plane Concepts...........................6 83 4. VCGs Composed of a Single Member Set (One LSP).................7 84 4.1. One-shot VCG Setup........................................7 85 4.2. Incremental VCG Setup.....................................8 86 4.3. Procedure for VCG Reduction by Removing a Member..........8 87 4.4. Removing Multiple VCG Members in One Shot.................9 88 4.5. Teardown of Whole VCG.....................................9 89 5. VCGs Composed of Multiple Member Sets (Multiple LSPs)..........9 90 5.1. Signaled VCG Service Layer Information...................10 91 5.2. CALL ATTRIBUTES Object VCAT TLV..........................11 92 5.3. Procedures for Multiple Member Sets......................13 93 5.3.1. Setting up a new VCAT call and VCG Simultaneously...13 94 5.3.2. Setting up a VCAT call + LSPs without a VCG.........13 95 5.3.3. Associating an existing VCAT call with a new VCG....14 96 5.3.4. Removing the association between a call and VCG.....14 97 5.3.5. VCG Bandwidth modification..........................14 98 6. Error Conditions and Codes....................................15 99 7. IANA Considerations...........................................16 100 7.1. RSVP CALL_ATTRIBUTE TLV..................................16 101 7.2. RSVP Error Codes and Error Values........................16 102 8. Security Considerations.......................................17 103 9. Contributors..................................................18 104 10. Acknowledgments..............................................18 105 11. References...................................................19 106 11.1. Normative References....................................19 107 11.2. Informative References..................................19 108 Author's Addresses...............................................20 109 Intellectual Property Statement..................................21 110 Disclaimer of Validity...........................................21 111 Acknowledgment...................................................21 113 1. Introduction 115 The Generalized Multi-Protocol Label Switching (GMPLS) suite of 116 protocols allows for the automated control of different switching 117 technologies including Synchronous Optical Network (SONET)[ANSI- 118 T1.105], Synchronous Digital Hierarchy (SDH)[ITU-T-G.707], Optical 119 Transport Network (OTN)[ITU-T-G.709] and Plesiochronous Digital 120 Hierarchy (PDH)[ITU-T-G.704]. This document updates the procedures of 121 [RFC4606] to allow supporting additional applications of the Virtual 122 Concatenation (VCAT) layer 1 inverse multiplexing mechanism that has 123 been standardized for SONET, SDH, OTN and PDH [ITU-T-G.707, ITU-T- 124 G.709, and ITU-T-G.7043] technologies along with its companion Link 125 Capacity Adjustment Scheme (LCAS) [ITU-T-G.7042]. 127 VCAT is a TDM oriented byte striping inverse multiplexing method that 128 works with a wide range of existing and emerging TDM framed signals, 129 including very high bit rate OTN and SDH/SONET signals. VCAT enables 130 the selection of an optimal signal server bandwidth (size) utilizing 131 a group of server signals and provides for efficient use of bandwidth 132 in a mesh network. When combined with LCAS, hitless dynamic resizing 133 of bandwidth and fast graceful degradation in the presence of network 134 faults can be supported. To take full advantage of VCAT/LCAS 135 functionality, additional extensions to GMPLS signaling are needed 136 that enable the setup of diversely routed signals that are members of 137 the same VCAT group. Note that the scope of this document is limited 138 to scenarios where all member signals of a VCAT group are controlled 139 using mechanisms defined in this document and related RFCs. Scenarios 140 where a subset of member signals are controlled by a management plane 141 or a proprietary control plane are outside the scope of this 142 document. 144 2. VCAT/LCAS Scenarios and Specific Requirements 146 There are a number of specific requirements for the support of 147 VCAT/LCAS in GMPLS that can be derived from the carriers' 148 applications for the use of VCAT/LCAS. These are set out in the 149 following section. 151 2.1. VCAT/LCAS Interface Capabilities 153 In general, an LSR can be ingress/egress of one or more VCAT groups. 154 VCAT and LCAS are data plane interface capabilities. An LSR may 155 have, for example, VCAT-capable interfaces that are not LCAS-capable. 156 It may at the same time have interfaces that are neither VCAT nor 157 LCAS-capable. 159 2.2. Member Signal Configuration Scenarios 161 We list in this section the different scenarios. Here we use the 162 [ITU-T-G.707] term "VCG" to refer to the VCAT group and the 163 terminology "set" and "subset" to refer to the subdivision of the 164 group and the individual VCAT group member signals. As noted above, 165 the scope of these scenarios is limited to scenarios where all member 166 signals are controlled using mechanisms defined in this document. 168 Fixed, co-routed: A fixed bandwidth VCG, transported over a co-routed 169 set of member signals. This is the case where the intended 170 bandwidth of the VCG does not change and all member signals follow 171 the same route to minimize differential delay. The application 172 here is the capability to allocate an amount of bandwidth close to 173 that required at the client layer. 175 Fixed, diversely routed: A fixed bandwidth VCG, transported over at 176 least two diversely routed subsets of member signals. In this 177 case, the subsets are link-disjoint over at least one link of the 178 route. The application here is more efficient use of network 179 resources, e.g., no unique route has the required bandwidth. 181 Fixed, member sharing: A fixed bandwidth VCG, transported over a set 182 of member signals that are allocated from a common pool of 183 available member signals without requiring member connection 184 teardown and setup. This document only covers the case where this 185 pool of "potential" member signals has been established via 186 mechanisms defined in this document. Note that by the nature of 187 VCAT, a member signal can only belong to one VCG at a time. To be 188 used in a different VCG, a signal must first be removed from any 189 VCG to which it may belong. 191 Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or 192 decreased via the addition or removal of member signals), 193 transported over a co-routed set of members. The application here 194 is dynamic resizing and resilience of bandwidth. 196 Dynamic, diversely routed: A dynamic VCG (bandwidth can be increased 197 or decreased via the addition or removal of member signals), 198 transported over at least two diversely routed subsets of member 199 signals. The application here is efficient use of network 200 resources, dynamic resizing and resilience of bandwidth. 202 Dynamic, member sharing: A dynamic bandwidth VCG, transported over a 203 set of member signals that are allocated from a common pool of 204 available member signals without requiring member connection 205 teardown and setup. 207 2.3. VCAT Operation With or Without LCAS 209 VCAT capabilities may be present with or without the presence of 210 LCAS. The use of LCAS is beneficial in the provisioning of flexible 211 bandwidth services, but in the absence of LCAS, VCAT is still a valid 212 technique. Therefore GMPLS mechanisms for the operation of VCAT are 213 REQUIRED for both the case where LCAS is available and the case where 214 it is not available. The GMPLS procedures for the two cases SHOULD 215 be identical. 217 . GMPLS signaling for LCAS-capable interfaces MUST support all 218 scenarios of section 2.2. with no loss of traffic. 220 . GMPLS signaling for non-LCAS-capable interfaces MUST support 221 only the "fixed" scenarios of section 2.2. 223 To provide for these requirements, GMPLS signaling MUST carry the 224 following information on behalf of the VCAT endpoints: 226 . The type of the member signal that the VCG will contain, e.g., 227 VC-3, VC-4, etc. 229 . The total number of members to be in the VCG. This provides the 230 endpoints in both the LCAS and non-LCAS case with information on 231 which to accept or reject the request, and in the non-LCAS case 232 will let the receiving endpoint know when all members of the VCG 233 have been established. 235 . Identification of the VCG and its associated members. This 236 provides information that allows the endpoints to differentiate 237 multiple VCGs and to tell what members (LSPs) to associate with 238 a particular VCG. 240 2.4. VCGs and VCG Members 242 The signaling solution SHOULD provide a mechanism to support these 243 scenarios: 245 . VCG members (server layer connections) may be set up prior to 246 their use in a VCG. 248 . VCG members (server layer connections) may exist after their 249 corresponding VCG has been removed. 251 However, it is not required that any arbitrarily created server layer 252 connection be supported in the above scenarios, i.e., connections 253 established without following the procedures of this document. 255 3. VCAT Data and Control Plane Concepts 257 When utilizing GMPLS with VCAT/LCAS, we use a number of control and 258 data plane concepts described below. 260 VCG -- This is the group of data plane server layer signals used to 261 provide the bandwidth for the virtual concatenation link connection 262 through a network ([G7042]). 264 VCG member -- This is an individual data plane server layer signal 265 that belongs to a VCG ([G7042]). 267 Member set -- One or more VCG members (or potential members) set up 268 via the same control plane signaling exchange. Note that all 269 members in a member set follow the same route. 271 Data plane LSP -- This is an individual VCG member. 273 Control plane LSP -- A control plane entity that can control multiple 274 data plane LSPs. For our purposes here, this is equivalent to the 275 member set. 277 Call - A control plane mechanism for providing association between 278 endpoints and possibly key transit points. 280 4. VCGs Composed of a Single Member Set (One LSP) 282 In this section and the next section, we will describe the procedures 283 for supporting the applications described in Section 2. 285 This section describes the support of a single VCG composed of a 286 single member set (in support of the fixed, co-routed application and 287 the dynamic, co-routed application) using existing GMPLS procedures 288 [RFC4606]. Note that this section is included for informational 289 purposes only. 291 The existing GMPLS signaling protocols support a VCG composed of a 292 single member set. Setup using the NVC field is explained in section 293 2.1 of [RFC4606]. In this case, one (single) control plane LSP is 294 used in support of the VCG. 296 There are two options for setting up the VCG, depending on policy 297 preferences: one-shot setup and incremental setup. 299 The following sections explain the procedure based on an example of 300 setting up a VC-4-7v SDH VCAT group (corresponding to an STS-3c-7v 301 SONET VCAT group) which is composed of 7 virtually concatenated VC-4s 302 (or STS-3c). 304 4.1. One-shot VCG Setup 306 This section describes establishment of an LSP that supports all VCG 307 members as part of the initial LSP establishment. To establish such 308 an LSP, an RSVP-TE Path message is sent containing the SONET/SDH 309 Traffic Parameters defined in [RFC4606]. In the case of this example: 311 . Elementary signal is set to 6 (for VC-4/STS-3c_SPE). 313 . NVC is set to 7 (number of members). 315 . Per [RFC4606] a Multiplier Transform greater than 1 (say N>1) 316 may be used if the operator wants to set up N identical VCAT 317 groups (for the same LSP). 319 . SDH or SONET labels have to be assigned for each member of the 320 VCG and concatenated to form a single Generalized Label 321 constructed as an ordered list of 32-bit timeslot identifiers of 322 the same format as TDM labels. [RFC4606] requires that the 323 order of the labels reflect the order of the payloads to 324 concatenate, and not the physical order of time-slots. 326 . Refer to [RFC4606] for other traffic parameter settings. 328 4.2. Incremental VCG Setup 330 In some cases, it may be necessary or desirable to set up the VCG 331 members individually, or to add group members to an existing group. 333 One example of this need is when the local policy requires that VCAT 334 can only add VCAT members one at a time or cannot automatically match 335 the members at the ingress and egress for the purposes of inverse 336 multiplexing. Serial or incremental setup solves this problem. 338 In order to accomplish incremental setup, an iterative process is 339 used to add group members. For each iteration, NVC is incremented up 340 to the final value required. A successful iteration consists of the 341 successful completion of Path and Resv signaling. At first, NVC = 1 342 and the label includes just one timeslot identifier 344 At each of the next iterations, NVC is set to (NVC +1), one more 345 timeslot identifier is added to the ordered list in the Generalized 346 Label (in the Path or Resv message). A node that receives a Path 347 message that contains changed fields will process the full Path 348 message and, based on the new value of NVC, it will add a component 349 signal to the VCAT group, and switch the new timeslot based on the 350 new label information. 352 Following the addition of the new label (identifying the new member) 353 to the LSP, in the data plane, LCAS may be used to add the new member 354 at the end points into the existing VCAT group. LCAS (data plane) 355 signaling is described in [ITU-T-G.7042]. 357 4.3. Procedure for VCG Reduction by Removing a Member 359 The procedure to remove a component signal is similar to that used to 360 add components as described in Section 4. 2. In the data plane, LCAS 361 signaling is used first to take the component out of service from the 362 group. LCAS signaling is described in [ITU-T-G.7042]. 364 In this case, the NVC value is decremented by 1 and the timeslot 365 identifier for the dropped component is removed from the ordered 366 list in the Generalized Label. 368 Note that for interfaces that are not LCAS-capable, removing one 369 component of the VCG will result in failure detection of the member 370 at the end point and failure of the whole group (per ITU-T 371 definition). So, this is a feature that only LCAS-capable VCAT 372 interfaces can support without management intervention at the end 373 points. 375 Note if using LCAS, a VCG member can be temporary removed from the 376 VCG due to a failure of the component signal. The LCAS data plane 377 signaling will take appropriate actions to adjust the VCG as 378 described in [ITU-T-G.7042]. 380 4.4. Removing Multiple VCG Members in One Shot 382 The procedure is similar to 4.3. In this case, the NVC value is 383 changed to the new value and all relevant timeslot identifiers for 384 the components to be torn down are removed from the ordered list in 385 the Generalized Label. This procedure is also not supported for 386 VCAT-only interfaces without management intervention as removing one 387 or more components of the VCG will tear down the whole group. 389 4.5. Teardown of Whole VCG 391 The entire LSP is deleted in a single step (i.e., all components are 392 removed in one go) using deletion procedures of [RFC3473]. 394 5. VCGs Composed of Multiple Member Sets (Multiple LSPs) 396 The motivation for VCGs composed of multiple member sets comes from 397 the requirement to support VCGs with diversely routed members. The 398 initial GMPLS specification did not support diversely routed signals 399 using the NVC construct. [RFC4606] says: 401 [...] The standard definition for virtual concatenation allows 402 each virtual concatenation components to travel over diverse 403 paths. Within GMPLS, virtual concatenation components must 404 travel over the same (component) link if they are part of the 405 same LSP. This is due to the way that labels are bound to a 406 (component) link. Note however, that the routing of components 407 on different paths is indeed equivalent to establishing 408 different LSPs, each one having its own route. Several LSPs 409 can be initiated and terminated between the same nodes and 410 their corresponding components can then be associated together 411 (i.e., virtually concatenated). 413 The setup of diversely routed VCG members requires multiple VCG 414 member sets, i.e., multiple control plane LSPs. 416 The support of a VCG with multiple VCG members sets requires being 417 able to identify separate sets of control plane LSPs with a single 418 VCG and exchange information pertaining to the VCG as a whole between 419 the endpoints. This document updates the procedures of [RFC4606] to 420 provide this capability by using the call procedures and extensions 421 described in [RFC4974]. The VCG makes use of one or more calls (VCAT 422 calls) to associate control plane LSPs in support of VCG server layer 423 connections (VCG members) in the data plane. Note, the trigger for 424 the VCG (by management plane or client layer) is outside the scope of 425 this document. These procedures provide for autonomy of the client 426 layer and server layer with respect to their management. 428 In addition, by supporting the identification of a VCG (VCG ID) and 429 VCAT call identification (VCAT Call ID), support can be provided for 430 the member sharing scenarios, i.e. by explicitly separating the VCG 431 ID from the VCAT call ID. Note that per [RFC4974], LSPs (connections) 432 cannot be moved from one call to another, hence to support member 433 sharing, the procedures in this document provide support by moving 434 call(s) and their associated LSPs from one VCG to another. Figure 1 435 below illustrates these relationships, however, note, VCAT calls can 436 exist independently of a VCG (for connection pre-establishment) as 437 will be described later in this document. 439 +-------+ +-------------+ +-------+ +------------+ 440 | |1 n| |1 n| |1 n| Data Plane | 441 | VCG |<>----| VCAT Call |<>----| LSP |<>----| Connection | 442 | | | | | | |(co-routed) | 443 +-------+ +-------------+ +-------+ +------------+ 444 Figure 1 Figure 1. Conceptual containment relationship between VCG, 445 VCAT calls, control plane LSPs, and data plane connections. 447 5.1. Signaled VCG Service Layer Information 449 In this section, we provide a list of information that will be 450 communicated at the VCG level, i.e., between the VCG signaling 451 endpoints using the call procedures of [RFC4974]. To accommodate the 452 VCG information, a new TLV is defined in this document for the CALL 453 ATTRIBUTES Object [RFC6001] for use in the Notify message [RFC4974]. 454 The Notify message is a targeted message and does not need to follow 455 the path of LSPs through the network i.e. there is no dependency on 456 the member signaling for establishing the VCAT call and does not 457 preclude the use of external call managers as described in [RFC4974]. 459 The following information is needed: 461 1. Signal Type 463 2. Number of VCG Members 465 3. LCAS requirements: 467 a. LCAS required 469 b. LCAS desired 471 c. LCAS not supported 473 4. VCG Identifier - Used to identify a particular VCG separately 474 from the call ID so that call members can be reused with 475 different VCGs per the requirements for member sharing and the 476 requirements of section 2.4. 478 5.2. CALL ATTRIBUTES Object VCAT TLV 480 This document defines a CALL_ATTRIBUTES object VCAT TLV for use in 481 the CALL_ATTRIBUTES object [RFC6001] as follows: 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type = TBA | Length = 12 | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Signal Type | Number of Members | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | LCAS Req | Action | VCG ID | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 Type, as defined in [RFC6001]. This field MUST be set to TBA (by 494 IANA). 496 Length, as defined in [RFC6001]. This field MUST be set to 12. 498 Signal Type: 16 bits 500 The signal types can never be mixed in a VCG (per ITU-T definition) 501 and hence a VCAT call contains only one signal type. This field can 502 take the following values and MUST never change over the lifetime 503 of a VCG [ANSI-T1-105, ITU-T-G.707, ITU-T-G.709, ITU-T-G.7043]: 505 Value Type (Elementary Signal) 506 ----- ------------------------ 507 1 VT1.5 SPE / VC-11 508 2 VT2 SPE / VC-12 509 3 STS-1 SPE / VC-3 510 4 STS-3c SPE / VC-4 511 11 ODU1 (i.e., 2.5 Gbit/s 512 12 ODU2 (i.e., 10 Gbit/s) 513 13 ODU3 (i.e., 40 Gbit/s) 514 21 T1 (i.e., 1.544 Mbps) 515 22 E1 (i.e., 2.048 Mbps) 516 23 E3 (i.e., 34.368 Mbps) 517 24 T3 (i.e., 44.736 Mbps) 519 Number of Members: 16 bits 521 This field is an unsigned integer that MUST indicate the total 522 number of members in the VCG (not just the call). This field MUST 523 be changed (over the life of the VCG) to indicate the current 524 number of members. 526 LCAS Required: 8 bits 528 This field can take the following values and MUST NOT change over 529 the life of a VCG: 531 Value Meaning 532 ----- --------------------------------- 533 0 LCAS required 534 1 LCAS desired 535 2 LCAS not supported 537 Action: 8 bits 539 This field is used to indicate the relationship between the call 540 and the VCG and has the following values. 542 Value Meaning 543 ----- --------------------------------- 544 0 No VCG ID (set up call prior to VCG creation) 545 1 New VCG for Call 546 2 Modification of number of members (No Change in VCG ID) 547 3 Remove VCG from Call 549 VCG Identifier (ID): 16 bit 551 This field carries an unsigned integer that is used to identify a 552 particular VCG within a session. The value of the field MUST NOT 553 change over the lifetime of a VCG but MAY change over the lifetime 554 of a call. 556 5.3. Procedures for Multiple Member Sets 558 The creation of a VCG based on multiple member sets requires the 559 establishment of at least one VCAT layer call. VCAT layer calls and 560 related LSPs (connections) MUST follow the procedures as defined in 561 [RFC4974] with the addition of the inclusion of a CALL_ATTRIBUTES 562 object containing the VCAT TLV. Multiple VCAT layer calls per VCG are 563 not required to support member sets, but are needed to support 564 certain member sharing scenario. 566 The remainder of this section provides specific procedures related to 567 VCG signaling. The procedures of [RFC4974] are only modified as 568 discussed in this section. 570 When LCAS is supported, the data plane will add or decrease the 571 members per [G7042]. When LCAS is not supported across LSPs, the data 572 plane coordination across member sets, is outside the scope of this 573 document. 575 5.3.1. Setting up a new VCAT call and VCG Simultaneously 577 To simultaneously set up a VCAT call and identify it with an 578 associated VCG, a CALL_ATTRIBUTES object containing the VCAT TLV 579 MUSTbe included in the Notify message at the time of call setup. The 580 VCAT TLV Action field MUST be set to 1, which indicates that this is 581 a new VCG for this call. LSPs MUST then be added to the call until 582 the number of members reaches the number specified in the VCAT TLV. 584 5.3.2. Setting up a VCAT call + LSPs without a VCG 586 To provide for pre-establishment of the server layer connections for 587 a VCG a VCAT call MAY be established without an associated VCG 588 identifier. In fact, to provide for the member sharing scenario, a 589 pool of VCAT calls with associated connections (LSPs) can be 590 established, and then one or more of these calls (with accompanying 591 connections) can be associated with a particular VCG (via the VCG 592 ID). Note that multiple calls can be associated with a single VCG but 593 that a call MUST NOT contain members used in more than one VCG. 595 To establish a VCAT call with no VCG association, a CALL_ATTRIBUTES 596 object containing the VCAT TLV MUST be included at the time of call 597 setup in the Notify message. The VCAT TLV Action field MUST be set 598 to 0, which indicates that this is a VCAT call without an associated 599 VCG. LSPs can then be added to the call. The number of members 600 parameter in the VCAT TLV has no meaning at this point since it 601 reflects the intended number of members in a VCG and not in a call. 603 5.3.3. Associating an existing VCAT call with a new VCG 605 A VCAT call that is not otherwise associated with a VCG may be 606 associated with a VCG. To establish such an association a Notify 607 message MUST be sent with a CALL_ATTRIBUTES object containing a VCAT 608 TLV. The TLV's Action field MUST be set to 1, the VCG Identifier 609 field MUST be set to correspond to the VCG. The number of members 610 field MUST equal the sum of all LSPs associated with the VCG. Note 611 that the total number of VCGs supported by a node may be limited and 612 hence on reception of any message with a change of VCG ID this limit 613 should be checked. Likewise the sender of a message with a change in 614 VCG ID MUST be prepared to receive an error response. Again, any 615 error in a VCG may result in the failure of the complete VCG. 617 5.3.4. Removing the association between a call and VCG 619 To reuse the server layer connections in a call in another VCG, the 620 current association between the call and a VCG MUST first be removed. 621 To do this, a Notify message MUST be sent with a CALL_ATTRIBUTES 622 object containing a VCAT TLV. The Action field of the TLV MUST be 623 set to 3 (Remove VCG from Call). The VCG ID field is ignored and MAY 624 be set to any value. The number of members field is also ignored and 625 MAY be set to any value. When the association between a VCG and all 626 existing calls has been removed then the VCG is considered torn down. 628 5.3.5. VCG Bandwidth modification 630 The following cases may occur when increasing or decreasing the 631 bandwidth of a VCG: 633 1. LSPs are added to or, in the case of a decrease, removed from a 634 VCAT Call already associated with a VCG. 636 2. An existing VCAT call, and corresponding LSPs, is associated 637 with a VCG or, in the case of a decrease, has its association 638 removed. Note that in the increase case, the call MUST NOT have 639 any existing association with a VCG. 641 The following sequence SHOULD be used when modifying the bandwidth of 642 a VCG: 644 1. In both cases, prior to any other change, a Notify message MUST 645 be sent with a CALL_ATTRIBUTES object containing a VCAT TLV for each 646 of the existing VCAT calls associated with the VCG. The Action field 647 of the TLV MUST be set to 2. The VCG ID field MUST be set to match 648 the VCG. The number of members field MUST equal the sum of all LSPs 649 that are anticipated to be associated with the VCG after the 650 bandwidth change. The Notify message is otherwise formatted and 651 processed as defined under Call Establishment in [RFC4974]. If an 652 error is encountered while processing any of the Notify messages, the 653 number of members is reverted to the pre-change value and the 654 increase is aborted. The reverted number of members MUST be signaled 655 in a Notify message as described above. Failures encountered in 656 processing these Notify messages are handled per [RFC4974]. 658 2. Once the existing calls have successfully been notified of the 659 new number of members in the VCG, the bandwidth change can be made. 660 The next step is dependent on the two cases defined above. In the 661 first case defined above, the bandwidth change is made by adding (in 662 the case of increase) or removing (in the case of a decrease) LSPs to 663 the VCAT call per the procedures defined in [RFC4974]. In the second 664 case, the same procedure defined in Section 5.3.3. is followed for an 665 increase, and the procedure defined in Section 5.3.4. is followed for 666 a decrease. 668 6. Error Conditions and Codes 670 VCAT Call and member LSP setup can be denied for various reasons. In 671 addition to the call procedures and related error codes described in 672 [RFC4974], below is a list of error conditions that can be 673 encountered during the procedures as defined in this document. These 674 fall under RSVP error code TBA. 676 These can occur when setting up a VCAT call or associating a VCG with 677 a VCAT call. 679 Error Value 680 ------------------------------------ -------- 681 VCG signal type not Supported 1 682 LCAS option not supported 2 683 Max number of VCGs exceeded 3 684 Max number of VCG members exceeded 4 685 LSP Type incompatible with VCAT call 5 687 Any failure in call or LSP establishment MUST be treated as a failure 688 of the VCG as a whole and MAY trigger the calls and LSPs associated 689 with the VCG being deleted. 691 7. IANA Considerations 693 7.1. RSVP CALL_ATTRIBUTE TLV 695 IANA has made the following assignments in the "Class Names, Class 696 Numbers, and Class Types" section of the "RSVP PARAMETERS" registry 697 located at http://www.iana.org/assignments/rsvp-parameters. 698 We request that IANA make assignments from the CALL_ATTRIBUTES TLV 699 [RFC6001] portions of this registry. 701 This document introduces a new CALL_ATTRIBUTES TLV 703 TLV Value Name Reference 704 --------- ---------------------- --------- 705 TBD (2) VCAT_TLV This I-D 707 7.2. RSVP Error Codes and Error Values 709 A new RSVP Error Code and new Error Values are introduced. We 710 request IANA make assignments from the "RSVP Parameters" registry 711 using the sub-registry "Error Codes and Globally-Defined Error Value 712 Sub-Codes". 714 o Error Codes: 716 - VCAT Call Management (value TBD) 718 o Error Values: 720 Meaning Value 721 ------------------------------------ -------- 722 VCG signal type not Supported 1 723 LCAS option not supported 2 724 Max number of VCGs exceeded 3 725 Max number of VCG members exceeded 4 726 LSP Type incompatible with VCAT call 5 728 8. Security Considerations 730 This document introduces a specific use of the Notify message and 731 admin status object for GMPLS signaling as originally specified in 732 [RFC4974]. It does not introduce any new signaling messages, nor 733 change the relationship between LSRs that are adjacent in the control 734 plane. The call information associated with diversely routed control 735 plane LSPs, in the event of an interception, may indicate that these 736 are members of the same VCAT group that take a different route, and 737 may indicate to an interceptor that the VCG call desires increased 738 reliability. 740 9. Contributors 742 Wataru Imajuku (NTT) 743 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 744 Japan 746 Phone +81-46-859-4315 747 Email: imajuku.wataru@lab.ntt.co.jp 749 Julien Meuric 750 France Telecom 751 2, avenue Pierre Marzin 752 22307 Lannion Cedex 753 France 755 Phone: + 33 2 96 05 28 28 756 Email: julien.meuric@orange-ft.com 758 Lyndon Ong 759 Ciena 760 PO Box 308 761 Cupertino, CA 95015 762 United States of America 764 Phone: +1 408 705 2978 765 Email: lyong@ciena.com 767 10. Acknowledgments 769 The authors would like to thank Adrian Farrel, Maarten Vissers, 770 Trevor Wilson, Evelyne Roch, Vijay Pandian, Fred Gruman, Dan Li, 771 Stephen Shew, Jonathan Saddler and Dieter Beller for extensive 772 reviews and contributions to this draft. 774 11. References 776 11.1. Normative References 778 [RFC6001] Papadimitriou, D., Vigoureux M., Shiomoto, K. 779 Brungard, D., Le Roux, JL., "Generalized Multi- 780 Protocol Label Switching (GMPLS) Protocol Extensions 781 for Multi-Layer and Multi-Region Networks (MLN/MRN)", 782 October, 2010. 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, March 1997. 787 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 788 Switching (GMPLS) Signaling Resource ReserVation 789 Protocol-Traffic Engineering (RSVP-TE) Extensions", 790 RFC 3473, January 2003. 792 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 793 Protocol Label Switching (GMPLS) Extensions for 794 Synchronous Optical Network (SONET) and Synchronous 795 Digital Hierarchy (SDH) Control", RFC 4606, December 796 2005. 798 [RFC4974] Papadimitriou, D. and A. Farrel, "Generalized MPLS 799 (GMPLS) RSVP-TE Signaling Extensions in Support of 800 Calls", RFC 4974, August 2007. 802 11.2. Informative References 804 [ANSI-T1.105] American National Standards Institute, "Synchronous 805 Optical Network (SONET) - Basic Description including 806 Multiplex Structure, Rates, and Formats", ANSI T1.105- 807 2001, May 2001. 809 [G7042] International Telecommunications Union, "Link Capacity 810 Adjustment Scheme (LCAS) for Virtual Concatenated 811 Signals", ITU-T Recommendation G.7042, March 2006. 813 [ITU-T-G.7043] International Telecommunications Union, "Virtual 814 Concatenation of Plesiochronous Digital Hierarchy 815 (PDH) Signals", ITU-T Recommendation G.7043, July 816 2004. 818 [ITU-T-G.704] International Telecommunications Union, " Synchronous 819 frame structures used at 1544, 6312, 2048, 8448 and 44 820 736 kbit/s hierarchical levels", ITU-T Recommendation 821 G.704, October 1998. 823 [ITU-T-G.707] International Telecommunications Union, "Network Node 824 Interface for the Synchronous Digital Hierarchy 825 (SDH)", ITU-T Recommendation G.707, December 2003. 827 [ITU-T-G.709] International Telecommunications Union, "Interfaces 828 for the Optical Transport Network (OTN)", ITU-T 829 Recommendation G.709, March 2003. 831 Author's Addresses 833 Greg M. Bernstein (ed.) 834 Grotto Networking 835 Fremont California, USA 837 Phone: (510) 573-2237 838 Email: gregb@grotto-networking.com 840 Diego Caviglia 841 Ericsson 842 Via A. Negrone 1/A 16153 843 Genoa Italy 845 Phone: +39 010 600 3736 846 Email: diego.caviglia@(marconi.com, ericsson.com) 848 Richard Rabbat 849 Google, Inc. 850 1600 Amphitheatre Parkway 851 Mountain View, CA 94043, USA 853 Email: rabbat@alum.mit.edu 855 Huub van Helvoort 856 Huawei Technologies, Ltd. 857 Kolkgriend 38, 1356 BC Almere 858 The Netherlands 860 Phone: +31 36 5315076 861 Email: hhelvoort@huawei.com 863 Intellectual Property Statement 865 The IETF Trust takes no position regarding the validity or scope of 866 any Intellectual Property Rights or other rights that might be 867 claimed to pertain to the implementation or use of the technology 868 described in any IETF Document or the extent to which any license 869 under such rights might or might not be available; nor does it 870 represent that it has made any independent effort to identify any 871 such rights. 873 Copies of Intellectual Property disclosures made to the IETF 874 Secretariat and any assurances of licenses to be made available, or 875 the result of an attempt made to obtain a general license or 876 permission for the use of such proprietary rights by implementers or 877 users of this specification can be obtained from the IETF on-line IPR 878 repository at http://www.ietf.org/ipr 880 The IETF invites any interested party to bring to its attention any 881 copyrights, patents or patent applications, or other proprietary 882 rights that may cover technology that may be required to implement 883 any standard or specification contained in an IETF Document. Please 884 address the information to the IETF at ietf-ipr@ietf.org. 886 Disclaimer of Validity 888 All IETF Documents and the information contained therein are provided 889 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 890 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 891 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 892 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 893 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 894 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 895 FOR A PARTICULAR PURPOSE. 897 Acknowledgment