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

                                              HannsJuergen Schwarzbauer
                                              Maximilian Riegel

                                              August 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


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

    Anavi, Stein, Schwartz, Schwarzbauer, Riegel                     1
                             TDM Over IP                   August 2001

Table of Contents

   1. Introduction....................................................2
   2. TDMoIP - the Concept............................................2
   3. Advantages of TDMoIP Approach...................................4
   4. TDM Network Timing..............................................5
   6. Frame Format....................................................6
   7. Ethernet Encapsulation..........................................9
   8. TDMoIP Payload - General.......................................10
   9. TDMoIP Payload - AAL2 Format (FORMID=01000)....................11
   10. TDMoIP Payload - AAL1 Format (FORMID=001XX)...................12
   11. TDMoIP Payload - HDLC Format (FORMID=10000)...................16
   12. TDMoIP Payload - Control Messages (FORMID=11111)..............16
   13. References....................................................16
   14. Acknowledgments...............................................17
   15. Contact Information...........................................17

1. Introduction

   Circuit-based services (e.g. T1/E1, Frame Relay, and ATM) are
   presently 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 tactic 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 support. The latter
   problem 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 T3/E3 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

    Anavi et al.        Expires February 2002                        2
                             TDM Over IP                   August 2001

   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 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 frame segmentation, the synchronization bit
   or byte need not be included, and accordingly the payload length
   would be 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 short-delay 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 one way packetization delay, about half that of the ITU-
   T "low delay" 16 Kbps encoder (G.728), 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.

   It will be useful to define a "bundle" as a collection of TDM
   timeslots originating from a single incoming trunk that are to be
   sent to a common destination. A bundle may encompass the entire
   trunk (e.g. 24 timeslots for T1) or be some fraction thereof. If
   different timeslots need to be sent to different destinations the
   trunk is divided into multiple bundles. All the timeslots in a
   bundle share a common timing source and common trunk-level fault

    Anavi et al.        Expires February 2002                        3
                             TDM Over IP                   August 2001

   indications. In particular, timeslots from different TDM trunks can
   not be combined into a single bundle.

   TDMoIP transports a bundle without any attempt at interpreting its
   content. 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 TDMoIP readily accommodates
   fractional T1 or channelized E1 systems, and traffic bandwidth is
   reduced because only the relevant bits need be included in the IP

3. Advantages of TDMoIP Approach

   The simplicity of TDMoIP translates into lower initial expenditure
   and operating costs. 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, and has 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 premises. Such
   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 can be made more efficient than ATM by adjusting
   payload size to reduce overhead.

   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

    Anavi et al.        Expires February 2002                        4
                             TDM Over IP                   August 2001

   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.

