CCAMP Working Group G. Bernstein Internet Draft Grotto Networking Updates: RFC 3946 D. Caviglia Proposed Category: Standards Track Ericsson Expires: December 2006 R. Rabbat Fujitsu H. van Helvoort Huawei June 25, 2006 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme with Generalized Multi-Protocol Label Switching (GMPLS) draft-bernstein-ccamp-gmpls-vcat-lcas-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. This document may only be posted in an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 25, 2006. Bernstein Expires December 25, 2006 [Page 1]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 Abstract This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. These techniques apply to the Optical Transport Network (OTN), Synchronous Optical Network (SONET), Synchronous Digital Hierarchy (SDH), and Plesiochronous Digital Hierarchy (PDH) signals. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. Table of Contents 1. Introduction...................................................3 2. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-02..........3 3. VCAT/LCAS Scenarios and Specific Requirements..................4 3.1. Multiple VCAT Groups per GMPLS Endpoint...................4 3.2. Component Signal Configuration Requirements...............4 3.3. VCAT Operation With or Without LCAS.......................5 4. GMPLS Mechanisms for Signaling VCAT/LCAS.......................5 4.1. Co-Routed Signals.........................................5 4.1.1. One-shot Setup of Co-Routed Signal...................6 4.1.2. Incremental Setup of Co-Routed Signal................6 4.1.3. Removing a Component Signal..........................7 4.1.4. Removing Multiple Component Signals in One Shot......7 4.1.5. Use of multiple LSPs for Co-Routed Signals...........7 4.1.6. Teardown of Whole VCG................................7 4.2. Diversely Routed Signals..................................8 4.2.1. Associating Diversely Routed Signals.................8 4.2.1.1. Format..........................................9 4.2.2. Recap of Setup Using Diversely Routed Components.....9 4.2.3. Recap of Reduction/Teardown Using Diversely Routed Components.................................................10 4.2.4. Update and Upgrade of Existing VCAT Groups..........10 4.2.5. One LSP per Circuit.................................10 5. IANA Considerations...........................................10 6. Security Considerations.......................................10 7. Contributors..................................................11 8. Acknowledgments...............................................11 Bernstein Expires December 25, 2006 [Page 2]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 APPENDIX A: An Overview of VCAT and LCAS.........................12 A.1. VCAT Signals and Components..............................12 A.2. VCAT Capabilities and Limitations........................12 A.3. The LCAS Protocol........................................13 APPENDIX B: Carrier Perspective on VCAT/LCAS Application Areas...14 B.1. VCAT Advantages..........................................14 B.1.1. Right Sizing Bandwidth..............................14 B.1.2. Bandwidth Efficiencies in a Mesh Network............14 B.1.3. Minimizing Restoration Impact.......................14 B.1.4. Modify Component Routing............................15 B.2. LCAS Advantages..........................................15 B.2.1. Graceful Degradation................................15 B.2.2. Dynamic Adjustment..................................15 B.2.3. Painless Re-Grooming................................15 9. References....................................................17 9.1. Normative References.....................................17 9.2. Informative References...................................17 Author's Addresses...............................................18 Intellectual Property Statement..................................19 Disclaimer of Validity...........................................19 Copyright Statement..............................................19 Acknowledgment...................................................20 1. Introduction This document describes requirements for, and use of, the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Concatenation (VCAT) layer 1 inverse multiplexing mechanism and its companion Link Capacity Adjustment Scheme (LCAS) which can be used for hitless dynamic resizing of the inverse multiplex group. The reader is directed to Appendix A that presents an overview of the capabilities of VCAT and LCAS in transport networks. Further, Appendix B describes a carrier perspective on the application areas for these technologies. We develop a set of scenarios and specific requirements to support these scenarios in GMPLS-enabled networks. We then describe the RSVP-TE mechanisms needed to set up co-routed as well as diversely routed circuits that are members of the same VCAT group and to resize those using LCAS. 2. Changes from draft-bernstein-ccamp-gmpls-vcat-lcas-02 o Added one more author (Huub) Bernstein Expires December 25, 2006 [Page 3]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 o Dropped section 3.3 about advertising VCAT and LCAS capability. This change is due to the amount of information that would need to be advertised. VCAT capability at the interface comprises a lot of information, which make advertising not very scalable. For example, a node could perform an adaptation using two interfaces lying on different line cards but that's not necessarily always the case. This update to the draft expects the use of the NMS in selecting the right destinations. o Removed references to OSPF-TE 3. VCAT/LCAS Scenarios and Specific Requirements From the carrier application areas discussed in Appendix B, we can derive a number of specific requirements for the support of VCAT/LCAS in GMPLS. A number of requirements can additionally be derived from the flexible nature of VCAT/LCAS. 3.1. Multiple VCAT Groups per GMPLS Endpoint In general, an LSR can be ingress/egress of one or more VCAT groups. VCAT and LCAS are interface capabilities. An LSR may have, for example, VCAT-capable interfaces that are not LCAS-capable. It may at the same time have interfaces that are neither VCAT nor LCAS- capable. 3.2. Component Signal Configuration Requirements We list in this section the different scenarios that SHOULD be supported. Here we use the term "VCG" to refer to the entire VCAT group and the terminology "set" and "subset" to refer to the collection of potential VCAT group member signals. o Fixed, co-routed: A fixed bandwidth VCG, transported over a co- routed set of member signals. This is the case where the intended bandwidth of the VCG does not change and all member signals follow the same route and minimize differential delay. The intent here is the capability to allocate an amount of bandwidth close to that required at the client layer. o Fixed, diversely routed: A fixed bandwidth VCG, transported over at least two diversely routed subsets of member signals. In this case, the subsets are link-disjoint over at least one link of the route. The intent here is more efficient use of network resources (no unique route has the required bandwidth), and additional resilience and graceful degradation in the case of failure (note that differential delay may be a limiting factor). Bernstein Expires December 25, 2006 [Page 4]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 o Dynamic, co-routed: A dynamic VCG (bandwidth can be increased or decreased via the addition or removal of member signals), transported over a co-routed set of members. Intent here is dynamic sizing of bandwidth. o Dynamic, diversely routed: A dynamic VCAT group, transported over at least two diversely routed subsets of member signals. The intent here is dynamic resizing and resilience (but differential delay may be a limiting factor). 3.3. VCAT Operation With or Without LCAS VCAT capabilities may be present with or without the presence of LCAS. The use of LCAS is beneficial to the provision of services, but in the absence of LCAS, VCAT is still a valid technique. Therefore GMPLS mechanisms for the operation of VCAT are REQUIRED for both the case where LCAS is available and the case where it is not available. The GMPLS procedures for the two cases SHOULD be identical. 4. GMPLS Mechanisms for Signaling VCAT/LCAS We describe in this section the signaling mechanisms that already exist in GMPLS using RSVP-TE [RFC3473] and the extensions needed, for diversely routed paths and in support of the LCAS procedure. Section 4.1 is included for informational purposes only. It describes existing procedures and makes not changes. Section 4.2 describes new procedures proposed to support diversely routed VCAT groups. Where possible it reuses applicable existing procedures from section 4.1. 4.1. Co-Routed Signals Note that this section is for informational purposes only. The existing signaling protocols support co-routed signal setup using the NVC field as explained in section 2.1 of RFC 3946 [RFC3946bis]. In this case, one single LSP is set up in support of the VCAT group. There are two options for setting up the VCAT group, depending on hardware capability, or management preferences: one-shot setup and incremental setup. Bernstein Expires December 25, 2006 [Page 5]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 The following sections explain the procedure based on an example of setting up a VC4-7v SDH VCAT group (corresponding to an STS-3c-7v SONET VCAT group). 4.1.1. One-shot Setup of Co-Routed Signal An RSVP-TE Path message is used with the following parameters. With regards to the traffic parameters, the elementary signal is chosen (6 for VC-4/STS-3c_SPE). The value of NVC is then set to 7. A Multiplier Transform greater than 1 (say N>1) is used if the operator wants to set up N VCAT groups that will belong to and be assigned to one LSP. SDH or SONET labels in turn have to be assigned for each member of the VCG and concatenated to form a single Generalized Label constructed as an ordered list of 32-bit timeslot identifiers of the same format as TDM labels. RFC 3946 requires that the order of the labels reflect the order of the payloads to concatenate and not the physical order of time-slots. When the MT field is larger than 1, the list includes labels for the components of each of the group. 4.1.2. Incremental Setup of Co-Routed Signal In some cases, it may be necessary or desirable to set up the VCG members individually, or to add group members to an existing group. One example of this need is when the hardware that supports VCAT can only add VCAT elements one at a time or cannot automatically match the elements at the ingress and egress for the purposes of inverse multiplexing. Serial or incremental setup solves this problem. In order to accomplish incremental setup an iterative process is used to add group members. For each iteration, NVC is incremented up to the final value required. The iteration consists of the successful completion of a Path and Resv signaling. At first, NVC = 1 and the label includes just one timeslot identifier At each of the next iterations, NVC is set to (NVC +1), one more timeslot identifier is added to the ordered list in the Generalized Label (in the Path or Resv message). A node that receives a Path message that contains changed fields will process the full Path message and, based on the new value of NVC, it will add a component Bernstein Expires December 25, 2006 [Page 6]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 signal to the VCAT group, and switch the new timeslot based on the new label information. Following the addition of the new label to the LSP, LCAS may be used in-band to add the new label into the existing VCAT group. LCAS signaling for this function is described in [ITU-T-G.7042]. 4.1.3. Removing a Component Signal The procedure to remove a component signal is similar to that used to add components as described in Section 4.1.2. The LCAS in-band signaling step is taken first to take the component out of the group. LCAS signaling is described in [ITU-T-G.7042]. In this case, the NVC value is decremented by 1 and the timeslot identifier for the dropped component is removed from the ordered list in the Generalized Label. This function is not supported without management intervention for VCAT-only interfaces as removing one component of the VCG will result in errors in the inverse- multiplexing procedure of VCAT and result in the teardown of the whole group. So, this is a feature that only LCAS-capable VCAT interfaces can support without management intervention at the end points. 4.1.4. Removing Multiple Component Signals in One Shot The procedure is similar to 4.1.3. In this case, the NVC value is changed to the new value and all relevant timeslot identifiers for the components to be torn down are removed from the ordered list in the Generalized Label. This is also not supported for VCAT-only interfaces without management intervention as removing one component of the VCG will tear down the whole group. 4.1.5. Use of multiple LSPs for Co-Routed Signals Co-routed signals may also be supported by distinct LSPs signaled separately using exactly the techniques described for diversely routed signals in Section 4.2. 4.1.6. Teardown of Whole VCG The entire LSP is deleted in a single step (i.e., all components are removed in one go) using deletion procedures of [RFC 3473]. Bernstein Expires December 25, 2006 [Page 7]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 4.2. Diversely Routed Signals The initial GMPLS specification did not support diversely routed signals using the NVC construct. In fact, RFC 3946 says: [...] The standard definition for virtual concatenation allows each virtual concatenation components to travel over diverse paths. Within GMPLS, virtual concatenation components must travel over the same (component) link if they are part of the same LSP. This is due to the way that labels are bound to a (component) link. Note however, that the routing of components on different paths is indeed equivalent to establishing different LSPs, each one having its own route. Several LSPs can be initiated and terminated between the same nodes and their corresponding components can then be associated together (i.e., virtually concatenated). Diverse routing of signals can be a useful capability but requires the extensions identified in this document. 4.2.1. Associating Diversely Routed Signals The feature that needs to be added is the functionality to associate the components of the same VCG. For this purpose, we use the Association Object that was defined in [E2E-RECOVERY] to associate working and recovery LSPs. A diversely routed VCG uses a number of routes R <= VCG size, as some routes may be the same for several components. A number of LSPs, L (L >= R) are used with each LSP establishing at least one component of the VCG, and at most all of the co-routed members of the group. For a set of c components using the same route, we set up the LSP with NVC = c exactly as explained in section 4.1.1. Therefore, the association of group members or of sub-groups to form the VCG requires the association of the LSPs used to establish the group members. To be able to associate the LSPs, the Session object MUST be the same for all LSPs (this also indicates that the same Tunnel ID is used for all the LSPs). The LSP ID, however, MUST be different for each LSP to distinguish between the LSPs. However, since there are potentially many reasons for multiple LSPs within a single session (for example, end-to-end protection, make-before-break, etc.) a mechanism to identify the association of a subset LSPs is needed. Bernstein Expires December 25, 2006 [Page 8]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 The Association ID in the Association object is a 16-bit value, so we can have for one SESSION up to 2^16 associations, meaning up to 2^16 diversely routed VCAT groups and any number of co-routed LSPs. Since we are not using this Association ID to indicate protection, the value for the Association ID should be decided by an outside entity. This may be the management plane. The assignment of the Association ID is outside the scope of GMPLS but MUST be unique for the same Session. Note that this does not preclude the use of another Association ID to indicate the recovery, as the standard allows the use of multiple Association objects. We need to differentiate between the association objects used for the VCAT group and the association objects used for recovery. In this draft, we define a new association type to indicate that this is a VCG association. 4.2.1.1. Format Association Type: 16 bits Value Type ----- ---- 3 VCAT group See [E2E-RECOVERY] for the definition of other fields and values while noting again that the Association ID should be unique per session. 4.2.2. Recap of Setup Using Diversely Routed Components For every route R, use procedure outlined in 4.1.1 or 4.1.2 depending on the capability of the equipment or general preference. The Path message MUST include the Association object with type set to 3. For example, we use two routes: one to carry 3 VC-4 circuits and the other to carry 4 VC-4 circuits. This results in two associated LSPs. Following the addition of the new LSP (i.e., RESV message is received by the endpoint adding bandwidth), LCAS signaling is used in-band to hitlessly add the new label into the existing group [ITU-T-G.7042]. Bernstein Expires December 25, 2006 [Page 9]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 4.2.3. Recap of Reduction/Teardown Using Diversely Routed Components For every route R, to remove component circuits on that route, first, LCAS signaling is used in-band to remove the labels associated with the LSP from the group. LCAS signaling is defined in [ITU-T-G.7042]. Then, use procedures outlined in 4.1.3 or 4.1.4. This again can only be done on LCAS-capable interfaces. If the procedure is attempted on VCAT-only interfaces, then the whole VCG is torn down (this is not a graceful teardown so ingress/egress initiate a Path Tear/Resv Tear) on all routes R. 4.2.4. Update and Upgrade of Existing VCAT Groups For existing VCAT groups, in order to allow them to participate in diversely routed VCGs, we use the same method of changing the message ID for the Path message of an existing LSP and adding the Association object that will be interpreted at all intermediate and edge nodes and that Association object will be added to the LSP information. 4.2.5. One LSP per Circuit Similarly to in 3.2.4, one may wish to use as many LSPs as circuits. This is supported and each LSP will be used to set up one element of the VCG. The Association object is used to indicate the VCG association type. 5. IANA Considerations This document requests from IANA the assignment of a new Association Type within the Association object. This object was defined in [E2E- RECOVERY]. 6. Security Considerations This document introduces a new use of the Association object for GMLS signaling [RFC3473] to associate diversely routed VCAT group members. It does not introduce any new signaling messages, nor change the relationship between LSRs that are adjacent in the control plane. This association information in the event of an interception may indicate that there members of the same VCAT group that take a different route and may indicate to an interceptor that the network may be more robust. Otherwise, this document does not introduce any additional security considerations. Bernstein Expires December 25, 2006 [Page 10]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 7. Contributors Wataru Imajuku (NTT) 1-1 Hikari-no-oka Yokosuka Kanagawa 239-0847 Japan Phone +81-46-859-4315 Email: imajuku.wataru@lab.ntt.co.jp Julien Meuric France Telecom 2, avenue Pierre Marzin 22307 Lannion Cedex France Phone: + 33 2 96 05 28 28 Email: julien.meuric@francetelecom.com Lyndon Ong (Ciena) PO Box 308 Cupertino, CA 95015 United States of America Phone: +1 408 705 2978 Email: lyong@ciena.com 8. Acknowledgments The authors would like to thank Maarten Vissers and Adrian Farrel for extensive reviews and contributions to this draft. Bernstein Expires December 25, 2006 [Page 11]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 APPENDIX A: An Overview of VCAT and LCAS Virtual Concatenation (VCAT) is a standardized layer 1 inverse multiplexing technique that can be applied to OTN [ITU-T-G.709], SONET [ANSI-T1.105], SDH [ITU-T-G.707], and PDH [ITU-T-G.7043] component signals. By inverse multiplexing we mean a method that combines multiple links at a particular layer into an aggregate link to achieve a commensurate increase in available bandwidth on that aggregate link. More formally, VCAT essentially combines the payload bandwidth of multiple path layer network signals (or trails) to support a single client (e.g. Ethernet) layer link. For a more detailed introduction, see [BCRH06], [BRS04] and [Hel05]. A.1. VCAT Signals and Components In the following we will use SDH terminology rather than both SONET and SDH terminology. In SDH Virtual Concatenation (VCAT) can be applied to the following component time division multiplex (TDM) signals referred to as Virtual Containers (VCs): VC-11, VC-12, VC-2, VC-3, and VC-4. Only like component signals can be aggregated into a VCAT group. These groups are respectively known as: VC-11-Xv, VC-12-Xv, VC-2-Xv (X= 1... 64), VC-3-Xv and VC-4-Xv (X=1... 256). VCAT can be applied to the following PDH signals as specified in reference [ITU-T-G.7043]: DS1, E1, E3, DS3. Similar to the SONET/SDH case these component signals can only be combined with like signals to produce aggregates. For some reason the virtual concatenation groups of the PDH signals were not given unique designations in [ITU- T-G.7043] so we shall adopt a similar notation to the SDH VCAT signals for the permitted PDH VCAT signals that follow: DS1-Xv, E1-Xv (X=1... 16), E3-Xv, DS3-Xv (X= 1... 8). Concatenation in the optical transport network (OTN) is realized by means of virtual concatenation of Optical Channel Payload Unit (OPU) signals. OPUk signals (k= 1, 2, 3) can be concatenated into OPUk-Xv aggregates (X= 1... 256). See reference [ITU-T-G.709] for details. A.2. VCAT Capabilities and Limitations VCAT performs inverse multiplexing by octet/byte de-interleaving of the encapsulated client bit stream. The main limitation of any VCAT standard or implementation is the amount of differential delay that can be accommodated between the component signals when they are diversely routed. These are summarized for the different signal Bernstein Expires December 25, 2006 [Page 12]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 types in reference [BCRH06] and [Hel05] with details given in the respective standards documents. A.3. The LCAS Protocol The Link Capacity Adjustment Scheme for VCAT signals is a protocol for dynamically and hitlessly changing (i.e., increasing and decreasing) the capacity of a VCAT group. LCAS also provides survivability capabilities, automatically decreasing the capacity if a member of the VCAT group experiences a failure in the network, and increasing the capacity when the network fault is repaired. LCAS, itself, provides a mechanism for interworking between LCAS and non- LCAS VCAT end points. VCAT does not require LCAS for its operation. LCAS functionality does not overlap or conflict with GMPLS' routing or signaling functionality for the establishment of component links or entire VCAT groups. LCAS instead is used to control whether a particular component signal is actually put into service carrying traffic for the VCAT group. LCAS provides for graceful degradation of failed links by having the sink end report back the receive status of all member components. In the case of a reported member failure, the source end will stop using the component and the source end will send an LCAS message to the sink end that it is not transmitting data on that component. The worst case notification times are summarized in [BCRH06] and [Hel05]. Bernstein Expires December 25, 2006 [Page 13]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 APPENDIX B: Carrier Perspective on VCAT/LCAS Application Areas We present in this appendix a number of application areas of VCAT and LCAS that make them valuable in the transport network. B.1. VCAT Advantages When used as a transport layer, SONET/SDH networks may require that containers be grouped together to offer services with higher bandwidth than the base elementary transport entities. While contiguous concatenation imposes stringent constraints on the placement of component signals and restricts sizing to specific combinations (X= 1, 4, 16 ...), virtual concatenation offers much more flexibility (X= 1, 2, 3 ...) in sizing and no placement restrictions. B.1.1. Right Sizing Bandwidth Virtual concatenation allows the customization of the number of components in a group, thus offering a bandwidth closer to the client layer needs. A common example is the STS-3c-7v/VC-4-7v often used in data transport since well fit to 1 Gbit/s traffic, whereas an STS- 48c/VC-4-16c (imposed by contiguous concatenation) would be too big and lead to wasting bandwidth. B.1.2. Bandwidth Efficiencies in a Mesh Network Given an end-to-end bandwidth demand between a source and a sink and a mesh network topology, there may be enough total bandwidth across the network to meet the demand, but not along a single route. VCAT has the ability to transport components of a Virtually Concatenated Group (VCG) over different paths which can be diversely routed in the network. In this way, a carrier increases the efficiency of the transport network by making better use of the mesh topology of that network. B.1.3. Minimizing Restoration Impact The diverse routing enabled by VCAT is a useful capability since, in case of single failure, only a subset of the members of the VCG needs to be recovered, which allows a higher availability than the single route case. This means that a failure does not require recovery for the whole VCG but only for the failed path, and a sub-part of the total bandwidth will be easier to restore than the full pipe. This becomes more beneficial when combined with LCAS (see below). As a matter of fact, this is a key driver for using VCAT in a carrier's network. Bernstein Expires December 25, 2006 [Page 14]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 B.1.4. Modify Component Routing In order to migrate from singly-routed transport services and distribute circuits over multiple routes, it is also useful to segregate a single VCG into several LSPs. Indeed, while resources may be provisioned using a single LSP at day one, there should be a migration path to allow the members of the VCG to be carried over diverse routes as allowed by VCAT. B.2. LCAS Advantages When VCAT is used in a carrier network, enabling LCAS brings a number of additional advantages to network operations. B.2.1. Graceful Degradation When a member of an LCAS-enabled VCG is faulty, the other members keep carrying their portion (interleaved bytes) of traffic, i.e., the portion of the traffic on the faulty member does not reach the destination. Hence, the entire VCG is delivering errored data until the faulty member is removed from the VCG. With LCAS the process of removing the faulty member is automated and very fast. Note that removing the member from carrying traffic for the group is different from setting up or removing the member circuit. This functionality is particularly useful when the VCG is diversely routed because some bandwidth remains available during restoration and can be used by the client layer with no interruption to traffic, albeit at a decreased bit-rate. B.2.2. Dynamic Adjustment LCAS allows for hitless resizing of VCGs between two endpoints. Without LCAS, the bandwidth associated with a transport service cannot be modified without traffic disruption: a VCG needs indeed to be re-provisioned with the necessary number of components to meet the new demand. LCAS brings the necessary mechanisms to modify a VCG by adding and removing some components while allowing the VCG to carry traffic uninterrupted. B.2.3. Painless Re-Grooming When connections need to be rerouted due to maintenance or to make efficient use of network resources, the process, known as re- grooming, generally impacts user traffic. LCAS enables a hitless method for re-grooming by first adding to VCGs additional components that have been set up on the new desired path, then removing the old Bernstein Expires December 25, 2006 [Page 15]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 components from the VCG and releasing the unused resources from the network. Bernstein Expires December 25, 2006 [Page 16]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2961] Berger, L. et ali "RSVP Refresh Overhead Reduction Extensions" RFC 2961, April 2001. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3946-bis] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control ", IETF draft, work in progress, December 2005. [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)" RFC 4206, October 2005. [E2E-RECOVERY] Lang, J.P., Rekhter, Y., and D. Papadimitriou (eds.), "RSVP-TE Extensions in support of End-to-End Generalized Multi-Protocol Label Switching (GMPLS)- based Recovery", IETF draft, work in progress, April 2005. 9.2. Informative References [ANSI-T1.105] American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates, and Formats", ANSI T1.105- 2001, May 2001. [BCRH06] Bernstein, G., Caviglia, D., R. Rabbat and H. van Helvoort, "VCAT/LCAS in a Clamshell", IEEE Communications Magazine, May 2006. [BRS04] Bernstein, G., Rajagopalan, B. and D. Saha, "Optical Network Control: Architecture, Protocols", Addison- Wesley, 2004. Bernstein Expires December 25, 2006 [Page 17]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 [Hel05] Helvoort, H., "Next Generation SDH/SONET: Evolution or Revolution?" Wiley & Sons, 2005. [ITU-T-G.7042] International Telecommunications Union, "Link Capacity Adjustment Scheme (LCAS) for Virtual Concatenated Signals", ITU-T Recommendation G.7042, February 2004. [ITU-T-G.7043] International Telecommunications Union, "Virtual Concatenation of Plesiochronous Digital Hierarchy (PDH) Signals", ITU-T Recommendation G.7043, July 2004. [ITU-T-G.707] International Telecommunications Union, "Network Node Interface for the Synchronous Digital Hierarchy (SDH)", ITU-T Recommendation G.707, December 2003. [ITU-T-G.709] International Telecommunications Union, "Interfaces for the Optical Transport Network (OTN)", ITU-T Recommendation G.709, March 2003. Author's Addresses Greg Bernstein Grotto Networking Phone: +1-510-573-2237 Email: gregb@grotto-networking.com Diego Caviglia Ericsson Via A. Negrone 1/A 16153 Genoa Italy Phone: +39 010 600 3736 Email: diego.caviglia@(marconi.com, ericsson.com) Richard Rabbat Fujitsu Laboratories of America 1240 East Arques Ave, MS 345 Sunnyvale, CA 94085 United States of America Phone: +1 408-530-4537 Email: richard@us.fujitsu.com Bernstein Expires December 25, 2006 [Page 18]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 Huub van Helvoort Huawei Kolkgriend 38, 1356 BC Almere The Netherlands Phone: +31 36 5315076 Email: hhelvoort@chello.nl Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). Bernstein Expires December 25, 2006 [Page 19]
Internet-Draft Operating VCAT and LCAS with GMPLS June 2006 This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Bernstein Expires December 25, 2006 [Page 20]