PWE3 Working Group Yaakov (Jonathan) Stein Internet Draft Ronen Shashoua draft-stein-pwe3-dtdmoip-00.txt Tuvia Segal Expires: August 2003 RAD Data Communications February 2003 TDM over IP using Loop Emulation draft-stein-pwe3-tdmoiple-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. TDMoIP-LE [PAGE 1] TDM over IP - Loop Emulation Feb, 2003 Abstract This document describes a method for transporting time division multiplexed (TDM) signals over Pseudo Wires using AAL2 loop emulation. It is complimentary to TDM over IP using AAL1 circuit emulation as defined in [TDMoIP]. 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. Table of Contents 1. Introduction .................................................2 2. The Need for Loop Emulation ..................................3 3. The Use of LES for Congestion Control ........................3 4. TDMoIP using Loop Emulation Encapsulation ....................5 5. Use of Native Signal Processing with Loop Emulation ..........5 6. AAL2 Format Payload ..........................................6 7. Procedures ...................................................8 8. IANA Considerations ..........................................8 9. References ...................................................8 10. Acknowledgments .............................................9 11. Contact Information .........................................9 1. Introduction The modern telephony network is comprised of an access network consisting of "local loops" and the core consisting of "trunks" or "circuits". Local loops are twisted pairs of copper wires that carry analog signals from the end-user terminal (typically a telephone, fax machine, or modem) to the telephony switch. At the switch the analog signal from each user is digitized into a 64 Kbps digital stream. Trunks, also known as circuits, are used to interconnect telephony switches and consist of fiber optic or coaxial cables that transport large numbers of 64 Kbps end-user streams, which have been time domain multiplexed into a single synchronous stream. Due to the time domain multiplexing, the bit stream belonging to each loop is called a timeslot. Stein et al. [PAGE 2] TDM over IP - Loop Emulation Feb, 2003 In this document "trunking" refers to any method of transporting multiple 64 Kbps streams over packet switched networks. In principle there are two approaches to trunking. "Circuit emulation" performs trunking by capturing segments of the time domain multiplexed data appearing in the synchronous "circuit"; while "loop emulation" performs the emulation at the individual "local loop" (timeslot) level, and hence must provide its own multiplexing mechanism. In the ATM world the need for both types of trunking has been acknowledged. Circuit emulation has been standardized in the form of AAL1 circuit emulation service (CES) [AAL1,CES], while loop emulation has been standardized as AAL2 loop emulation service (LES) [AAL2,SSCS,LES]. 2. The Need for Loop Emulation Most of the previous work on pseudo-wire trunking has focused on circuit emulation, due to its comparative simplicity, its low delay, and its inherent ability to replicate a large range of features of the emulated circuit (e.g. signaling structures and data flows). However, circuit emulation inherits two innate deficiencies from its synchronous progenitor. First, it must transport the data originating in each loop included in the trunk, even when that loop's terminal is "on-hook", or when the end-user is not speaking or sending any information. Second, its data rate must remain constant; it is not capable of shrinking its bandwidth requirements when the underlying network is unable to provide for its demands. Loop emulation over packet switched networks has been described in [TDMoIP]. Since the individual loops are emulated, they need only be transported when they carry valid information. Even when the loop is carrying legitimate data, the use of native signal processing may significantly reduce its bandwidth requirements. Finally, since the data rate of a loop emulation stream is intrinsically variable, the bandwidth of the PW may be incrementally reduced when necessary. 3. The Use of LES for Congestion Control Most of the previous work on pseudo-wire trunking has focused on so called "well engineered" packet switched networks, where congestion and its ensuing packet loss and end-to-end delay are considered extremely rare events. A performance measurement facility has been built into [TDMoIP] to monitor congestion and its effects. Stein et al. [PAGE 3] TDM over IP - Loop Emulation Feb, 2003 In [PL] the effect of packet loss caused by congestion has been studied from the point of view of its effect on the loops being trunked. Here we consider methods to diminish the potentially detrimental effects of congestion, to which the trunking pseudo- wire contributes, on neighboring flows in the packet switched network. When a network route used by a constant bandwidth service (such as circuit emulation) becomes congested, the only recourses are to reroute the service and avoid the congested links, or to withdraw the service. In many cases the former option is not available, due to the provider of the service lacking the required control over underlying network. The remaining option, that of service removal, is obviously an unacceptable alternative for trunking. Not only does removal of the pseudo-wire carrying a telephony trunk impact a large number of users, its impression on users accustomed to "five nines" availability would be highly detrimental to the service's (and the service provider's) image. The situation is all the more deplorable when congestion is not expected to be the norm. Assuming that the TDM flow can indeed statistically co-exist with the other traffic, congestion is due solely to temporary load peaks. As aforementioned, using constant bit-rate circuit emulation, the lone option may be service withdrawal, even if the congestion lasts only for a few seconds. The loops will be disconnected, the TDM equipment will suffer red alarm, and the reconnection time before other users may be served will be significant. Since loop emulation can be combined with native service processing such as silence suppression and voice compression (see section 5 below), the loop emulation trunk may consume less bandwidth a priori, and hence its effect on neighboring flows is minimized. Moreover, when congestion is detected, there are several bandwidth conserving options available that facilitate significant further reduction. For example, speech compression could be enabled which can reduce bandwidth by a factor of ten; voice activity detection and comfort noise generation typically contribute a further factor of two, reducing the bandwidth to 5 percent of the original. At this level there is little reason to withdraw the pseudo-wire, and the service can be maintained. The compression may indeed be perceivable to users, but would undoubtably be considered much more acceptable than service outages. Once the congestion clears the original service emulation characteristics can be restored. For loops carrying fax transmissions the situation is similar; in one direction the bandwidth usage is negligible, and in the other the use of fax-relay with spoofing can radically reduce the instantaneous bandwidth demands. Stein et al. [PAGE 4] TDM over IP - Loop Emulation Feb, 2003 4. TDMoIP using Loop Emulation Encapsulation The general format for TDMoIP is defined in [TDMoIP]. TDMoIP can be used in UDP/IP, MPLS, and L2TPv3/IP packet switched networks, and includes a mandatory control word that contains a sequence number, a six bit length field, a four bit format identifier (FORMID) and various flags required for trunking applications. TDMoIP defines three different payload types, namely circuit emulation using AAL1, loop emulation using AAL2 (for which FORMID=1000), and a special payload type for HDLC signaling support. The AAL1 and AAL2 protocols, which were developed for trunking over ATM networks, are the natural choice for trunking over packet networks as well. Although originally developed to adapt various types of application data to the rigid format of ATM, the mechanisms are general solutions to the problem of transporting constant or variable bandwidth data streams over a byte-oriented packet network. In addition, since the AAL mechanisms are extensively used within and on the edge of the telephony system, they were specifically designed to efficiently treat audio, non-audio data and telephony signaling. Finally, simple service interworking with legacy TDM networks is a major design goal of TDMoIP. Hence, payload types should be chosen in order to simplify interworking with the existing infrastructure, including AAL1 and AAL2 networks. 5. Use of Native Signal Processing with Loop Emulation Arbitrary native signal processing functions may be performed before the timeslot is placed in the AAL2 loop emulation payload. In the simplest case the loop is examined for off-hook status based on the telephony signaling. If the loop is off-hook the single byte samples are stored in a buffer of predetermined length (up to 64 bytes) until this buffer is full. At that point the buffer is encapsulated as described in section 6 below. In a somewhat more sophisticated scenario voice activity detection is performed. Assuming the loop is off-hook, if voice activity is detected then the data is handled as before; otherwise either no data is sent or a limited number of statistics is gathered and sent as the payload in order to enable comfort noise generation at the egress edge. Since in normal conversation simultaneous speech is rare, this results in a bandwidth reduction of approximately one half. Stein et al. [PAGE 5] TDM over IP - Loop Emulation Feb, 2003 At a higher level of sophistication the voice itself may be compressed by utilizing speech coding. Bandwidth reduction by factors of up to eight can be had with little effect on perceived speech quality, while factors exceeding twenty can be achieved with good understandability. When combined with voice activity, factors of 16 can be achieved while maintaining toll quality, while factors of fifty can be utilized if end users are willing to suffer a certain loss of voice quality. These speech compression methods function only for speech, and even tones (such as those used for dialing) may not be reliably passed. When the proportion of non-speech audio is expected to be small, these segments may be detected and passed uncompressed. When substantial amounts of non-speech are expected, relays must be provided. Tone relays, fax relays, and modem relays all function by detecting the respective audio signal, transporting the information carried by this signal in some efficient format, and regenerating the audio signal at the egress edge. 6. AAL2 Format Payload The variable bit rate AAL2 format is described in [AAL2,SSCS] and its use for loop emulation over ATM is explained in [LES]. The ATM AAL2 is subdivided into the Common Part Sublayer (CPS) and the Service Specific Convergence Sublayer (SSCS); for PWs we need only the CPS. Note that for TDMoIP the multiplexed AAL2 streams need not segmented into ATM cells, rather the AAL2 payloads belonging to all timeslots are concatenated, and a single packet sent over the network. The basic AAL2-CPS packet is as follows: | Octet 1 | Octet 2 | Octet 3 | 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.) Stein et al. [PAGE 6] TDM over IP - Loop Emulation Feb, 2003 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 CAS signaling packets. HEC (5 bits) the header error control Payload - voice A block of length indicated by LI of audio samples, or their compressed representation, are placed in the AAL2 packet. Payload - CAS signaling For CAS signaling the payload is formatted as a type 3 packet (in the notation of [AAL2]) in order to ensure error protection. The signaling is sent 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. Stein et al. [PAGE 7] TDM over IP - Loop Emulation Feb, 2003 7. Procedures All behavior specified in [TDMoIP] MUST be followed for AAL2 mode as well. This includes handling alarms, timing recovery, OAM signaling, etc. Filling the AAL2 payload is performed per [SSCS]. Upon receipt of a packet the egress edge MUST examine the packet control word for FORMID and length. Arbitrary native signal processing functions MAY be performed before the timeslot is placed in the AAL2 payload. For a signal processing function to be employed the desired functionality must be present at both edge devices. The precise functionality and parameters to be used may be manually configured or signaled. 8. IANA Considerations All IANA considerations of the underlying PSN (e.g. UDP or L2TP IP types) MUST be abided. When used with UDP/IP the destination port number MUST be set to 0x085E (2142), the user port number which has been assigned by the to TDMoIP. 9. References [AAL1] ITU-T Recommendation I.363.1 (08/96) B-ISDN ATM Adaptation Layer (AAL) specification: Type 1 [AAL2] ITU-T Recommendation I.363.2 (11/00) B-ISDN ATM Adaptation Layer (AAL) specification: Type 2 [CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0 [LES] ATM forum specification atm-vmoa-0145 (LES) Voice and Multimedia over ATM - Loop Emulation Service Using AAL2 [PL] draft-stein-pwe3-tdm-packetloss-00.txt (2002) The Effect of Packet Loss on Voice Quality for TDM over Pseudowires, Y(J) Stein and I Druker, work in progress [SSCS] ITU-T Recommendation I.366.2 (02/99) AAL Type 2 service specific convergence sublayer for trunking [TDMoIP] draft-anavi-tdmoip-04.txt (2002) TDM over IP, Y(J) Stein et al, work in progress Stein et al. [PAGE 8] TDM over IP - Loop Emulation Feb, 2003 10. Acknowledgments The authors would like to thank Hugo Silberman, Ron Insler, and Eyal Ben Saadon of RAD Data Communications for their valuable contributions to the technology described herein. 11. Contact Information Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenburg St., Bldg C Tel-Aviv 69719 ISRAEL Phone: +972 3 645-5389 Email: yaakov_s@rad.com Ronen Shashoua RAD Data Communications 24 Raoul Wallenburg St., Bldg C Tel-Aviv 69719 ISRAEL Phone: +972 3 645-5447 Email: ronen_s@rad.com Tuvia Segal RAD Data Communications 24 Raoul Wallenburg St., Bldg C Tel-Aviv 69719 ISRAEL Phone: +972 3 645-5757 Email: tuvia_s@rad.com Stein et al. [PAGE 9] TDM over IP - Loop Emulation Feb, 2003 Copyright Notice Copyright (C) The Internet Society (2002). 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." Stein et al. [PAGE 10]