idnits 2.17.1 draft-bernstein-ccamp-gmpls-vcat-lcas-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 781. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 787. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 231 has weird spacing: '...ast row in Ta...' == Line 430 has weird spacing: '...ensions in Se...' == Line 488 has weird spacing: '...e first confi...' == Line 642 has weird spacing: '...ponents shoul...' -- 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 (July 8, 2005) is 6866 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) == Unused Reference: '3' is defined on line 719, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP working Group G. Bernstein 3 Internet-Draft Grotto Networking 4 Expires: January 9, 2006 D. Caviglia 5 Marconi 6 R. Rabbat 7 Fujitsu 8 July 8, 2005 10 Operating Virtual concatenation (VCAT) and the Link Capacity Adjustment 11 Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS) 12 draft-bernstein-ccamp-gmpls-vcat-lcas-00 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on January 9, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). 43 Abstract 45 This document describes the use of the Generalized Multi-Protocol 46 Label Switching (GMPLS) control plane in conjunction with the Virtual 47 Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its 48 companion Link Capacity Adjustment Scheme (LCAS) which can be used 49 for hitless dynamic resizing of the inverse multiplex group. These 50 techniques apply to the Optical Transport Network (OTN), Synchronous 51 Optical Network (SONET), Synchronous Digital Hierarchy (SDH) and 52 Plesiochronous Digital Hierarchy (PDH) signals. 54 Table of Contents 56 1. Overview of VCAT and LCAS . . . . . . . . . . . . . . . . . . 3 57 1.1 SDH/SONET VCAT signals and components . . . . . . . . . . 3 58 1.2 PDH VCAT signals and components . . . . . . . . . . . . . 4 59 1.3 OTN VCAT signals and components . . . . . . . . . . . . . 5 60 1.4 VCAT Capabilities and Limitations . . . . . . . . . . . . 6 61 1.5 The LCAS Protocol . . . . . . . . . . . . . . . . . . . . 8 62 2. VCAT/LCAS Scenarios . . . . . . . . . . . . . . . . . . . . . 11 63 2.1 Discovery of Enabled End Systems . . . . . . . . . . . . . 11 64 2.2 Client to End Point Mappings . . . . . . . . . . . . . . . 11 65 2.3 VCAT configuration without LCAS . . . . . . . . . . . . . 12 66 2.4 VCAT configuration with LCAS . . . . . . . . . . . . . . . 12 67 2.5 Component Signal Configuration Scenarios . . . . . . . . . 13 68 3. Current Support for VCAT group provisioning with GMPLS . . . . 15 69 3.1 Discovery of VCAT/LCAS . . . . . . . . . . . . . . . . . . 15 70 3.2 Support for Multiple Client to End Point Mappings . . . . 15 71 3.3 Support for VCAT configuration without LCAS . . . . . . . 15 72 3.4 Support for VCAT configuration with LCAS . . . . . . . . . 15 73 3.5 Component Signal Configuration Support . . . . . . . . . . 16 74 4. Possible Extensions to GMPLS to support additional 75 VCAT/LCAS scenarios . . . . . . . . . . . . . . . . . . . . . 17 76 4.1 Mechanisms for Discovery of VCAT/LCAS . . . . . . . . . . 17 77 4.2 Mechanism to Support Multiple Client to End Point 78 Mappings . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 4.3 Support for Component Signal Configuration Scenarios . . . 17 80 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 82 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 83 Intellectual Property and Copyright Statements . . . . . . . . 20 85 1. Overview of VCAT and LCAS 87 Virtual Concatenation (VCAT) is a standardized layer 1 inverse 88 multiplexing technique that can be applied to OTN [5], SONET [2], SDH 89 [1], and PDH [4] component signals. By inverse multiplexing we mean 90 a method that combines multiple links at a particular layer into an 91 aggregate link to achieve a commensurate increase in available 92 bandwidth on that aggregate link. More formally, VCAT essentially 93 combines the payload bandwidth of multiple path layer network signals 94 (or trails) to support a single client (e.g. Ethernet) layer link. 95 Other well known standardized inverse multiplexing techniques include 96 Multi Link PPP [6] and Ethernet's Link Aggregation mechanism as 97 documented in chapter 43 of [7]. 99 One of the main differences between VCAT and the other mentioned 100 inverse multiplexing standards is that VCAT works at layer 1 rather 101 than at the data link layer, i.e., VCAT works with "circuits" and the 102 others with layer 2 packets. This can be important when considering 103 its capabilities or limitations. 105 1.1 SDH/SONET VCAT signals and components 107 In the following we will use SDH terminology rather than both SONET 108 and SDH terminology. In SDH Virtual Concatenation (VCAT) can be 109 applied to the following component time division multiplex (TDM) 110 signals referred to as Virtual Containers (VCs) (and not to be 111 confused with virtual circuits): 113 +---------+----------------+----------------+ 114 | VC type | VC bandwidth | VC payload | 115 +---------+----------------+----------------+ 116 | VC-11 | 1 664 kbit/s | 1 600 kbit/s | 117 | | | | 118 | VC-12 | 2 240 kbit/s | 2 176 kbit/s | 119 | | | | 120 | VC-2 | 6 848 kbit/s | 6 784 kbit/s | 121 | | | | 122 | VC-3 | 48 960 kbit/s | 48 384 kbit/s | 123 | | | | 124 | VC-4 | 150 336 kbit/s | 149 760 kbit/s | 125 +---------+----------------+----------------+ 127 Extracted from table 6-1 of [1]. 129 Table 1: Permissible SDH VCAT components 131 Note that when reading the VCAT and LCAS references the term "frame" 132 is generally used to describe the repetitive structure of TDM signals 133 and not to describe a layer 2 packet. To simplify high speed 134 aggregation of these signals, only like component signals can be 135 aggregated into a VCAT group. The aggregate signals are named and 136 characterized in Table 2 extended from table 11-4 of [1]. 138 +----------------+----------------+----------------+----------------+ 139 | VCAT group | X | Capacity | In steps of | 140 +----------------+----------------+----------------+----------------+ 141 | VC-11-Xv | 1 to 64 | 1600 Kbit/s to | 1 600 Kbit/s | 142 | | | 102 400 Kbit/s | | 143 | | | | | 144 | VC-12-Xv | 1 to 64 | 2176 Kbit/s to | 2 176 Kbit/s | 145 | | | 139 264 Kbit/s | | 146 | | | | | 147 | VC-2-Xv | 1 to 64 | 6784 Kbit/s to | 6 784 Kbit/s | 148 | | | 434 176 Kbit/s | | 149 | | | | | 150 | VC-3-Xv | 1 to 256 | approx. 48 | 48 384 Kbit/s | 151 | | | Mbit/s to 12.5 | | 152 | | | Gbit/s | | 153 | | | | | 154 | VC-4-Xv | 1 to 256 | approx. 149 | 149 760 Kbit/s | 155 | | | Mbit/s to 38.3 | | 156 | | | Gbit/s | | 157 +----------------+----------------+----------------+----------------+ 159 Table 2: SDH VCAT Signals 161 Since VCAT is an inverse multiplexing technique, SONET/SDH transport 162 network nodes do not need to support these VCAT signals explicitly 163 since it is the job of the VCAT end systems to reassemble the 164 aggregate signal. The only requirement on the SONET/SDH network is 165 to be able to transport the individual component signals, i.e., the 166 VCs of Table 1. 168 1.2 PDH VCAT signals and components 170 VCAT can be applied to the following PDH signals as specified in 171 reference [4]: 173 +--------------------+---------------+ 174 | Common signal name | Signal Rate | 175 +--------------------+---------------+ 176 | DS1 | 1544 Kbit/s | 177 | | | 178 | E1 | 2048 Kbit/s | 179 | | | 180 | E3 | 34 368 Kbit/s | 181 | | | 182 | DS3 | 44 736 Kbit/s | 183 +--------------------+---------------+ 185 Similar to the SONET/SDH case these component signals can only be 186 combined with like signals to produce aggregates. For some reason 187 the virtual concatenation groups of the PDH signals were not given 188 unique designations in [4] so we shall adopt a similar notation to 189 the SDH VCAT signals for the permitted PDH VCAT signals that follow. 191 +-------------+---------+------------------+ 192 | pseudo name | X range | Approx. capacity | 193 +-------------+---------+------------------+ 194 | DS1-Xv | 1 to 16 | X*1533 Kbit/s | 195 | | | | 196 | E1-Xv | 1 to 16 | X*1980 Kbit/s | 197 | | | | 198 | E3-Xv | 1 to 8 | X*33856 Kbit/s | 199 | | | | 200 | DS3-Xv | 1 to 8 | X*44134 Kbit/s | 201 +-------------+---------+------------------+ 203 Table 4: Standardized PDH VCAT signals 205 1.3 OTN VCAT signals and components 207 Concatenation in the optical transport network (OTN) is realized by 208 means of virtual concatenation of Optical Channel Payload Unit (OPU) 209 signals. OPUk signals (k=1, 2, 3) can be concatenated into OPUk-Xv 210 aggregates with X= 1,..., 256. The aggregate signals are named and 211 characterized as follows (Table 5 is taken from Table 6-3 G.8012). 213 +----------+---------------------------+----------------------+ 214 | OPU Type | OPU payload (kbit/s) | In steps of (kbit/s) | 215 +----------+---------------------------+----------------------+ 216 | OPU1 | 2488320 | | 217 | | | | 218 | OPU2 | 238/237x9953280 ~ 9995277 | | 219 | | | | 220 | OPU3 | 238/236x39813720~40150519 | | 221 | | | | 222 | OPU1-Xv | 2488320 to 637009920 | 2488320 | 223 | | | | 224 | OPU2-Xv | ~9995277 to ~2558709902 | ~9995277 | 225 | | | | 226 | OPU3-Xv | ~40150519 to ~10278532946 | ~40150519 | 227 +----------+---------------------------+----------------------+ 229 Table 5: Standardized OTN component VCAT signals 231 Note that the last row in Table 5 is not a mis-print. Reference [5] 232 does indeed permit the virtual concatenation of up to 256, 40Gbps, 233 ODU3 signals to produce an aggregate link, a ODU3-256v, with a 234 capacity of over 10Tbps! At the time of this writing the authors do 235 not currently know of any actual implementations, but it should be 236 noted that the standard is quite "future proof". 238 1.4 VCAT Capabilities and Limitations 240 VCAT performs inverse multiplexing by octet/byte de-interleaving of 241 the encapsulated client bit stream. As such it operates below the 242 packet/frame level. Each frame/packet will therefore "travel" over 243 all members of the VCAT group, and a fault in any of those members 244 hits every Xth byte in each packet/frame. With LCAS the failed 245 member is temporarily taken out of the service providing set of the 246 VCAT group, until the fault is repaired. Due to this octet/byte de- 247 interleaving VCAT introduces an insignificant processing delay into 248 the transmission path. The propagation time for the aggregate signal 249 will correspond to that of the longest component signal. 251 Figure 1 illustrates how incoming client traffic, in this case an 252 Ethernet frame, is transported via VCAT in a transport network. The 253 incoming Ethernet frame -for the sake of simplicity only six bytes of 254 the frame are depicted- is inverse-multiplexed by VCAT into three 255 different VCAT members. In Figure 1 the incoming Ethernet frame is 256 spread across the three VCAT members, that is, bytes 1 and 4 are 257 carried by VCAT member number 1, bytes 2 and 5 by member number 2 258 while bytes 3 and 6 by member number 3. In the case of a failure of 259 VCAT member 2 bytes 2 and 5 are lost and thus it is not possible to 260 rebuild the original incoming Ethernet frame. 262 Transport Network 263 <--------------------> 264 /| b1 b4 |\ 265 | |----------------------| | 266 | | VCAT member #1 | | 267 | | | | 268 | | | | 269 Eth Link | | b2 b5 | | Eth Link 270 =====================| |----------------------| 271 |===================== 272 +--+--+--+--+--+--+ | | VCAT member #2 | | +--+--+--+--+--+--+ 273 |b1|b2|b3|b4|b5|b6| | | | | |b1|b2|b3|b4|b5|b6| 274 +--+--+--+--+--+--+ | | | | +--+--+--+--+--+--+ 275 Ethernet Pkt | | b3 b6 | | Ethernet Pkt 276 | |----------------------| | 277 \| VCAT member #3 |/ 279 VCAT VCAT 280 Ingress Egress 282 Figure 1: VCAT Inverse Multiplexing 284 With any inverse multiplexing technique two important issues come up: 285 (a) how packet reordering is prevented, and (b) delay compensation 286 limits. For example Ethernet's link aggregation scheme prevents 287 reordering by restricting "conversations" to a single link. This 288 means that the total aggregate bandwidth is not available to a single 289 flow. MLPPP and VCAT prevent reordering in a way that imposes no 290 limits on the bandwidth delivered to a single flow. Since VCAT works 291 with circuits it doesn't have to deal with queueing induced 292 differential delays between components. In fact, since most circuit 293 switched technologies have very low switching latency most 294 differential delays experienced by VCAT component signals are due to 295 propagation. The maximum differential delays that can be 296 accommodated by the standards is given in Table 6. Actual 297 implementation can choose to provide much less differential delay 298 compensation and frequently do so to save on memory requirements. 300 +-------------+-----------------+ 301 | VCAT Signal | max diff. delay | 302 +-------------+-----------------+ 303 | VC-m-Xv | 256 msec | 304 | | | 305 | DS1-Xv | 384 msec | 306 | | | 307 | E1-Xv | 256 msec | 308 | | | 309 | E3-Xv | 255 msec | 310 | | | 311 | DS3-Xv | 217 msec | 312 | | | 313 | ODU1-Xv | 411 sec | 314 | | | 315 | ODU2-Xv | 102 sec | 316 | | | 317 | ODU3-Xv | 25.4 sec | 318 +-------------+-----------------+ 320 Table 6: Differential Delay Limits 322 As mentioned in [8] the ability to compensate for 256msec of 323 differential delay compares favorably with the circumference of the 324 earth and some rather paranoid disjoint paths. The theoretical 325 differential delay compensation limits for the OPUk, last three rows 326 of Table 6, are in far excess of that needed for any terrestrial 327 applications. However it is the natural outcome of future proofing 328 the VCAT mechanism for OPUk signals via the allocation of the 329 equivalent of a 24 bit frame counter which can also be used by future 330 higher speed signals without modification to meet the need for 256 ms 331 of delay compensation. 333 1.5 The LCAS Protocol 335 The Link Capacity Adjustment Scheme for VCAT signals is a protocol 336 for dynamically and hitlessly changing (i.e., increasing and 337 decreasing) the capacity of a VCAT group. LCAS also provides 338 survivability capabilities, automatically decreasing the capacity if 339 a member of the VCAT group experiences a failure in the network, and 340 increasing the capacity when the network fault is repaired. LCAS, 341 itself, provides a mechanism for interworking between LCAS and non- 342 LCAS VCAT end points. VCAT does not require LCAS for its operation. 344 We find analogous mechanisms in other inverse multiplexing technology 345 such as the Link Control Protocol (LCP) used in MLPPP [6] and the 346 Link Aggregation Control Protocol (LACP) used in Ethernet Link 347 Aggregation [7]. It needs to be emphasized that none of these 348 mechanisms are responsible for establishing the component links. 349 Indeed, these protocols run over the component links themselves. 350 Hence LCAS functionality does not overlap or conflict with GMPLS' 351 routing or signaling functionality for the establishment of component 352 links or entire VCAT groups. LCAS instead is used to control whether 353 a particular component signal is actually put into service carrying 354 traffic for the VCAT group. 356 Although we are used to PDH and SONET/SDH signals being bi- 357 directional, LCAS actually works on unidirectional components in a 358 VCAT group with the proviso that there is at least one return 359 component for conveyance of LCAS messages. As viewed from LCAS' 360 point of view the source end of each component can have the following 361 states: 363 +---------------------------------+---------------------------------+ 364 | State | Explanation | 365 +---------------------------------+---------------------------------+ 366 | IDLE | This member is not provisioned | 367 | | to participate in the | 368 | | concatenated group. | 369 | | | 370 | NORM | This member is provisioned to | 371 | | participate in the concatenated | 372 | | group and has a good path to | 373 | | the sink end. | 374 | | | 375 | DNU (Do Not Use) | This member is provisioned to | 376 | | participate in the concatenated | 377 | | group and has a failed path to | 378 | | the sink end. | 379 | | | 380 | ADD | This member is in the process | 381 | | of being added to the | 382 | | concatenated group. | 383 | | | 384 | REMOVE | This member is in the process | 385 | | of being deleted from the | 386 | | concatenated group. | 387 +---------------------------------+---------------------------------+ 389 Table 7: LCAS/VCAT component states 391 LCAS provides for graceful degradation of failed links by having the 392 sink end report back the receive status of all member components. In 393 the case of a reported member failure, the source end will stop using 394 the component and the source end will send an LCAS message to the 395 sink end that it is not transmitting data on that component. The 396 worst case notification times, not including propagation delays, for 397 the different VCAT signals discussed here are given in Table 8. 398 These values were obtained from [1] and [5], and reverse engineered 399 from information in [4]. 401 +-----------------------------+-------------------+ 402 | VCAT signal type | Notification Time | 403 +-----------------------------+-------------------+ 404 | VC-11-Xv, VC-12-Xv, VC-2-XV | 128 msec | 405 | | | 406 | VC-3-Xv, VC-4-Xv | 64 msec | 407 | | | 408 | DS1-Xv | 96 msec | 409 | | | 410 | E1-Xv | 64 msec | 411 | | | 412 | E3-Xv | 2 msec | 413 | | | 414 | DS3-Xv | 1.7024 msec | 415 | | | 416 | OPU1-Xv | 1.567 msec | 417 | | | 418 | OPU2-Xv | 390 usec | 419 | | | 420 | OPU3-Xv | 97 usec | 421 +-----------------------------+-------------------+ 423 Table 8: LCAS Notification times for Member Status 425 2. VCAT/LCAS Scenarios 427 In this section we list a number of VCAT/LCAS usage scenarios. We 428 will evaluate the applicability of GMPLS to these scenarios in 429 Section 3 and for those scenarios that GMPLS does not currently 430 support we describe possible GMPLS extensions in Section 4. These 431 scenarios can easily form the basis for formal requirements, however 432 at this point in time we list the scenarios and can later evaluate 433 which of these must be supported. Note the term "component" signal 434 in the text is used as a simplified notion to the more formal 435 concepts of VC-n, ODUk, and PDH termination function as well as VC-n, 436 ODUk and PDH path/trail. 438 2.1 Discovery of Enabled End Systems 440 Discovering VCAT: VCAT sources can only communicate with VCAT capable 441 sinks. Hence the VCAT capabilities of a PDH, SDH, or OTN path 442 termination points need to be known. 444 Discovering LCAS: LCAS offers additional functionality between VCAT 445 capable sources and sinks. Hence the LCAS capabilities of VCAT 446 enabled path termination points can be useful to know in advance 447 of component signal setup. 449 2.2 Client to End Point Mappings 451 Fixed Client to End point Mapping: Per client signal there is a 452 VC-n-Xv circuit in which the X VC-n termination points are 453 dedicated to this client signal. At any point in time, Y out of X 454 VC-n termination points may be set up to carry client traffic. 455 For example when VCAT is deployed on a Router, the VCAT group 456 connects directly to one STM-N interface port (in absence of a HO 457 or LO switch fabric in the router). The transport network will 458 then split the VCAT group into two or more subgroups of 459 components, each being routed via diverse routes. 461 Variable Client to End point Mapping: For a set of M client signals 462 there are M VC-n-Xv VCAT endpoints sharing a set of N (N>M) VC-n 463 termination points. Typically MxX > N (example: M=10, X=7, N=64); 464 i.e. there is a kind of overbooking. Implication: must be able to 465 accommodate multiple different sized VCAT groups at an 466 "interface". For example an STM-64 interface can support many 467 different VC-4-Xv groups. 469 2.3 VCAT configuration without LCAS 471 1. Sink end needs to be informed of how many components are in the 472 VCAT group. It has no other way of knowing if it is currently 473 receiving all components intended to be in the group. 475 2. Additions or removals of components from the VCAT group are not 476 hitless, that is data loss will occur while the source and sink 477 become synchronized as to the number of members in the group. 478 With each addition or removal the sink end point needs to be told 479 the expected number of components in the group. 481 3. Failure of a component is detected external to VCAT system. 482 Entire group is rendered inoperable until source takes the failed 483 component out of service and sink end is notified to take 484 component out of service. 486 2.4 VCAT configuration with LCAS 488 1. Sink end (and source end) are first configured with the value of 489 "Y" (the number of components), and more specifically which of 490 the X (e.g. VC-n) access points (and thus (VC-n) termination 491 functions) are allocated to the VCAT group with Y (VC-n) 492 components. LCAS then detects automatically which of those Y 493 (VC-n) components is carrying actual traffic and puts them into 494 service for the group. 496 2. When a new component signal has to be added to a VCAT group the 497 following procedure applies. 499 1. Configure the adaptation source/sink functions and change the 500 number of components, Y, to Y+1 by identifying which of the 501 X-Y (e.g. VC-n) access points currently outside the group is 502 added to the group; 504 2. The new component is created, e.g., the cross-connections are 505 establish along the components path. 507 3. As soon as LCAS protocol information exchange is finished, 508 i.e., the state NORM is reached, client traffic is sent on 509 the added component. 511 This procedure does not affect the already established LCAS 512 members, that is, client traffic is not sent on the new component 513 until the LCAS procedure is complete; 515 3. When a component is removed the following procedure applies: 517 1. LCAS protocol is used to remove the component from the group, 518 that is, incoming traffic client data is transmitted on the 519 other VCAT component(s) to assure that the procedure is not 520 traffic affecting 522 2. Configure the adaptation source/sink functions and change the 523 number of components Y to Y-1; i.e. remove the VC-n access 524 point from the group. 526 3. The component connection can be, if needed, removed from the 527 transport network. 529 4. When a component fails, the LCAS sink detects the failure (how 530 this is done is outside the scope of this ID) and informs the 531 source of this failure via the member status (MST) information. 532 The source then: 534 1. Takes the failed component out of service and if necessary 535 rearranges the sequencing of the VCAT group. 537 2. Informs the sink about the component removed from service and 538 any re-arranging of the VCAT group. 540 When the failed component is repaired, LCAS can automatically add 541 the repaired component back to the group, or alternatively a new 542 component can be added to bring the group back to its original 543 size. Note that component failure is not hitless, but note the 544 fast notification times of Table 8 546 2.5 Component Signal Configuration Scenarios 548 Here we use the term "group" to refer to the entire VCAT group and 549 the terminology "set" and "subset" to refer to the collection of 550 potential VCAT group member signals. 552 1. A fixed bandwidth VCAT group, transported over a co-routed set of 553 member signals. This is the case where the intended bandwidth of 554 the VCAT group does not change and all member signals follow a 555 similar route. The intent here is the capability to allocate the 556 "right" amount of bandwidth. 558 2. A fixed bandwidth VCAT group, transported over at least two 559 disjointly routed subsets of member signals. The intent here is 560 additional resilience and graceful degradation in the case of 561 failure. Implications: either LCAS needs to be supported by both 562 source and sink or we need two-way communications of some type 563 between source and sink to coordinate which members are to be 564 used in the group in a failure scenario. Protection or 565 restoration may be applied in order to restore the original group 566 size in case of failure of either one of the subsets. 568 3. A dynamic VCAT group (bandwidth can be increased or decreased via 569 the addition or removal of member signals), transported over a 570 co-routed set of members. Intent here is dynamic sizing of 571 bandwidth. Implications: LCAS is needed for hitless resizing. 572 Note before LCAS can do its part of getting traffic over the 573 modified VCAT group, the two VCAT/LCAS endpoints need to be 574 configured (Y -> Y+1 or Y -> Y-1); this requires either 575 "communication" between the two endpoints (when one of the 576 endpoints is configured by call/connection controller, or simple 577 communication of the call/connection controller with both 578 endpoints. Without LCAS we still need two way communications 579 between source and sink to coordinate which members are used in 580 the group and changes will not be hitless. Of course, if all the 581 members of the group are co-routed a single failure may destroy 582 the entire group and cause interruption of traffic even if LCAS 583 is enabled. 585 4. A dynamic VCAT group, transported over at least two disjointly 586 routed subsets of member signals. Intent here is dynamic 587 resizing and resilience. Implications similar to cases 2 and 3 588 above. 590 5. Two or more VCAT groups between the same source and sink who 591 desire to share a pool of component signals between them. Each 592 VCAT group may have a dedicated set of members, and may also 593 obtain additional members from a "common pool" of components. 594 Note that at any given point in time a component signal can 595 belong to at most one VCAT group. The intent here is to allow 596 dynamic resizing of VCAT groups via the sharing of a pool of 597 established component signals without requiring complete circuit 598 provisioning, i.e., only the group membership of the component 599 signal would change. Implications: a communications mechanism 600 between source and sink to indicate during a "change" which group 601 a component should now belong. Similar dynamics and resilience 602 implications as cases 2 and 3 above. (This is Adrian's 603 scenario). 605 3. Current Support for VCAT group provisioning with GMPLS 607 Here we see how well we can satisfy the scenarios of Section 2. 609 3.1 Discovery of VCAT/LCAS 611 Currently no support for discovery of VCAT or LCAS apriori, i.e., via 612 routing information. Support for "discovery" of VCAT capability at 613 connection establishment time via signaling, i.e., we can request 614 VCAT connection and if the end system cannot support it,it would 615 refuse the connection. TBD -- is there a specific error code 616 concerning "VCAT not supported". 618 Currently there is no mechanism to ask for an LCAS enabled end point 619 nor is there a way to find out if the other end is LCAS enabled until 620 after the connection is established. This is a problem if we 621 specifically want hitless dynamic resizing or fast graceful 622 degradation for a VCAT group. 624 3.2 Support for Multiple Client to End Point Mappings 626 This is where we can have more than one VCAT group on an "interface" 627 (port, etc...) and we need to tell them apart. Currently there is no 628 "VCAT group identifier" in GMPLS. 630 3.3 Support for VCAT configuration without LCAS 632 Fixed sized co-routed groups are supported with current GMPLS 633 signaling. For disjointly routed components we would need a small 634 amount of signaling between the VCAT source and sink to make up for 635 the lack of LCAS. In particular, each side (source and sink) needs 636 to know and be in agreement on the components in the group. It is 637 TBD whether GMPLS's existing Admin-Status object can provide 638 sufficient information to achieve this purpose. Note that we cannot 639 achieve hitless resizing this way but we can be fairly prompt and 640 keep the management systems from having to do this. Main items that 641 we need to know are: (a) which component has failed (sink to source), 642 (b) the which components should be in the group (source to sink). 644 3.4 Support for VCAT configuration with LCAS 646 Currently both co-routed and disjointly routed connections can be 647 supported. Detailed analysis TBD. For hitless resizing some 648 reasonable default behaviors for controlling LCAS should be followed: 649 (a) After GMPLS has successfully established a potential new 650 component, LCAS should be told (local to source end) to add it to the 651 group, (b) Before GMPLS tears down a component, LCAS should be told 652 (local to source end) to remove it from the group. 654 3.5 Component Signal Configuration Support 656 Rough analysis of the list of Section 2.5. 658 1. Fixed bandwidth, Co-routed: Yes, already in the signaling RFC. 660 2. Fixed bandwidth, Diversely routed component subsets: TBD if 661 admin-status object will suffice in the non-LCAS case. 663 3. Dynamic Bandwidth, Co-routed: TBD if admin-status object will 664 suffice in the non-LCAS case. 666 4. Dynamic Bandwidth, Diversely routed: Similar requirements as 667 above. 669 5. Adrian's scenario: Currently not supported. Need to be able to 670 signal that we want a potential component to be used in a new 671 VCAT group. Note that the source end would first remove it from 672 its old group. However we need to tell the VCAT group to add it 673 to. The sink end really can't tell this itself. The LCAS group 674 id is just a 1 bit psuedo-random sequence that is used to avoid 675 adding the wrong component to a group. 677 4. Possible Extensions to GMPLS to support additional VCAT/LCAS 678 scenarios 680 Here we look at what might be reasonable to add to GMPLS to support 681 the interest scenarios of Section 2 that were not covered under 682 Section 3 . 684 4.1 Mechanisms for Discovery of VCAT/LCAS 686 Would like to get both VCAT and LCAS capability of end systems via 687 routing... 689 Would like to be able to specifically ask for LCAS capability via 690 signaling... 692 4.2 Mechanism to Support Multiple Client to End Point Mappings 694 This is a very important capability and it is very similar to one 695 that is being proposed in the end-to-end signaling for recovery I-D. 696 In particular the ASSOCIATION object. Note, however, since there is 697 a rather high probability that at some point we might use VCAT/LCAS 698 with GMPLS based protection we would really need an ASSOCIATION 699 object type specific to VCAT. Association objects are not unique and 700 therefore adding a new type to the Association object would make it a 701 good candidate to support this requirement. 703 4.3 Support for Component Signal Configuration Scenarios 705 TBD based on analysis of use of admin-status object. If the admin- 706 status object is sufficient we will detail its use in this 707 application since it is currently an optional object. 709 5. References 711 [1] International Telecommunications Union, "Network node interface 712 for the synchronous digital hierarchy (SDH)", ITU- 713 T Recommendation G.707, December 2003. 715 [2] American National Standards Institute, "Synchronous Optical 716 Network (SONET) - Basic Description including Multiplex 717 Structure, Rates, and Formats", ANSI T1.105-2001, 2001. 719 [3] "Link capacity adjustment scheme (LCAS) for virtual concatenated 720 signals", ITU-T Recommendation G.7042, February 2004. 722 [4] "Virtual concatenation of plesiochronous digital hierarchy (PDH) 723 signals", ITU-T Recommendation G.7043, July 2004. 725 [5] "Interfaces for the Optical Transport Network (OTN)", ITU- 726 T Recommendation G.709, March 2003. 728 [6] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. 729 Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, 730 August 1996. 732 [7] "Information technology - Telecommunications and information 733 exchange between systems - Local and metropolitan area networks 734 - Specific requirements - Part 3: Carrier sense multiple access 735 with collision detection (CSMA/CD) access method and physical 736 layer specifications", IEEE Standard 802.3, March 2002. 738 [8] Bernstein, G., Rajagopalan, B., and D. Saha, "Optical Network 739 Control: Archtecture, Protocols", Addison-Wesley, 2004. 741 Authors' Addresses 743 Greg Bernstein 744 Grotto Networking 746 Phone: +1 510 573 2237 747 Email: gregb@grotto-networking.com 749 Diego Caviglia 750 Marconi 752 Email: Diego.Caviglia@marconi.com 754 Richard Rabbat 755 Fujitsu 757 Phone: +1 408 530 4537 758 Email: richard@us.fujitsu.com 760 Appendix A. Acknowledgements 762 The authors would like to thank Maarten Vissers for extensive reviews 763 and contributions to this draft. 765 Intellectual Property Statement 767 The IETF takes no position regarding the validity or scope of any 768 Intellectual Property Rights or other rights that might be claimed to 769 pertain to the implementation or use of the technology described in 770 this document or the extent to which any license under such rights 771 might or might not be available; nor does it represent that it has 772 made any independent effort to identify any such rights. Information 773 on the procedures with respect to rights in RFC documents can be 774 found in BCP 78 and BCP 79. 776 Copies of IPR disclosures made to the IETF Secretariat and any 777 assurances of licenses to be made available, or the result of an 778 attempt made to obtain a general license or permission for the use of 779 such proprietary rights by implementers or users of this 780 specification can be obtained from the IETF on-line IPR repository at 781 http://www.ietf.org/ipr. 783 The IETF invites any interested party to bring to its attention any 784 copyrights, patents or patent applications, or other proprietary 785 rights that may cover technology that may be required to implement 786 this standard. Please address the information to the IETF at 787 ietf-ipr@ietf.org. 789 Disclaimer of Validity 791 This document and the information contained herein are provided on an 792 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 793 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 794 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 795 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 796 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 797 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 799 Copyright Statement 801 Copyright (C) The Internet Society (2005). This document is subject 802 to the rights, licenses and restrictions contained in BCP 78, and 803 except as set forth therein, the authors retain all their rights. 805 Acknowledgment 807 Funding for the RFC Editor function is currently provided by the 808 Internet Society.