Internet Draft PPP Extensions Working Group N. Jones, INTERNET DRAFT Lucent Microelectronics Category: Informational C. Murton, Expires: December 2000 Nortel Networks June 2000 Extending PPP over SONET/SDH, with virtual concatenation, high order and low order payloads <draft-ietf-pppext-posvcholo-02.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "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 memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this draft is unlimited. Jones Expires December 2000 1 Internet Draft POS with VC, HO & LO June 2000 Abstract The RFC 1661 Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. The RFC 1662 PPP in HDLC-like Framing [2] and RFC 2615 PPP over SONET/SDH (POS) [3] documents describe the use of PPP over Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits. This document proposes an extension to the mapping of PPP into SONET/SDH defined in RFC 2615 PPP over SONET/SDH (POS) [3], to include use of SONET/SDH SPE/VC virtual concatenation and use of both high order and low order payloads. The objective of this document is to provide an update of the status of this proposal in the telecommunications standards definition process. The current situation is that work in ANSI, ETSI & ITU-T has resulted in a global standard for virtual concatenation. This document is the product of the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Table of Contents 1. Introduction................................................3 2. Rate Comparisons............................................4 3. Current Technologies........................................6 4. Virtual Concatenation Description...........................7 5. Emerging Benefits...........................................8 6. Standards Status............................................9 7. Security Considerations....................................10 8. References.................................................10 9. Acknowledgments............................................11 10. Author's Addresses.........................................11 11. Copyright Notice...........................................11 Jones Expires December 2000 2 Internet Draft POS with VC, HO & LO June 2000 1. Introduction A broad consensus has emerged among major market researchers indicating, that while voice traffic will continue to grow at a moderate clip, data will come to dominate most networks by the years 2002-2005. Moreover, recent network studies [4][5] have shown that this data traffic is overwhelmingly dominated by relatively short IP datagrams transported across network sessions that are in the tens of seconds duration range. In the face of the above trends, it is becoming increasingly more obvious that, although the existing SONET/SDH transport structures are sufficiently optimized to support traditional TDM voice type applications, they are bandwidth inefficient when confronted with the inherently bursty, statistical characteristics of data applications. In addition, new applications requiring transport in SONET/SDH concatenated payload envelopes run the risk of being unsupported. This is a result of the non-standardization and, consequently, non- availability of particular rates (e.g. SONET STS-2c, STS-4c, STS-24c or SDH VC-2-2c) or the unavailability in practice of particular concatenation rates even if they were standardized (e.g., STS-12c in SONET or VC-4-4c in SDH). Furthermore, even if the concatenated rates were defined in standards and supported by the network operator, the practical availability of such payload coverage is often dependent upon the non-fragmentation (i.e., the availability of contiguous time slots) of bandwidth in the SONET/SDH network. The SONET/SDH standards have been updated to include the mechanism for SONET/SDH payload virtual concatenation. This scheme can provide right sized link channelisation for ring and other SONET/SDH network topologies. The ITU-T has developed a standard for SDH High Order and Low Order payload Virtual Concatenation. This global standards development has been aligned with ANSI T1X1 (SONET) and ETSI. Further standards work on the subject of Variable Bandwidth Allocation (VBA) will make the dynamic re-sizing and hitless re- configuration of virtually concatenated paths possible. Jones Expires December 2000 3 Internet Draft POS with VC, HO & LO June 2000 For the convenience of the reader, the equivalent terms are listed below: SONET SDH --------------------------------------------- SPE VC VT (1.5/2/6) Low order VC (VC-11/12/2) STS-SPE Higher Order VC (VC-3/4/4-Nc) STS-1 frame STM-0 frame (rarely used) STS-1-SPE VC-3 STS-1 payload C-3 STS-3c frame STM-1 frame, AU-4 STS-3c-SPE VC-4 STS-3c payload C-4 STS-12c/48c/192c frame STM-4/16/64 frame, AU-4-4c/16c/64c STS-12c/48c/192c-SPE VC-4-4c/16c/64c STS-12c/48c/192c payload C-4-4c/16c/64c This table is an extended version of the equivalent table in RFC 2615 [3]. Additional information on the above terms can be found in Bellcore GR-253-CORE [6], ANSI T1.105 [7], ANSI T1.105.02 [8] and ITU-T G.707 [9]. 2. Rate Comparisons The original tributary bit rates chosen for SONET/SDH were intended for voice services. These rates have a coarse granularity, require duplicate network resources for protection and are not a good match to LAN bandwidths. Currently supported WAN bandwidth links for PPP: ANSI ETSI ----------------------------------------------------- DS1 (1.5Mbit/s) E1 (2Mbit/s) DS3 (45Mbit/s) E3 (34Mbit/s) STS-3c (150Mbit/s) STM-1 (150Mbit/s) STS-12c (620Mbit/s) STM-4 AU-4-4c (620Mbit/s) STS-48c (2.4Gbit/s) STM-16 AU-4-16c (2.4Gbit/s) Note that AU-4-4c and AU-4-16c are not generally available in SDH networks at present. With virtual concatenation the following additional WAN bandwidth links would be available for PPP : SONET VT-1.5-nv (n=1-64) 1.6Mbit/s-102Mbit/s STS-1-nv (n=1-64) 49Mbit/s-3.1Gbit/s STS-3c-nv (n=1-64) 150Mbit/s-10Gbit/s Jones Expires December 2000 4 Internet Draft POS with VC, HO & LO June 2000 SDH VC-12-nv (n=1-64) 2.2Mbit/s-139Mbit/s VC-3-nv (n=1-64) 49Mbit/s-3.1Gbit/s VC-4-nv (n=1-64) 150Mbit/s-10Gbit/s Higher levels of virtual concatenation are possible, but not necessarily useful. At present CONTIGUOUS concatenation caters for 4 or 16 VC-4s. Bit rates for Transparent LAN Services (TLS) are typically 10Mbit/s and 100Mbit/s. Bit rates of 1Gbit/s are also becoming more and more popular. Also other services (e.g. ATM cells stream) may vary from a few Mbit/s to several tens of Mbit/s. However there are no direct mappings for the transport of such bit rates over SONET/SDH. In order to transport the services mentioned above via a SONET/SDH transport network there is no match in the bandwidth granularity. Table 1 and Table 2,respectively depict the SONET/SDH transport structures that are currently available to carry various popular bit rates. Each table contains three columns. The first column shows the bit rates of the service to be transported. The next column contains two values: a) the logical signals that are currently available to provide such transport and, b) in parenthesis, the percent efficiency of the given transport signal without the use of virtual concatenation. Likewise, the final column also contains two values: a) the logical signals that are currently available to provide such transport and, b) in parenthesis, the percent efficiency of the given transport signal with the use of virtual concatenation. Note, that Table 1, contains SONET transport signals with the following effective payload capacity: VT-1.5 SPE = 1.600 Mbit/s, STS-1 SPE = 49.536 Mbit/s, STS-3c SPE = 149.760 Mbit/s, STS-12c SPE = 599.040 Mbit/s and STS-48c SPE = 2,396.160 Mbit/s. Table 1. SONET Virtual Concatenation Bit rate Without With ------------------------------------------------------------- 10Mbit/s STS-1 (20%) VT-1.5-7v (89%) 25Mbit/s STS-1 (50%) VT-1.5-16v(98%) 100Mbit/s STS-3c (67%) STS-1-2v (100%) or VT-1.5-63v (99%) 200Mbit/s STS-12c(33%) STS-1-4v (100%) or STS-3c-2v (66%) 1Gbit/s STS-48c(42%) STS-3c-7v (95%) Jones Expires December 2000 5 Internet Draft POS with VC, HO & LO June 2000 Similarly, Table 2, contains SDH transport signals with the following effective payload capacity: VC-11 = 1.600 Mbit/s, VC-12 = 2.176 Mbit/s, VC-2 = 6.784 Mbit/s, VC-3 = 48.960 Mbit/s, VC-4 = 149.760 Mbit/s and VC-4-4c = 599.040 Mbit/s. Table 2. SDH Virtual Concatenation Bit rate Without With ------------------------------------------------------------- 10Mbit/s VC-3 (20%) VC-12-5v (92%) 25Mbit/s VC-3 (50%) VC-12-12v (96%) 100Mbit/s VC-4 (67%) VC-3-2v (100%) or VC-12-46v (100%) 200Mbit/s VC-4-4c(33%) VC-3-4v (100%) or VC-4-2v (66%) 1Gbit/s VC-4-16c(42%) VC-4-7v (95%) The only currently supported SONET/SDH SPE/VCs in RFC 2615 [4] are the following: SONET SDH ---------------------------------------- STS-3c-SPE VC-4 STS-12c-SPE VC-4-4c STS-48c-SPE VC-4-16c STS-192c-SPE VC-4-64c Note that VC-4-4c and above are not widely supported in SDH networks at present. 3. Current Technologies Two existing standard technologies for making use of multiple physical paths to build a single logical link are Multi-link PPP (ML-PPP RFC 1990 [10]) and Inverse Multiplexing for ATM (IMA af-phy- 0086.001 [11]). These approaches use frame/cell level load balancing and typically use multiple T1/E1 paths to build a link. Virtual concatenation uses SONET/SDH SPE/VC directly and therefore does not have the inefficiency of mapping into asynchronous (T1/T3) or plesiochronous (E1/E3) payload first. In addition since virtual concatenation is a byte level inverse multiplexing technique, it has the characteristics of right sized bandwidth, improved granularity, cost, low delay, low jitter, re-use of protection bandwidth and high efficiency payload mapping. This makes it a suitable physical layer for a single PPP link. Note that virtual concatenation can also be of benefit for ATM for much the same reasons. SONET/SDH virtual concatenation operates at the physical layer below PPP. The main objective of virtual concatenation is to provide a Jones Expires December 2000 6 Internet Draft POS with VC, HO & LO June 2000 logical mesh of multiple right sized channels over a SONET/SDH network. It is therefore independent of any higher layer schemes for providing equal cost multi-path routing or load balancing. 4. Virtual Concatenation Description This section describes Concatenation of Virtual Containers and in particular describes Virtual Concatenation. Concatenation is a method for the transport, over SONET/SDH networks, of a payload of a bandwidth greater than the capacity of the information structure currently defined in standards. For example to transport a signal of bandwidth equivalent to four VC-4s the frame structure would be VC-4-4c. Concatenation is defined in ITU-T recommendation G.707 [9] as "A procedure whereby a multiplicity of Virtual Containers is associated one with another with the result that their combined capacity can be used as a single container across which bit sequence integrity is maintained". Two types of concatenation are proposed: contiguous and virtual. Contiguous concatenation Contiguous concatenation uses a concatenation indicator in the pointer associated with each concatenated frame to indicate that the SPE/VC with which the pointers are associated are concatenated. For example, four VC-4s contiguously concatenated in an information structure would have a data rate of VC-4-4C. The resulting signal has one valid path overhead (9-byte column) and three 9-byte columns of fixed stuff. The four payloads are byte interleaved in the VC-4- 4c payload area. For contiguously concatenated payload to pass through a network, all intermediate nodes must support contiguous concatenation. Virtual Concatenation Many installed network elements in SONET/SDH networks cannot support contiguous concatenation. The processing in these NEs is limited to processing only individual SPE/VC. To implement contiguous concatenation in such networks would require extensive hardware upgrade of the equipment and would be prohibitively expensive. Virtual Concatenation is one way of overcoming this problem. The main aim of virtual concatenation is to provide the SONET/SDH NEs at both ends of the signal path with the capability of sending/receiving individual SPE/VC that are associated in a concatenated group. In this way the cost of transporting concatenated signal is confined to the up-grade costs at the ends of the path. These cost are likely to be significantly lower than up- grading a whole network to handle contiguously concatenated signals. Jones Expires December 2000 7 Internet Draft POS with VC, HO & LO June 2000 At the sending end it will be necessary to provide each SPE/VC with information about its concatenated group identity and its position/sequence within the group, and to give each its own POH for processing in the intermediate nodes in the network. At the receiving end the equipment must be capable of identifying a SPE/VC as belonging to a particular concatenated group and identifying its position/sequence within that group. Because of the likelihood of different propagation and processing delays for each of the individual SPE/VC, it will be necessary for the receiving end equipment to provide buffers to store the incoming data until the latest SPE/VC arrives, when re-alignment can be performed. One method of providing group identification is to use the J1 byte (Path Trace). If each concatenated group used a different path trace identifier then the receiving equipment will know that a particular VC belongs to that group. The information of what sequence/position a SPE/VC has within the group must be conveyed in the POH. The receiving end will process this information and re-assemble the SPE/VC in the correct order. The difference in the arrival times at the receiver of given SPEs/VCs in a virtually concatenated group is known as the Differential Delay. It will be necessary for the receiving equipment to measure this parameter and to detect if it has gone beyond the range of the buffers, which have been provided to re-align the incoming data. Network Management of the virtually concatenated signal will not require the network equipment to be modified since the NEs are processing essentially standard SPE/VC. 5. Emerging Benefits The main objective of virtual concatenation is to provide multiple right sized channels over a SONET/SDH network. The benefit of virtual concatenation to PPP is the ability to provide channels in a SONET/SDH network that are more appropriate for IP. The advantages of these channels are bandwidth granularity, right sized capacity, efficient mapping into SONET/SDH SPE/VC, traffic scalability and channelized high capacity SONET/SDH interfaces. The characteristics of virtually concatenated links, which provide for bandwidth reduction in the event of a path failure, are a good match for Differentiated Services. The reason for this is that the loss of bandwidth will effect the lower priority traffic first and should allow the higher priority traffic to continue passing over the link. Jones Expires December 2000 8 Internet Draft POS with VC, HO & LO June 2000 Another benefit of virtual concatenation is the ability to add or remove a SPE/VC from the group without taking a PPP link using the group Out Of Service. The change in bandwidth should take place in a few milli-seconds, depending on the physical distance between the two ends of the link. Virtual concatenation could make better use of SONET/SDH path protection bandwidth. Consider a single path protected 45Mbit/s or 34Mbit/s circuit. The SONET/SDH bandwidth needed to support this would involve using two STS-1/VC-3s. When virtual concatenation is applied to this situation, a link of 100Mbit/s can be provided. In the event of a path failure this would be reduced to 50Mbit/s. 6. Standards Status ITU-T (SG13/SG15), ANSI T1X1 and ETSI TM1/WP3 have developed global standards for SONET/SDH High Order and Low Order payload Virtual Concatenation. These changes will appear in the following standards: ITU-T G.803 Architecture of transport networks based on the synchronous digital hierarchy (SDH) ITU-T G.707 Network Node Interface for the Synchronous Digital Hierarchy (SDH) ITU-T G.783 Characteristics of Synchronous Digital Hierarchy (SDH) Equipment Functional Blocks ANSI T1.105 Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats ANSI T1.105.02 Synchronous Optical Network (SONET) - Payload Mappings ETSI EN 300 417-9-1 Transmission and Multiplexing (TM) Generic requirements of transport functionality of equipment Part 9: Synchronous Digital Hierarchy (SDH) concatenated path layer functions. Subpart 1: Requirements Work in ITU-T, ANSI T1X1 and ETSI TM1/WP3 has ensured global standards alignment. The completion of a standard for SONET/SDH SPE/VC virtual concatenation means it has become appropriate to consider the use of this standard for PPP. This could take the form of a backward compatible update to RFC 2615 [3]. Jones Expires December 2000 9 Internet Draft POS with VC, HO & LO June 2000 7. Security Considerations This document is for information only. Any protocol related documents that arise from it would contain security consideration. 8. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC 1661, Daydreamer, July 1994. [2] Simpson, W., Editor, "PPP in HDLC-like Framing, "RFC 1662, Daydreamer, July 1994. [3] Malis, A. & Simpson, W., "PPP over SONET/SDH, "RFC 2615, June 1999. [4] K. Thompson, G. Miller, and R. Wilder, "Wide Area Internet Traffic Patterns and Characteristics" IEEE Network, Nov 1997. http://www.vbns.net/presentations/papers/MCItraffic.ps [5] K Claffy, Greg Miller, and Kevin Thompson, "The nature of the beast: Recent traffic measurements from an Internet backbone", INET'98 Conference, April 1998. http://www.caida.org/Papers/Inet98/index.html [6] Bellcore Publication GR-253-Core "Synchronous Optical Network (SONET) Transport Systems: Common Generic Criteria" January 1999 [7] American National Standards Institute, "Synchronous Optical Network (SONET) - Basic Description including Multiplex Structure, Rates and Formats" ANSI T1.105-1995 [8] American National Standards Institute, "Synchronous Optical Network (SONET) - Payload Mappings" ANSI T1.105.02-1998 [9] ITU-T Recommendation G.707 "Network Node Interface for the Synchronous Digital Hierarchy" 1996 [10] Sklower, K. et al., "The PPP Multilink Protocol (MP)" RFC 1990, August 1996 [11] Inverse Multiplexing for ATM (IMA) Specification version 1.1 af-phy-0086.001, March 1999 Jones Expires December 2000 10 Internet Draft POS with VC, HO & LO June 2000 9. Acknowledgments Huub van Helvoort, Maarten Vissers (Lucent), Paul Langner (Lucent Microelectronics), Trevor Wilson (Nortel), Mark Carson (Nortel) and James McKee (Nortel) for their contribution to the development of virtual concatenation of SONET/SDH payloads. 10. Author's Addresses Nevin Jones Lucent Technologies Microelectronics Group 600 Mountain Avenue Murray Hill, New Jersey 07974 USA Email: nrjones@lucent.com Chris Murton Nortel Networks Harlow Laboratories London Road, Harlow, Essex, CM17 9NA UK Email: murton@nortelnetworks.com 11. Copyright Notice Copyright (C) The Internet Society 2000. 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 organisations, 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. Jones Expires December 2000 11