idnits 2.17.1 draft-bernstein-ccamp-gmpls-vcat-lcas-03.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 22. -- Found old boilerplate from RFC 3978, Section 5.3 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 762. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 769. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 775. -- The document has an RFC 3978 Section 5.3 Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. ** 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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC3946, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3946, updated by this document, for RFC5378 checks: 2001-05-11) -- 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 (June 25, 2006) is 6515 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: 'RFC3946bis' is mentioned on line 218, but not defined ** Obsolete undefined reference: RFC 3946 (Obsoleted by RFC 4606) == Missing Reference: 'RFC 3473' is mentioned on line 313, but not defined == Unused Reference: 'RFC2961' is defined on line 661, but no explicit reference was found in the text == Unused Reference: 'RFC3946-bis' is defined on line 669, but no explicit reference was found in the text == Unused Reference: 'RFC4206' is defined on line 675, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3946 (Obsoleted by RFC 4606) -- Possible downref: Non-RFC (?) normative reference: ref. 'E2E-RECOVERY' Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group G. Bernstein 2 Internet Draft Grotto Networking 3 Updates: RFC 3946 D. Caviglia 4 Proposed Category: Standards Track Ericsson 5 Expires: December 2006 R. Rabbat 6 Fujitsu 7 H. van Helvoort 8 Huawei 9 June 25, 2006 11 Operating Virtual Concatenation (VCAT) and the Link Capacity 12 Adjustment Scheme with Generalized Multi-Protocol Label Switching 13 (GMPLS) 14 draft-bernstein-ccamp-gmpls-vcat-lcas-03.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that 19 any applicable patent or other IPR claims of which he or she is 20 aware have been or will be disclosed, and any of which he or she 21 becomes aware will be disclosed, in accordance with Section 6 of 22 BCP 79. 24 This document may only be posted in an Internet-Draft. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html 42 This Internet-Draft will expire on December 25, 2006. 44 Abstract 46 This document describes requirements for, and use of, the Generalized 47 Multi-Protocol Label Switching (GMPLS) control plane in conjunction 48 with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing 49 mechanism and its companion Link Capacity Adjustment Scheme (LCAS) 50 which can be used for hitless dynamic resizing of the inverse 51 multiplex group. These techniques apply to the Optical Transport 52 Network (OTN), Synchronous Optical Network (SONET), Synchronous 53 Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) 54 signals. 56 Conventions used in this document 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in RFC-2119 [RFC2119]. 62 Table of Contents 64 1. Introduction...................................................3 65 2. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-02..........3 66 3. VCAT/LCAS Scenarios and Specific Requirements..................4 67 3.1. Multiple VCAT Groups per GMPLS Endpoint...................4 68 3.2. Component Signal Configuration Requirements...............4 69 3.3. VCAT Operation With or Without LCAS.......................5 70 4. GMPLS Mechanisms for Signaling VCAT/LCAS.......................5 71 4.1. Co-Routed Signals.........................................5 72 4.1.1. One-shot Setup of Co-Routed Signal...................6 73 4.1.2. Incremental Setup of Co-Routed Signal................6 74 4.1.3. Removing a Component Signal..........................7 75 4.1.4. Removing Multiple Component Signals in One Shot......7 76 4.1.5. Use of multiple LSPs for Co-Routed Signals...........7 77 4.1.6. Teardown of Whole VCG................................7 78 4.2. Diversely Routed Signals..................................8 79 4.2.1. Associating Diversely Routed Signals.................8 80 4.2.1.1. Format..........................................9 81 4.2.2. Recap of Setup Using Diversely Routed Components.....9 82 4.2.3. Recap of Reduction/Teardown Using Diversely Routed 83 Components.................................................10 84 4.2.4. Update and Upgrade of Existing VCAT Groups..........10 85 4.2.5. One LSP per Circuit.................................10 86 5. IANA Considerations...........................................10 87 6. Security Considerations.......................................10 88 7. Contributors..................................................11 89 8. Acknowledgments...............................................11 90 APPENDIX A: An Overview of VCAT and LCAS.........................12 91 A.1. VCAT Signals and Components..............................12 92 A.2. VCAT Capabilities and Limitations........................12 93 A.3. The LCAS Protocol........................................13 94 APPENDIX B: Carrier Perspective on VCAT/LCAS Application Areas...14 95 B.1. VCAT Advantages..........................................14 96 B.1.1. Right Sizing Bandwidth..............................14 97 B.1.2. Bandwidth Efficiencies in a Mesh Network............14 98 B.1.3. Minimizing Restoration Impact.......................14 99 B.1.4. Modify Component Routing............................15 100 B.2. LCAS Advantages..........................................15 101 B.2.1. Graceful Degradation................................15 102 B.2.2. Dynamic Adjustment..................................15 103 B.2.3. Painless Re-Grooming................................15 104 9. References....................................................17 105 9.1. Normative References.....................................17 106 9.2. Informative References...................................17 107 Author's Addresses...............................................18 108 Intellectual Property Statement..................................19 109 Disclaimer of Validity...........................................19 110 Copyright Statement..............................................19 111 Acknowledgment...................................................20 113 1. Introduction 115 This document describes requirements for, and use of, the Generalized 116 Multi-Protocol Label Switching (GMPLS) control plane in conjunction 117 with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing 118 mechanism and its companion Link Capacity Adjustment Scheme (LCAS) 119 which can be used for hitless dynamic resizing of the inverse 120 multiplex group. The reader is directed to Appendix A that presents 121 an overview of the capabilities of VCAT and LCAS in transport 122 networks. Further, Appendix B describes a carrier perspective on the 123 application areas for these technologies. We develop a set of 124 scenarios and specific requirements to support these scenarios in 125 GMPLS-enabled networks. We then describe the RSVP-TE mechanisms 126 needed to set up co-routed as well as diversely routed circuits that 127 are members of the same VCAT group and to resize those using LCAS. 129 2. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-02 131 o Added one more author (Huub) 132 o Dropped section 3.3 about advertising VCAT and LCAS capability. 133 This change is due to the amount of information that would need to 134 be advertised. VCAT capability at the interface comprises a lot 135 of information, which make advertising not very scalable. For 136 example, a node could perform an adaptation using two interfaces 137 lying on different line cards but that's not necessarily always 138 the case. This update to the draft expects the use of the NMS in 139 selecting the right destinations. 141 o Removed references to OSPF-TE 143 3. VCAT/LCAS Scenarios and Specific Requirements 145 From the carrier application areas discussed in Appendix B, we can 146 derive a number of specific requirements for the support of VCAT/LCAS 147 in GMPLS. A number of requirements can additionally be derived from 148 the flexible nature of VCAT/LCAS. 150 3.1. Multiple VCAT Groups per GMPLS Endpoint 152 In general, an LSR can be ingress/egress of one or more VCAT groups. 153 VCAT and LCAS are interface capabilities. An LSR may have, for 154 example, VCAT-capable interfaces that are not LCAS-capable. It may 155 at the same time have interfaces that are neither VCAT nor LCAS- 156 capable. 158 3.2. Component Signal Configuration Requirements 160 We list in this section the different scenarios that SHOULD be 161 supported. Here we use the term "VCG" to refer to the entire VCAT 162 group and the terminology "set" and "subset" to refer to the 163 collection of potential VCAT group member signals. 165 o Fixed, co-routed: A fixed bandwidth VCG, transported over a co- 166 routed set of member signals. This is the case where the intended 167 bandwidth of the VCG does not change and all member signals follow 168 the same route and minimize differential delay. The intent here 169 is the capability to allocate an amount of bandwidth close to that 170 required at the client layer. 172 o Fixed, diversely routed: A fixed bandwidth VCG, transported over 173 at least two diversely routed subsets of member signals. In this 174 case, the subsets are link-disjoint over at least one link of the 175 route. The intent here is more efficient use of network resources 176 (no unique route has the required bandwidth), and additional 177 resilience and graceful degradation in the case of failure (note 178 that differential delay may be a limiting factor). 180 o Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or 181 decreased via the addition or removal of member signals), 182 transported over a co-routed set of members. Intent here is 183 dynamic sizing of bandwidth. 185 o Dynamic, diversely routed: A dynamic VCAT group, transported over 186 at least two diversely routed subsets of member signals. The 187 intent here is dynamic resizing and resilience (but differential 188 delay may be a limiting factor). 190 3.3. VCAT Operation With or Without LCAS 192 VCAT capabilities may be present with or without the presence of 193 LCAS. The use of LCAS is beneficial to the provision of services, 194 but in the absence of LCAS, VCAT is still a valid technique. 195 Therefore GMPLS mechanisms for the operation of VCAT are REQUIRED for 196 both the case where LCAS is available and the case where it is not 197 available. The GMPLS procedures for the two cases SHOULD be 198 identical. 200 4. GMPLS Mechanisms for Signaling VCAT/LCAS 202 We describe in this section the signaling mechanisms that already 203 exist in GMPLS using RSVP-TE [RFC3473] and the extensions needed, for 204 diversely routed paths and in support of the LCAS procedure. 206 Section 4.1 is included for informational purposes only. It 207 describes existing procedures and makes not changes. 209 Section 4.2 describes new procedures proposed to support diversely 210 routed VCAT groups. Where possible it reuses applicable existing 211 procedures from section 4.1. 213 4.1. Co-Routed Signals 215 Note that this section is for informational purposes only. 217 The existing signaling protocols support co-routed signal setup using 218 the NVC field as explained in section 2.1 of RFC 3946 [RFC3946bis]. 219 In this case, one single LSP is set up in support of the VCAT group. 221 There are two options for setting up the VCAT group, depending on 222 hardware capability, or management preferences: one-shot setup and 223 incremental setup. 225 The following sections explain the procedure based on an example of 226 setting up a VC4-7v SDH VCAT group (corresponding to an STS-3c-7v 227 SONET VCAT group). 229 4.1.1. One-shot Setup of Co-Routed Signal 231 An RSVP-TE Path message is used with the following parameters. 233 With regards to the traffic parameters, the elementary signal is 234 chosen (6 for VC-4/STS-3c_SPE). The value of NVC is then set to 7. 236 A Multiplier Transform greater than 1 (say N>1) is used if the 237 operator wants to set up N VCAT groups that will belong to and be 238 assigned to one LSP. 240 SDH or SONET labels in turn have to be assigned for each member of 241 the VCG and concatenated to form a single Generalized Label 242 constructed as an ordered list of 32-bit timeslot identifiers of the 243 same format as TDM labels. RFC 3946 requires that the order of the 244 labels reflect the order of the payloads to concatenate and not the 245 physical order of time-slots. 247 When the MT field is larger than 1, the list includes labels for the 248 components of each of the group. 250 4.1.2. Incremental Setup of Co-Routed Signal 252 In some cases, it may be necessary or desirable to set up the VCG 253 members individually, or to add group members to an existing group. 255 One example of this need is when the hardware that supports VCAT can 256 only add VCAT elements one at a time or cannot automatically match 257 the elements at the ingress and egress for the purposes of inverse 258 multiplexing. Serial or incremental setup solves this problem. 260 In order to accomplish incremental setup an iterative process is used 261 to add group members. For each iteration, NVC is incremented up to 262 the final value required. The iteration consists of the successful 263 completion of a Path and Resv signaling. At first, NVC = 1 and the 264 label includes just one timeslot identifier 266 At each of the next iterations, NVC is set to (NVC +1), one more 267 timeslot identifier is added to the ordered list in the Generalized 268 Label (in the Path or Resv message). A node that receives a Path 269 message that contains changed fields will process the full Path 270 message and, based on the new value of NVC, it will add a component 271 signal to the VCAT group, and switch the new timeslot based on the 272 new label information. 274 Following the addition of the new label to the LSP, LCAS may be used 275 in-band to add the new label into the existing VCAT group. LCAS 276 signaling for this function is described in [ITU-T-G.7042]. 278 4.1.3. Removing a Component Signal 280 The procedure to remove a component signal is similar to that used to 281 add components as described in Section 4.1.2. The LCAS in-band 282 signaling step is taken first to take the component out of the group. 283 LCAS signaling is described in [ITU-T-G.7042]. 285 In this case, the NVC value is decremented by 1 and the timeslot 286 identifier for the dropped component is removed from the ordered list 287 in the Generalized Label. This function is not supported without 288 management intervention for VCAT-only interfaces as removing one 289 component of the VCG will result in errors in the inverse- 290 multiplexing procedure of VCAT and result in the teardown of the 291 whole group. So, this is a feature that only LCAS-capable VCAT 292 interfaces can support without management intervention at the end 293 points. 295 4.1.4. Removing Multiple Component Signals in One Shot 297 The procedure is similar to 4.1.3. In this case, the NVC value is 298 changed to the new value and all relevant timeslot identifiers for 299 the components to be torn down are removed from the ordered list in 300 the Generalized Label. This is also not supported for VCAT-only 301 interfaces without management intervention as removing one component 302 of the VCG will tear down the whole group. 304 4.1.5. Use of multiple LSPs for Co-Routed Signals 306 Co-routed signals may also be supported by distinct LSPs signaled 307 separately using exactly the techniques described for diversely 308 routed signals in Section 4.2. 310 4.1.6. Teardown of Whole VCG 312 The entire LSP is deleted in a single step (i.e., all components are 313 removed in one go) using deletion procedures of [RFC 3473]. 315 4.2. Diversely Routed Signals 317 The initial GMPLS specification did not support diversely routed 318 signals using the NVC construct. In fact, RFC 3946 says: 320 [...] The standard definition for virtual concatenation allows 321 each virtual concatenation components to travel over diverse 322 paths. Within GMPLS, virtual concatenation components must 323 travel over the same (component) link if they are part of the 324 same LSP. This is due to the way that labels are bound to a 325 (component) link. Note however, that the routing of components 326 on different paths is indeed equivalent to establishing 327 different LSPs, each one having its own route. Several LSPs 328 can be initiated and terminated between the same nodes and 329 their corresponding components can then be associated together 330 (i.e., virtually concatenated). 332 Diverse routing of signals can be a useful capability but requires 333 the extensions identified in this document. 335 4.2.1. Associating Diversely Routed Signals 337 The feature that needs to be added is the functionality to associate 338 the components of the same VCG. For this purpose, we use the 339 Association Object that was defined in [E2E-RECOVERY] to associate 340 working and recovery LSPs. 342 A diversely routed VCG uses a number of routes R <= VCG size, as some 343 routes may be the same for several components. A number of LSPs, L 344 (L >= R) are used with each LSP establishing at least one component 345 of the VCG, and at most all of the co-routed members of the group. 346 For a set of c components using the same route, we set up the LSP 347 with NVC = c exactly as explained in section 4.1.1. Therefore, the 348 association of group members or of sub-groups to form the VCG 349 requires the association of the LSPs used to establish the group 350 members. 352 To be able to associate the LSPs, the Session object MUST be the same 353 for all LSPs (this also indicates that the same Tunnel ID is used for 354 all the LSPs). The LSP ID, however, MUST be different for each LSP 355 to distinguish between the LSPs. However, since there are 356 potentially many reasons for multiple LSPs within a single session 357 (for example, end-to-end protection, make-before-break, etc.) a 358 mechanism to identify the association of a subset LSPs is needed. 360 The Association ID in the Association object is a 16-bit value, so we 361 can have for one SESSION up to 2^16 associations, meaning up to 2^16 362 diversely routed VCAT groups and any number of co-routed LSPs. 364 Since we are not using this Association ID to indicate protection, 365 the value for the Association ID should be decided by an outside 366 entity. This may be the management plane. The assignment of the 367 Association ID is outside the scope of GMPLS but MUST be unique for 368 the same Session. 370 Note that this does not preclude the use of another Association ID to 371 indicate the recovery, as the standard allows the use of multiple 372 Association objects. We need to differentiate between the 373 association objects used for the VCAT group and the association 374 objects used for recovery. 376 In this draft, we define a new association type to indicate that this 377 is a VCG association. 379 4.2.1.1. Format 381 Association Type: 16 bits 383 Value Type 384 ----- ---- 386 3 VCAT group 388 See [E2E-RECOVERY] for the definition of other fields and values 389 while noting again that the Association ID should be unique per 390 session. 392 4.2.2. Recap of Setup Using Diversely Routed Components 394 For every route R, use procedure outlined in 4.1.1 or 4.1.2 depending 395 on the capability of the equipment or general preference. The Path 396 message MUST include the Association object with type set to 3. 398 For example, we use two routes: one to carry 3 VC-4 circuits and the 399 other to carry 4 VC-4 circuits. This results in two associated LSPs. 401 Following the addition of the new LSP (i.e., RESV message is received 402 by the endpoint adding bandwidth), LCAS signaling is used in-band to 403 hitlessly add the new label into the existing group [ITU-T-G.7042]. 405 4.2.3. Recap of Reduction/Teardown Using Diversely Routed Components 407 For every route R, to remove component circuits on that route, first, 408 LCAS signaling is used in-band to remove the labels associated with 409 the LSP from the group. LCAS signaling is defined in [ITU-T-G.7042]. 411 Then, use procedures outlined in 4.1.3 or 4.1.4. 413 This again can only be done on LCAS-capable interfaces. If the 414 procedure is attempted on VCAT-only interfaces, then the whole VCG is 415 torn down (this is not a graceful teardown so ingress/egress initiate 416 a Path Tear/Resv Tear) on all routes R. 418 4.2.4. Update and Upgrade of Existing VCAT Groups 420 For existing VCAT groups, in order to allow them to participate in 421 diversely routed VCGs, we use the same method of changing the message 422 ID for the Path message of an existing LSP and adding the Association 423 object that will be interpreted at all intermediate and edge nodes 424 and that Association object will be added to the LSP information. 426 4.2.5. One LSP per Circuit 428 Similarly to in 3.2.4, one may wish to use as many LSPs as circuits. 429 This is supported and each LSP will be used to set up one element of 430 the VCG. The Association object is used to indicate the VCG 431 association type. 433 5. IANA Considerations 435 This document requests from IANA the assignment of a new Association 436 Type within the Association object. This object was defined in [E2E- 437 RECOVERY]. 439 6. Security Considerations 441 This document introduces a new use of the Association object for GMLS 442 signaling [RFC3473] to associate diversely routed VCAT group members. 443 It does not introduce any new signaling messages, nor change the 444 relationship between LSRs that are adjacent in the control plane. 445 This association information in the event of an interception may 446 indicate that there members of the same VCAT group that take a 447 different route and may indicate to an interceptor that the network 448 may be more robust. 450 Otherwise, this document does not introduce any additional security 451 considerations. 453 7. Contributors 455 Wataru Imajuku (NTT) 456 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 457 Japan 459 Phone +81-46-859-4315 460 Email: imajuku.wataru@lab.ntt.co.jp 462 Julien Meuric 463 France Telecom 464 2, avenue Pierre Marzin 465 22307 Lannion Cedex 466 France 468 Phone: + 33 2 96 05 28 28 469 Email: julien.meuric@francetelecom.com 471 Lyndon Ong (Ciena) 472 PO Box 308 473 Cupertino, CA 95015 474 United States of America 476 Phone: +1 408 705 2978 477 Email: lyong@ciena.com 479 8. Acknowledgments 481 The authors would like to thank Maarten Vissers and Adrian Farrel for 482 extensive reviews and contributions to this draft. 484 APPENDIX A: An Overview of VCAT and LCAS 486 Virtual Concatenation (VCAT) is a standardized layer 1 inverse 487 multiplexing technique that can be applied to OTN [ITU-T-G.709], 488 SONET [ANSI-T1.105], SDH [ITU-T-G.707], and PDH [ITU-T-G.7043] 489 component signals. By inverse multiplexing we mean a method that 490 combines multiple links at a particular layer into an aggregate link 491 to achieve a commensurate increase in available bandwidth on that 492 aggregate link. More formally, VCAT essentially combines the payload 493 bandwidth of multiple path layer network signals (or trails) to 494 support a single client (e.g. Ethernet) layer link. For a more 495 detailed introduction, see [BCRH06], [BRS04] and [Hel05]. 497 A.1. VCAT Signals and Components 499 In the following we will use SDH terminology rather than both SONET 500 and SDH terminology. In SDH Virtual Concatenation (VCAT) can be 501 applied to the following component time division multiplex (TDM) 502 signals referred to as Virtual Containers (VCs): VC-11, VC-12, VC-2, 503 VC-3, and VC-4. 505 Only like component signals can be aggregated into a VCAT group. 506 These groups are respectively known as: VC-11-Xv, VC-12-Xv, VC-2-Xv 507 (X= 1... 64), VC-3-Xv and VC-4-Xv (X=1... 256). 509 VCAT can be applied to the following PDH signals as specified in 510 reference [ITU-T-G.7043]: DS1, E1, E3, DS3. Similar to the SONET/SDH 511 case these component signals can only be combined with like signals 512 to produce aggregates. For some reason the virtual concatenation 513 groups of the PDH signals were not given unique designations in [ITU- 514 T-G.7043] so we shall adopt a similar notation to the SDH VCAT 515 signals for the permitted PDH VCAT signals that follow: DS1-Xv, E1-Xv 516 (X=1... 16), E3-Xv, DS3-Xv (X= 1... 8). 518 Concatenation in the optical transport network (OTN) is realized by 519 means of virtual concatenation of Optical Channel Payload Unit (OPU) 520 signals. OPUk signals (k= 1, 2, 3) can be concatenated into OPUk-Xv 521 aggregates (X= 1... 256). See reference [ITU-T-G.709] for details. 523 A.2. VCAT Capabilities and Limitations 525 VCAT performs inverse multiplexing by octet/byte de-interleaving of 526 the encapsulated client bit stream. The main limitation of any VCAT 527 standard or implementation is the amount of differential delay that 528 can be accommodated between the component signals when they are 529 diversely routed. These are summarized for the different signal 530 types in reference [BCRH06] and [Hel05] with details given in the 531 respective standards documents. 533 A.3. The LCAS Protocol 535 The Link Capacity Adjustment Scheme for VCAT signals is a protocol 536 for dynamically and hitlessly changing (i.e., increasing and 537 decreasing) the capacity of a VCAT group. LCAS also provides 538 survivability capabilities, automatically decreasing the capacity if 539 a member of the VCAT group experiences a failure in the network, and 540 increasing the capacity when the network fault is repaired. LCAS, 541 itself, provides a mechanism for interworking between LCAS and non- 542 LCAS VCAT end points. VCAT does not require LCAS for its operation. 544 LCAS functionality does not overlap or conflict with GMPLS' routing 545 or signaling functionality for the establishment of component links 546 or entire VCAT groups. LCAS instead is used to control whether a 547 particular component signal is actually put into service carrying 548 traffic for the VCAT group. 550 LCAS provides for graceful degradation of failed links by having the 551 sink end report back the receive status of all member components. In 552 the case of a reported member failure, the source end will stop using 553 the component and the source end will send an LCAS message to the 554 sink end that it is not transmitting data on that component. The 555 worst case notification times are summarized in [BCRH06] and [Hel05]. 557 APPENDIX B: Carrier Perspective on VCAT/LCAS Application Areas 559 We present in this appendix a number of application areas of VCAT and 560 LCAS that make them valuable in the transport network. 562 B.1. VCAT Advantages 564 When used as a transport layer, SONET/SDH networks may require that 565 containers be grouped together to offer services with higher 566 bandwidth than the base elementary transport entities. While 567 contiguous concatenation imposes stringent constraints on the 568 placement of component signals and restricts sizing to specific 569 combinations (X= 1, 4, 16 ...), virtual concatenation offers much 570 more flexibility (X= 1, 2, 3 ...) in sizing and no placement 571 restrictions. 573 B.1.1. Right Sizing Bandwidth 575 Virtual concatenation allows the customization of the number of 576 components in a group, thus offering a bandwidth closer to the client 577 layer needs. A common example is the STS-3c-7v/VC-4-7v often used in 578 data transport since well fit to 1 Gbit/s traffic, whereas an STS- 579 48c/VC-4-16c (imposed by contiguous concatenation) would be too big 580 and lead to wasting bandwidth. 582 B.1.2. Bandwidth Efficiencies in a Mesh Network 584 Given an end-to-end bandwidth demand between a source and a sink and 585 a mesh network topology, there may be enough total bandwidth across 586 the network to meet the demand, but not along a single route. VCAT 587 has the ability to transport components of a Virtually Concatenated 588 Group (VCG) over different paths which can be diversely routed in the 589 network. In this way, a carrier increases the efficiency of the 590 transport network by making better use of the mesh topology of that 591 network. 593 B.1.3. Minimizing Restoration Impact 595 The diverse routing enabled by VCAT is a useful capability since, in 596 case of single failure, only a subset of the members of the VCG needs 597 to be recovered, which allows a higher availability than the single 598 route case. This means that a failure does not require recovery for 599 the whole VCG but only for the failed path, and a sub-part of the 600 total bandwidth will be easier to restore than the full pipe. This 601 becomes more beneficial when combined with LCAS (see below). As a 602 matter of fact, this is a key driver for using VCAT in a carrier's 603 network. 605 B.1.4. Modify Component Routing 607 In order to migrate from singly-routed transport services and 608 distribute circuits over multiple routes, it is also useful to 609 segregate a single VCG into several LSPs. Indeed, while resources 610 may be provisioned using a single LSP at day one, there should be a 611 migration path to allow the members of the VCG to be carried over 612 diverse routes as allowed by VCAT. 614 B.2. LCAS Advantages 616 When VCAT is used in a carrier network, enabling LCAS brings a number 617 of additional advantages to network operations. 619 B.2.1. Graceful Degradation 621 When a member of an LCAS-enabled VCG is faulty, the other members 622 keep carrying their portion (interleaved bytes) of traffic, i.e., the 623 portion of the traffic on the faulty member does not reach the 624 destination. Hence, the entire VCG is delivering errored data until 625 the faulty member is removed from the VCG. With LCAS the process of 626 removing the faulty member is automated and very fast. Note that 627 removing the member from carrying traffic for the group is different 628 from setting up or removing the member circuit. This functionality 629 is particularly useful when the VCG is diversely routed because some 630 bandwidth remains available during restoration and can be used by the 631 client layer with no interruption to traffic, albeit at a decreased 632 bit-rate. 634 B.2.2. Dynamic Adjustment 636 LCAS allows for hitless resizing of VCGs between two endpoints. 637 Without LCAS, the bandwidth associated with a transport service 638 cannot be modified without traffic disruption: a VCG needs indeed to 639 be re-provisioned with the necessary number of components to meet the 640 new demand. LCAS brings the necessary mechanisms to modify a VCG by 641 adding and removing some components while allowing the VCG to carry 642 traffic uninterrupted. 644 B.2.3. Painless Re-Grooming 646 When connections need to be rerouted due to maintenance or to make 647 efficient use of network resources, the process, known as re- 648 grooming, generally impacts user traffic. LCAS enables a hitless 649 method for re-grooming by first adding to VCGs additional components 650 that have been set up on the new desired path, then removing the old 651 components from the VCG and releasing the unused resources from the 652 network. 654 9. References 656 9.1. Normative References 658 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 659 Requirement Levels", BCP 14, RFC 2119, March 1997. 661 [RFC2961] Berger, L. et ali "RSVP Refresh Overhead Reduction 662 Extensions" RFC 2961, April 2001. 664 [RFC3473] Berger, L., "Generalized Multi-Protocol Label 665 Switching (GMPLS) Signaling Resource ReserVation 666 Protocol-Traffic Engineering (RSVP-TE) Extensions", 667 RFC 3473, January 2003. 669 [RFC3946-bis] Mannie, E. and D. Papadimitriou, "Generalized Multi- 670 Protocol Label Switching (GMPLS) Extensions for 671 Synchronous Optical Network (SONET) and Synchronous 672 Digital Hierarchy (SDH) Control ", IETF draft, work in 673 progress, December 2005. 675 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths 676 (LSP) Hierarchy with Generalized Multi-Protocol Label 677 Switching (GMPLS) Traffic Engineering (TE)" RFC 4206, 678 October 2005. 680 [E2E-RECOVERY] Lang, J.P., Rekhter, Y., and D. Papadimitriou (eds.), 681 "RSVP-TE Extensions in support of End-to-End 682 Generalized Multi-Protocol Label Switching (GMPLS)- 683 based Recovery", IETF draft, work in progress, April 684 2005. 686 9.2. Informative References 688 [ANSI-T1.105] American National Standards Institute, "Synchronous 689 Optical Network (SONET) - Basic Description including 690 Multiplex Structure, Rates, and Formats", ANSI T1.105- 691 2001, May 2001. 693 [BCRH06] Bernstein, G., Caviglia, D., R. Rabbat and H. van 694 Helvoort, "VCAT/LCAS in a Clamshell", IEEE 695 Communications Magazine, May 2006. 697 [BRS04] Bernstein, G., Rajagopalan, B. and D. Saha, "Optical 698 Network Control: Architecture, Protocols", Addison- 699 Wesley, 2004. 701 [Hel05] Helvoort, H., "Next Generation SDH/SONET: Evolution or 702 Revolution?" Wiley & Sons, 2005. 704 [ITU-T-G.7042] International Telecommunications Union, "Link Capacity 705 Adjustment Scheme (LCAS) for Virtual Concatenated 706 Signals", ITU-T Recommendation G.7042, February 2004. 708 [ITU-T-G.7043] International Telecommunications Union, "Virtual 709 Concatenation of Plesiochronous Digital Hierarchy 710 (PDH) Signals", ITU-T Recommendation G.7043, July 711 2004. 713 [ITU-T-G.707] International Telecommunications Union, "Network Node 714 Interface for the Synchronous Digital Hierarchy 715 (SDH)", ITU-T Recommendation G.707, December 2003. 717 [ITU-T-G.709] International Telecommunications Union, "Interfaces 718 for the Optical Transport Network (OTN)", ITU-T 719 Recommendation G.709, March 2003. 721 Author's Addresses 723 Greg Bernstein 724 Grotto Networking 726 Phone: +1-510-573-2237 727 Email: gregb@grotto-networking.com 729 Diego Caviglia 730 Ericsson 731 Via A. Negrone 1/A 16153 732 Genoa Italy 734 Phone: +39 010 600 3736 735 Email: diego.caviglia@(marconi.com, ericsson.com) 737 Richard Rabbat 738 Fujitsu Laboratories of America 739 1240 East Arques Ave, MS 345 740 Sunnyvale, CA 94085 741 United States of America 743 Phone: +1 408-530-4537 744 Email: richard@us.fujitsu.com 745 Huub van Helvoort 746 Huawei 747 Kolkgriend 38, 1356 BC Almere 748 The Netherlands 750 Phone: +31 36 5315076 751 Email: hhelvoort@chello.nl 753 Intellectual Property Statement 755 The IETF takes no position regarding the validity or scope of any 756 Intellectual Property Rights or other rights that might be claimed to 757 pertain to the implementation or use of the technology described in 758 this document or the extent to which any license under such rights 759 might or might not be available; nor does it represent that it has 760 made any independent effort to identify any such rights. Information 761 on the procedures with respect to rights in RFC documents can be 762 found in BCP 78 and BCP 79. 764 Copies of IPR disclosures made to the IETF Secretariat and any 765 assurances of licenses to be made available, or the result of an 766 attempt made to obtain a general license or permission for the use of 767 such proprietary rights by implementers or users of this 768 specification can be obtained from the IETF on-line IPR repository at 769 http://www.ietf.org/ipr. 771 The IETF invites any interested party to bring to its attention any 772 copyrights, patents or patent applications, or other proprietary 773 rights that may cover technology that may be required to implement 774 this standard. Please address the information to the IETF at 775 ietf-ipr@ietf.org. 777 Disclaimer of Validity 779 This document and the information contained herein are provided on an 780 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 781 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 782 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 783 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 784 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 785 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 787 Copyright Statement 789 Copyright (C) The Internet Society (2006). 791 This document is subject to the rights, licenses and restrictions 792 contained in BCP 78, and except as set forth therein, the authors 793 retain all their rights. 795 Acknowledgment 797 Funding for the RFC Editor function is currently provided by the 798 Internet Society.