Internet Draft Motty (Mordechai) Anavi Document: draft-anavi-tdmoip-00.txt Jonathan (Yaakov) Stein Expires: August 2001 Eitan Schwartz RAD Data Communications February 2001 TDM over IP draft-anavi-tdmoip-00.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 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. Anavi, Stein, Schwartz [PAGE 1] TDM over IP February, 2001 Abstract This document describes a method for transporting multiple time division multiplexed (TDM) digital voice and data signals including timing over IP networks. 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 [2]. Table of Contents 1. Introduction....................................................2 2. TDMoIP - the Concept............................................3 3. Clock Recovery..................................................4 4. Advantages of TDMoIP approach...................................5 5. Frame Format....................................................6 6. References......................................................6 7. Intellectual Property Rights....................................7 8. Acknowledgments.................................................7 9. Contact Information.............................................7 1. Introduction Circuit-based services (e.g. T1/E1, Frame Relay, and ATM) are presently being carried over existing networks. The problem facing many service providers is how to integrate multiple services utilizing a unified infrastructure. Although most data traffic is IP-based, legacy TDM and other circuit-based services must still be supported in order to ensure evolutionary migration to Next Generation Packet Networks. The most popular path to date has been to offer a packet-over-circuit solution, whereby pre-established circuits transport packets across the network. While this works, it is not the most efficient nor scalable solution for networks whose primary payload is IP. Another approach to this problem is to transport the circuit-based traffic over a packet network, as done in VoIP. However, VoIP is limited to the transport of voice traffic, other circuit-based services can not presently be supported. Present VoIP implementations suffer other limitations as well, the most important of these being QoS and signaling. The latter problem Anavi, Stein, Schwartz [PAGE 2] TDM over IP February, 2001 in particular has proven problematic due to the large number of special features supported by the existing telephone network. In this document we describe a method of transporting arbitrary circuit-based services over IP-based networks. This method can support TDM-type traffic (from T1/E1 to SONET speeds) as well as a variety of legacy data services. QoS and voice quality are similar to those of existing circuit-based networks and all signaling features are preserved. 2. TDMoIP - the Concept A T1 frame consists of 24 single byte timeslots and a single synchronization bit, for a total of 193 bits. An E1 frame consists of precisely 32 bytes (256 bits), one of which is used for synchronization and one traditionally reserved for signaling. In both cases frames are transmitted 8000 times per second. Details can be found in ITU-T recommendation G.704. A simplistic implementation of TDMoIP would encapsulate each T1 or E1 frame in an IP packet by tacking on the appropriate header. Since the packets provide the segmentation, the synchronization bit / byte need not be included, and accordingly the payload length is 24 or 31 bytes for T1 or E1 respectively. For reliable connection-oriented service one might consider using TCP/IP, which requires a 20 byte TCP header and a 20 byte IP header, for a total of 40 overhead bytes per packet. A more reasonable alternative would be the real-time transport protocol RTP, with its header of at least 12 bytes, to which one must add an 8 byte UDP header and the IP header, resulting in the same overhead. A 40 byte overhead for a payload of 24 or 31 bytes seems extravagant, but there are at least two solutions to this problem. The first solution involves header compression schemes, such as those of RFC 2507, 2508, and 2509. These schemes reduce the average header length to three bytes, reducing the overhead percentage to between eight and nine percent. The second solution involves grouping together multiple frames into a super-frame before encapsulation. For example, grouping eight T1 (E1) frames results in a payload of 192 (248) bytes, so that the overhead percentage drops to a reasonable 17 (14) percent. Grouping does add a certain amount of buffering delay, but since each frame is only 125 microseconds in duration, this latency is negligible, especially when compared with that of VoIP systems. For example, a super-frame comprised of eight successive frames introduces a one millisecond one way delay, about Anavi, Stein, Schwartz [PAGE 3] TDM over IP February, 2001 half that of the standard 16 Kbps "low delay" encoder (G.728) used in VoIP, and much lower than the 15 millisecond delay of the 8 Kbps encoder (G.729). Simple encapsulation of the raw frames is not the only way of implementing TDMoIP. More sophisticated approaches first encode the TDM data in some other protocol before IP encapsulation. There may be many advantages to thus imposing another layer of protocol between the TDM and the IP. Intermediate encoding may be employed when the natural TDM induced frame sizes are not appropriate, to provide error correction, to enable interoperability with other systems, or to enhance QoS. Whatever the details, it is important to notice that TDMoIP transports the TDM frame without any attempt at interpreting the data. This transparency resembles that of a regular CSU/DSU or digital cross connect (DCC), but now with an IP link to the network. It can be completely oblivious to such TDM internals as time slots, signaling channels, etc. Thus TDMoIP can be used to transport arbitrary T1/E1 or T3/E3 services, even if some of the channels are actually used to carry data, or if the entire frame is an unstructured bit-stream. Similarly the basic TDMoIP concept is easily extended to fractional or channelized T1/E1 systems. In this way, traffic is reduced because only the information carrying bits need be included in the IP packet. 3. Clock Recovery TDM networks are inherently synchronous. In the public switched telephone network and in SONET / SDH networks one node, called the clock master provides a time reference to the other, called the slave. Somewhere in the network there will always be at least one extremely accurate primary reference clock, with long-term accuracy of one part in 1011. This node, whose accuracy is called stratum 1, provides the reference clock to secondary nodes with lower stratum 2 accuracy, and these in turn provide reference clock to stratum 3 nodes. This hierarchy of time synchronization is essential for the proper functioning of the network as a whole. Packets in IP networks reach their destination with delay that has a random component, known as jitter. When emulating TDM on an IP network, it is possible to overcome this randomness by using a "jitter buffer" on all incoming data, assuming the proper time reference is available. The problem is that the original time reference information is no longer available. Anavi, Stein, Schwartz [PAGE 4] TDM over IP February, 2001 In principle there are two different levels of integration of TDMoIP into a T1/E1 network. In the "bypass" scenario a one party might want to transport TDM T1/E1 traffic over another party's network. In such applications both TDMoIP devices SHALL receive time reference from the central offices to which they connect. In the "whole network" scenario, major portions of the primary infrastructure are replaced with TDMoIP networks, and a method of time synchronization is required. IP networks also disseminate clock information through NTP (RFC 1305), but unless the IP network is completely private and dedicated to the TDMoIP link, there will be no connection between the NTP clock and the desired TDM one. In such cases independent time standards MAY be provided to all TDMoIP devices, thus relieving the IP network of the need to send synchronization information. The use of time standards less accurate than stratum 3 is NOT RECOMMENDED since it may result in service impairments. When the provision of accurate local time references is not practical then clock recovery SHOULD be performed based on the rate of arrival of incoming packets using an appropriate `averaging' process that negates the effect of the zero mean random jitter. Conventionally a phase locked loop (PLL) is used for this purpose. 4. Advantages of TDMoIP approach The simplicity of TDMoIP translates into initial expenditure and operational cost benefits. In addition, due to its transparency TDMoIP can support mixed voice, data and video services. It is transparent to both protocols and signaling, irrespective of whether they are standards based or proprietary with full timing support and the capability of maintaining the integrity of framed and unframed DS1 formats. From a service provider point of view, TDMoIP complements VoIP by extending VoIP services transparently from the carrier point-of- presence (POP) to the customer site. This makes it simple for the carrier to deploy larger, scalable VoIP gateways at the POP where resources are available, and provide the customer with a simple TDMoIP Network Termination Unit (NTU). In this way it is unnecessary to deploy complex VoIP gateways at the customer location. Such TDMoIP circuits could then be used to provide additional services, such as PSTN access, Frame Relay, and ISDN. Anavi, Stein, Schwartz [PAGE 5] TDM over IP February, 2001 TDMoIP provides many of the benefits of ATM including low end-to-end delay (as low as 2ms) and maintaining integrity of structured or unstructured T1/E1. Yet TDMoIP is simpler, less expensive and can be carried over commonly available IP and Ethernet networks. In addition TDMoIP may be made more efficient than ATM by adjusting payload size to reduce overhead; the ATM payload is always 48 bytes. Gigabit Ethernet (and 10-Gigabit Ethernet) are rapidly becoming popular for metropolitan-area networks (MAN) and Wide Area Networks (WAN). In particular, Gigabit Ethernet over dark fiber is becoming a popular alternative to SONET and ATM. However, Ethernet is basically a data network technology, and cannot by itself handle voice traffic. TDMoIP empowers Gigabit Ethernet with voice and circuit extension capabilities and therefore can be viewed as a natural complementing technology. Gigabit Ethernet lacks some of the features of the present PSTN. For example, the SONET ring topology is considered very reliable because of its capability to rapidly recovery from a failure or fiber cut. Gigabit Ethernet does not inherently have this capability, but can redirect traffic to an alternative trunk within a few milliseconds. In the case where there is only a single fiber between the switches, protocols such as OSPF can update routing tables within a few seconds and the IP data stream quickly recovers. Another important example relates to QoS. ATM is usually considered the most advanced in this area, having the highest number of defined service level categories. However, today's Gigabit Ethernet switches implement advanced mechanisms to prioritize packets and reserve bandwidth for specific applications. By classifying TDMoIP packets (using 802.1p&q, ToS, and set UDP port numbers) they may be easily identified and prioritized. 5. Frame Format TDMoIP SHALL use a standard UDP/IP frame structure. The Internet Assigned Numbers Authority (IANA) has assigned TDMoIP a user port number of 2142 (0x85E). The payload SHOULD be encoded using AAL2 cells (without cell headers) as defined in ITU-T I.363.2. When channel allocation is static the payload MAY be encoded using AAL1 cells as defined in ITU-T I.363.1. 6. References Anavi, Stein, Schwartz [PAGE 6] TDM over IP February, 2001 ITU-T Recommendation G.704 (10/98) Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 kbit/s hierarchical levels ITU-T Recommendation I.363.1 (08/96) B-ISDN ATM Adaptation Layer (AAL) specification: Type 1 ITU-T Recommendation I.363.2 (11/00) B-ISDN ATM Adaptation Layer (AAL) specification: Type 2 7. Intellectual Property Rights This document is being submitted for use in IETF standards discussions. RAD Data Communications has filed patent applications relating to TDMoIP technology as outlined in this document. 8. Acknowledgments The authors would like to thank Hugo Silberman, Amir Shapira, and Shimon Halevy of RAD Data Communications. 9. Contact Information Motty (Mordechai) Anavi RAD Data Communications 900 Corporate Drive, Mahwah, NJ 07430 USA Phone: +1 201 529-1100 Ext. 213 Email: motty@radusa.com Jonathan (Yaakov) Stein RAD Data Communications 24 Raoul Wallenburg St., Bldg C Tel-Aviv 69719 ISRAEL Phone: +972 3 645-5389 Email: Yaakov_s@rad.co.il Eitan Schwartz RAD Data Communications 900 Corporate Drive Mahwah, NJ 07430 USA Phone: +1 201 529-1100 Ext. 241 Email: eitan@radusa.com Copyright Notice Copyright (C) The Internet Society (date). All Rights Reserved. Anavi, Stein, Schwartz [PAGE 7] TDM over IP February, 2001 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." Anavi, Stein, Schwartz [PAGE 8]