Internet Draft                                Motty (Mordechai) Anavi
   Document: draft-anavi-tdmoip-01.txt           Jonathan (Yaakov) Stein
   Expires: August 2001                                   Eitan Schwartz
                                                 RAD Data Communications

                                              Hanns-Juergen Schwarzbauer
                                                       Maximilian Riegel
                                                                 Siemens

                                                           February 2001



                                TDM over IP

                         draft-anavi-tdmoip-01.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, Schwarzbauer, Riegel                  [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......................................................7
   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 TDM 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, Schwarzbauer, Riegel                  [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 often 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.

   For point-to-point connections one can use 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

Anavi, Stein, Schwartz, Schwarzbauer, Riegel                  [PAGE 3]


                             TDM over IP                February, 2001

   one way packetization delay, about 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 embed 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 protocols 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; for details see ANSI/T1.101-1998. Somewhere in the network
   there will always be at least one extremely accurate primary
   reference clock, with long-term accuracy of one part in 10E-11. 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

Anavi, Stein, Schwartz, Schwarzbauer, Riegel                  [PAGE 4]


                             TDM over IP                February, 2001

   reference is available. The problem is that the original time
   reference information is no longer available.

   In principle there are two different levels of integration of TDMoIP
   into a T1/E1 network. In the "bypass" scenario 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

Anavi, Stein, Schwartz, Schwarzbauer, Riegel                  [PAGE 5]


                             TDM over IP                February, 2001

   TDMoIP circuits could then be used to provide additional services,
   such as PSTN access, Frame Relay, and ISDN.

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

Anavi, Stein, Schwartz, Schwarzbauer, Riegel                  [PAGE 6]


                             TDM over IP                February, 2001


6. References

   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. In
   accordance with the intellectual property rights procedures of the
   IETF standards process, RAD is willing to offer, upon written
   request from the implementers of the TDMoIP, a non-exclusive license
   under reasonable and non-discriminatory terms and conditions.

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

Anavi, Stein, Schwartz, Schwarzbauer, Riegel                  [PAGE 7]


                             TDM over IP                February, 2001

   Phone: +1 201 529-1100 Ext. 241
   Email: eitan@radusa.com

   HannsJuergen Schwarzbauer
   SIEMENS AG
   81379 Munich
   Germany
   Phone: +49 89 722 24236
   E-Mail: hannsjuergen.schwarzbauer@icn.siemens.de

   Maximilian Riegel
   SIEMENS AG
   81379 Munich
   Germany
   Phone: +49 89 722 49557
   E-Mail: maximilian.riegel@icn.siemens.de



Copyright Notice

   Copyright (C) The Internet Society (date). 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."


Anavi, Stein, Schwartz, Schwarzbauer, Riegel                  [PAGE 8]