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 Siemens August 2001 TDM over IP draft-anavi-tdmoip-02.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. 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]. 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 packet. 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 variation). 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 field. 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 destination. 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 purposes. 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 signaling. 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 eight. 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 +-+-+-+-+-+-+-+-+----------------------- where 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 subframe. 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 taken; 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 lost. 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 format. +-+-----+-----+-+-+--------------+---------------------- |C| SN | CRC |P|E| pointer | 46 octets of payload +-+-----+-----+-+-+--------------+---------------------- where C (1 bit) convergence sublayer indication, C=1 for P-format subframes 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 required. 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 payloads. 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 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 Anavi et al. Expires February 2002 17 TDM Over IP August 2001 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 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 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 et al. Expires February 2002 19