CCAMP Working Group G. Bernstein Internet Draft Grotto Networking Updates: RFC 3946 D. Caviglia Proposed Category: Standards Track Ericsson Expires: September 2006 R. Rabbat Fujitsu March 6, 2006 Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme with Generalized Multi-Protocol Label Switching (GMPLS) draft-bernstein-ccamp-gmpls-vcat-lcas-02.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 September 6, 2006. Abstract This document describes the use of the Generalized Multi-Protocol Label Switching (GMPLS) control plane in conjunction with the Virtual Bernstein Expires September 6, 2006 [Page 1]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 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. VCAT/LCAS Scenarios and Specific Requirements..................3 2.1. Multiple VCAT Groups per GMPLS Endpoint...................4 2.2. Component Signal Configuration Requirements...............4 2.3. Discovery of Interface Capability.........................5 2.4. VCAT Operation With or Without LCAS.......................5 2.5. Incremental Construction of a VCG.........................5 3. GMPLS Mechanisms for Signaling VCAT/LCAS.......................6 3.1. Co-Routed Signals.........................................6 3.1.1. One-shot Setup of Co-Routed Signal...................6 3.1.2. Incremental Setup of Co-Routed Signal................7 3.1.3. Removing a Component Signal..........................7 3.1.4. Removing Multiple Component Signals in One Shot......8 3.1.5. Use of multiple LSPs for Co-Routed Circuits..........8 3.1.6. Teardown of Whole VCG................................8 3.2. Diversely Routed Signals..................................8 3.2.1. Association Object...................................9 3.2.1.1. Format..........................................9 3.2.2. Recap of Setup Using Diversely Routed Components....10 3.2.3. Recap of Reduction/Teardown Using Diversely Routed Components.................................................10 3.2.4. Update and Upgrade of Existing VCAT Groups..........10 3.2.5. One LSP per Circuit.................................10 4. IANA Considerations...........................................11 5. Security Considerations.......................................11 6. Contributors..................................................12 7. Acknowledgments...............................................12 APPENDIX A: An Overview of VCAT and LCAS.........................13 A.1. VCAT Signals and Components..............................13 A.2. VCAT Capabilities and Limitations........................13 A.3. The LCAS Protocol........................................14 Bernstein Expires September 6, 2006 [Page 2]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 APPENDIX B: Carrier Perspective on VCAT/LCAS Application Areas...15 B.1. VCAT Advantages..........................................15 B.1.1. Right Sizing Bandwidth..............................15 B.1.2. Bandwidth Efficiencies in a Mesh Network............15 B.1.3. Minimizing Restoration Impact.......................15 B.1.4. Modify Component Routing............................16 B.2. LCAS Advantages..........................................16 B.2.1. Graceful Degradation................................16 B.2.2. Dynamic Adjustment..................................16 B.2.3. Painless Re-Grooming................................16 8. References....................................................18 8.1. Normative References.....................................18 8.2. Informative References...................................19 Author's Addresses...............................................19 Intellectual Property Statement..................................20 Disclaimer of Validity...........................................20 Copyright Statement..............................................21 Acknowledgment...................................................21 1. Introduction This document describes the 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 and diversely routed circuits that are members of the same VCAT group and to resize those using LCAS. We also identify some capabilities that would be nice to have through advertising OSPF-TE. The actual advertisement is currently TBD. 2. 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. Bernstein Expires September 6, 2006 [Page 3]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 2.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 or LCAS-capable. 2.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 differ are link-disjoint over at least one link of the route. The intent here is additional resilience and graceful degradation in the case of failure (note that differential delay may be a limiting factor). 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 is a limiting factor). Bernstein Expires September 6, 2006 [Page 4]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 2.3. Discovery of Interface Capability o Discovering VCAT: VCAT sources can only establish VCGs with VCAT capable sinks. Hence the VCAT capabilities of a PDH, SDH, or OTN path termination points may need to be known before the signaling of the individual member LSPs can start. Currently there is no support for the discovery of VCAT or LCAS a priori, i.e., via routing information. Instead, if a network operator tries to signal a co-routed VCAT group, if the interface does not support it, then RFC 3946 states that the receiver node MUST generate a PathErr message with a "Traffic Control Error/ Service unsupported" indication. If the VCAT group is made up of diversely routed LSPs, each with carrying one element of the group, there is no specification of the error code to be used. TBD -- It may be useful to have a specific error code concerning "VCAT not supported". o Discovering LCAS: LCAS offers additional functionality between VCAT capable sources and sinks. Hence the LCAS capabilities of VCAT enabled path termination points can be useful to know in advance of component signal setup. Currently there is no mechanism to check a priori that an ingress or egress is LCAS capable until after the VCG has been established and LCAS is invoked to dynamically resize the VCG. This may be a problem as this information may not be known until the VCG has been put in service. TBD -- It may be useful to have this information advertised and it may be good to have a specific error code "LCAS not supported" in the case LCAS is used on an interface that is not LCAS enabled. 2.4. VCAT Operation With or Without LCAS VCAT capabilities may be present with or without the presence of LCAS, hence GMPLS mechanisms for the establishment and removal of VCAT groups SHALL be equally applicable in the presence or absence of the LCAS. 2.5. Incremental Construction of a VCG In some cases, it may not be possible to set up the VCG in one shot. This may be the case for example when hardware cannot match the individual members at sink and source in the inverse multiplexing function. Therefore support for VCAT in GMPLS SHOULD allow incremental setup of the individual members of the VCG. Bernstein Expires September 6, 2006 [Page 5]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 3. 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, mainly for diversely routed paths and in support of the LCAS procedure. We also discuss the advertising of bandwidth availability to the client layer using OSPF-TE [RFC3630], [RFC4202] and [RFC4203]. Section 3.1. is included for informational purposes only. It describes existing procedures and was included for completeness and for reference. Section 3.2. describes new procedures proposed to support diversely routed VCAT groups. When possible it reuses any applicable existing procedures from section 3.1. 3.1. Co-Routed Signals Note that this section is for informational purposes only. The existing RFCs support co-routed signal setup using the NVC field as explained in section 2.1 of RFC 3946 [RFC3946bis]. In this case, one LSP will be 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. We'll outline the one-shot and incremental setup. Let's explain the procedure based on an example of setting up an VC4- 7v in SDH (corresponding to STS-3c-7v SONET) VCAT group. 3.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 and SONET labels in turn have to be defined: an explicit ordered list of all labels (32-bit values of the Generalized Label object) in the concatenation is given. 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). Bernstein Expires September 6, 2006 [Page 6]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 When the MT field is larger than 1, the list includes labels for the components of each of the group. Note that full Refresh messages (using Path) carry all the information and parameters explained above whereas Summary Refresh messages will only carry the Message IDs. Full Path Refresh messages are NOT end-to-end signaling messages. 3.1.2. Incremental Setup of Co-Routed Signal In some cases, it may be necessary to set up components individually. One example of this requirement is when the hardware that supports VCAT can only add VCAT elements one at a time or cannot match automatically the elements at the ingress and egress for the purposes of inverse multiplexing. The serial or incremental setup solves this problem. In order to accomplish incremental setup, and 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 one label is included. At each of the next iterations, NVC is set to (NVC +1), one more label is added to the ordered list of labels (in the Path or Resv message). A node that receives the message that contains changed fields will process the full Path message and based on the new value of NVC, it will add a component signal to the VCAT group, and switch the new timeslot based on the new label information. Note that if a new upstream label is required, this label must be added to the PATH message. If only a downstream label is required, then the upstream label is unchanged and a downstream label is received in the RESV message. Following the addition of the new label to the LSP, LCAS is used in- band to add the new label into the existing VCAT group. LCAS signaling for this is described in [ITU-T-G.7042]. 3.1.3. Removing a Component Signal The procedure is similar to 3.1.2. The LCAS step is taken first though as follows. First, the label to be dropped is taken out of the group using LCAS signaling (in-band). LCAS signaling is described in [ITU-T-G.7042]. Bernstein Expires September 6, 2006 [Page 7]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 In this case, the NVC value is decremented by 1 and a label is removed from the ordered list. This is not supported 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. 3.1.4. Removing Multiple Component Signals in One Shot The procedure is similar to 3.1.3. In this case, the NVC value is changed to the new value and all relevant labels for the components to be torn down are removed from the ordered list. This is also not supported for VCAT-only interfaces as removing one component of the VCG will tear down the whole group. 3.1.5. Use of multiple LSPs for Co-Routed Circuits It is possible to use as many LSPs to subtend the co-routed circuits. If this is the case, the procedure outlined in the following section can be applied directly here. The Association object as discussed in this section is used to indicate the VCG association type. 3.1.6. Teardown of Whole VCG LCAS signaling is used inband to remove the labels associated with the LSP from the group. LCAS signaling is defined in [ITU-T-G.7042]. Following the removal of the LSP from the group, the LSP is deleted by using deletion procedures of [RFC 3473] (e.g., the deleting ingress LSR -egress LSR respectively- sends a Path -Resv message respectively- with Admin_Status marked for the LSP being removed). 3.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 Bernstein Expires September 6, 2006 [Page 8]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 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. 3.2.1. Association Object The feature that needs to be added is the functionality to associate the corresponding components. For this purpose, we propose the use of the Association Object. The association object was defined in [E2E-RECOVERY] to associate working and recovery LSPs. We expect a diversely routed VCG to use a number of routes R <= VCG size, as some routes may be the same for several components. We should then set up R LSPs. For a bin of c components using the same route, we set up the LSP with a value NVC = c as explained in 1.B and 1.C. To be able to associate the LSPs, the SESSION object MUST be the same for all LSPs (also indicates that the same Tunnel ID is used for all the LSPs). The LSP ID, however, MUST be different to distinguish between the LSPs. The Association ID 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. 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. 3.2.1.1. Format Association Type: 16 bits Value Type ----- ---- Bernstein Expires September 6, 2006 [Page 9]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 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. 3.2.2. Recap of Setup Using Diversely Routed Components For every route R, use procedure outlined in 3.1.1. or 3.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]. 3.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 3.1.3. or 3.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. 3.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. 3.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. Bernstein Expires September 6, 2006 [Page 10]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 4. 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]. 5. 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 September 6, 2006 [Page 11]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 6. 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 Huub van Helvoort (Huawei) Kolkgriend 38, 1356 BC Almere The Netherlands Phone: +31 36 5315076 Email: hhelvoort@chello.nl 7. Acknowledgments The authors would like to thank Maarten Vissers and Adrian Farrel for extensive reviews and contributions to this draft. Bernstein Expires September 6, 2006 [Page 12]
Internet-Draft Operating VCAT and LCAS with GMPLS March 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 [BCR05], [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 types Bernstein Expires September 6, 2006 [Page 13]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 in reference [BCR05] 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 [BCR05] and [Hel05]. Bernstein Expires September 6, 2006 [Page 14]
Internet-Draft Operating VCAT and LCAS with GMPLS March 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 September 6, 2006 [Page 15]
Internet-Draft Operating VCAT and LCAS with GMPLS March 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 September 6, 2006 [Page 16]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 components from the VCG and releasing the unused resources from the network. Bernstein Expires September 6, 2006 [Page 17]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 8. References 8.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. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 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. [RFC4202] Kompella, K. and Y. Rekhter (Eds.), "Routing Extensions in Support of Generalized Multi-protocol Label Switching", RFC 4202, October 2005. [RFC4203] Kompella, K. and Y. Rekhter (Eds.), "OSPF Extensions in Support of Generalized Multi-protocol Label Switching", RFC 4203, October 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. Bernstein Expires September 6, 2006 [Page 18]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 8.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. [BCR05] Bernstein, G., Caviglia, D. and R. Rabbat, "VCAT/LCAS in a Clamshell", to be published, available at http:// www.grotto-networking.com/pages/VCAT-in-a-Clamshell- DRAFT.pdf, October 2005. [BRS04] Bernstein, G., Rajagopalan, B. and D. Saha, "Optical Network Control: Architecture, Protocols", Addison- Wesley, 2004. [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 Bernstein Expires September 6, 2006 [Page 19]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 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 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 Bernstein Expires September 6, 2006 [Page 20]
Internet-Draft Operating VCAT and LCAS with GMPLS March 2006 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). 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 September 6, 2006 [Page 21]