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


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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

Anavi, Stein, Schwartz                                        [PAGE 1]

                             TDM over IP                February, 2001


   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
   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

   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
   Phone: +1 201 529-1100 Ext. 213

   Jonathan (Yaakov) Stein
   RAD Data Communications
   24 Raoul Wallenburg St., Bldg C
   Tel-Aviv 69719
   Phone: +972 3 645-5389

   Eitan Schwartz
   RAD Data Communications
   900 Corporate Drive
   Mahwah, NJ 07430
   Phone: +1 201 529-1100 Ext. 241

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

   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

Anavi, Stein, Schwartz                                        [PAGE 8]