4. TDM Network Timing

   TDM networks are inherently synchronous; 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  reference
   timing 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; for details see ANSI/T1.101-1999 or ITU-T
   G.81x series recommendations. The use of time standards less
   accurate than stratum 3 is NOT RECOMMENDED as it may result in
   service impairments.

   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 TDM time
   reference information is not disseminated through the IP network.

   In broadest terms there are two methods of overcoming this
   difficulty; in one method the timing information is provided by some
   means independent of the IP network, while in the other the timing
   must be transferred over the IP network.

   For example, in the "whole network" scenario the entire TDM
   infrastructure (or at least major portions of it) is replaced by
   TDMoIP. Here timing information MUST be delivered over the IP
   network, and the reconstructed TDM stream SHOULD conform to ITU-T
   recommendations G.823 for E1 and G.824 for T1 trunks. IP networks
   can disseminate accurate timing information through NTP (RFC 1305),
   and synchronous operation of a real-time stream can be emulated
   using RTP (RFC 1889). RTP appends a sequence number and a timestamp
   to each packet, enabling the reconstitution of timing at the expense
   of considerable overhead.

    Anavi et al.        Expires February 2002                        5
                             TDM Over IP                   August 2001

   However, TDMoIP is frequently used in a "toll-bypass" scenario,
   where an IP link connects two existing TDM networks. In such a case
   both TDMoIP devices SHALL receive accurate timing from the TDM
   networks to which they connect, and there is no need to carry timing
   over the IP network. In such cases the overhead associated with RTP
   can  be avoided.

   5. IP Packet Integrity

      TDMoIP assumes a relatively benevolent environment. On the IP
   side this means a network with prioritization and sufficient
   bandwidth, low probability of bit error, packet order interchange or
   lost packets. In particular, use of TDMoIP over the public Internet
   is not presently envisaged.

   Layer 2 priority can be bestowed upon a TDMoIP stream by using the
   VLAN priority field, layer 3 priority is controllable by using TOS.
   Switches and routers which the TDMoIP stream must traverse should be
   configured to respect these priorities. Sufficient bandwidth can be
   guaranteed by undersubscription and/or traffic engineering
   (including IP flow load sharing).

      In order to compensate for packet delay variation which exists in
   any IP network a jitter buffer SHALL be provided. The length of this
   buffer SHOULD be configurable and MAY be dynamic (i.e. grow and
   shrink in length according to the statistics of the delay

      In order to handle (infrequent) packet loss and misordering a
   packet order integrity mechanism SHALL be provided. This mechanism
   SHALL track the serial numbers of packets in the jitter buffer and
   MUST take appropriate action when faults are detected. When missing
   packet(s) are detected the mechanism SHALL output interpolation
   packet(s) in order to retain TDM timing. Packets with incorrect
   serial numbers or other detectable header errors MAY be discarded.
   Packets arriving in incorrect order SHOULD be swapped. Whenever
   possible, interpolation packets SHOULD ensure that proper
   synchronization bits are sent to the TDM network.

6. Frame Format

   A UDP/IP header is prefixed to the TDMoIP data as described in RFCs
   768 (STD0006) and 791 (STD0005). If (and only if) timing needs to be
   delivered over the IP network the RTP header defined in RFC 1889
   SHALL then appear. Finally, a further four octet TDMoIP header is
   appended. The combined frame structure is as follows:

    Anavi et al.        Expires February 2002                        6
                             TDM Over IP                   August 2001

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    1| IPVER |  IHL  |    IP TOS     |          Total Length         |
    2|         Identification        |Flags|      Fragment Offset    |
    3|  Time to Live |    Protocol   |      IP Header Checksum       |
    4|                     Source IP Address                         |
    5|                  Destination IP Address                       |
    6| VER | TDMoIP Bundle Number    |   Destination Port Number     |
    7|           UDP Length          |         UDP Checksum          |
    8|RTV|P|X|  CC   |M|     PT      |      RTP sequence number      |
    9|                            timestamp                          |
   10|                         SSRC identifier                       |
     |    SEQNUM     | FORMID  |L|R|Z|            padding            |
     |                                                               |
     |                         TDMoIP Payload                        |
     |                                                               |

   Each row in the above table is composed of four octets.
   The first five rows are the IP header, rows 6 and 7 are the UDP
   header, and row 8 is the TDMoIP header.

   IPVER (4 bits) is the IP version number, for IPv4 IPVER=4.

   IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5.

   IP TOS (8 bits) is the IP type of service.

   Total Length (16 bits) is the length in octets of header and data.

   Identification (16 bits) is the IP fragmentation identification

   Flags (3 bits) are the IP control flags and MUST be set to Flags=010
   to avoid fragmentation.

   Fragment Offset (13 bits) indicates where in the datagram the
   fragment belongs and is not used here.

    Anavi et al.        Expires February 2002                        7
                             TDM Over IP                   August 2001

   Time to Live (8 bits) is the IP time to live field. Datagrams with
   zero in this field are to be discarded.

   Protocol (8 bits) MUST be set to 0x11 for UDP.

   IP Header Checksum (16 bits) is a checksum on the IP header.
   Source IP Address (32 bits) is the IP address of the source.

   Destination IP Address (32 bits) is the IP address of the

   VER (3 bits) is the TDMoIP version number. The original version
   (VER=000) was experimental and should no longer be used. Presently
   VER=001 when RTP is not required, and VER=011 when RTP is required.

   TDMoIP Bundle Number (13 bits) This field is usually dedicated to
   the Source Port Number, but here identifies the unique data stream
   emanating from a given trunk and sharing a common destination. This
   nonstandard use of a UDP port number is similar to RTP/RTCP's use of
   port numbers to uniquely identify sessions, and the common practice
   (sanctioned in H.225) of randomly allocating port numbers for VoIP
   sessions. Here placing the bundle identifier in the UDP header
   rather than the application area enables fast switching. The
   available bundle numbers are 1-8063, with 0 invalid and the 128
   ports 8064-8191 reserved for more advanced applications.

   Destination Port Number (16 bits) MUST be set to 0x085E (2142), the
   user port number which has been assigned by the Internet Assigned
   Numbers Authority (IANA) to TDMoIP.

   UDP Length (16 bits) is the length in octets of UDP header and data.

   UDP Checksum (16 bits) is the checksum of UDP/IP header and data. If
   not computed it must be set to zero.

   RTV (2 bits) the RTP Version number SHALL be set to RTV=010

   P (1 bit) the RTP padding indicator SHALL be set to P=0

   X (1 bit) the RTP extension SHALL be set to X=0

   CC (4 bits) the RTP CSRC count SHALL be set to CC=0000

   M (1 bit) the RTP marker indicator SHALL be set to M=0

   PT (7 bits) the RTP Payload Type

   RTP sequence number (16 bits) The RTP sequence number is defined
   separately for each bundle and increments by one for each TDMoIP
   frame sent for that bundle. It MAY be used by the receiver to detect
   packet loss and to restore packet sequence. The initial value of the
   sequence number SHOULD be random (unpredictable) for security

    Anavi et al.        Expires February 2002                        8
                             TDM Over IP                   August 2001

   RTP timestamp (32 bits) The RTP timestamp indicates the precise
   sampling instant of the first octet in the TDM payload. It is
   derived from a clock that increments monotonically and linearly in
   time to allow synchronization and jitter calculations, and that has
   sufficient resolution.

   SSRC identifier (32 bits) the RTP synchronization source identifier
   uniquely identifies the bundle. It is chosen randomly for each
   bundle as described in RFC 1899.

   SEQNUM (8 bits) The TDMoIP sequence number is required when the RTP
   header is not used and fulfills the same function as the RTP
   sequence number. In addition, since the basic clock rate for each
   bundle is constant, the sequence number may be used as an
   approximate timestamp. The initial value of the sequence number
   SHOULD be random (unpredictable) for security purposes.

   FORMID  Format identifier (5 bits)
   The following values are presently defined:
   00100   AAL1 unstructured
   00101   AAL1 structured
   00110   AAL1 structured w/ CAS
   01000   AAL2
   10000   HDLC
   11111   Control messages
   the payload format for each of these cases will be described below.

   L Loss of Sync failure (1 bit) The L bit being set indicates that
   the source has detected or has been informed of a TDM physical layer
   fault impacting the data to be transmitted. This bit can be used to
   indicate Physical layer LOS that should trigger AIS generation at
   the far end.

   R Receive failure (1 bit) The R bit being set indicates that the
   source is not receiving packets at its TDMoIP receive port.

   Z (1 bit) The Z bit indicates an extended header and MUST be set to
   zero at present.

   padding (16 bits) is included so that the TDMoIP payload will
   commence on a double-word boundary.

   TDMoIP Payload is the data and will be described in sections 8-12.

7. Ethernet Encapsulation

   In many applications the TDMoIP frame as described in the previous
   section will be further encapsulated in an Ethernet frame by
   prefixing the Ethernet preamble, destination and source MAC
   addresses, optional VLAN header, etc and appending the four octet
   frame check sequence after the TDMoIP frame.

    Anavi et al.        Expires February 2002                        9
                             TDM Over IP                   August 2001

   A TDMoIP implementation MUST be able to receive both industry
   standard (DIX) Ethernet and IEEE 802.3 CSMA/CD frames and SHOULD
   transmit Ethernet frames.

   Ethernet encapsulation introduces a maximum transmission unit (MTU).
   For example, the length of the Ethernet payload for a non-RTP AAL2
   adapted E1 trunk with 31 channels is 8*4 + 31*47 = 1489 octets. This
   falls below the maximal permitted payload size of 1500 bytes.

8. TDMoIP Payload - General

   The above sections have clarified the datalink, network and
   transport layers of TDMoIP, in this and the following sections we
   discuss issues relating to end-to-end delivery of TDM data, such as
   channel multiplexing, proper interfacing with TDM networks, sequence
   numbering, synchronization and timing recovery.

   As we have seen TDMoIP includes RTP as an option. RTP augments
   UDP/IP to provide payload type identification, sequence numbering
   and timestamping services. RTP is primarily intended for
   multiparticipant multimedia conferencing, and so its design focus
   was on coping with jittered, lost, and re-ordered packets. RTP has
   no inherent mechanism for trunking, i.e. for multiplexing of
   multiple independent channels; according to the spirit of RTP each
   such channel should be carried by a separate RTP session with
   different address or UDP port pairs. However, RTP is an extensible
   protocol framework and several attempts to rectify this limitation
   have been made in the past. All of these attempts have focused on
   reducing overhead by aggregating several user audio channels; none
   addressed the issues of signaling, efficient interworking nor non-
   audio TDM services.

   As an alternative to RTP we could utilize ATM Adaptation Layer (AAL)
   mechanisms. AAL is a set of protocols for adapting virtually any
   type of application data to the rigid format of the ATM payload.
   Various protocols in this set handle the different types of data.
   For example, AAL1 adapts constant bit rate serial bit streams (as
   for example required for telephony trunk "circuit emulation"), while
   AAL2 adapts multichannel, variable bit rate streams (as for example
   compressed voice or video, or multichannel trunks with dynamic
   activity-based "loop emulation"). These protocols are extensively
   used within and on the edge of the telephony system. Neither RTP nor
   AAL provides mechanisms to ensure timely delivery or provide other
   quality-of-service guarantees, both relying on lower-layer services
   to do so. Unlike RTP the AAL mechanisms are specifically designed to
   handle trunking, and efficiently treat audio, non-audio data and

   In fact, even when using RTP for timing purposes it is sensible to
   exploit AAL mechanisms for trunking. Simple interfacing with legacy
   devices (e.g. switches, PBXs) is a major design goal of TDMoIP.

    Anavi et al.        Expires February 2002                       10
                             TDM Over IP                   August 2001

   Hence, the multiplexing mechanism to be used should be one which can
   easily interwork with the existing TDM infrastructure.

   The main problem with an IP/UDP/RTP/AAL protocol is its large
   overhead. For this reason TDMoIP allows the RTP header (header words
   8-10 in section 6 above) to be omitted when timing information need
   not be transferred over the network.

   In sections 9 and 10 we detail the format of the TDMoIP payload
   based on AAL1 and AAL2.

9. TDMoIP Payload - AAL2 Format (FORMID=01000)

   The variable bit rate AAL2 format is described in ITU-T standard
   I.363.2 and its use for loop emulation explained in ATM forum
   specification atm-vmoa-0145 (LES). The AAL2 is subdivided into the
   Common Part Sublayer (CPS) and the Service Specific Convergence
   Sublayer (SSCS); for our purposes we need only the CPS.

   The basic AAL2-CPS packet is as follows:

   |    Octet 1    |    Octet 2    |    Octet 3    | Octets 4-47
    0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
   |      CID      |     LI    |   UUI   |   HEC   |   PAYLOAD

   CID (8 bits) channel identifier is a unique identifier for the
   bundle. The values below 8 are reserved and so there are 248
   possible channels. The mapping of CID values to trunk timeslots is
   outside the scope of the TDMoIP protocol and must be configured
   during installation or via network management.

   LI (6 bits) length indicator is one less than the length of the
   payload in octets. (Note that the payload is limited to 64 octets.)

   UUI (5 bits) user-to-user indication is the higher layer
   (application) identifier and counter. For voice data the UUI will
   always be in the range 0-15, and SHOULD be incremented modulo 16
   each time a channel buffer is sent. The receiver MAY monitor this
   sequence. UUI is set to 24 for signaling packets.

   HEC (5 bits) the header error control

   Payload - voice
   A block of length indicated by LI of voice samples are placed as-is
   into the AAL2 packet.

   Payload - CAS signaling
   For CAS signaling the payload is formatted as a I.366.2 type 3
   packet in order to ensure error protection. The signaling is sent

    Anavi et al.        Expires February 2002                       11
                             TDM Over IP                   August 2001

   with the same CID as the corresponding voice channel. Signaling is
   sent whenever the state of the ABCD bits changes,
   and is sent with triple redundancy, i.e. sent three times spaced 5
   milliseconds apart. In addition, the entire set of the signaling
   bits is sent periodically to ensure reliability.

       0                   1
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
      |RED|       timestamp           |
      |  RES  | ABCD  |    type   | CRC
      |   CRC (cont)  |       PAD     |

   RED (2 bits) is the triple redundancy counter. For the first packet
   it takes the value 00, for the second 01 and for the third 10.
   RED=11 means non-redundant information and is used for periodic
   refresh of the CAS information.

   timestamp (14 bits)
   The timestamp is the same for all three redundant transmissions.

   RES (4 bits) is reserved and MUST be set to zero

   ABCD (4 bits) are the CAS signaling bits

   type (6 bits) for CAS signaling this is 000011

   CRC-10 (10 bits) is a 10 bit CRC error detection code

   PAD (8 bits) is set to zero.

10. TDMoIP Payload - AAL1 Format (FORMID=001XX)

   For the prevalent case for which the timeslot allocation is static
   and no activity detection is performed, the payload can be more
   efficiently encoded using constant bit rate AAL1 adaptation. The
   AAL1 format is described in ITU-T standard I.363.1 and its use for
   circuit emulation explained in ATM forum specification atm-vtoa-0078
   (CES 2.0).

   In AAL1 mode the TDMoIP payload consists of between one and thirty
   48-octet subframes. The number of subframes, which can be inferred
   by the receiving side from the total length or UDP length as
   specified in the header, is pre-configured and typically chosen
   according to latency and bandwidth constraints. Using a single
   subframe reduces latency to a minimum, but incurs the highest
   overhead, while using, for example, eight subframes reduces the
   overhead percentage while increasing the latency by a factor of

    Anavi et al.        Expires February 2002                       12
                             TDM Over IP                   August 2001

    |TDMoIP header|48-octet subframe|
   Single TDMoIP-AAL1 subframe per TDMoIP frame

    +-------------+-----------------+   +-----------------+
    |TDMoIP header|48-octet subframe|---|48-octet subframe|
    +-------------+-----------------+   +-----------------+
   Multiple TDMoIP-AAL1 subframes per TDMoIP frame

   The first octet of each 48-octet AAL1 subframe consists of an error
   protected three-bit sequence number.

     1 2 3 4 5 6 7 8
    |C| SN  | CRC |P| 47 octets of payload

   C (1 bit) convergence sublayer indication, its use here is limited
   to indication of the existence of a pointer (see below)
   C=0 means no pointer, C=1 means a pointer is present.

   SN (3 bits) The AAL1 sequence number increments from subframe to

   CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN

   P (1 bit) even byte parity

   As can be readily inferred this octet can only take on eight
   different values, and incrementing the sequence number forms an
   eight subframe sequence number cycle, the importance of which will
   become clear shortly.

   The structure of the remaining 47 octets in the TDMoIP-AAL1 subframe
   depends on the subframe type, of which there are three,
   corresponding to the three types of AAL1 circuit emulation service
   defined in ATM forum specification af-vtoa-0078. These are known as
   namely unstructured circuit emulation, structured circuit emulation
   and structured circuit emulation with CAS.

   The simplest subframe is the unstructured one which is used for
   transparent transfer of whole trunks (T1,E1,T3,E3). The 47 octets
   after the sequence number octet contain 376 bits from the TDM bit
   stream. No frame synchronization is supplied or implied, and framing
   is the sole responsibility of the end-user equipment. Hence the
   unstructured mode can be used for leased lines which carry data
   rather than N*64 Kbps timeslots, and even for trunks with
   nonstandard frame synchronization. For the T1 case the raw frame
   consists of 193 bits, and hence 1 183/193 T1 frames fit into each

    Anavi et al.        Expires February 2002                       13
                             TDM Over IP                   August 2001

   TDMoIP-AAL1 subframe. The E1 frame consists of 256 bits, and so 1
   15/32 E1 frames fit into each subframe. In either case, if a single
   subframe is used per TDMoIP frame, the overhead percentage without
   RTP is 32 header octets + 1 sequence number octet for every 47 TDM
   payload octets, i.e. 41.5%, while for eight TDMoIP-AAL1 subframes
   per TDMoIP frame the payload is 8*47=376 octets, resulting in an
   overhead of about 10%. These overhead figures do not include
   ethernet framing as described in section 7.

   When the TDM trunk is segmented into timeslots according to ITU-T
   G.704, and it is desired to transport N*64 Kbps circuit where N is
   only a fraction of the full E1 or T1, it is more efficient to use
   one of the structured AAL1 circuit emulation services. Structured
   AAL1 views the data not merely as a bit stream, but as a bundle of
   timeslots. Furthermore, when CAS signaling is used it can be
   formatted such that it can be readily detected and manipulated.

   In the structured circuit emulation mode without CAS, N octets from
   the N timeslots to be transported are first arranged in order of
   timeslot number. Thus if timeslots 2, 3, 5, 7 and 11 are to be
   transported the corresponding five octets are placed in the subframe
   immediately after the sequence number octet.
   This placement is repeated until all 47 octets in the subframe are

   octet    1  2  3  4  5  6  7  8  9 10 --- 41 42 43 44 45 46 47
   timeslot 2  3  5  7 11  2  3  5  7 11 ---  2  3  5  7 11  2  3

   the next subframe commences where the present subframe left off

   octet    1  2  3  4  5  6  7  8  9 10 --- 41 42 43 44 45 46 47
   timeslot 5  7 11  2  3  5  7 11  2  3 ---  5  7 11  2  3  5  7

   and so forth. The set of timeslots 2,3,5,7,11 is called a structure
   and the point where one structure ends and the next commences is a
   structure boundary.

   The problem with this arrangement is the lack of explicit indication
   of the octet identities. As can be seen in the above example, each
   TDMoIP-AAL1 subframe starts with a different timeslot, so a single
   lost frame will result in misidentifying timeslots from that point
   onwards, without possibility of recovery. The solution to this
   deficiency is the periodic introduction of a pointer to the next
   structure boundary. This pointer need not be used too frequently, as
   the timeslot identification are uniquely inferable unless frames are

   The particular method used in AAL1 is to insert a pointer once every
   sequence number cycle of length eight subframes. The pointer is
   seven bits and protected by an even parity MSB, and so occupies a
   single octet. Since seven bits are sufficient to represent offsets
   larger than 47, we can limit the placement of the pointer octet to

    Anavi et al.        Expires February 2002                       14
                             TDM Over IP                   August 2001

   subframes with even sequence number. Unlike usual TDMoIP-AAL1
   subframes with 47 octets available for payload, subframes which
   contain a pointer, called P-format subframes, have the following

    |C| SN  | CRC |P|E|   pointer    | 46 octets of payload

   C (1 bit) convergence sublayer indication, C=1 for P-format

   SN (3 bits) is an even AAL1 sequence number,

   CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN

   P (1 bit) even byte parity LSB for sequence number octet

   E (1 bit) even byte parity MSB for pointer octet
   pointer (7 bits) pointer to next structure boundary

   Since P-format subframes have 46 octets of payload and the next
   subframe has 47 octets, viewed as a single entity the pointer needs
   to indicate one of 93 octets. If P=0 it is understood that the
   structure commences with the following octet (i.e. the first octet
   in the payload belongs to the lowest numbered timeslot).
   P=93 means that the last octet of the second subframe is the final
   octet of the structure, and the following subframe commences with a
   new structure. The special value P=127 indicates that there is no
   structure boundary to be indicated (needed when extremely large
   structures are being transported).

   The P-format subframe is always placed at the first possible
   position in the sequence number cycle that a structure boundary
   occurs, and can only occur once per cycle.

   The only difference between the structured circuit emulation format
   and structured circuit emulation with CAS is the definition of the
   structure. Whereas in structured circuit emulation the structure is
   composed of the N timeslots, in structured circuit emulation with
   CAS the structure encompasses
   the super-frame consisting of multiple repetitions of the N
   timeslots and then the CAS signaling bits. The CAS bits are tightly
   packed into octets and the final octet is padded with zeros if

   For example, for E1 trunks the CAS signaling bits are updated once
   per superframe of 16 frames. Hence the structure for N*64 derived
   from an E1 with CAS signaling consists of 16 repetitions of N
   octets, followed by N sets of the four ABCD bits, and finally four

    Anavi et al.        Expires February 2002                       15
                             TDM Over IP                   August 2001

   zero bits if N is odd. For example, the structure for timeslots 2,3
   and 5 will be as follows

   2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5
   2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2 ABCD3] [ABCD5 0000]

   Similarly for T1 ESF trunks the superframe is 24 frames, and the
   structure consists of 24 repetitions of N octets, followed by the
   ABCD bits as before. For the T1 case the signaling bits will in
   general appear twice, in their regular (bit-robbed) positions and at
   the end of the structure.

