idnits 2.17.1 draft-ietf-pwe3-tdmoip-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2094. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2071. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2078. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2084. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 5, 2006) is 6345 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC3985' on line 2036 looks like a reference -- Missing reference section? 'RFC4197' on line 2039 looks like a reference -- Missing reference section? 'RFC4553' on line 1969 looks like a reference -- Missing reference section? 'RFC4447' on line 1965 looks like a reference -- Missing reference section? 'TDM-CONTROL' on line 2054 looks like a reference -- Missing reference section? 'RFC2119' on line 1948 looks like a reference -- Missing reference section? 'G704' on line 1907 looks like a reference -- Missing reference section? 'G751' on line 1911 looks like a reference -- Missing reference section? 'TRAU' on line 2058 looks like a reference -- Missing reference section? 'G826' on line 1924 looks like a reference -- Missing reference section? 'CESoPSN' on line 1997 looks like a reference -- Missing reference section? 'RFC3550' on line 1958 looks like a reference -- Missing reference section? 'RFC4385' on line 2047 looks like a reference -- Missing reference section? 'Y1413' on line 1983 looks like a reference -- Missing reference section? 'Y1414' on line 1986 looks like a reference -- Missing reference section? 'Y1453' on line 1992 looks like a reference -- Missing reference section? 'Y1452' on line 1989 looks like a reference -- Missing reference section? 'MEF8' on line 1938 looks like a reference -- Missing reference section? 'RFC768' on line 1942 looks like a reference -- Missing reference section? 'RFC791' on line 1945 looks like a reference -- Missing reference section? 'RFC3032' on line 1951 looks like a reference -- Missing reference section? 'RFC3931' on line 1955 looks like a reference -- Missing reference section? 'IEEE802.3' on line 1931 looks like a reference -- Missing reference section? 'IEEE802.1Q' on line 1928 looks like a reference -- Missing reference section? 'AAL1' on line 1898 looks like a reference -- Missing reference section? 'CES' on line 1904 looks like a reference -- Missing reference section? 'AAL2' on line 1901 looks like a reference -- Missing reference section? 'SSCS' on line 1976 looks like a reference -- Missing reference section? 'LES' on line 1935 looks like a reference -- Missing reference section? 'SS7' on line 2051 looks like a reference -- Missing reference section? 'ISDN-PRI' on line 2001 looks like a reference -- Missing reference section? 'RFC4618' on line 1972 looks like a reference -- Missing reference section? 'G823' on line 1916 looks like a reference -- Missing reference section? 'G824' on line 1920 looks like a reference -- Missing reference section? 'RFC2914' on line 2024 looks like a reference -- Missing reference section? 'RFC2212' on line 2007 looks like a reference -- Missing reference section? 'RFC2475' on line 2017 looks like a reference -- Missing reference section? 'RFC3246' on line 2027 looks like a reference -- Missing reference section? 'RFC2474' on line 2013 looks like a reference -- Missing reference section? 'G.826' on line 1163 looks like a reference -- Missing reference section? 'RFC3711' on line 2032 looks like a reference -- Missing reference section? 'RFC4446' on line 1962 looks like a reference -- Missing reference section? 'ABCD2 ABCD3' on line 1541 looks like a reference -- Missing reference section? 'ABCD5 0000' on line 1541 looks like a reference -- Missing reference section? 'RFC2330' on line 2010 looks like a reference -- Missing reference section? 'RFC792' on line 2004 looks like a reference -- Missing reference section? 'RFC4379' on line 2043 looks like a reference -- Missing reference section? 'VCCV' on line 1979 looks like a reference -- Missing reference section? 'RFC2679' on line 2021 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 56 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Y(J) Stein 3 Internet-Draft R. Shashoua 4 Expires: June 8, 2007 R. Insler 5 M. Anavi 6 RAD Data Communications 7 December 5, 2006 9 TDM over IP 10 draft-ietf-pwe3-tdmoip-06.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on June 8, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 TDM over IP (TDMoIP) is a structure-aware method for transporting 44 Time Division Multiplexed (TDM) signals as pseudowires (PWs). By 45 ensuring TDM structure integrity, TDMoIP is able to better withstand 46 network degradations. As TDM signaling and individual channels are 47 visible, it is possible to use mechanisms that exploit or manipulate 48 these to conceal packet loss or conserve bandwidth. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. TDM Structure and Structure-aware Transport . . . . . . . . . 4 54 3. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 6 55 4. Encapsulation Details for Specific PSNs . . . . . . . . . . . 9 56 4.1 UDP/IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 9 57 4.2 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 58 4.3 L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 59 4.4 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15 60 5. TDMoIP Payload types . . . . . . . . . . . . . . . . . . . . . 17 61 5.1 AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 18 62 5.2 AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 19 63 5.3 HDLC Format Payload . . . . . . . . . . . . . . . . . . . 20 64 6. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . . 21 65 7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24 66 7.1 Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 24 67 7.2 Timing Recovery . . . . . . . . . . . . . . . . . . . . . 24 68 7.3 Congestion Control . . . . . . . . . . . . . . . . . . . . 25 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 71 10. Applicability Statement . . . . . . . . . . . . . . . . . . 28 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29 74 A. Sequence Number Processing (informative) . . . . . . . . . . . 30 75 B. AAL1 Review (informative) . . . . . . . . . . . . . . . . . . 32 76 C. AAL2 Review (informative) . . . . . . . . . . . . . . . . . . 36 77 D. Performance Monitoring Mechanisms (informative) . . . . . . . 38 78 D.1 TDMoIP Connectivity Verification . . . . . . . . . . . . . 38 79 D.2 OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39 80 E. Capabilities, Configuration and Statistics (informative) . . . 42 81 F. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45 82 F.1 Normative References . . . . . . . . . . . . . . . . . . . 45 83 F.2 Informative References . . . . . . . . . . . . . . . . . . 47 84 Intellectual Property and Copyright Statements . . . . . . . . 49 86 1. Introduction 88 Telephony traffic is conventionally carried over connection-oriented 89 synchronous or plesiochronous links (loosely called TDM circuits 90 herein). With the proliferation of Packet Switched Networks (PSNs), 91 transport of TDM services over PSN infrastructures has become 92 desirable. Emulation of TDM circuits over the PSN can be carried out 93 using pseudowires (PWs), as described in the PWE3 architecture 94 [RFC3985]. This emulation must maintain service quality of native 95 TDM; in particular voice quality, latency, timing, and signaling 96 features must be similar to those of existing TDM networks, as 97 described in the TDM PW requirements document [RFC4197]. 99 Structure Agnostic TDM over Packet (SAToP) [RFC4553] is a structure- 100 agnostic protocol for transporting TDM over PSNs. The present 101 document details TDM over IP (TDMoIP), a structure-aware method for 102 TDM transport. In contrast to SAToP, structure-aware methods such as 103 TDMoIP ensure the integrity of TDM structure and thus enable the PW 104 to better withstand network degradations. Individual multiplexed 105 channels become visible, enabling the use of per channel mechanisms 106 for packet loss concealment and bandwidth conservation. TDM 107 signaling also becomes accessible, facilitating mechanisms that 108 exploit or manipulate this signaling. 110 Despite its name, the TDMoIP(R) protocol herein described may operate 111 over several types of PSN, including UDP over IPv4 or IPv6, MPLS, 112 L2TPv3 over IP, or pure Ethernet. Implementation specifics for 113 particular PSNs are discussed in Section 4. Although the protocol 114 should be more generally called TDMoPW and its specific 115 implementations TDMoIP, TDMoMPLS, etc. we retain the nomenclature 116 TDMoIP for consistency with earlier usage. 118 The interworking function that connects between the TDM and PSN 119 worlds will be called a TDMoIP interworking function (IWF), and it 120 may be situated at the provider edge (PE) or at the customer edge 121 (CE). The IWF that encapsulates TDM and injects packets into the PSN 122 will be called the PSN-bound interworking function, while the IWF 123 that extracts TDM data from packets and generates traffic on a TDM 124 network will be called the TDM-bound interworking function. Emulated 125 TDM circuits are always point-to-point, bidirectional, and transport 126 the same TDM rate in both directions. 128 As with all PWs, TDMoIP PWs may be manually configured or set up 129 using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 130 control protocol required specifically for setup and maintenance of 131 TDMoIP pseudowires are described in [TDM-CONTROL]. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. TDM Structure and Structure-aware Transport 139 Although TDM circuits can be used to carry arbitrary bit-streams, 140 there are standardized methods for carrying constant-length blocks of 141 data called "structures". Familiar structures are the T1 or E1 142 frames [G704] of length 193 and 256 bits, respectively. By 143 concatenation of consecutive T1 or E1 frames we can build higher 144 level structures called superframes or multiframes. T3 and E3 frames 145 [G704][G751] are much larger than those of T1 and E1, and even larger 146 structures are used in the GSM Abis channel described in [TRAU]. TDM 147 structures contain TDM data plus structure overhead; for example, the 148 193-bit T1 frame contains a single bit of structure overhead and 24 149 bytes of data, while the 32-byte E1 frame contains a byte of overhead 150 and 31 data bytes. 152 Structured TDM circuits are frequently used to transport multiplexed 153 channels. A single byte in the TDM frame (called a timeslot) is 154 allocated to each channel. A frame of a channelized T1 carries 24 155 byte-sized channels, while an E1 frame consists of 32 channels. 156 Since TDM frames are sent 8000 times per second, a single byte-sized 157 channel carries 64 kbps. 159 TDM structures are universally delimited by placing an easily 160 detectable periodic bit pattern, called the Frame Alignment Signal 161 (FAS), in the structure overhead. The structure overhead may 162 additionally contain error monitoring and defect indications. We 163 will use the term "structured TDM" to refer to TDM with any level of 164 structure imposed by an FAS. Unstructured TDM signifies a bit stream 165 upon which no structure has been imposed, implying that all bits are 166 available for user data. 168 SAToP [RFC4553] is a structure-agnostic protocol for transporting TDM 169 using PWs. SAToP treats the TDM input as an arbitrary bit-stream, 170 completely disregarding any structure that may exist in the TDM bit- 171 stream. Hence SAToP is ideal for transport of truly unstructured 172 TDM, but is also suitable for transport of structured TDM when there 173 is no need to protect structure integrity nor interpret or manipulate 174 individual channels during transport. In particular, SAToP is the 175 technique of choice for PSNs with negligible packet loss, and for 176 applications that do not require discrimination between channels nor 177 intervention in TDM signaling. 179 As described in [RFC4553], when a single SAToP packet is lost an "all 180 ones" pattern is played out to the TDM interface. This pattern is 181 interpreted by the TDM end equipment as an AIS indication, which, 182 according to TDM standards [G826], immediately triggers a "severely 183 errored second" event. As such events are considered highly 184 undesirable, the suitability of SAToP is limited to extremely 185 reliable and overprovisioned PSNs. 187 When structure-aware TDM transport is employed, it is possible to 188 explicitly safeguard TDM structure during transport over the PSN, 189 thus making possible to effectively conceal packet loss events. 190 Structure-aware transport exploits at least some level of the TDM 191 structure to enhance robustness to packet loss or other PSN 192 shortcomings. Structure-aware TDM PWs are not required to transport 193 structure overhead across the PSN; in particular, the FAS MAY be 194 stripped by the PSN-bound IWF and MUST be regenerated by the TDM- 195 bound IWF. However, structure overhead MAY be transported over the 196 PSN, since it may contain information other than FAS. 198 In addition to guaranteeing maintenance of TDM synchronization, 199 structure-aware TDM transport can also distinguish individual 200 timeslots of channelized TDM, thus enabling sophisticated packet loss 201 concealment at the channel level. TDM signaling also becomes 202 visible, facilitating mechanisms that maintain or exploit this 203 information. Finally, by taking advantage of TDM signaling and/or 204 voice activity detection, structure-aware TDM transport makes 205 bandwidth conservation possible. 207 There are three conceptually distinct methods of ensuring TDM 208 structure integrity, namely structure-locking, structure-indication, 209 and structure-reassembly. Structure-locking requires each packet to 210 commence at the start of a TDM structure, and to contain an entire 211 structure or integral multiples thereof. Structure-indication allows 212 packets to contain arbitrary fragments of basic structures, but 213 employs pointers to indicate where each structure commences. 214 Structure-reassembly is only defined for channelized TDM; the PSN- 215 bound IWF extracts and buffers individual channels, and the original 216 structure is reassembled from the received constituents by the TDM- 217 bound IWF. 219 All three methods of TDM structure preservation have their 220 advantages. Structure-locking is described in [CESoPSN], while the 221 present document specifies both structure-indication (see 222 Section 5.1) and structure-reassembly (see Section 5.2) approaches. 223 Structure-indication is used when channels may be allocated 224 statically, and/or when it is required to interwork with existing 225 circuit emulation systems (CES) based on AAL1. Structure-reassembly 226 is used when dynamic allocation of channels is desirable and/or when 227 it is required to interwork with existing loop emulation systems 228 (LES) based on AAL2. 230 Operation, administration, and maintenance (OAM) mechanisms are vital 231 for proper TDM deployments. As aforementioned, structure-aware 232 mechanisms may refrain from transporting structure overhead across 233 the PSN, disrupting OAM functionality. It is beneficial to 234 distinguish between two OAM cases, the "trail terminated" and the 235 "trail extended" scenarios. A trail is defined to be the combination 236 of data and associated OAM information transfer. When the TDM trail 237 is terminated, OAM information such as error monitoring and defect 238 indications are not transported over the PSN, and the TDM networks 239 function as separate OAM domains. In the trail extended case we 240 transfer the OAM information over the PSN (although not necessarily 241 in its native format). OAM will be discussed further in Section 6. 243 3. TDMoIP Encapsulation 245 The overall format of TDMoIP packets is shown in Figure 1. 247 +---------------------+ 248 | PSN Headers | 249 +---------------------+ 250 | TDMoIP Control Word | 251 +---------------------+ 252 | Adapted Payload | 253 +---------------------+ 255 Figure 1. Basic TDMoIP Packet Format 257 The PSN-specific headers are those of UDP/IP, L2TPv3/IP, MPLS or 258 layer 2 Ethernet, and contain all information necessary for 259 forwarding the packet from the PSN-bound IWF to the TDM-bound one. 260 The PSN is assumed to be reliable enough and of sufficient bandwidth 261 to enable transport of the required TDM data. 263 A TDMoIP IWF may simultaneously support multiple TDM PWs, and the 264 TDMoIP IWF MUST maintain context information for each TDM PW. 265 Distinct PWs are differentiated based on PW labels, which are carried 266 in the PSN-specific layers. Since TDM is inherently bidirectional, 267 the association of two PWs in opposite directions is required. The 268 PW labels of the two directions MAY take different values. 270 In addition to the aforementioned headers, an OPTIONAL 12-byte RTP 271 header may appear in order to enable explicit transfer of timing 272 information. This usage is a purely formal reuse of the header 273 format of [RFC3550]. RTP mechanisms, such as header extensions, CSRC 274 list, padding, RTCP, RTP header compression, SRTP, etc. are not 275 applicable. 277 The RTP timestamp indicates the packet creation time in units of a 278 common clock available to both communicating TDMoIP IWFs. When no 279 common clock is available, or when the TDMoIP IWFs have sufficiently 280 accurate local clocks or can derive sufficiently accurate timing 281 without explicit timestamps, the RTP header SHOULD be omitted. 283 If RTP is used, the fixed RTP header described in [RFC3550] MUST 284 immediately follow the control word for all PSN types except UDP/IP, 285 for which it MUST precede the control word. The version number MUST 286 be set to 2, the P (padding), X (header extension), CC (CSRC count), 287 and M (marker) fields in the RTP header MUST be set to zero, and the 288 PT values MUST be allocated from the range of dynamic values. The 289 RTP sequence number MUST be identical to the sequence number in the 290 TDMoIP control word (see below). The RTP timestamp MUST be generated 291 in accordance with the rules established in [RFC3550]; the clock 292 frequency MUST be an integer multiple of 8 kHz, and MUST be chosen to 293 enable timing recovery that conforms with the appropriate standards 294 (see Section 7.2). 296 The 32-bit control word MUST appear in every TDMoIP packet. Its 297 format, in conformity with [RFC4385], is depicted in Figure 2. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | RES |L|R| M |RES| Length | Sequence Number | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 Figure 2. Structure of the TDMoIP Control Word 307 RES The first nibble of the control word MUST be set to zero when the 308 PSN is MPLS, in order to ensure that the packet does not alias an 309 IP packet when forwarding devices perform deep packet inspection. 310 For PSNs other than MPLS the first nibble MAY be set to zero; 311 however, in earlier versions of TDMoIP this field contained a 312 format identifier that was optionally used to specify the payload 313 format. 315 L Local Failure (1 bit) The L flag is set when the IWF has detected 316 or has been informed of a TDM physical layer fault impacting the 317 TDM data being forwarded. In the "trail extended" OAM scenario 318 the L flag MUST be set when the IWF detects loss of signal, loss 319 of frame synchronization, or AIS. When the L flag is set the 320 contents of the packet may not be meaningful, and the payload MAY 321 be suppressed in order to conserve bandwidth. Once set, if the 322 TDM fault is rectified the L flag MUST be cleared. Use of the L 323 flag is further explained in Section 6. 325 R Remote Failure (1 bit) The R flag is set when the IWF has detected 326 or has been informed, that TDM data is not being received from the 327 remote TDM network, indicating failure of the reverse direction of 328 the bidirectional connection. An IWF SHOULD generate TDM RDI upon 329 receipt of an R flag indication. In the "trail extended" OAM 330 scenario the R flag MUST be set when the IWF detects RDI. Use of 331 the R flag is further explained in Section 6. 333 M Defect Modifier (2 bits) Use of the M field is optional, and when 334 used supplements the meaning of the L flag. 336 When L is cleared (indicating valid TDM data) the M field is used 337 as follows: 339 0 0 indicates no local defect modification. 340 0 1 reserved. 341 1 0 reserved. 342 1 1 reserved. 344 When L is set (invalid TDM data) the M field is used as follows: 346 0 0 indicates a TDM defect that should trigger conditioning 347 or AIS generation by the TDM-bound IWF. 348 0 1 indicates idle TDM data that should not trigger any alarm. 349 If the payload has been suppressed then the preconfigured 350 idle code should be generated at egress. 351 1 0 indicates corrupted but potentially recoverable TDM data. 352 1 1 reserved. 354 Use of the M field is further explained in Section 6. 356 RES (2 bits) These bits are reserved and MUST be set to zero. 358 Length (6 bits) is used to indicate the length of the TDMoIP packet 359 (control word and payload), in case padding is employed to meet 360 minimum transmission unit requirements of the PSN. It MUST be 361 used if the total packet length (including PSN, optional RTP, 362 control word, and payload) is less than 64 bytes, and MUST be set 363 to zero when not used. 365 Sequence number (16 bits) The TDMoIP sequence number provides the 366 common PW sequencing function described in [RFC3985], and enables 367 detection of lost and misordered packets. The sequence number 368 space is a 16-bit, unsigned circular space; the initial value of 369 the sequence number SHOULD be random (unpredictable) for security 370 purposes, and its value is incremented modulo 2^16 separately for 371 PW. Pseudocode for a sequence number processing algorithm that 372 could be used by a TDM-bound IWF is provided in Appendix A. 374 In order to form the TDMoIP payload, the PSN-bound IWF extracts bytes 375 from the continuous TDM stream, filling each byte from its most 376 significant bit. The extracted bytes are then adapted using one of 377 two adaptation algorithms (see Section 5), and the resulting adapted 378 payload is placed into the packet. 380 4. Encapsulation Details for Specific PSNs 382 TDMoIP PWs may exploit various PSNs, including UDP/IP (both IPv4 and 383 IPv6), L2TPv3 over IP (with no intervening UDP), MPLS, and layer-2 384 Ethernet. In the following subsections we depict the packet format 385 for these cases. 387 For MPLS PSNs the format is aligned with those specified in [Y1413] 388 and [Y1414]. For UDP/IP PSNs the format is aligned with those 389 specified in [Y1453] and [Y1452]. For transport over layer 2 390 Ethernet the format is aligned with [MEF8]. 392 4.1 UDP/IPv4 394 ITU-T recommendation Y.1453 [Y1453] describes structure-agnostic and 395 structure-aware mechanisms for transporting TDM over IP networks. 396 Similarly, ITU-T recommendation Y.1452 [Y1452] defines structure- 397 reassembly mechanisms for this purpose. Although the terminology 398 used here differs slightly from that of the ITU, implementations of 399 TDMoIP for UDP/IP PSNs as described herein will interoperate with 400 implementations designed to comply with Y.1453 subclause 9.2.2 or 401 Y.1452 clause 10. 403 For UDP/IPv4, the headers as described in [RFC768] and [RFC791] are 404 prefixed to the TDMoIP data. The format is similar for UDP/IPv6, 405 except the IP header described in [RFC2460 ] is used. The TDMoIP 406 packet structure is depicted in Figure 3. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | IPVER | IHL | IP TOS | Total Length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Identification |Flags| Fragment Offset | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Time to Live | Protocol | IP Header Checksum | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Source IP Address | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Destination IP Address | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Source Port Number | Destination Port Number | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | UDP Length | UDP Checksum | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 opt|RTV|P|X| CC |M| PT | RTP Sequence Number | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 opt| Timestamp | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 opt| SSRC identifier | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | RES |L|R| M |RES| Length | Sequence Number | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | | 434 | Adapted Payload | 435 | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Figure 3. TDMoIP Packet Format for UDP/IP 440 The first five rows are the IP header, the sixth and seventh rows are 441 the UDP header. Rows 8 through 10 are the optional RTP header. Row 442 11 is the TDMoIP control word. 444 IPVER (4 bits) is the IP version number, e.g. for IPv4 IPVER=4. 446 IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5. 448 IP TOS (8 bits) is the IP type of service. 450 Total Length (16 bits) is the length in bytes of header and data. 452 Identification (16 bits) is the IP fragmentation identification 453 field. 455 Flags (3 bits) are the IP control flags and MUST be set to Flags=010 456 to avoid fragmentation. 458 Fragment Offset (13 bits) indicates where in the datagram the 459 fragment belongs and is not used for TDMoIP. 461 Time to Live (8 bits) is the IP time to live field. Datagrams with 462 zero in this field are to be discarded. 464 Protocol (8 bits) MUST be set to 11 hex = 17 dec to signify UDP. 466 IP Header Checksum (16 bits) is a checksum for the IP header. 468 Source IP Address (32 bits) is the IP address of the source. 470 Destination IP Address (32 bits) is the IP address of the 471 destination. 473 Source and Destination Port Numbers (16 bits each) 475 Either the source UDP port or destination UDP port MAY be used to 476 multiplex and demultiplex individual PWs between nodes. 477 Architecturally [RFC3985], this makes the UDP port act as the PW 478 Label. PW endpoints MUST agree upon use of either the source UDP 479 or destination UDP port as the PW Label. 481 UDP ports MUST be manually configured by both endpoints of the PW. 482 The configured source or destination port (one or the other, but 483 not both) together with both the source and destination IP 484 addresses uniquely identify the PW. When the source UDP port is 485 used as the PW label, the destination UDP port number MUST be set 486 to the IANA assigned value of 2142 (0x085E). All UDP port values 487 that function as PW labels SHOULD be in the range of dynamically 488 allocated UDP port numbers (49152 through 65535). 490 While many UDP-based protocols are able to traverse middleboxes 491 without dire consequences, the use of UDP ports as PW labels makes 492 middlebox traversal more difficult. Hence, it is NOT RECOMMENDED 493 to use UDP-based PWs where port-translating middleboxes are 494 present between PW endpoints. 496 UDP Length (16 bits) is the length in bytes of UDP header and data. 498 UDP Checksum (16 bits) is the checksum of UDP/IP header and data. If 499 not computed it must be set to zero. 501 4.2 MPLS 503 ITU-T recommendation Y.1413 [Y1413] describes structure-agnostic and 504 structure-aware mechanisms for transporting TDM over MPLS networks. 505 Similarly, ITU-T recommendation Y.1414 [Y1413] defines structure- 506 reassembly mechanisms for this purpose. Although the terminology 507 used here differs slightly from that of the ITU, implementations of 508 TDMoIP for MPLS PSNs as described herein will interoperate with 509 implementations designed to comply with Y.1413 subclause 9.2.2 or 510 Y.1414 clause 10. 512 The MPLS header as described in [RFC3032] is prefixed to the control 513 word and TDM payload. The packet structure is depicted in Figure 4. 515 0 1 2 3 516 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 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Tunnel Label | EXP |S| TTL | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | PW label | EXP |1| TTL | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | RES |L|R| M |RES| Length | Sequence Number | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 524 opt|RTV|P|X| CC |M| PT | RTP Sequence Number | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 opt| Timestamp | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 opt| SSRC identifier | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | | 531 | Adapted Payload | 532 | | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 Figure 4. TDMoIP Packet Format for MPLS 537 The first two rows depicted above are the MPLS header; the third is 538 the TDMoIP control word. Fields not previously described will now be 539 explained. 541 Tunnel Label (20 bits) is the MPLS label that identifies the MPLS LSP 542 used to tunnel the TDM packets through the MPLS network. The 543 label can be assigned either by manual provisioning or via an MPLS 544 control protocol. While transiting the MPLS network there may be 545 zero, one or several tunnel label rows. For label stack usage see 546 [RFC3032]. 548 EXP (3 bits) experimental field, may be used to carry DiffServ 549 classification for tunnel labels. 551 S (1 bit) the stacking bit indicates MPLS stack bottom. S=0 for 552 all tunnel labels, and S=1 for the PW label. 554 TTL (8 bits) MPLS Time to live. 556 PW Label (20 bits) This label MUST be a valid MPLS label, and MAY be 557 configured or signaled. 559 4.3 L2TPv3 561 The L2TPv3 header defined in [RFC3931] is prefixed to the TDMoIP 562 data. The packet structure is depicted in Figure 5. 564 0 1 2 3 565 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 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | IPVER | IHL | IP TOS | Total Length | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Identification |Flags| Fragment Offset | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Time to Live | Protocol | IP Header Checksum | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Source IP Address | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Destination IP Address | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Session ID = PW label | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | cookie 1 (optional) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | cookie 2 (optional) | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | RES |L|R| M |RES| Length | Sequence Number | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 opt|RTV|P|X| CC |M| PT | RTP Sequence Number | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 opt| Timestamp | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 opt| SSRC identifier | 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | | 592 | Adapted Payload | 593 | | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Figure 5. TDMoIP Packet Format for L2TPv3 598 Rows 6 through 8 are the L2TPv3 header. Fields not previously 599 described will now be explained. 601 Protocol the IP protocol field must be set to 73 hex = 115 dec, the 602 user port number that has been assigned to L2TP by IANA. 604 Session ID (32 bits) is the locally significant L2TP session 605 identifier, and contains the PW label. The value 0 is reserved. 607 Cookie (32 or 64 bits) is an optional field that contains a randomly 608 selected value that can be used to validate association of the 609 received frame with the expected PW. 611 4.4 Ethernet 613 MEF Implementation Agreement 8 [MEF8] describes structure-agnostic 614 and structure-aware mechanisms for transporting TDM over Ethernet 615 networks. Implementations of structure-indicated TDMoIP as described 616 herein will interoperate with implementations designed to comply with 617 MEF 8 section 6.3.3. 619 The TDMoIP payload is encapsulated in an Ethernet frame by prefixing 620 the Ethernet destination and source MAC addresses, optional VLAN 621 header, and Ethertype, and suffixing the four-byte frame check 622 sequence. TDMoIP implementations MUST be able to receive both 623 industry standard (DIX) Ethernet and IEEE 802.3 [IEEE802.3] frames 624 and SHOULD transmit Ethernet frames. 626 Ethernet encapsulation introduces restrictions on both minimum and 627 maximum packet size. Whenever the entire TDMoIP packet is less than 628 64 bytes, padding is introduced and the true length indicated by 629 using the Length field in the control word. In order to avoid 630 fragmentation the TDMoIP packet MUST be restricted to the maximum 631 payload size. For example, the length of the Ethernet payload for a 632 UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet 633 is 1472 bytes, which falls below the maximal permitted payload size 634 of 1500 bytes. 636 Ethernet frames MAY be used for TDMoIP transport without intervening 637 IP or MPLS layers, however, an MPLS-style label MUST always be 638 present. In this four-byte header S=1, and all other non-label bits 639 are reserved (set to zero in the PSN-bound direction and ignored in 640 the TDM-bound direction). The Ethertype SHOULD be set to 0x88D8 641 (35032), the value allocated for this purpose by the IEEE, but MAY be 642 set to 0x8847 (34887), the Ethertype of MPLS. The overall frame 643 structure is as follows: 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Destination MAC Address 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Destination MAC Address (cont) | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Source MAC Address 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Source MAC Address (cont) | VLAN Ethertype (opt) | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 |VLP|C| VLAN ID (opt) | Ethertype | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | PW label | RES |1| RES | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | RES |L|R| M |RES| Length | Sequence Number | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 opt|RTV|P|X| CC |M| PT | RTP Sequence Number | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 opt| Timestamp | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 opt| SSRC identifier | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | | 669 | Adapted Payload | 670 | | 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Frame Check Sequence | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 Figure 6. TDMoIP Packet Format for Ethernet 677 Rows 1 through 6 are the (DIX) Ethernet header; for 802.3 there may 678 be additional fields, depending on the value of the length field, see 679 [IEEE802.3]. Fields not previously described will now be explained. 681 Destination MAC Address (48 bits) is the globally unique address of a 682 single station that is to receive the packet. The format is 683 defined in [IEEE802.3]. 685 Source MAC Address (48 bits) is the globally unique address of the 686 station that originated the packet. The format is defined in 687 [IEEE802.3]. 689 VLAN Ethertype (16 bits) a 8100 hex in this position indicates that 690 optional VLAN tagging according to [IEEE802.1Q] is employed, and 691 that the next two bytes contain the VLP, C and VLAN ID fields. 692 VLAN tags may be stacked, in which case the two-byte field 693 following the VLAN ID is once again a VLAN Ethertype. 695 VLP (3 bits) is the VLAN priority, see [IEEE802.1Q]. 697 C (1 bit) the "canonical format indicator" being set, indicates that 698 route descriptors appear; see [IEEE802.1Q]. 700 VLAN ID (12 bits) the VLAN identifier uniquely identifies the VLAN to 701 which the frame belongs. If zero only the VLP information is 702 meaningful. Values 1 and FFF are reserved. The other 4193 values 703 are valid VLAN identifiers. 705 Ethertype (16 bits) is the protocol identifier, as allocated by the 706 IEEE. The Ethertype SHOULD be set to 0x88D8 (35032), but MAY be 707 set to 0x8847 (34887). 709 PW Label (20 bits) This label MUST be manually configured. The 710 remainder of this row is formatted to resemble an MPLS label. 712 Frame Check Sequence (32 bits) is a CRC error detection field, 713 calculated per [IEEE802.3]. 715 5. TDMoIP Payload types 717 As discussed at the end of Section 3, TDMoIP transports real-time 718 streams by first extracting bytes from the stream, and then adapting 719 these bytes. TDMoIP offers two different adaptation algorithms, one 720 for constant rate real-time traffic, and one for variable rate real- 721 time traffic. 723 For unstructured TDM, or structured but unchannelized TDM, or 724 structured channelized TDM with all channels active all the time, a 725 constant rate adaptation is needed. In such cases TDMoIP uses 726 structure-indication to emulate the native TDM circuit, and the 727 adaptation is known as "circuit emulation". However, for channelized 728 TDM wherein the individual channels (corresponding to "loops" in 729 telephony terminology) are frequently inactive, bandwidth may be 730 conserved by transporting only active channels. This results in 731 variable rate real-time traffic, for which TDMoIP uses structure- 732 reassembly to emulate the individual loops, and the adaptation is 733 known as "loop emulation". 735 TDMoIP uses constant-rate AAL1 [AAL1,CES] for circuit emulation, 736 while variable-rate AAL2 [AAL2] is employed for loop emulation. The 737 AAL1 mode MUST be used for structured transport of unchannelized data 738 and SHOULD be used for circuits with relatively constant usage. In 739 addition, AAL1 MUST be used when the TDM-bound IWF is required to 740 maintain a high timing accuracy (e.g. when its timing is further 741 distributed) and SHOULD be used when high reliability is required. 742 AAL2 SHOULD be used for channelized TDM when bandwidth needs to be 743 conserved, and MAY be used whenever usage of voice-carrying channels 744 is expected to be highly variable. 746 Additionally, a third mode is defined specifically for efficient 747 transport of HDLC-based CCS signaling carried in TDM channels. 749 The AAL family of protocols is a natural choice for TDM emulation. 750 Although originally developed to adapt various types of application 751 data to the rigid format of ATM, the mechanisms are general solutions 752 to the problem of transporting constant or variable rate real-time 753 streams over a packet network. 755 Since the AAL mechanisms are extensively deployed within and on the 756 edge of the public telephony system, they have been demonstrated to 757 reliably transfer voice-grade channels, data and telephony signaling. 758 These mechanisms are mature and well understood, and implementations 759 are readily available. 761 Finally, simplified service interworking with legacy networks is a 762 major design goal of TDMoIP. Re-use of AAL technologies simplifies 763 interworking with existing AAL1- and AAL2-based networks. 765 5.1 AAL1 Format Payload 767 For the prevalent cases of unchannelized TDM, or channelized TDM for 768 which the channel allocation is static, the payload can be 769 efficiently encoded using constant rate AAL1 adaptation. The AAL1 770 format is described in [AAL1] and its use for circuit emulation over 771 ATM in [CES]. We briefly review highlights of AAL1 technology in 772 Appendix B. In this section we describe the use of AAL1 in the 773 context of TDMoIP. 775 +-------------+----------------+ 776 |control word | AAL1 PDU | 777 +-------------+----------------+ 779 Figure 7a. Single AAL1 PDU per TDMoIP Packet 781 +-------------+----------------+ +----------------+ 782 |control word | AAL1 PDU |---| AAL1 PDU | 783 +-------------+----------------+ +----------------+ 785 Figure 7b. Multiple AAL1 PDUs per TDMoIP Packet 787 In AAL1 mode the TDMoIP payload consists of at least one, and perhaps 788 many, 48-byte "AAL1 PDUs", see Figures 7a and 7b. The number of PDUs 789 MUST be pre-configured and MUST be chosen such that the overall 790 packet size does not exceed the maximum allowed by the PSN (e.g. 30 791 for UDP/IP over Ethernet). The precise number of PDUs per packet is 792 typically chosen taking latency and bandwidth constraints into 793 account. Using a single PDU delivers minimal latency, but incurs the 794 highest overhead. All TDMoIP implementations MUST support between 1 795 and 8 PDUs per packet for E1 and T1 circuits, and between 5 and 15 796 PDUs per packet for E3 and T3 circuits. 798 AAL1 differentiates between unstructured and structured data 799 transfer, which correspond to structure-agnostic and structure-aware 800 transport. For structure-agnostic transport, AAL1 provides no 801 inherent advantage as compared to SAToP; however, there may be 802 scenarios for which its use is desirable. For example, when it is 803 necessary to interwork with an existing AAL1 ATM circuit emulation 804 system, or when clock recovery based on AAL1-specific mechanisms is 805 favored. 807 For structure-aware transport, [CES] defines two modes, structured 808 and structured with CAS. Structured AAL1 maintains TDM frame 809 synchronization by embedding a pointer to the beginning of the next 810 frame in the AAL1 PDU header. Similarly, structured AAL1 with CAS 811 maintains TDM frame and multiframe synchronization by embedding a 812 pointer to the beginning of the next multiframe. Furthermore, 813 structured AAL1 with CAS contains a substructure including the CAS 814 signaling bits. 816 5.2 AAL2 Format Payload 818 Although AAL1 may be configured to transport fractional E1 or T1 819 circuits, the allocation of channels to be transported must be static 820 due to the fact that AAL1 transports constant rate bit-streams. It 821 is often the case that not all the channels in a TDM circuit are 822 simultaneously active ("off-hook"), and by observation of the TDM 823 signaling channel activity status may be determined. Moreover, even 824 during active calls about half the time is silence that can be 825 identified using voice activity detection (VAD). Using the variable 826 rate AAL2 mode we may dynamically allocate channels to be 827 transported, thus conserving bandwidth. 829 The AAL2 format is described in [AAL2] and its use for loop emulation 830 over ATM is explained in [SSCS,LES]. We briefly review highlights of 831 AAL2 technology in Appendix C. In this section we describe the use 832 of AAL2 in the context of TDMoIP. 834 +-------------+----------------+ +----------------+ 835 |control word | AAL2 PDU |---| AAL2 PDU | 836 +-------------+----------------+ +----------------+ 838 Figure 8. Concatenation of AAL2 PDUs in a TDMoIP packet 840 In AAL2 mode the TDMoIP payload consists of one or more variable- 841 length "AAL2 PDUs", see Figure 8. Each AAL2 PDU contains 3 bytes of 842 overhead and between 1 and 64 bytes of payload. A packet may be 843 constructed by inserting PDUs corresponding to all active channels, 844 by appending PDUs ready at a certain time, or by any other means. 845 Hence, more than one PDU belonging to a single channel may appear in 846 a packet. 848 [RFC3985] denotes as Native Service Processing (NSP) functions all 849 processing of the TDM data before its use as payload. Since AAL2 is 850 inherently variable rate, arbitrary NSP functions MAY be performed 851 before the channel is placed in the AAL2 loop emulation payload. 852 These include testing for on-hook/off-hook status, voice activity 853 detection, speech compression, fax/modem/tone relay, etc. 855 All mechanisms described in [AAL2,SSCS,LES] may be used for TDMoIP. 856 In particular, CID encoding and use of PAD octets according to 857 [AAL2], encoding formats defined in [SSCS], and transport of CAS and 858 CCS signaling as described in [LES] MAY all be used in the PSN-bound 859 direction, and MUST be supported in the TDM-bound direction. The 860 overlap functionality and AAL-CU timer and related functionalities 861 may not be required, and the STF field is NOT used. Computation of 862 error detection codes, namely the HEC in the AAL2 PDU header and the 863 CRC in the CAS packet, is superfluous if an appropriate error 864 detection mechanism is provided by the PSN. In such cases these 865 fields MAY be set to zero. 867 5.3 HDLC Format Payload 869 The motivation for handling HDLC in TDMoIP is to efficiently 870 transport common channel signaling (CCS) such as SS7 [SS7] or ISDN 871 PRI signaling [ISDN-PRI], embedded in the TDM stream. This mechanism 872 is not intended for general HDLC payloads, and assumes that the HDLC 873 messages are always shorter than the maximum packet size. 875 The HDLC mode should only be used when the majority of the bandwidth 876 of the input HDLC stream is expected to be occupied by idle flags. 877 Otherwise the CCS channel should be treated as an ordinary channel. 879 The HDLC format is intended to operate in port mode, transparently 880 passing all HDLC data and control messages over a separate PW. The 881 encapsulation is compatible with that of [RFC4618], however the 882 sequence number generation and processing SHOULD be according to 883 section 3 above. 885 The PSN-bound IWF monitors flags until a frame is detected. The 886 contents of the frame are collected and the FCS tested. If the FCS 887 is incorrect the frame is discarded, otherwise the frame is sent 888 after initial or final flags and FCS have been discarded and zero 889 removal has been performed. When an TDMoIP- HDLC frame is received 890 its FCS is recalculated, and the original HDLC frame reconstituted. 892 6. TDMoIP Defect Handling 894 Native TDM networks signify network faults by carrying indications of 895 forward defects (AIS) and reverse defects (RDI) in the TDM bit 896 stream. Structure-agnostic TDM transport transparently carries all 897 such indications; however, for structure-aware mechanisms where the 898 PSN-bound IWF may remove TDM structure overhead carrying defect 899 indications, explicit signaling of TDM defect conditions is required. 901 We saw in Section 3 that defects can be indicated by setting flags in 902 the control word. This insertion of defect reporting into the packet 903 rather than in a separate stream mimics the behavior of native TDM 904 OAM mechanisms that carry such indications as bit patterns embedded 905 in the TDM stream. The flags are designed to address the urgent 906 messaging, i.e. messages whose contents must not be significantly 907 delayed with respect to the TDM data that they potentially impact. 908 Mechanisms for slow OAM messaging are discussed in Appendix D. 910 +---+ +-----+ +------+ +-----+ +------+ +-----+ +---+ 911 |TDM|->-| |->-|TDMoIP|->-| |->-|TDMoIP|->-| |->-|TDM| 912 | | |TDM 1| | | | PSN | | | |TDM 2| | | 913 |ES1|-<-| |-<-| IWF1 |-<-| |-<-| IWF2 |-<-| |-<-|ES2| 914 +---+ +-----+ +------+ +-----+ +------+ +-----+ +---+ 916 Figure 9. Typical TDMoIP Network Configuration 918 The operation of TDMoIP defect handling is best understood by 919 considering the downstream TDM flow from TDM end system 1 (ES1) 920 through TDM network 1, through TDMoIP IWF 1 (IWF1), through the PSN, 921 through TDMoIP IWF 2 (IWF2), through TDM network 2, towards TDM end 922 system 2 (ES2), as depicted in the figure. We wish not only to 923 detect defects in TDM network 1, the PSN, and TDM network 2, but to 924 localize such defects in order to raise alarms only in the 925 appropriate network. 927 In the "trail terminated" OAM scenario, only user data is exchanged 928 between TDM network 1 and TDM network 2. The IWF functions as a TDM 929 trail termination function, and defects detected in TDM network 1 are 930 not relayed to network 2, or vice versa. 932 In the "trail extended" OAM scenario, if there is a defect (e.g. loss 933 of signal or loss of frame synchronization) anywhere in TDM network 1 934 before the ultimate link, the following TDM node will generate AIS 935 downstream (towards TDMoIP IWF1). If a break occurs in the ultimate 936 link, the IWF itself will detect the loss of signal. In either case, 937 IWF1 having directly detected lack of validity of the TDM signal, or 938 having been informed of an earlier problem, raises the local ("L") 939 defect flag in the control word of the packets it sends across the 940 PSN. In this way the trail is extended to TDM network 2 across the 941 PSN. 943 Unlike forward defect indications that are generated by all network 944 elements, reverse defect indications are only generated by trail 945 termination functions. In the trail terminated scenario, IWF1 serves 946 as a trail termination function for TDM network 1, and thus when IWF1 947 directly detects lack of validity of the TDM signal, or is informed 948 of an earlier problem, it MAY generate TDM RDI towards TDM ES1. In 949 the trail extended scenario IWF1 is not a trail termination, and 950 hence MUST NOT generate TDM RDI, but rather, as we have seen, sets 951 the "L" defect flag. As we shall see, this will cause the AIS 952 indication to reach ES2, which is the trail termination, and which 953 MAY generate TDM RDI. 955 When the "L" flag is set there are four possibilities for treatment 956 of payload content. The default is for IWF1 to fill the payload with 957 the appropriate amount of AIS (usually all-ones) data. If the AIS 958 has been generated before the IWF this can be accomplished by copying 959 the received TDM data; if the penultimate TDM link fails and the IWF 960 needs to generate the AIS itself. Alternatively, with structure- 961 aware transport of channelized TDM one SHOULD fill the payload with 962 "trunk conditioning"; this involves placing a preconfigured "out of 963 service" code in each individual channel (the "out of service" code 964 may differ between voice and data channels). Trunk conditioning MUST 965 be used when channels taken from several TDM PWs are combined by the 966 TDM-bound IWF into a single TDM circuit. The third possibility is to 967 suppress the payload altogether. Finally, if IWF1 believes that the 968 TDM defect is minor or correctable (e.g. loss of multiframe 969 synchronization, or initial phases of detection of incorrect frame 970 sync), it MAY place the TDM data it has received into the payload 971 field, and specify in the defect modification field ("M") that the 972 TDM data is corrupted, but potentially recoverable. 974 When IWF2 receives a local defect indication without "M"-field 975 modification, it forwards (or generates if the payload has been 976 suppressed) AIS or trunk conditioning towards ES2 (the choice between 977 AIS and conditioning being preconfigured). Thus AIS has been 978 properly delivered to ES2 emulating the TDM scenario from the TDM end 979 system's point of view. In addition, IWF2 receiving the "L" 980 indication uniquely specifies that the defect was in TDM network 1 981 and not in TDM network 2, thus suppressing alarms in the correctly 982 functioning network. 984 If the M field indicates that the TDM has been marked as potentially 985 recoverable, then implementation specific algorithms (not herein 986 specified) may optionally be utilized to minimize the impact of 987 transient defects on the overall network performance. If the "M" 988 field indicates that the TDM is "idle", no alarms should be raised 989 and IWF2 treats the payload contents as regular TDM data. If the 990 payload has been suppressed, trunk conditioning and not AIS MUST be 991 generated by IWF2. 993 The second case is when the defect is in TDM network 2. Such defects 994 cause AIS generation towards ES2, which may respond by sending TDM 995 RDI in the reverse direction. In the trail terminated scenario this 996 RDI is restricted to network 2. In the trail extended scenario, IWF2 997 upon observing this RDI inserted into valid TDM data, MUST indicate 998 this by setting the "R" flag in packets sent back across the PSN 999 towards IWF1. IWF1, upon receiving this indication, generates RDI 1000 towards ES1, thus emulating a single conventional TDM network. 1002 The final possibility is that of a unidirectional defect in the PSN. 1003 In such a case TDMoIP IWF1 sends packets toward IWF2, but these are 1004 not received. IWF2 MUST inform the PSN's management system of this 1005 problem, and furthermore generate TDM AIS towards ES2. ES2 may 1006 respond with TDM RDI, and as before, in the trail extended scenario, 1007 when IWF2 detects RDI it MUST raise the "R" flag indication. When 1008 IWF1 receives packets with the "R" flag set it has been informed of a 1009 reverse defect, and MUST generate TDM RDI towards ES1. 1011 In all cases, if any of the above defects persist for a preconfigured 1012 period (default value of 2.5 seconds) a service failure is declared. 1013 Since TDM PWs are inherently bidirectional, a persistent defect in 1014 either directional results in a bidirectional service failure. In 1015 addition, if signaling is sent over a distinct PW as per Section 5.3, 1016 both PWs are considered to have failed when persistent defects are 1017 detected in either. 1019 When failure is declared the PW MUST be withdrawn, and both TDMoIP 1020 IWFs commence sending AIS (and not trunk conditioning) to their 1021 respective TDM networks. The IWFs then engage in connectivity 1022 testing using VCCV or TDMoIP OAM as described in Appendix D until 1023 connectivity is restored. 1025 7. Implementation Issues 1027 General requirements for transport of TDM over pseudo-wires are 1028 detailed in [RFC4197]. In the following subsections we review 1029 additional aspects essential to successful TDMoIP implementation. 1031 7.1 Jitter and Packet Loss 1033 In order to compensate for packet delay variation that exists in any 1034 PSN, a jitter buffer MUST be provided. A jitter buffer is a block of 1035 memory into which the data from the PSN is written at its variable 1036 arrival rate, and data is read out and sent to the destination TDM 1037 equipment at a constant rate. Use of a jitter buffer partially hides 1038 the fact that a PSN has been traversed rather than a conventional 1039 synchronous TDM network, except for the additional latency. 1040 Customary practice is to operate with the jitter buffer approximately 1041 half full, thus minimizing the probability of its overflow or 1042 underflow. Hence the additional delay equals half the jitter buffer 1043 size. The length of the jitter buffer SHOULD be configurable and MAY 1044 be dynamic (i.e. grow and shrink in length according to the 1045 statistics of the PDV). 1047 In order to handle (infrequent) packet loss and misordering a packet 1048 sequence integrity mechanism MUST be provided. This mechanism MUST 1049 track the serial numbers of arriving packets and MUST take 1050 appropriate action when anomalies are detected. When missing 1051 packet(s) are detected the mechanism MUST output filler packet(s) in 1052 order to retain TDM timing. Packets arriving in incorrect order 1053 SHOULD be reordered. Processing of filler packets SHOULD ensure that 1054 proper FAS is sent to the TDM network. An example sequence number 1055 processing algorithm is provided in Appendix A. 1057 While the insertion of arbitrary filler packets may be sufficient to 1058 maintain the TDM timing, for telephony traffic it may lead to gaps or 1059 artifacts that result in choppy, annoying or even unintelligible 1060 audio. An implementation MAY blindly insert a preconfigured constant 1061 value in place of any lost samples, and this value SHOULD be chosen 1062 to minimize the perceptual effect. Alternatively one MAY replay the 1063 previously received packet. When computational resources are 1064 available, implementations SHOULD conceal the packet loss event by 1065 properly estimating missing sample values in such fashion as to 1066 minimize the perceptual error. 1068 7.2 Timing Recovery 1070 TDM networks are inherently synchronous; somewhere in the network 1071 there will always be at least one extremely accurate primary 1072 reference clock, with long-term accuracy of one part in 1E-11. This 1073 node provides reference timing to secondary nodes with somewhat lower 1074 accuracy, and these in turn distribute timing information further. 1075 This hierarchy of time synchronization is essential for the proper 1076 functioning of the network as a whole; for details see [G823][G824]. 1078 Packets in PSNs reach their destination with delay that has a random 1079 component, known as packet delay variation (PDV). When emulating TDM 1080 on a PSN, extracting data from the jitter buffer at a constant rate 1081 overcomes much of the high frequency component of this randomness 1082 ("jitter"). The rate at which we extract data from the jitter buffer 1083 is determined by the destination clock, and were this to be precisely 1084 matched to the source clock proper timing would be maintained. 1085 Unfortunately the source clock information is not disseminated 1086 through a PSN, and the destination clock frequency will only 1087 nominally equal the source clock frequency, leading to low frequency 1088 ("wander") timing inaccuracies. 1090 In broadest terms there are four methods of overcoming this 1091 difficulty. In the first and second methods timing information is 1092 provided by some means independent of the PSN. This timing may be 1093 provided to the TDM end systems (method 1) or to the IWFs (method 2). 1094 In a third method a common clock is assumed available to both IWFs, 1095 and the relationship between the TDM source clock and this clock is 1096 encoded in the packet. This encoding may be take the form of RTP 1097 timestamps or may utilizing the SRTS bits in the AAL1 overhead. In 1098 the final method (adaptive clock recovery) the timing must be deduced 1099 solely based on the packet arrival times. Example scenarios are 1100 detailed in [RFC4197] and in [Y1413]. 1102 Adaptive clock recovery utilizes only observable characteristics of 1103 the packets arriving from the PSN, such as the precise time of 1104 arrival of the packet at the TDM-bound IWF, or the fill-level of the 1105 jitter buffer as a function of time. Due to the packet delay 1106 variation in the PSN, filtering processes that combat the statistical 1107 nature of the observable characteristics must be employed. Frequency 1108 Locked Loops (FLL) and Phase Locked Loops (PLL) are well suited for 1109 this task. 1111 Whatever timing recovery mechanism is employed, the output of the 1112 TDM-bound IWF MUST conform to the jitter and wander specifications of 1113 TDM traffic interfaces, as defined in [G823][G824]. For some 1114 applications, more stringent jitter and wander tolerances MAY be 1115 required. 1117 7.3 Congestion Control 1119 As explained in [RFC3985], the underlying PSN may be subject to 1120 congestion. Unless appropriate precautions are taken, undiminished 1121 demand of bandwidth by TDMoIP can contribute to network congestion 1122 that may impact network control protocols. 1124 The AAL1 mode of TDMoIP is an inelastic constant bit-rate (CBR) flow 1125 and cannot respond to congestion in a TCP-friendly manner prescribed 1126 by [RFC2914], although the percentage of total bandwidth they consume 1127 remains constant. The AAL2 mode of TDMoIP is variable bit-rate 1128 (VBR), and it is often possible to reduce the bandwidth consumed by 1129 employing mechanisms that are beyond the scope of this document. 1131 Whenever possible, TDMoIP SHOULD be carried across traffic- 1132 engineered PSNs that provide either bandwidth reservation and 1133 admission control or forwarding prioritization and boundary traffic 1134 conditioning mechanisms. IntServ-enabled domains supporting 1135 Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains 1136 [RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide 1137 examples of such PSNs. Such mechanisms will negate, to some degree, 1138 the effect of TDMoIP on neighboring streams. In order to facilitate 1139 boundary traffic conditioning of TDMoIP traffic over IP PSNs, the 1140 TDMoIP packets SHOULD NOT use the DiffServ Code Point (DSCP) value 1141 reserved for the Default Per-Hop Behavior (PHB) [RFC2474]. 1143 If TDMoIP run over a PSN providing best-effort service, packet loss 1144 SHOULD be monitored in order to detect congestion. If congestion is 1145 detected and bandwidth reduction is possible, then such reduction 1146 SHOULD be enacted. If bandwidth reduction is not possible the TDMoIP 1147 PW SHOULD shut down bi-directionally for some period of time as 1148 described in Section 6.5 of [RFC3985]. 1150 Note that: 1152 1. In AAL1 mode TDMoIP can inherently provide packet loss 1153 measurement since the expected rate of packet arrival is fixed and 1154 known. 1156 2. The results of the packet loss measurement may not be a 1157 reliable indication of presence or absence of severe congestion if 1158 the PSN provides enhanced delivery. For example, if TDMoIP 1159 traffic takes precedence over other traffic, severe congestion may 1160 not significantly affect TDMoIP packet loss. 1162 3. The TDM services emulated by TDMoIP have high availability 1163 objectives (see [G.826]) that MUST be taken into account when 1164 deciding on temporary shutdown. 1166 This specification does not define exact criteria for detecting 1167 severe congestion or specific methods for TDMoIP shutdown or 1168 subsequent re-start. However, the following considerations may be 1169 used as guidelines for implementing the shutdown mechanism: 1171 1. If the TDMoIP PW has been set up using the PWE3 control 1172 protocol [RFC4447], the regular PW teardown procedures of these 1173 protocols SHOULD be used. 1175 2. If one of the TDMoIP IWFs stops transmission of packets for a 1176 sufficiently long period, its peer (observing 100% packet loss) 1177 will necessarily detect "severe congestion" and also stop 1178 transmission, thus achieving bi-directional PW shutdown. 1180 TDMoIP does not provide mechanisms to ensure timely delivery or 1181 provide other quality-of-service guarantees; hence it is required 1182 that the lower-layer services do so. Layer 2 priority can be 1183 bestowed upon a TDMoIP stream by using the VLAN priority field, MPLS 1184 priority can be provided by using EXP bits, and layer 3 priority is 1185 controllable by using TOS. Switches and routers which the TDMoIP 1186 stream must traverse should be configured to respect these 1187 priorities. 1189 8. Security Considerations 1191 TDMoIP does not enhance or detract from the security performance of 1192 the underlying PSN, rather it relies upon the PSN's mechanisms for 1193 encryption, integrity, and authentication whenever required. The 1194 level of security provided may be less than that of a native TDM 1195 service. 1197 When MPLS is the PSN, PW-specific security mechanisms will generally 1198 be required, while for IP-based PSNs IPsec MAY be used. TDMoIP using 1199 L2TPv3 is subject to the security considerations discussed in section 1200 4.1.3 of [RFC3931]. 1202 TDMoIP shares susceptibility to a number of pseudowire-layer attacks 1203 (see [RFC3985]) and implementations SHOULD use whatever mechanisms 1204 for confidentiality, integrity, and authentication are developed for 1205 general PWs. These methods are beyond the scope of this document. 1207 Random initialization of sequence numbers, in both the control word 1208 and the optional RTP header, makes known-plaintext attacks on 1209 encrypted TDMoIP more difficult. Encryption of PWs is beyond the 1210 scope of this document. 1212 PW labels SHOULD be selected in an unpredictable manner rather than 1213 sequentially or otherwise in order to deter session hijacking. When 1214 using L2TPv3, randomly selected cookies MAY be used to validate 1215 circuit origin. 1217 Although TDMoIP MAY employ an RTP header when explicit transfer of 1218 timing information is required, SRTP (see [RFC3711]) mechanisms are 1219 not applicable. 1221 9. IANA Considerations 1223 For MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446]. 1225 For UDP/IP PSNs, when the source port is used to identify the TDM 1226 stream, the destination port number MUST be set to 0x085E (2142), the 1227 user port number assigned by IANA to TDMoIP. 1229 10. Applicability Statement 1231 It must be recognized that the emulation provided by TDMoIP may be 1232 imperfect, and the service may differ from of the native TDM circuit 1233 in the following ways. 1235 The end-to-end delay of a TDM circuit emulated using TDMoIP may 1236 exceed that of a native TDM circuit. 1238 When using adaptive clock recovery, the timing performance of the 1239 emulated TDM circuit depends on characteristics of the PSN, and thus 1240 may be inferior to that of a native TDM circuit. 1242 If the TDM structure overhead is not transported over the PSN, then 1243 non-FAS data in the overhead will be lost. 1245 When packets are lost in the PSN TDMoIP mechanisms ensure that frame 1246 synchronization will be maintained, and when packet loss events are 1247 properly concealed the effect on telephony channels will be 1248 perceptually minimized. However, the bit error rate will be degraded 1249 as compared to the native service. 1251 Data in inactive channels is not transported in AAL2 mode, and thus 1252 this data will differ from that of the native service. 1254 Native TDM connections are point-to-point, while PSNs are shared 1255 infrastructures. Hence the level of security of the emulated service 1256 may be less than that of the native service. 1258 11. Acknowledgments 1260 The authors would like to thank Hugo Silberman, Shimon HaLevy, Tuvia 1261 Segal, and Eitan Schwartz of RAD Data Communications for their 1262 invaluable contributions to the technology described herein. 1264 Authors' Addresses 1266 Yaakov (Jonathan) Stein 1267 RAD Data Communications 1268 24 Raoul Wallenberg St., Bldg C 1269 Tel Aviv 69719 1270 ISRAEL 1272 Phone: +972 3 645-5389 1273 Email: yaakov_s@rad.com 1275 Ronen Shashoua 1276 RAD Data Communications 1277 24 Raoul Wallenberg St., Bldg C 1278 Tel Aviv 69719 1279 ISRAEL 1281 Phone: +972 3 645-5447 1282 Email: ronen_s@rad.com 1284 Ron Insler 1285 RAD Data Communications 1286 24 Raoul Wallenberg St., Bldg C 1287 Tel Aviv 69719 1288 ISRAEL 1290 Phone: +972 3 645-5445 1291 Email: ron_i@rad.com 1293 Motty (Mordechai) Anavi 1294 RAD Data Communications 1295 900 Corporate Drive 1296 Mahwah, NJ 07430 1297 USA 1299 Phone: +1 201 529-1100 Ext. 213 1300 Email: motty@radusa.com 1302 Appendix A. Sequence Number Processing (informative) 1304 The sequence number field in the control word enables detection of 1305 lost and misordered packets. Here we give pseudocode for an example 1306 algorithm in order to clarify the issues involved. These issues are 1307 implementation specific and no single explanation can capture all the 1308 possibilities. 1310 In order to simplify the description modulo arithmetic is 1311 consistently used in lieu of ad-hoc treatment of the cyclicity. All 1312 differences between indexes are explicitly converted to the range 1313 [-2^15 ... +2^15 - 1] to ensure that simple checking of the 1314 difference's sign correctly predicts the packet arrival order. 1316 Furthermore, we introduce the notion of a playout buffer in order to 1317 unambiguously define packet lateness. When a packet arrives after 1318 having previously having been assumed lost, the TDM-bound IWF may 1319 discard it, and continue to treat it as lost. Alternatively if the 1320 filler data that had been inserted in its place has not yet been 1321 played out, the option remains to insert the true data into the 1322 playout buffer. Of course, the filler data may be generated upon 1323 initial detection of a missing packet or upon playout. This 1324 description is stated in terms of a packet-oriented playout buffer 1325 rather than a TDM byte oriented one; however this is not a true 1326 requirement for re-ordering implementations since the latter could be 1327 used along with pointers to packet commencement points. 1329 Having introduced the playout buffer we explicitly treat over-run and 1330 under-run of this buffer. Over-run occurs when packets arrive so 1331 quickly that they can not be stored for playout. This is usually an 1332 indication of gross timing inaccuracy or misconfiguration, and we can 1333 do little but discard such early packets. Under-run is usually a 1334 sign of network starvation, resulting from congestion or network 1335 failure. 1337 The external variables used by the pseudocode are: 1339 received: sequence number of packet received 1340 played: sequence number of the packet being played out (Note 1) 1341 over-run: is the playout buffer full? (Note 3) 1342 under-run: has the playout buffer been exhausted? (Note 3) 1344 The internal variables used by the pseudocode are: 1346 expected: sequence number we expect to receive next 1347 D: difference between expected and received (Note 2) 1348 L: difference between sequence numbers of packet being played out 1349 and that just received (Notes 1 and 2) 1351 In addition, the algorithm requires one parameter: 1353 R: maximum lateness of packet recoverable (Note 1). 1355 Note 1: this is only required for the optional re-ordering 1356 Note 2: this number is always in the range -2^15 ... +2^15 - 1 1357 Note 3: the playout buffer is emptied by the TDM playout process, 1358 which runs asynchronously to the packet arrival processing, 1359 and which is not herein specified 1361 Sequence Number Processing Algorithm 1363 Upon receipt of a packet 1364 if received = expected 1365 { treat packet as in-order } 1366 if not over-run then 1367 place packet contents into playout buffer 1368 else 1369 discard packet contents 1370 set expected = (received + 1) mod 2^16 1371 else 1372 calculate D = ( (expected-received) mod 2^16 ) - 2^15 1373 if D > 0 then 1374 { packets expected, expected+1, ... received-1 are lost } 1375 while not over-run 1376 place filler (all-ones or interpolation) into playout buffer 1377 if not over-run then 1378 place packet contents into playout buffer 1379 else 1380 discard packet contents 1381 set expected = (received + 1) mod 2^16 1382 else { late packet arrived } 1383 declare "received" to be a late packet 1384 do NOT update "expected" 1385 either 1386 discard packet 1387 or 1388 if not under-run then 1389 calculate L = ( (played-received) mod 2^16 ) - 2^15 1390 if 0 < L <= R then 1391 replace data from packet previously marked as lost 1392 else 1393 discard packet 1394 Note: by choosing R=0 we always discard the late packet 1396 Appendix B. AAL1 Review (informative) 1398 The first byte of the 48-byte AAL1 PDU always contains an error- 1399 protected three-bit sequence number. 1401 1 2 3 4 5 6 7 8 1402 +-+-+-+-+-+-+-+-+----------------------- 1403 |C| SN | CRC |P| 47 bytes of payload 1404 +-+-+-+-+-+-+-+-+----------------------- 1406 C (1 bit) convergence sublayer indication, its use here is limited 1407 to indication of the existence of a pointer (see below); C=0 means 1408 no pointer, C=1 means a pointer is present. 1410 SN (3 bits) The AAL1 sequence number increments from PDU to PDU. 1412 CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN. 1414 P (1 bit) even byte parity. 1416 As can be readily inferred, incrementing the sequence number forms an 1417 eight PDU sequence number cycle, the importance of which will become 1418 clear shortly. 1420 The structure of the remaining 47 bytes in the AAL1 PDU depends on 1421 the PDU type, of which there are three, corresponding to the three 1422 types of AAL1 circuit emulation service defined in [CES]. These are 1423 known as namely unstructured circuit emulation, structured circuit 1424 emulation and structured circuit emulation with CAS. 1426 The simplest PDU is the unstructured one, which is used for 1427 transparent transfer of whole circuits (T1,E1,T3,E3). Although AAL1 1428 provides no inherent advantage as compared to SAToP for unstructured 1429 transport, in certain cases AAL1 may be required or desirable. For 1430 example, when it is necessary to interwork with an existing AAL1- 1431 based network, or when clock recovery based on AAL1-specific 1432 mechanisms is favored. 1434 For unstructured AAL1 the 47 bytes after the sequence number byte 1435 contain the full 376 bits from the TDM bit stream. No frame 1436 synchronization is supplied or implied, and framing is the sole 1437 responsibility of the end-user equipment. Hence the unstructured 1438 mode can be used to carry data, and for circuits with nonstandard 1439 frame synchronization. For the T1 case the raw frame consists of 193 1440 bits, and hence 1 183/193 T1 frames fit into each AAL1 PDU. The E1 1441 frame consists of 256 bits, and so 1 15/32 E1 frames fit into each 1442 PDU. 1444 When the TDM circuit is channelized according to [G704], and in 1445 particular when it is desired to fractional E1 or T1, it is 1446 advantageous to use one of the structured AAL1 circuit emulation 1447 services. Structured AAL1 views the data not merely as a bit stream, 1448 but as a bundle of channels. Furthermore, when CAS signaling is used 1449 it can be formatted so that it can be readily detected and 1450 manipulated. 1452 In the structured circuit emulation mode without CAS, N bytes from 1453 the N channels to be transported are first arranged in order of 1454 channel number. Thus if channels 2, 3, 5, 7 and 11 are to be 1455 transported the corresponding five bytes are placed in the PDU 1456 immediately after the sequence number byte. This placement is 1457 repeated until all 47 bytes in the PDU are taken; 1459 byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47 1460 channel 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3 1462 the next PDU commences where the present PDU left off 1464 byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47 1465 channel 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7 1467 and so forth. The set of channels 2,3,5,7,11 is the basic structure 1468 and the point where one structure ends and the next commences is the 1469 structure boundary. 1471 The problem with this arrangement is the lack of explicit indication 1472 of the byte identities. As can be seen in the above example, each 1473 AAL1 PDU starts with a different channel, so a single lost packet 1474 will result in misidentifying channels from that point onwards, 1475 without possibility of recovery. The solution to this deficiency is 1476 the periodic introduction of a pointer to the next structure 1477 boundary. This pointer need not be used too frequently, as the 1478 channel identifications are uniquely inferable unless packets are 1479 lost. 1481 The particular method used in AAL1 is to insert a pointer once every 1482 sequence number cycle of eight PDUs. The pointer is seven bits and 1483 protected by an even parity MSB, and so occupies a single byte. 1484 Since seven bits are sufficient to represent offsets larger than 47, 1485 we can limit the placement of the pointer byte to PDUs with even 1486 sequence number. Unlike most AAL1 PDUs that contain 47 TDM bytes, 1487 PDUs that contain a pointer (P-format PDUs) have the following 1488 format. 1490 0 1 1491 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 1492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 1493 |C| SN | CRC |P|E| pointer | 46 bytes of payload 1494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 1496 where 1498 C (1 bit) convergence sublayer indication, C=1 for P-format PDUs. 1500 SN (3 bits) is an even AAL1 sequence number. 1502 CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN. 1504 P (1 bit) even byte parity LSB for sequence number byte. 1506 E (1 bit) even byte parity MSB for pointer byte. 1508 pointer (7 bits) pointer to next structure boundary. 1510 Since P-format PDUs have 46 bytes of payload and the next PDU has 47 1511 bytes, viewed as a single entity the pointer needs to indicate one of 1512 93 bytes. If P=0 it is understood that the structure commences with 1513 the following byte (i.e. the first byte in the payload belongs to the 1514 lowest numbered channel). P=93 means that the last byte of the 1515 second PDU is the final byte of the structure, and the following PDU 1516 commences with a new structure. The special value P=127 indicates 1517 that there is no structure boundary to be indicated (needed when 1518 extremely large structures are being transported). 1520 The P-format PDU is always placed at the first possible position in 1521 the sequence number cycle that a structure boundary occurs, and can 1522 only occur once per cycle. 1524 The only difference between the structured circuit emulation format 1525 and structured circuit emulation with CAS is the definition of the 1526 structure. Whereas in structured circuit emulation the structure is 1527 composed of the N channels, in structured circuit emulation with CAS 1528 the structure encompasses the superframe consisting of multiple 1529 repetitions of the N channels and then the CAS signaling bits. The 1530 CAS bits are tightly packed into bytes and the final byte is padded 1531 with zeros if required. 1533 For example, for E1 circuits the CAS signaling bits are updated once 1534 per superframe of 16 frames. Hence the structure for N*64 derived 1535 from an E1 with CAS signaling consists of 16 repetitions of N bytes, 1536 followed by N sets of the four ABCD bits, and finally four zero bits 1537 if N is odd. For example, the structure for channels 2,3 and 5 will 1538 be as follows 1540 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 1541 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2 ABCD3] [ABCD5 0000] 1543 Similarly for T1 ESF circuits the superframe is 24 frames, and the 1544 structure consists of 24 repetitions of N bytes, followed by the ABCD 1545 bits as before. For the T1 case the signaling bits will in general 1546 appear twice, in their regular (bit-robbed) positions and at the end 1547 of the structure. 1549 Appendix C. AAL2 Review (informative) 1551 The basic AAL2 PDU is : 1553 | Byte 1 | Byte 2 | Byte 3 | 1554 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------ 1556 | CID | LI | UUI | HEC | PAYLOAD 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------ 1559 CID (8 bits) channel identifier is an identifier that must be unique 1560 for the PW. The values 0-7 are reserved for special purposes, 1561 (and if interworking with VoDSL is required, so are values 8 1562 through 15 as specified in [LES]), thus leaving 248 (240) CIDs per 1563 PW. The mapping of CID values to channels MAY be manually 1564 configured manually or signaled. 1566 LI (6 bits) length indicator is one less than the length of the 1567 payload in bytes. Note that the payload is limited to 64 bytes. 1569 UUI (5 bits) user-to-user indication is the higher layer 1570 (application) identifier and counter. For voice data the UUI will 1571 always be in the range 0-15, and SHOULD be incremented modulo 16 1572 each time a channel buffer is sent. The receiver MAY monitor this 1573 sequence. UUI is set to 24 for CAS signaling packets. 1575 HEC (5 bits) the header error control 1577 Payload - voice A block of length indicated by LI of voice samples 1578 are placed as- is into the AAL2 packet. 1580 Payload - CAS signaling For CAS signaling the payload is formatted as 1581 an AAL2 "fully protected" (type 3) packet (see [AAL2]) in order to 1582 ensure error protection. The signaling is sent with the same CID 1583 as the corresponding voice channel. Signaling MUST be sent 1584 whenever the state of the ABCD bits changes, and SHOULD be sent 1585 with triple redundancy, i.e. sent three times spaced 5 1586 milliseconds apart. In addition, the entire set of the signaling 1587 bits SHOULD be sent periodically to ensure reliability. 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 |RED| timestamp | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | RES | ABCD | type | CRC 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 CRC (cont) | 1595 +-+-+-+-+-+-+-+-+ 1597 RED (2 bits) is the triple redundancy counter. For the first packet 1598 it takes the value 00, for the second 01 and for the third 10. 1599 RED=11 means non-redundant information, and is used when triple 1600 redundancy is not employed, and for periodic refresh messages. 1602 Timestamp (14 bits) The timestamp is optional and in particular is 1603 not needed if RTP is employed. If not used the timestamp MUST be 1604 set to zero. When used with triple redundancy it MUST be the same 1605 for all three redundant transmissions. 1607 RES (4 bits) is reserved and MUST be set to zero. 1609 ABCD (4 bits) are the CAS signaling bits. 1611 type (6 bits) for CAS signaling this is 000011. 1613 CRC-10 (10 bits) is a 10 bit CRC error detection code. 1615 Appendix D. Performance Monitoring Mechanisms (informative) 1617 PWs require OAM mechanisms to monitor performance measures that 1618 impact the emulated service. Performance measures, such as packet 1619 loss ratio and packet delay variation, may be used to set various 1620 parameters and thresholds; for TDMoIP PWs adaptive timing recovery 1621 and packet loss concealment algorithms may benefit from such 1622 information. In addition, OAM mechanisms may be used to collect 1623 statistics relating to the underlying PSN [RFC2330], and its 1624 suitability for carrying TDM services. 1626 TDMoIP IWFs may benefit from knowledge of PSN performance metrics, 1627 such as round trip time (RTT), packet delay variation (PDV) and 1628 packet loss ratio (PLR). These measurements are conventionally 1629 performed by a separate flow of packets designed for this purpose, 1630 e.g. ICMP packets [RFC792] or MPLS LSP ping packets [RFC4379] with 1631 multiple timestamps. For AAL1 mode TDMoIP sends packets across the 1632 PSN at a constant rate, and hence no additional OAM flow is required 1633 for measurement of PDV or PLR. However, separate OAM flows are 1634 required for RTT measurement, for AAL2 mode PWs, for measurement of 1635 parameters at setup, for monitoring of inactive backup PWs, and for 1636 low-rate monitoring of PSNs after PWs have been withdrawn due to 1637 service failures. 1639 If the underlying PSN has appropriate maintenance mechanisms that 1640 provide connectivity verification, RTT, PDV, and PLR measurements 1641 that correlate well with those of the PW, then these mechanisms 1642 SHOULD be used. If such mechanisms are not available, either of two 1643 similar OAM signaling mechanisms may be used. The first is internal 1644 to the PW and based on inband VCCV [VCCV], and the second is defined 1645 only for UDP/IP PSNs, and is based on a separate PW. The latter is 1646 particularly efficient for a large number of fate-sharing TDM PWs. 1648 D.1 TDMoIP Connectivity Verification 1650 In most conventional IP applications a server sends some finite 1651 amount of information over the network after explicit request from a 1652 client. With TDMoIP PWs the PSN-bound IWF could send a continuous 1653 stream of packets towards the destination without knowing whether the 1654 TDM-bound IWF is ready to accept them. For layer-2 networks this may 1655 lead to flooding of the PSN with stray packets. 1657 This problem may occur when a TDMoIP IWF is first brought up, when 1658 the TDM-bound IWF fails or is disconnected from the PSN, or the PW is 1659 broken. After an aging time the destination IWF becomes unknown, and 1660 intermediate switches may flood the network with the TDMoIP packets 1661 in an attempt to find a new path. 1663 The solution to this problem is to significantly reduce the number of 1664 TDMoIP packets transmitted per second when PW failure is detected, 1665 and to return to full rate only when the PW is available. The 1666 detection of failure and restoration is made possible by the periodic 1667 exchange of one-way connectivity-verification messages. 1669 Connectivity is tested by periodically sending OAM messages from the 1670 source IWF to the destination IWF, and having the destination reply 1671 to each message. The connectivity verification mechanism SHOULD be 1672 used during setup and configuration. Without OAM signaling one must 1673 ensure that the destination IWF is ready to receive packets before 1674 starting to send them. Since TDMoIP IWFs operate full-duplex, both 1675 would need to be set up and properly configured simultaneously if 1676 flooding is to be avoided. When using connectivity verification, a 1677 configured IWF may wait until it detects its peer before transmitting 1678 at full rate. In addition, configuration errors may be readily 1679 discovered by using the service specific field of the OAM PW packets. 1681 In addition to one way connectivity, OAM signaling mechanisms can be 1682 used to request and report on various PSN metrics, such as one way 1683 delay, round trip delay, packet delay variation, etc. They may also 1684 be used for remote diagnostics, and for unsolicited reporting of 1685 potential problems (e.g. dying gasp messages). 1687 D.2 OAM Packet Format 1689 When using inband performance monitoring, additional packets are sent 1690 using the same PW label. These packets are identified by having 1691 their first nibble equal to 0001, and must be separated from TDM data 1692 packets before further processing of the control word. 1694 When using a separate OAM PW, all OAM messages MUST use the PW label 1695 preconfigured to indicate OAM. All PSN layer parameters MUST remain 1696 those of the PW being monitored. 1698 The format of an inband OAM PW message packet for UDP/IP PSNs is 1699 based on [RFC2679]. The PSN-specific layers are identical to those 1700 defined in Section 4.1 with the PW label set to the value 1701 preconfigured or assigned for PW OAM. 1703 0 1 2 3 1704 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 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | PSN-specific layers (with preconfigured PW label) | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 |0 0 0 0|L|R| M |RES| Length | OAM Sequence Number | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | OAM Msg Type | OAM Msg Code | Service specific information | 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Forward PW label | Reverse PW label | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | Source Transmit Timestamp | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 | Destination Receive Timestamp | 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 | Destination Transmit Timestamp | 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1721 L, R, and M are identical to those of the PW being tested. 1723 Length is the length in bytes of the OAM message packet. 1725 OAM Sequence Number (16 bits) is used to uniquely identify the 1726 message. Its value is unrelated to the sequence number of the 1727 TDMoIP data packets for the PW in question. It is incremented in 1728 query messages, and replicated without change in replies. 1730 OAM Msg Type (8 bits) indicates the function of the message. At 1731 present the following are defined: 1733 0 for one way connectivity query message 1734 8 for one way connectivity reply message. 1736 OAM Msg Code (8 bits) is used to carry information related to the 1737 message, and its interpretation depends on the message type. For 1738 type 0 (connectivity query) messages the following codes are 1739 defined: 1741 0 validate connection. 1742 1 do not validate connection 1744 for type 8 (connectivity reply) messages the available codes are: 1746 0 acknowledge valid query 1747 1 invalid query (configuration mismatch). 1749 Service specific information (16 bits) is a field that can be used to 1750 exchange configuration information between IWFs. If it is not 1751 used this field MUST contain zero. Its interpretation depends on 1752 the payload type. At present the following is defined for AAL1 1753 payloads. 1755 0 1 1756 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | Number of TSs | Number of SFs | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 Number of TSs (8 bits) is the number of channels being transported, 1762 e.g. 24 for full T1. 1764 Number of SFs (8 bits) is the number of 48-byte AAL1 PDUs per packet, 1765 e.g. 8 when packing 8 PDUs per packet. 1767 Forward PW label (16 bits) is the PW label used for TDMoIP traffic 1768 from the source to destination IWF. 1770 Reverse PW label (16 bits) is the PW label used for TDMoIP traffic 1771 from the destination to source IWF. 1773 Source Transmit Timestamp (32 bits) represents the time the PSN-bound 1774 IWF transmitted the query message. This field and the following 1775 ones only appear if delay is being measured. All time units are 1776 derived from a clock of preconfigured frequency, the default being 1777 100 microseconds. 1779 Destination Receive Timestamp (32 bits) represents the time the 1780 destination IWF received the query message. 1782 Destination Transmit Timestamp (32 bits) represents the time the 1783 destination IWF transmitted the reply message. 1785 Appendix E. Capabilities, Configuration and Statistics (informative) 1787 Every TDMoIP IWF will support some number of physical TDM 1788 connections, certain types of PSN, and some subset of the modes 1789 defined above. The following capabilities SHOULD be able to be 1790 queried by the management system: 1792 AAL1 capable 1794 AAL2 capable (and AAL2 parameters, e.g. support for VAD and 1795 compression) 1797 HDLC capable 1799 Supported PSN types (UDP/IPv4, UDP/IPv6, L2TPv3/IPv4, L2TPv3/IPv6, 1800 MPLS, Ethernet) 1802 OAM support (none, separate PW, VCCV) and capabilities (CV, delay 1803 measurement, etc.) 1805 maximum packet size supported. 1807 For every TDM PW the following parameters MUST be provisioned or 1808 signaled: 1810 PW label (for UDP and Ethernet the label MUST be manually 1811 configured) 1813 TDM type (E1, T1, E3, T3, fractional E1, fractional T1) 1815 for fractional links: number of timeslots 1817 TDMoIP mode (AAL1, AAL2, HDLC) 1819 for AAL1 mode: 1821 AAL1 type (unstructured, structured, structured with CAS) 1823 number of AAL1 PDUs per packet 1825 for AAL2 mode: 1827 CID mapping 1829 creation time of full minicell (units of 125 microsecond) 1831 size of jitter buffer (in 32-bit words) 1833 clock recovery method (local, loop-back timing, adaptive, common 1834 clock) 1836 use of RTP (if used: frequency of common clock, PT and SSRC 1837 values). 1839 During operation the following statistics and impairment indications 1840 SHOULD be collected for each TDM PW, and can be queried by the 1841 management system. 1843 average round-trip delay 1845 packet delay variation (maximum delay - minimum delay) 1847 number of potentially lost packets 1849 indication of misordered packets (succesfully reordered or 1850 dropped) 1852 for AAL1 mode PWs: 1854 indication of malformed PDUs (incorrect CRC, bad C, P or E) 1856 indication of cells with pointer mismatch 1858 number of seconds with jitter buffer over-run events 1860 number of seconds with jitter buffer under-run events 1862 for AAL2 mode PWs: 1864 number of malformed minicells (incorrect HEC) 1866 indication of misordered minicells (unexpected UUI) 1868 indication of stray minicells (CID unknown, illegal UUI) 1870 indication of mis-sized minicells (unexpected LI) 1872 for each CID: number of seconds with jitter buffer over-run 1873 events 1875 for HDLC mode PWs: 1877 number of discarded frames from TDM (e.g. CRC error, illegal 1878 packet size) 1879 number of seconds with jitter buffer over-run events. 1881 During operation the following statistics MAY be collected for each 1882 TDM PW. 1884 number of packets sent to PSN 1886 number of packets received from PSN 1888 number of seconds during which packets were received with L flag 1889 set 1891 number of seconds during which packets were received with R flag 1892 set. 1894 Appendix F. References 1896 F.1 Normative References 1898 [AAL1] ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM Adaptation 1899 Layer (AAL) specification: Type 1 1901 [AAL2] ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM Adaptation 1902 Layer (AAL) specification: Type 2 1904 [CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit 1905 Emulation Service Interoperability Specification Ver. 2.0 1907 [G704] ITU-T Recommendation G.704 (10/98) - Synchronous frame 1908 structures used at 1544, 6312, 2048, 8448 and 44736 kbit/s 1909 hierarchical levels 1911 [G751] ITU-T Recommendation G.751 (11/88) - Digital multiplex 1912 equipments operating at the third order bit rate of 34368 kbit/s 1913 and the fourth order bit rate of 139264 kbit/s and using positive 1914 justification 1916 [G823] ITU-T Recommendation G.823 (03/00) - The control of jitter and 1917 wander within digital networks which are based on the 2048 Kbit/s 1918 hierarchy 1920 [G824] ITU-T Recommendation G.824 (03/00) - The control of jitter and 1921 wander within digital networks which are based on the 1544 Kbit/s 1922 hierarchy 1924 [G826] ITU-T Recommendation G.826 (13/02) - End-to-end error 1925 performance parameters and objectives for international, constant 1926 bit-rate digital paths and connections 1928 [IEEE802.1Q] IEEE 802.1Q, IEEE Standards for Local and Metropolitan 1929 Area Networks -- Virtual Bridged Local Area Networks (2003) 1931 [IEEE802.3] IEEE 802.3, IEEE Standard Local and Metropolitan Area 1932 Networks - Carrier Sense Multiple Access with Collision Detection 1933 (CSMA/CD) Access Method and Physical Layer Specifications (2002) 1935 [LES] ATM forum specification atm-vmoa-0145 (LES) Voice and 1936 Multimedia over ATM - Loop Emulation Service Using AAL2 1938 [MEF8] Metro Ethernet Forum, "Implementation Agreement for the 1939 Emulation of PDH Circuits over Metro Ethernet Networks, October 1940 2004. 1942 [RFC768] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, 1943 August 1980. 1945 [RFC791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791, 1946 September 1981. 1948 [RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement 1949 Levels", RFC 2119, March 1997. 1951 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1952 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", 1953 RFC 3032, January 2001. 1955 [RFC3931] Lau, J., Townsley, M., Goyret, I., "Layer Two Tunneling 1956 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1958 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, 1959 V., "RTP: A Transport Protocol for Real-Time Applications", STD 1960 64, RFC 3550, July 2003. 1962 [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge 1963 Emulation (PWE3)", BCP 116, RFC 4446, April 2006. 1965 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1966 Heron, "Pseudowire Setup and Maintenance Using the Label 1967 Distribution Protocol (LDP)", RFC 4447, April 2006. 1969 [RFC4553] Vainshtein A., and Stein YJ., "Structure-Agnostic TDM over 1970 Packet (SAToP)", RFC 4553, June 2006. 1972 [RFC4618] Martini L., Rosen E., Heron G., and Malis A., 1973 "Encapsulation Methods for Transport of PPP/High-Level Data Link 1974 Control (HDLC) over MPLS Networks", RFC 4618, September 2006. 1976 [SSCS] ITU-T Recommendation I.366.2 (11/00) - AAL type 2 service 1977 specific convergence sublayer for narrow-band services. 1979 [VCCV] draft-ietf-pwe3-vccv-06.txt (08/05) - Pseudo Wire Virtual 1980 Circuit Connectivity Verification, T. Nadeau and R. Aggarwal, work 1981 in progress. 1983 [Y1413] ITU-T Recommendation Y.1413 (03/04) - TDM-MPLS network 1984 interworking - User plane interworking 1986 [Y1414] ITU-T Recommendation Y.1414 (07/04) - Voice services - MPLS 1987 network interworking. 1989 [Y1452] ITU-T Recommendation Y.1452 (03/06) - Voice trunking over IP 1990 networks. 1992 [Y1453] ITU-T Recommendation Y.1453 (03/06) - TDM-IP interworking - 1993 User plane interworking. 1995 F.2 Informative References 1997 [CESoPSN] draft-ietf-cesopsn-07.txt, TDM Circuit Emulation Service 1998 over Packet Switched Network, A. Vainshtein et al, work in 1999 progress, May 2006. 2001 [ISDN-PRI] ITU-T Recommendation Q.931 (05/98) - ISDN user-network 2002 interface layer 3 specification for basic call control. 2004 [RFC792] Postel J., "Internet Control Message Protocol", STD 5, RFC 2005 792, September 1981. 2007 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 2008 of Guaranteed Quality of Service", RFC 2212, September 1997. 2010 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis M., "Framework 2011 for IP Performance Metrics", RFC 2330, May 1998. 2013 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2014 "Definition of the Differentiated Services Field (DS Field) in the 2015 IPv4 and IPv6 Headers", RFC 2474, December 1998. 2017 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 2018 and W. Weiss, "An Architecture for Differentiated Service", RFC 2019 2475, December 1998. 2021 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 2022 Delay Metric for IPPM", RFC 2679, September 1999. 2024 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2025 2914, September 2000. 2027 [RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, 2028 J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An 2029 Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2030 2002. 2032 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2033 Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 2034 3711, March 2004. 2036 [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge- to- 2037 Edge (PWE3) Architecture", RFC 3985, March 2005. 2039 [RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of 2040 Time Division Multiplexed (TDM) Circuits over Packet Switching 2041 Networks", RFC 4197, October 2005. 2043 [RFC4379] Kompella, K. and Swallow, G., "Detecting Multi-Protocol 2044 Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2045 2006. 2047 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 2048 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use 2049 over an MPLS PSN", RFC 4385, February 2006. 2051 [SS7] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT 2052 Signalling System No. 7. 2054 [TDM-CONTROL] Vainshtein, A. and Stein, Y(J), "Control Protocol 2055 Extensions for Setup of TDM Pseudowires", Work in Progress, July 2056 2005. 2058 [TRAU] GSM 08.60 (10/01) - Digital cellular telecommunications system 2059 (Phase 2+); Inband control of remote transcoders and rate adaptors 2060 for Enhanced Full Rate (EFR) and full rate traffic channels. 2062 Intellectual Property Statement 2064 The IETF takes no position regarding the validity or scope of any 2065 Intellectual Property Rights or other rights that might be claimed to 2066 pertain to the implementation or use of the technology described in 2067 this document or the extent to which any license under such rights 2068 might or might not be available; nor does it represent that it has 2069 made any independent effort to identify any such rights. Information 2070 on the procedures with respect to rights in RFC documents can be 2071 found in BCP 78 and BCP 79. 2073 Copies of IPR disclosures made to the IETF Secretariat and any 2074 assurances of licenses to be made available, or the result of an 2075 attempt made to obtain a general license or permission for the use of 2076 such proprietary rights by implementers or users of this 2077 specification can be obtained from the IETF on-line IPR repository at 2078 http://www.ietf.org/ipr. 2080 The IETF invites any interested party to bring to its attention any 2081 copyrights, patents or patent applications, or other proprietary 2082 rights that may cover technology that may be required to implement 2083 this standard. Please address the information to the IETF at 2084 ietf-ipr@ietf.org. 2086 Disclaimer of Validity 2088 This document and the information contained herein are provided on an 2089 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2090 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2091 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2092 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2093 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2094 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2096 Copyright Statement 2098 Copyright (C) The Internet Society (2006). This document is subject 2099 to the rights, licenses and restrictions contained in BCP 78, and 2100 except as set forth therein, the authors retain all their rights. 2102 Acknowledgment 2104 Funding for the RFC Editor function is currently provided by the 2105 Internet Society.