CCAMP Working Group Krishna Pattabhiraman (Editor) Internet Draft Coriolis Networks Expires: April 2002 October 2002 Signaling Requirements for LCAS based Applications draft-krishna-ccamp-lcas-reqts-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. Abstract With LCAS and VCAT, the transport layer is capable of not only providing right-sized data pipes, but also elastic pipes. Fluid transport pipes spur services like frame-relay transport (CIR, EIR) and intelligent COS-aware protection. The popular protocol used to convey control information in SONET networks is GMPLS. There are two aspects of control mechanisms for a connection: call-control and connection-control. Call-control is used to establish a signaling association between two end-points, whereas connection-control is used to setup and modify the attributes (e.g., bandwidth) of an transport connection. This draft deals with signaling requirements for connection-control of elastic pipes. 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. Table of Contents 1. Introduction .............................................. 2 K. Pattabhiraman (Editor) Expires April 2003 [Page 1] Internet Draft LCAS Signaling Requirements October 2002 2. Motivation ................................................ 3 3. Signaling Requirements .................................... 5 4. Summary ................................................... 7 5. Security Considerations ................................... 7 6. References ................................................ 7 7. Appendix A - Applications ................................. 8 7.1. Flexible transport pipe for bursty data traffic ........ 8 7.2. Intelligent Protection (1:N) ........................... 9 8. Authors' Addresses ........................................ 9 9. Full Copyright Statement .................................. 10 1. Introduction SONET was deemed an inefficient medium to transport data. With the rapid advent of data services, new SONET standards like virtual concatenation (VCAT) [G.707] and link capacity adjustment scheme (LCAS) [G.7042] have been developed to provide not only right sized transport pipes, but also elastic (variable sized) pipes. The motivation behind virtual concatenation (VCAT) [G.707] is to equip transport networks like SONET and SDH with the ability to efficiently transport data traffic. The data traffic load is mapped into arbitrary multiples of standard high-order (HO) or low-order (LO) transport channels (e.g., STS-1, STS-3) called members. For example, let there be a group of M STS-1s members called VCG-1 (VC group 1) between two nodes SRC and SNK. The VC group VCG-1 provides a virtual pipe of capacity MxSTS-1 for transporting data between SRC and SNK. Only the end points are aware of the VCAT nature of the path. The intermediate crossconnects switch the tributary STS-1/STS-3cÆs. This is no different than what they do today. However, the endpoints are aware that this path is a VCAT path. The SRC node is responsible of inverse multiplexing the data signal onto the VCAT tributaries. Correspondingly, the SNK node is responsible of recreating the original data signal by concatenating the tributary signals received from different paths. Link Capacity Adjustment Scheme (LCAS) [G.7042] is a mechanism to hitlessly change the capacity for virtually concatenated synchronous payload envelopes (SPEs). The goal is to accommodate situations like changes in capacity requirements or link failure conditions. The basic mechanism allows addition / deletion of member channels to/ from a group of virtually concatenated SPEs between two nodes that have been identified as a single virtual pipe. LCAS is an in-band mechanism using the H4 byte of the SONET header to send the control information across and thus does not require extra K. Pattabhiraman (Editor) Expires April 2003 [Page 2] Internet Draft LCAS Signaling Requirements October 2002 overhead. Since VCAT is a layer 1 mechanism, using layer 1 based messaging for controlling the VCAT group size is the appropriate choice. The following explains briefly the LCAS Add and Delete process: LCAS Add: - SRC sends a CRTL=ADD to SNK on the new member channel. CRTL is a field in the control packet. - The SNK node performs a connectivity check. Some of the checks that are performed are as follows: a. CRC checking of the control packet; b. Differential delay of the new member channel relative to existing member channels are within bounds; c. The BER on the new member channel is within acceptable limits; d. Capacity available at the SNK node. - Upon successful completion of the connectivity check, the SNK node sends back Member Status (MS) = OK for that channel. LCAS Decrease: - SRC sends a CRTL=IDLE to SNK on the unwanted member channel M, and CRTL=EOS on the member channel M-1. EOS is end of sequence indicator and is used to determine the last member of a VC group. - The SNK node sends a MS=FAIL on the deleted member channel and acknowledges the re-sequence event by inverting RA bit in the control packet. The basic LCAS mechanism depends on a handshake mechanism, which causes a dependence of the update latency on the size of the network [KP-LCAS]. Only after multiple RTTs worth of latency, does the SRC node determine if the LCAS operation was a success or not. One of the main reasons for a failure is the delay skew check at the SNK node. However, if the source node intelligently selects the member channel to add to a VCG then the LCAS operation will succeed. This will require information exchange between the SRC and SNK nodes. This draft presents the requirements for a signaling protocol to efficiently support applications using LCAS/VCAT transport networks. This draft however does not present the GMPLS extensions. We will present them in a forthcoming draft. 2. Motivation Deployment of LCAS/VCAT capable devices in the carrier networks will spur new service offerings by the carriers like flexibly-sized K. Pattabhiraman (Editor) Expires April 2003 [Page 3] Internet Draft LCAS Signaling Requirements October 2002 transport pipes. For example, these pipes could be used to directly transport EVPL-like end-to-end ethernet services [MEF]. Flexibly-size pipes means the size of the pipe varies with demand. The carrier can exert policies in the way it's network bandwidth is shared amongst the different flexibly-sized pipes. The carriers can choose to have policies that lends to statistical multiplexing of these flexibly sized pipes - this leads to efficient and profitable way of bandwidth usage - similar to frame-relay networks. Details of this application and others that can potentially use LCAS/VCAT are presented in the appendix. These applications require: - that all the member channels that the carrier intends to use have been preprovisioned between the SRC and SNK nodes; by pre- provisioned member channels, we mean that for these member channels, the path was already set up; - mechanisms to detect change in bandwidth requirement of a VCG. Capacity increase: - Select a member channel from the free pool to assign to the requesting VCG. - Assign the available member channel to the VCG. - Allow the SRC to start sending data for the VCG on the new member channel. Capacity decrease: - Determine the member channel to be removed from the VCG. - Add the member channel to the free pool. - The SRC stops sending data on the removed channel; the SNK node stops using this channel while concatenating. Thus, bandwidth management then effectively involves shuffling unused member channels between the different VCGs between a SRC and a SNK node. This allows for multiple VCGs to exist between a SRC and SNK node whose bandwidths are dynamically changed based on some real-time triggers, without involving any provisioning operations. Depending on the application, the bandwidth adjustments may happen frequently or infrequently. We envisage that the frequency of bandwidth adjustments will invariably depend on the network diameter (or in this case the VCAT path length) - larger the network, slower K. Pattabhiraman (Editor) Expires April 2003 [Page 4] Internet Draft LCAS Signaling Requirements October 2002 the frequency of change. LBM [LBM] claims to extend GMPLS signaling for setting up diversely routed, virtually concatenated circuits (something not possible with GMPLS signaling as it stands, because it does not support diverse routing of components of a given VCAT circuit). LBM draft claims to do so by use of a Circuit ID field to identify a circuit, and an LSP Seq. # field to uniquely identify LSPs concatenated inside of the circuit. However, LBM does not propose any way for the end points to be able to determine which circuits are appropriate to be added to which VCG. So the problem of determining whether a new circuit can, in fact, be added to a VCG is out of the scope of the LBM draft. In the following section, we argue that in order to exploit the advantages of LCAS/VCAT and hence efficiently support new services, there needs to be a tight coupling between the control plane and the layer-1 transport plane. 3. Signaling Requirements In this section, we present some VCAT/LCAS issues that need to be tackled in order to provide efficient services using these protocols. a) Delay Skew A VCAT path is comprised of multiple tributary signals. Each tributary signal has a sequence number. The framer/mapper device at the sink node creates the concatenated signal using the tributary signals of the same sequence number. If the tributary signals arriving from different path having the same sequence number arrive at different times, then the mapper has to wait till all the tributary signals have arrived. In order for the SNK node to successfully recreate the original data signal, the delay skew of the tributaries have to be within the delay skew budget of the snk node. The delay skew budget is determined by the amount of memory that is present in the framer/mapper device. For a bi-directional path, the SRC and SNK nodes needs to be aware of the delay skew budgets at the other end. If it is not aware, then during a LCAS operation, the SRC node (for example) may add a tributary that exceeds the delay skew budget at the SNK node. This will cause a FAIL in the LCAS operation. Without the delay skew budget knowledge, the SRC node might keep picking an ineligible tributary signal. This will hamper the responsiveness to the bandwidth demands. Bi-directional paths not using the same route adds to the complexity. ThatÆs because the delay skew numbers of the VCAT tributary signals at the either end (SRC/SNK) will not be the same. So for example, if SRC node sees a max delay skew of x us in VCAT group, it cannot assume the max delay skew to be x in the SNK node. K. Pattabhiraman (Editor) Expires April 2003 [Page 5] Internet Draft LCAS Signaling Requirements October 2002 Thus, when the SRC node decides to add a tributary (SPE) for a VCAT group, and the tributary happens to be a bi-directional path (i.e., this tributary will be used for bi-directional communication between the SRC and SNK), then the SRC has to check if the tributary signalÆs delay skew relative to the paths at the SNK node is within the SNK node's delay skew budget. b) VCAT/LCAS-aware provisioning This means that the selection of the new tributary signal to be provisioned is done such that the "final" LCAS operation is less likely to fail when this tributary signal is added to the existing VCAT group. c) LCAS/VCAT over packet clouds emulating SONET [PWE] In SONET clouds, the only time delay skew numbers change is when there are link failures or provisioning events. However, if packet clouds are used to emulate SONET, the delay skew numbers could potentially change quite frequently. Let us suppose the packet cloud is able to provide a service {min/max}, which means that the transit delay D thru the packet cloud is always between min and max. This complicates the "admittance control" for tributary signals to a VCAT group. ThatÆs because delay skew is now measured as the difference between min_i with max_j for all i, j, where i and j are member channels. d) A VCAT group does not have mix of different-sized tributary signals. Thus, for example a HO-VCAT signal contains only STS-1s or only STS-3cs. It will not contain a mix of STS-1 and STS-3c. The question now is, how does a node other than the SRC and SNK know what is tributary size for a VCAT-group? The concerned node may be for example the bandwidth manager in the network. If the bandwidth management between the VCG is done at the end nodes itself, then the key information that need to be exchanged between the SRC and the SNK nodes are: - Delay skew information of each member signal between the SRC and SNK nodes. On the other hand, if the bandwidth management is performed at a domain bandwidth manager node then, the information maintained at this node is: - Delay skew information of each member signal between the SRC and the SNK nodes; - Base tributary signal (STS1 or STS3c for example) making up each VCG. K. Pattabhiraman (Editor) Expires April 2003 [Page 6] Internet Draft LCAS Signaling Requirements October 2002 As things stand today, setting up of new circuits with the objective of combining them into existing VCGs would be a trial and error process. An NMS or intelligent control plane would setup a new circuit, and the LCAS process between the end point framers would determine if this new circuit meets the differential delay bounds for the VCG for which it was proposed. If not, the process would have to be repeated, until a circuit meeting the constraints was found. 4. Summary This draft presents applications that are envisioned to be deployed using LCAS/VCAT transport networks. These applications require almost real-time adjustment in bandwidth. In order to use a handshake- protocol[KP-LCAS] like LCAS for successfully adjusting bandwidth in real-time, certain information has to be present at the node initiating the adjustment. This draft presents an overview of the VCAT/LCAS issues that has to be tackled by exchanging information between the nodes participating in the bandwidth adjustment. 5. Security Considerations TBD. 6. References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [G.7042] ITU-T Recommendation G.7042/Y.1305, "Link capacity adjustment scheme for virtual concatenated signals" (International Telecommunication Union), November 2001. [G.707] "Network node interface for the synchronous digital hierarchy", (International Telecommunication Union), March 2001. [LBM] E. Mannie et. al, "LSP Bandwidth Modification (LBM) for TDM Networks", draft-mannie-ccamp-gmpls-lbm-tdm- 01.txt. [KP-LCAS] K. Pattabhiraman et. al., "Justification for a Faster and Lightweight Link Capacity Adjustment Scheme for K. Pattabhiraman (Editor) Expires April 2003 [Page 7] Internet Draft LCAS Signaling Requirements October 2002 SONET/SDH Virtually Concatenated SPEs", T1X1.5/2001- 212, Sep 2001. [PWE] IETF PWE Working Group. [MEF] "Ethernet Layer 2 Service Definitions", Metro Ethernet Forum. 7. Appendix A - Applications This section describes a couple of example new applications that can be deployed over a transport network using LCAS and an enhanced GMPLS. 7.1. Flexible transport pipe for bursty data traffic In the current networks today, data devices like routers are connected via fixed provisioned pipes. Data traffic is inherently bursty, so the peak traffic between two data devices may exceed the average traffic by a significant amount. Any burst of traffic can last from a few milliseconds to a few minutes depending on the cause. The network planners deal with the bursty traffic with fixed provisioned pipes in some of the following ways: a.) Provision for the peak: The bandwidth provisioned can accomodate the peak traffic burst expected. This results in no packet loss between the data devices but results in inefficient use, thus waste of bandwidth resources b) Traffic buffering: The data devices may include a configurable packet buffer to handle bursts and prevent loss of data. The effectiveness of this method depends on the size of the buffer, thus being either a very expensive proposition or not effective in case of extended bursts. c) Advanced Queuing: The data devices separate traffic based on Class of Service and selectively drop lower priority packets to handle the burst condition. If the bandwidth between the two data devices were elastic i.e. change according to bursts, then that would be an efficient way of handling bursts of data. The only impediment in such a solution is the time required to change the bandwidth allocation as compared to the size of the burst. For example, if the burst lasts for 5 seconds but the bandwidth increment feature takes 5 minutes, then this method will fail. Fast bandwidth adjustment using LCAS, pre-provisioned pipes and the K. Pattabhiraman (Editor) Expires April 2003 [Page 8] Internet Draft LCAS Signaling Requirements October 2002 methods described above are quick enough to provide bandwidth adjustment in a smaller timescale than the size of the burst. This allows carriers to offer {CIR, PR} contract for each transport pipe where CIR is the committed information rate and PR is the peak rate. The bandwidth allocated initially equals the CIR and PR size of bandwidth is added/deleted dynamically to/from the pre-provisioned pipe between the data devices. In addition, use of statistical-multiplexing at the transport layer vastly improves efficiencies of data transport. For example, a network carrier could pre-provision paths of certain capacity C between SRC and SNK. This capacity could then be statistically shared across the transport channels going between the end points SRC and SNK. This way, the carrier could sell more capacity than it could otherwise sell using a fixed pipe model. This reduces the expense to the carrier by improving efficiencies of data transport over their own SONET/Layer 2 network. 7.2. Intelligent Protection (1:N) The transport networks of today and mesh networks of tomorrow provide different levels of protection for fixed provisioned connections -- from 1:1 protection to 1:N protection. Each of these methods results in bandwidth being reserved for protection and not utilized. By improving the speed of LCAS provisioning using the methods described in this draft, the protection bandwidth can be utilized for best effort traffic. When the service provider loses a higher CoS pipe with protection, the protection bandwidth can be deleted dynamically from the best effort traffic pipes and added dynamically to the right VCG serving the higher CoS traffic. The decision of which VT/STS-1 to delete from the VCG and use as protection bandwidth depends on the knowledge obtained using enhanced GMPLS signaling methods. 8. Authors' Addresses Krishna Pattabhiraman Coriolis Networks Email: krishna@coriolisnet.com Vishal Sharma Metanoia, Inc. Email: v.sharma@ieee.org Inder Monga Nortel Networks Email: imonga@nortelnetworks.com K. Pattabhiraman (Editor) Expires April 2003 [Page 9] Internet Draft LCAS Signaling Requirements October 2002 Cheenu Srinivasan Parama Networks, Inc. Email: mailto:cheenu@paramanet.com 9. Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. K. Pattabhiraman (Editor) Expires April 2003 [Page 10]