11. TDMoIP Payload - HDLC Format (FORMID=10000)

   In order to transport HDLC the sender monitors flags until a frame
   is detected. The contents of the frame, are collected and the FCS
   tested. If the FCS is incorrect the frame is discarded, otherwise
   the frame is sent (without the FCS, flags or transparency zero-
   insertions) as-is in the payload. When an HDLCoIP frame is received
   its FCS is calculated, and the original HDLC frame reconstituted.

   This format assumes that the HDLC messages are shorter than the MTU
   and hence avoid fragmentation (i.e. do not exceed the Ethernet
   payload size restriction). The motivation for handling HDLC here is
   transport of common channel signaling (e.g. SS7), not general HDLC

12. TDMoIP Payload - Control Messages (FORMID=11111)

   This FORMID identifies packets that carry system control
   information. Its precise use will be the subject of further study.

13. References

   RFC 768 (STD0006) User Datagram Protocol (UDP)

   RFC 791 (STD0005) Internet Protocol (IP)

   RFC 1305 Network Time Protocol (NTP) (Version 3)

   RFC 1889 RTP: A Transport Protocol for Real-Time Applications

   ITU-T Recommendation G.704 (10/98)
   Synchronous frame structures used at 1544, 6312, 2048, 8448 and
   44736 kbit/s hierarchical levels

   ITU-T Recommendation G.823 (03/00)
   The control of jitter and wander within digital networks which are
   based on the 2048 kbit/s hierarchy

    Anavi et al.        Expires February 2002                       16
                             TDM Over IP                   August 2001

   ITU-T Recommendation G.824 (03/00)
   The control of jitter and wander within digital networks which are
   based on the 1544 kbit/s hierarchy

   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

   T1.101-1999 Synchronization Interface Standard: February, 1999

   ATM forum specification atm-vtoa-0078 (CES 2.0)
   Circuit Emulation Service Interoperability Specification Ver. 2.0

   ATM forum specification atm-vmoa-0145 (LES)
   Voice and Multimedia over ATM - Loop Emulation Service Using AAL2

14. Acknowledgments

   The authors would like to thank Hugo Silberman, Amir Shapira, and
   Shimon Halevy of RAD Data Communications.

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

    Anavi et al.        Expires February 2002                       17
                             TDM Over IP                   August 2001


   HannsJuergen Schwarzbauer
   81379 Munich
   Phone: +49 89 722 24236

   Maximilian Riegel
   81379 Munich
   Phone: +49 89 722 49557

    Anavi et al.        Expires February 2002                       18
                             TDM Over IP                   August 2001

   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

   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 et al.        Expires February 2002                       19