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]