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]