idnits 2.17.1 draft-anavi-tdmoip-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** There are 69 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 146: '... fixed RTP header described in [RTP], MUST immediately precede the...' RFC 2119 keyword, line 147: '...IPv4 or IPv6 PSN, and MUST immediately...' RFC 2119 keyword, line 150: '... MUST be set to zero, and the PT val...' RFC 2119 keyword, line 151: '...TP sequence number SHOULD be identical...' RFC 2119 keyword, line 170: '...bit control word MUST appear in every ...' (47 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 26, 2003) is 7459 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: 'PWE-REQ' is mentioned on line 82, but not defined == Missing Reference: 'PWE-ARCH' is mentioned on line 757, but not defined == Missing Reference: 'G.704' is mentioned on line 90, but not defined == Missing Reference: 'IP' is mentioned on line 232, but not defined == Missing Reference: 'ABCD2 ABCD3' is mentioned on line 660, but not defined == Missing Reference: 'ABCD5 0000' is mentioned on line 660, but not defined == Unused Reference: 'DELAY' is defined on line 1071, but no explicit reference was found in the text == Unused Reference: 'IPv4' is defined on line 1087, but no explicit reference was found in the text == Unused Reference: 'PWE3-ARCH' is defined on line 1118, but no explicit reference was found in the text == Unused Reference: 'PWE3-REQ' is defined on line 1121, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AAL1' -- Possible downref: Non-RFC (?) normative reference: ref. 'AAL2' -- Possible downref: Non-RFC (?) normative reference: ref. 'CES' ** Obsolete normative reference: RFC 2679 (ref. 'DELAY') (Obsoleted by RFC 7679) -- Possible downref: Non-RFC (?) normative reference: ref. 'G704' -- Possible downref: Non-RFC (?) normative reference: ref. 'G823' -- Possible downref: Non-RFC (?) normative reference: ref. 'G824' ** Downref: Normative reference to an Informational RFC: RFC 2330 (ref. 'IPPM') -- Possible downref: Non-RFC (?) normative reference: ref. 'LES' == Outdated reference: A later version (-15) exists of draft-ietf-l2tpext-l2tp-base-10 == Outdated reference: A later version (-05) exists of draft-ietf-pwe3-satop-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'SSCS' -- Possible downref: Non-RFC (?) normative reference: ref. 'TRAU' == Outdated reference: A later version (-07) exists of draft-vainshtein-cesopsn-06 -- No information found for draft-ietf - is the name correct? == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-requirements-06 == Outdated reference: A later version (-08) exists of draft-ietf-pwe3-tdm-requirements-01 Summary: 5 errors (**), 0 flaws (~~), 17 warnings (==), 12 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: April 25, 2004 R. Insler 5 M. Anavi 6 RAD Data Communications 7 October 26, 2003 9 TDM over IP 10 draft-anavi-tdmoip-06.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 25, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This document describes methods for transporting time division 42 multiplexed (TDM) digital voice and data signals over Pseudowires. 43 It is a revision of the document draft-anavi-tdmoip-05. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 4 49 3. Encapsulation Details for Specific PSNs . . . . . . . . . . . 6 50 3.1 UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 51 3.2 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 52 3.3 L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 53 3.4 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 54 4. TDMoIP Payload types . . . . . . . . . . . . . . . . . . . . . 10 55 4.1 AAL1 Format Payload . . . . . . . . . . . . . . . . . . . . . 11 56 4.2 AAL2 Format Payload . . . . . . . . . . . . . . . . . . . . . 15 57 4.3 HDLC Format Payload . . . . . . . . . . . . . . . . . . . . . 17 58 5. OAM Signaling . . . . . . . . . . . . . . . . . . . . . . . . 18 59 5.1 Connectivity-Check Messages . . . . . . . . . . . . . . . . . 18 60 5.2 Performance Measurements . . . . . . . . . . . . . . . . . . . 19 61 5.3 OAM Packet Format . . . . . . . . . . . . . . . . . . . . . . 19 62 6. Implementation Issues . . . . . . . . . . . . . . . . . . . . 21 63 6.1 Quality of Service . . . . . . . . . . . . . . . . . . . . . . 21 64 6.2 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 65 6.3 Jitter and Packet Loss . . . . . . . . . . . . . . . . . . . . 22 66 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 67 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 68 9. Normative References . . . . . . . . . . . . . . . . . . . . . 24 69 10. Informative References . . . . . . . . . . . . . . . . . . . . 25 70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 27 74 1. Introduction 76 Telephony traffic is conventionally carried over connection- oriented 77 synchronous or plesiochronous links (loosely called TDM circuits 78 herein). With the proliferation of packet-switched networks (PSNs), 79 integration of TDM services into a unified PSN infrastructure has 80 become desirable. Such integration requires emulation of TDM 81 circuits within the PSN, a function that can be carried out using 82 Pseudo-Wires (PWs), as described in the PWE3 requirements [PWE-REQ] 83 and architecture [PWE-ARCH] documents. This emulation must ensure 84 QoS and voice quality similar to those of existing TDM networks as 85 well as preserving signaling features, as described in the TDM PW 86 requirements document [TDM-REQ]. 88 SAToP [SAToP] is a structure-agnostic protocol for transporting TDM 89 over PWs. SAToP completely disregards any structure that may exist 90 in the TDM bit-stream, such as T1 or E1 framing described in [G.704], 91 or that of the GSM Abis channel described in [TRAU]. Hence SAToP is 92 ideal for transport of unstructured TDM data, and also eminently 93 suitable for transport of structured TDM when there is no need to 94 interpret or manipulate individual timeslots. In particular, SAToP 95 is the technique of choice for PSNs with low packet loss, and for 96 applications that do not require discrimination between timeslots nor 97 intervention in TDM signaling. 99 When it is required or desirable to explicitly safeguard TDM 100 structure, this can be accomplished in three conceptually distinct 101 ways, namely structure-locking, structure-indication, and structure- 102 reassembly. Structure-locking ensures that packets consist of entire 103 TDM structures or multiples thereof. Structure-indication allows 104 packets to contain arbitrary fragments of basic structures, and 105 employs pointers to indicate where a structure commences. In 106 structure-reassembly the individual timeslots are extracted and 107 reorganized at ingress, and the original structure reassembled from 108 the received constituents at egress. 110 All three methods of TDM structure preservation have their 111 advantages. Structure-locking is described in [CESoPSN], while the 112 present document describes TDMoIP, which specifies both structure- 113 indication (see Section 4.1) and structure-reassembly (see Section 114 4.2) approaches. The necessity for two different approaches will be 115 explained below. 117 Despite its name, the TDMoIP protocol herein described allows several 118 types of PSN, including UDP over IPv4 or IPv6, MPLS, L2TPv3 over IP, 119 or pure Ethernet. Implementation specifics for particular PSNs are 120 discussed in Section 3. Although the protocol should be more 121 generally called TDMoPW and its specific implementations TDMoIP, 122 TDMoMPLS, etc. we will use the nomenclature TDMoIP for reasons of 123 consistency with previous versions of this draft. 125 2. TDMoIP Encapsulation 127 The overall format of TDMoIP packets is shown in the following 128 figure. 130 +----------------+ 131 | PSN headers | 132 +----------------+ 133 | control word | 134 +----------------+ 135 | payload | 136 +----------------+ 138 The PSN-specific headers contain all necessary infrastructure, and 139 may consist of UDP/IP, L2TPv3 over IP, MPLS or layer 2 Ethernet. The 140 PSN is assumed to be reliable enough and of sufficient bandwidth to 141 enable transport of the required TDM data. 143 In addition to the aforementioned headers, an optional 12-byte RTP 144 header may appear in order to provide a mechanism for explicit 145 transfer of timing information in the packet. If RTP is used, the 146 fixed RTP header described in [RTP], MUST immediately precede the 147 control word in case of an IPv4 or IPv6 PSN, and MUST immediately 148 follow it in the case of an MPLS PSN. The P (padding), X (header 149 extension), CC (CSRC count), and M (marker) fields in the RTP header 150 MUST be set to zero, and the PT values MUST be allocated from the 151 range of dynamic values. The RTP sequence number SHOULD be identical 152 to the sequence number in the TDMoIP control word (see below). When 153 the TDMoIP edge devices have sufficiently accurate local clocks or 154 can derive a sufficiently accurate timing source without explicit 155 timestamps, the RTP header is omitted. 157 If a TDMoIP edge device is required to handle multiple circuit 158 bundles, then it is the responsibility of the PSN-specific layers to 159 provide a circuit bundle identifier (CBID) in order to enable 160 differentiation between these circuits. A circuit bundle is defined 161 as a stream of bits that have originated from a single physical 162 interface or from interfaces that share a common clock, which are 163 transmitted from a single TDMoIP source device to a single TDMoIP 164 destination device. For example, bundles may comprise some number of 165 64 Kbps timeslots originating from a single E1, or an entire T3 or 166 E3. Circuit bundles are uni-direction streams, but are universally 167 coupled with bundles in the opposite direction to form a bi- 168 directional connection. 170 The 32-bit control word MUST appear in every TDMoIP packet. Its 171 format is given in the following figure. 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 |FORMID |L|R| RES | Length | Sequence Number | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 FORMID Format identifier (4 bits) is an OPTIONAL field that specifies 180 the payload format. When it is not used it must be set to zero. 181 The following values are presently defined: 183 1100 AAL1 unstructured 184 1101 AAL1 structured 185 1110 AAL1 structured with CAS 186 1001 AAL2 187 1111 HDLC 189 The payload format for each of these cases will be described 190 later. 192 L Local Loss of Sync failure (1 bit) The L bit being set indicates 193 that the source has detected or has been informed of a TDM 194 physical layer fault impacting the data to be transmitted. This 195 bit can be used to indicate Physical layer LOS that should trigger 196 AIS generation at the far end. When the L bit is set the contents 197 of the packet may not be meaningful, and the payload size MAY be 198 reduced in order to conserve bandwidth. Once set, if the TDM 199 fault is rectified the L bit MUST be cleared. 201 R Remote Receive failure (1 bit) The R bit being set indicates that 202 the source is not receiving packets at its TDMoIP receive port, 203 indicating failure of that direction of the bi-directional 204 connection. This indication can be used to signal congestion or 205 other network related faults. Receiving remote failure indication 206 MAY trigger fall-back mechanisms for congestion avoidance. The R 207 bit MUST be set after a preconfigured number of consecutive 208 packets are not received, and MUST be cleared once packets are 209 once again received. 211 RES (4 bits) These bits are reserved and MUST be set to zero. 213 Length (6 bits) is used to indicate the length of the TDMoIP packet 214 (control word and payload), in case padding is employed to meet 215 minimum transmission unit requirements of the PSN. It MUST be 216 used if the total packet length (including PSN, optional RTP, 217 control word, and payload) is less than 64 bytes, and MUST be set 218 to zero if not used. 220 Sequence number (16 bits) The TDMoIP sequence number provides the 221 common PW sequencing function, and enables detection of lost 222 packets. Since the basic clock rate for each circuit bundle is 223 constant, the sequence number may also be used as an approximate 224 timestamp. The initial value of the sequence number SHOULD be 225 random (unpredictable) for security purposes, and its value is 226 incremented modulo 2^16 separately for each circuit bundle. 228 3. Encapsulation Details for Specific PSNs 230 3.1 UDP/IP 232 The UDP/IP header as described in [UDP] and [IP] is prefixed to the 233 TDMoIP data. The TDMoIP packet structure is as follows: 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | IPVER | IHL | IP TOS | Total Length | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Identification |Flags| Fragment Offset | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Time to Live | Protocol | IP Header Checksum | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Source IP Address | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Destination IP Address | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | VER | CBID | Destination Port Number | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | UDP Length | UDP Checksum | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 opt|RTV|P|X| CC |M| PT | RTP Sequence Number |opt 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 opt| Timestamp |opt 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 opt| SSRC identifier |opt 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |FORMID |L|R| RES | Length | Sequence Number | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 | TDMoIP Payload | 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 The first five rows are the IP header, the sixth and seventh rows are 266 the UDP header. Rows 8 through 10 are the optional RTP header. Row 267 11 is the TDMoIP control word. 269 IPVER (4 bits) is the IP version number, e.g. for IPv4 IPVER=4. 271 IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5. 273 IP TOS (8 bits) is the IP type of service. 275 Total Length (16 bits) is the length in octets of header and data. 277 Identification (16 bits) is the IP fragmentation identification 278 field. 280 Flags (3 bits) are the IP control flags and MUST be set to Flags=010 281 to avoid fragmentation. 283 Fragment Offset (13 bits) indicates where in the datagram the 284 fragment belongs and is not used for TDMoIP. 286 Time to Live (8 bits) is the IP time to live field. Datagrams with 287 zero in this field are to be discarded. 289 Protocol (8 bits) MUST be set to 0x11 to signify UDP. 291 IP Header Checksum (16 bits) is a checksum for the IP header. 293 Source IP Address (32 bits) is the IP address of the source. 295 Destination IP Address (32 bits) is the IP address of the 296 destination. 298 VER (3 bits) is the TDMoIP version number. The original version 299 (VER=000) was experimental and should no longer be used. 300 Presently VER=001 when RTP is not used, and VER=011 when RTP is 301 used. 303 CBID Circuit Bundle Identifier (13 bits) This field is usually 304 dedicated to the Source Port Number, but here identifies the 305 unique data stream emanating from a given trunk and sharing a 306 common destination. This nonstandard use of a UDP port number is 307 similar to RTP/RTCP's use of port numbers to uniquely identify 308 sessions, and the common practice (sanctioned in H.225) of 309 randomly allocating port numbers for VoIP sessions. Here placing 310 the circuit bundle identifier in the UDP header rather than the 311 application area enables fast switching. The available circuit 312 bundle numbers are 1-8063; 0 is invalid; 8191 (1FFF) is used for 313 OAM control messages (see Section 5); and the 127 ports 8064-8190 314 are reserved. 316 Destination Port Number (16 bits) MUST be set to 0x085E (2142), the 317 user port number which has been assigned to TDMoIP by the Internet 318 Assigned Numbers Authority (IANA). 320 UDP Length (16 bits) is the length in octets of UDP header and data. 322 UDP Checksum (16 bits) is the checksum of UDP/IP header and data. If 323 not computed it must be set to zero. 325 3.2 MPLS 327 The MPLS header as described in [MPLS] is prefixed to the TDMoIP 328 data. The packet structure (as seen at the edges) is as follows: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Outer Label | EXP |S| TTL | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Inner Label = CBID | EXP |S| TTL | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 |FORMID |L|R| RES | Length | Sequence Number | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | 340 | PAYLOAD | 341 | | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 The first two rows depicted above are the MPLS header; the third is 345 the TDMoIP control word. 347 Outer Label (20 bits) is the MPLS label that identifies the MPLS LSP 348 used to tunnel the TDM packets through the MPLS network. It is 349 also known as the tunnel label or the transport label. The label 350 number can be assigned either by manual provisioning or via the 351 MPLS control protocol. While transiting the MPLS network there 352 can be zero, one or more outer label rows. For label stack usage 353 see [MPLS]. 355 EXP (3 bits) experimental field 357 S (1 bit) stacking bit where 1 indicates stack bottom S=0 for all 358 outer labels 360 TTL (8 bits) MPLS Time to live 362 Inner Label (20 bits) the MPLS inner label (also known as the PW 363 label or the interworking label), contains the circuit bundle 364 identifier used to multiplex multiple circuit bundles within the 365 same tunnel. Valid values are as in the pervious subsection. 366 Note that the inner label is always be at the bottom of the MPLS 367 label stack, and hence its stacking bit is set. 369 3.3 L2TPv3 371 If L2TP is used over IPv4 without UDP the L2TPv3 header defined in 372 [L2TPv3] is prefixed to the TDMoIP data. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Session ID = CBID | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | cookie 1 (optional) | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | cookie 2 (optional) | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 |FORMID |L|R| RES | Length | Sequence Number | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | | 386 | PAYLOAD | 387 | | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Session ID (32 bits) is the locally significant L2TP session 391 identifier, and contains the circuit bundle identifier used to 392 multiplex multiple circuit bundles within the same tunnel. Valid 393 values are as in subsection 3.1 supra. 395 Cookie (32 or 64 bits) is an optional field that contains a randomly 396 selected value that can be used to validate association of the 397 received frame with the expected circuit bundle. 399 3.4 Ethernet 401 The TDMoIP packet described in the previous subsections will 402 frequently be further encapsulated in an Ethernet frame by prefixing 403 the Ethernet preamble, destination and source MAC addresses, optional 404 VLAN header, etc. and appending the four octet frame check sequence 405 after the TDMoIP frame. TDMoIP implementations MUST be able to 406 receive both industry standard (DIX) Ethernet and IEEE 802.3 CSMA/CD 407 frames and SHOULD transmit Ethernet frames. 409 Ethernet encapsulation introduces restrictions on both minimum and 410 maximum packet size. Whenever the entire TDMoIP packet is less than 411 64 bytes, zero padding is introduced and the true length indicated by 412 using the Length field in the control word. In order to avoid 413 fragmentation the TDMoIP packet must be restricted to the maximum 414 payload size. For example, the length of the Ethernet payload for a 415 non-RTP AAL2 adapted E1 trunk with 31 channels is 8*4 + 31*47 = 1489 416 octets. This falls below the maximal permitted payload size of 1500 417 bytes. 419 Layer 2 Ethernet frames can be directly used for TDMoIP transport 420 without IP or MPLS layers. In this case the CBID is be carried in an 421 MPLS-style inner label, and hence the Ethernet protocol type may be 422 reasonably set to MPLS. 424 +----------------------+ 425 | destination address | 426 +----------------------+ 427 | source address | 428 +----------------------+ 429 | VLAN tag (optional) | 430 +----------------------+ 431 | protocol type | 432 +----------------------+ 433 | inner label | 434 +----------------------+ 435 | control word | 436 +----------------------+ 437 | payload | 438 +----------------------+ 439 | CRC | 440 +----------------------+ 442 4. TDMoIP Payload types 444 TDMoIP is a trunking application, i.e. it transports entire trunks 445 containing multiple voice and/or data streams. Trunking can be 446 carried out at two levels - circuit emulation and loop emulation. 447 Circuit emulation is a structure-indication method of transporting 448 TDM in which the TDM trunk (circuit) bit-stream is transferred across 449 the network intact, without separation into individual timeslots. 450 Loop emulation is a structure-reassembly method whereby the 451 individual timeslots (loops) are identified and transported, albeit 452 while preserving the trunk integrity. 454 TDMoIP uses constant-rate AAL1 [AAL1,CES] for circuit emulation, 455 while variable-rate AAL2 [AAL2] is employed for loop emulation. 456 Additionally, a third mode is defined specifically for transport of 457 HDLC-based CCS signaling. 459 The AAL1 mode must be used for structured transport of data and is 460 recommended for trunks with relatively constant usage. AAL2 may be 461 used to conserve bandwidth for voice-carrying trunks in which usage 462 is highly variable. The HDLC mode is mainly for efficient transport 463 of trunk-associated CCS signaling. 465 The AAL family of protocols is a natural choice for trunking 466 applications. Although originally developed to adapt various types 467 of application data to the rigid format of ATM, the mechanisms are 468 general solutions to the problem of transporting constant or variable 469 bandwidth data streams over a packet network. 471 In addition, since the AAL mechanisms are extensively used within and 472 on the edge of the telephony system, they were specifically designed 473 for audio, non-audio data and telephony signaling. 475 Finally, simple service interworking with legacy networks is a major 476 design goal of TDMoIP. Re-uses of AAL technologies simplifies 477 interworking with existing AAL1 and AAL2 networks. 479 4.1 AAL1 Format Payload 481 For the prevalent case for which the timeslot allocation is static 482 and no activity detection is performed, the payload can be 483 efficiently encoded using constant bit rate AAL1 adaptation. The 484 AAL1 format is described in [AAL1] and its use for circuit emulation 485 over ATM in [CES]. We will herein briefly describe the use of AAL1 486 in the context of TDMoIP; the reader will find the full description 487 in the normative references. 489 In AAL1 mode the TDMoIP payload consists of between one and thirty 490 48-octet subframes. The number of subframes is pre-configured and 491 typically chosen according to latency and bandwidth constraints. 492 Using a single subframe reduces latency to a minimum, but incurs the 493 highest overhead, while using, for example, eight subframes reduces 494 the overhead percentage while increasing the latency by a factor of 495 eight. 497 +-------------+-----------------+ 498 |control word |48-octet subframe| 499 +-------------+-----------------+ 501 Single AAL1 subframe per TDMoIP packet 503 +-------------+-----------------+ +-----------------+ 504 |control word |48-octet subframe|---|48-octet subframe| 505 +-------------+-----------------+ +-----------------+ 507 Multiple AAL1 subframes per TDMoIP packet 509 The first octet of each 48-octet AAL1 subframe consists of an error 510 protected three-bit sequence number. 512 1 2 3 4 5 6 7 8 513 +-+-+-+-+-+-+-+-+----------------------- 514 |C| SN | CRC |P| 47 octets of payload 515 +-+-+-+-+-+-+-+-+----------------------- 517 where 519 C (1 bit) convergence sublayer indication, its use here is limited 520 to indication of the existence of a pointer (see below) C=0 means 521 no pointer, C=1 means a pointer is present. 523 SN (3 bits) The AAL1 sequence number increments from subframe to 524 subframe. 526 CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN. 528 P (1 bit) even byte parity 530 As can be readily inferred this octet can only take on eight 531 different values, and incrementing the sequence number forms an eight 532 subframe sequence number cycle, the importance of which will become 533 clear shortly. 535 The structure of the remaining 47 octets in the TDMoIP-AAL1 subframe 536 depends on the subframe type, of which there are three, corresponding 537 to the three types of AAL1 circuit emulation service defined in 538 [CES]. These are known as namely unstructured circuit emulation, 539 structured circuit emulation and structured circuit emulation with 540 CAS. 542 The simplest subframe is the unstructured one, which is used for 543 transparent transfer of whole trunks (T1,E1,T3,E3). Although AAL1 544 provides no inherent advantage as compared to SAToP for unstructured 545 transport, in certain cases AAL1 may be required or desirable. For 546 example, when it is necessary to interwork with an existing AAL1- 547 based network, or when clock recovery based on AAL1-specific 548 mechanisms is favored. 550 For unstructured AAL1 the 47 octets after the sequence number octet 551 contain 376 bits from the TDM bit stream. No frame synchronization 552 is supplied or implied, and framing is the sole responsibility of the 553 end-user equipment. Hence the unstructured mode can be used for 554 leased lines which carry data rather than N*64 Kbps timeslots, and 555 even for trunks with nonstandard frame synchronization. For the T1 556 case the raw frame consists of 193 bits, and hence 1 183/193 T1 557 frames fit into each TDMoIP-AAL1 subframe. The E1 frame consists of 558 256 bits, and so 1 15/32 E1 frames fit into each subframe. 560 When the TDM trunk is segmented into timeslots according to [G704], 561 and it is desired to transport N*64 Kbps circuit where N is only a 562 fraction of the full E1 or T1, it is advantageous to use one of the 563 structured AAL1 circuit emulation services. Structured AAL1 views 564 the data not merely as a bit stream, but as a circuit bundle of 565 timeslots. Furthermore, when CAS signaling is used it can be 566 formatted such that it can be readily detected and manipulated. 568 In the structured circuit emulation mode without CAS, N octets from 569 the N timeslots to be transported are first arranged in order of 570 timeslot number. Thus if timeslots 2, 3, 5, 7 and 11 are to be 571 transported the corresponding five octets are placed in the subframe 572 immediately after the sequence number octet. This placement is 573 repeated until all 47 octets in the subframe are taken; 575 octet 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47 576 timeslot 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3 578 the next subframe commences where the present subframe left off 580 octet 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47 581 timeslot 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7 583 and so forth. The set of timeslots 2,3,5,7,11 is called a structure 584 and the point where one structure ends and the next commences is a 585 structure boundary. 587 The problem with this arrangement is the lack of explicit indication 588 of the octet identities. As can be seen in the above example, each 589 TDMoIP-AAL1 subframe starts with a different timeslot, so a single 590 lost packet will result in misidentifying timeslots from that point 591 onwards, without possibility of recovery. The solution to this 592 deficiency is the periodic introduction of a pointer to the next 593 structure boundary. This pointer need not be used too frequently, as 594 the timeslot identification are uniquely inferable unless packets are 595 lost. 597 The particular method used in AAL1 is to insert a pointer once every 598 sequence number cycle of length eight subframes. The pointer is 599 seven bits and protected by an even parity MSB, and so occupies a 600 single octet. Since seven bits are sufficient to represent offsets 601 larger than 47, we can limit the placement of the pointer octet to 602 subframes with even sequence number. Unlike usual TDMoIP- AAL1 603 subframes with 47 octets available for payload, subframes which 604 contain a pointer, called P-format subframes, have the following 605 format. 607 0 1 608 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 610 |C| SN | CRC |P|E| pointer | 46 octets of payload 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+----------------------- 613 where 615 C (1 bit) convergence sublayer indication, C=1 for P-format 616 subframes 618 SN (3 bits) is an even AAL1 sequence number 620 CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN 622 P (1 bit) even byte parity LSB for sequence number octet 624 E (1 bit) even byte parity MSB for pointer octet 626 pointer (7 bits) pointer to next structure boundary 628 Since P-format subframes have 46 octets of payload and the next 629 subframe has 47 octets, viewed as a single entity the pointer needs 630 to indicate one of 93 octets. If P=0 it is understood that the 631 structure commences with the following octet (i.e. the first octet 632 in the payload belongs to the lowest numbered timeslot). P=93 means 633 that the last octet of the second subframe is the final octet of the 634 structure, and the following subframe commences with a new structure. 635 The special value P=127 indicates that there is no structure boundary 636 to be indicated (needed when extremely large structures are being 637 transported). 639 The P-format subframe is always placed at the first possible position 640 in the sequence number cycle that a structure boundary occurs, and 641 can only occur once per cycle. 643 The only difference between the structured circuit emulation format 644 and structured circuit emulation with CAS is the definition of the 645 structure. Whereas in structured circuit emulation the structure is 646 composed of the N timeslots, in structured circuit emulation with CAS 647 the structure encompasses the superframe consisting of multiple 648 repetitions of the N timeslots and then the CAS signaling bits. The 649 CAS bits are tightly packed into octets and the final octet is padded 650 with zeros if required. 652 For example, for E1 trunks the CAS signaling bits are updated once 653 per superframe of 16 frames. Hence the structure for N*64 derived 654 from an E1 with CAS signaling consists of 16 repetitions of N octets, 655 followed by N sets of the four ABCD bits, and finally four zero bits 656 if N is odd. For example, the structure for timeslots 2,3 and 5 will 657 be as follows 659 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 660 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2 ABCD3] [ABCD5 0000] 662 Similarly for T1 ESF trunks the superframe is 24 frames, and the 663 structure consists of 24 repetitions of N octets, followed by the 664 ABCD bits as before. For the T1 case the signaling bits will in 665 general appear twice, in their regular (bit-robbed) positions and at 666 the end of the structure. 668 4.2 AAL2 Format Payload 670 Although AAL1 may be configured to transport fractional trunks, the 671 allocation of timeslots to be transported must be static due to the 672 fact that AAL1 is a constant rate bit-stream. It is often the case 673 that not all the timeslots in a trunk are simultaneously active 674 ("off-hook"), and by observation of the TDM signaling timeslot 675 activity status may be determined. Moreover, even during active 676 calls there is silence about half the time. Using the variable rate 677 AAL2 mode we may dynamically allocate timeslots to be transported, 678 thus conserving bandwidth. 680 The variable rate AAL2 format is described in [AAL2] and its use for 681 loop emulation over ATM is explained in [SSCS,LES]. 683 For TDMoIP the AAL2 streams need not be segmented into ATM cells, 684 rather the AAL2 payloads belonging to all timeslots are concatenated, 685 and a single packet sent over the network. 687 +-------------+-------------+ +-------------+ 688 |control word |AAL2 subframe|---|AAL2 subframe| 689 +-------------+-------------+ +-------------+ 691 Concatenation of AAL2 subframes in a TDMoIP packet 693 The basic AAL2 subframe is : 695 | Octet 1 | Octet 2 | Octet 3 | 696 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------ 698 | CID | LI | UUI | HEC | PAYLOAD 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------ 701 CID (8 bits) channel identifier is a unique identifier for the 702 bundle. The values below 8 are reserved and so there are 248 703 possible channels. The mapping of CID values to trunk timeslots 704 is outside the scope of the TDMoIP protocol and must be configured 705 manually or via network management. 707 LI (6 bits) length indicator is one less than the length of the 708 payload in octets. (Note that the payload is limited to 64 709 octets.) 711 UUI (5 bits) user-to-user indication is the higher layer 712 (application) identifier and counter. For voice data the UUI will 713 always be in the range 0-15, and SHOULD be incremented modulo 16 714 each time a channel buffer is sent. The receiver MAY monitor this 715 sequence. UUI is set to 24 for CAS signaling packets. 717 HEC (5 bits) the header error control 719 Payload - voice A block of length indicated by LI of voice samples 720 are placed as- is into the AAL2 packet. 722 Payload - CAS signaling For CAS signaling the payload is formatted as 723 a type 3 packet (in the notation of [AAL2]) in order to ensure 724 error protection. The signaling is sent with the same CID as the 725 corresponding voice channel. Signaling is sent whenever the state 726 of the ABCD bits changes, and is sent with triple redundancy, i.e. 727 sent three times spaced 5 milliseconds apart. In addition, the 728 entire set of the signaling bits is sent periodically to ensure 729 reliability. 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 |RED| timestamp | 733 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 | RES | ABCD | type | CRC 735 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 CRC (cont) | PAD | 737 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 RED (2 bits) is the triple redundancy counter. For the first packet 740 it takes the value 00, for the second 01 and for the third 10. 741 RED=11 means non-redundant information and is used for periodic 742 refresh of the CAS information. 744 Timestamp (14 bits) The timestamp is the same for all three redundant 745 transmissions. 747 RES (4 bits) is reserved and MUST be set to zero 749 ABCD (4 bits) are the CAS signaling bits 751 type (6 bits) for CAS signaling this is 000011 753 CRC-10 (10 bits) is a 10 bit CRC error detection code 755 PAD (8 bits) is set to zero. 757 [PWE-ARCH] denotes as Native Service Processing (NSP) functions all 758 processing of the TDM data before its use as payload. Since AAL2 is 759 inherently variable rate, arbitrary NSP functions MAY be performed 760 before the timeslot is placed in the AAL2 loop emulation payload. 761 This includes testing for on-hook/off-hook status, voice activity 762 detection, speech compression, fax/modem relay, etc. 764 4.3 HDLC Format Payload 766 The motivation for handling HDLC in TDMoIP is to efficiently 767 transport CCS (common channel signaling such as SS7) which is 768 embedded in the TDM stream. This mechanism is not intended for 769 general HDLC payloads, and assumes that the HDLC messages are always 770 shorter than the maximum packet size. 772 The HDLC format is intended to operate in port mode, transparently 773 passing all HDLC data and control messages over the PW. 775 In order to transport HDLC the sender monitors flags until a frame is 776 detected. The contents of the frame are collected and the FCS 777 tested. If the FCS is incorrect the frame is discarded, otherwise 778 the frame is sent after initial or final flags and FCS have been 779 discarded and bit unstuffing has been performed. When an TDMoIP- 780 HDLC frame is received its FCS is calculated, and the original HDLC 781 frame reconstituted. 783 5. OAM Signaling 785 Since the TDMoIP PW is not absolutely reliable, it requires a 786 signaling mechanism to provide feedback regarding problems in the 787 communications environment. In addition, such signaling can be used 788 to collect statistics relating to the performance of the underlying 789 PSN [IPPM]. 791 If the underlying PSN has adequate signaling mechanisms then these 792 are to be used. If not, the ICMP-like procedures detailed below 793 SHOULD be followed. 795 All TDMoIP OAM signaling messages MUST use CBID 8191 (1FFF). All PSN 796 layer parameters (for example, IP addresses, TOS, EXP bits, and VLAN 797 ID) MUST remain those of the circuit bundle being investigated. 799 5.1 Connectivity-Check Messages 801 In most conventional IP applications a server sends some finite 802 amount of information over the network after explicit request from a 803 client. With TDMoIP the source sends a continuous stream of packets 804 towards the destination without knowing whether the destination 805 device is ready to accept them, leading to flooding of the PSN. 807 The problem may occur when an edge device fails or is disconnected 808 from the PSN, or the PW is broken. After an aging time the 809 destination edge disappears from the routing tables, and intermediate 810 routers may flood the network with the TDMoIP packets in an attempt 811 to find a new path. 813 The solution to this problem is to significantly reduce the number of 814 TDMoIP packets transmitted per second when PW failure is detected, 815 and to return to full rate only when the PW is restored. The 816 detection of failure and restoration is made possible by the periodic 817 exchange of one-way connectivity-check messages, as defined in 818 [CONNECT]. 820 Connectivity is tested by periodically sending OAM messages from the 821 source edge to the destination edge, and having the destination reply 822 to each message. The format of connectivity- check messages is given 823 in subsection 10.3 infra. 825 The connectivity check mechanism can also be useful during setup and 826 configuration. Without OAM signaling one must ensure that the 827 destination edge is ready to receive packets before starting to send 828 them. Since TDMoIP edge devices usually operate full-duplex, both 829 edges must be set up and properly configured simultaneously if 830 flooding is to be avoided. By using the connectivity mechanism a 831 configured edge device waits until it can detect its destination 832 before transmitting at full rate. In addition, errors in 833 configuration can be readily discovered by using the service specific 834 field. 836 5.2 Performance Measurements 838 In addition to one way connectivity, the OAM signaling mechanism can 839 be used to request and report on various PSN metrics, such as one way 840 delay, round trip delay, packet delay variation, etc. It can also be 841 used for remote diagnostics, and for unsolicited reporting of 842 potential problems (e.g. dying gasp messages). 844 5.3 OAM Packet Format 846 The format of an OAM message packet is depicted in the following 847 figure. Note that PSN-specific layers are identical to those used to 848 carry the TDMoIP data, with the exception that their CBID = 1FFF 849 instead of the usual circuit bundle identifier. 851 0 1 2 3 852 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 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | PSN-specific layers (with CBID=1FFF) | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 |FORMID |L|R| RES | Length | OAM Sequence Number | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | OAM Msg Type | OAM Msg Code | Service specific information | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Source CBID | Destination CBID | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Source Transmit Timestamp | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Destination Receive Timestamp | 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 866 | Destination Transmit Timestamp | 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 869 FORMID, L and R are identical to those used for the circuit bundle 870 being tested. 872 Length is the length in bytes of the OAM message packet. 874 OAM Sequence Number (16 bits) is used to uniquely identify the 875 message. Its value is unrelated to the sequence number of the 876 TDMoIP data packets for the circuit bundle in question. It is 877 incremented in query messages, and replicated without change in 878 replies. 880 OAM Msg Type (8 bits) indicates the function of the message. At 881 present the following are defined: 883 0 for one way connectivity query message 884 8 for one way connectivity reply message. 886 OAM Msg Code (8 bits) is used to carry information related to the 887 message, and its interpretation depends on the message type. For 888 type 0 (connectivity query) messages the following codes are 889 defined: 891 0 validate connection. 892 1 do not validate connection 894 for type 8 (connectivity reply) messages the available codes are: 896 0 acknowledge valid query 897 1 invalid query (configuration mismatch). 899 Service specific information (16 bits) is a field that can be used to 900 exchange configuration information between edge devices. If it is 901 not used this field MUST contain zero. Its interpretation depends 902 on the FORMID field. At present the following is defined for AAL1 903 payloads. 905 0 1 906 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Number of TSs | Number of SFs | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 Number of TSs (8 bits) is the number of timeslots being transported, 912 e.g. 24 for full T1. 914 Number of SFs (8 bits) is the number of 48-octet AAL1 subframes per 915 packet, e.g. 8 when packing 8 subframes per packet. 917 Source CBID (16 bits) uniquely identifies the circuit bundle as 918 labeled by the source edge. 920 Destination CBID (16 bits) uniquely identifies the circuit bundle as 921 labeled by the destination edge. 923 Source Transmit Timestamp (32 bits) represents the time the source 924 edge transmitted the query message in units of 100 microseconds. 925 This field and the following ones only appear if delay is being 926 measured. 928 Destination Receive Timestamp 32 bits) represents the time the 929 destination edge received the query message in units of 100 930 microseconds. 932 Destination Transmit Timestamp (32 bits) represents the time the 933 destination edge transmitted the reply message in units of 100 934 microseconds. 936 6. Implementation Issues 938 General requirements for transport of TDM over pseudo-wires are 939 detailed in [TDM-REQ]. In the following subsections we review 940 additional aspects essential to successful TDMoIP implementation. 942 6.1 Quality of Service 944 TDMoIP does not provide mechanisms to ensure timely delivery or 945 provide other quality-of-service guarantees; hence it is required 946 that the lower-layer services do so. Layer 2 priority can be 947 bestowed upon a TDMoIP stream by using the VLAN priority field, MPLS 948 priority can be provided by using EXP bits, and layer 3 priority is 949 controllable by using TOS. Switches and routers which the TDMoIP 950 stream must traverse should be configured to respect these 951 priorities. 953 If the PSN is Diffserv-enabled then an EF-PHB (expedited forwarding) 954 class based PDB SHOULD be used, in order to provide a low latency and 955 minimal jitter service. It is suggested that the transport LSP be 956 somewhat overprovisioned. 958 If the MPLS network is Intserv enabled, then GS (Guaranteed Service) 959 with the appropriate bandwidth reservation SHOULD be used in order to 960 provide a bandwidth BW guarantee equal or greater than that of the 961 aggregate TDM traffic. The delay introduced by the MPLS network 962 SHOULD be measured prior to traffic flow, to ensure its compliance 963 with latency requirements. 965 6.2 Timing 967 TDM networks are inherently synchronous; somewhere in the network 968 there will always be at least one extremely accurate primary 969 reference clock, with long-term accuracy of one part in 10E-11. This 970 node, whose accuracy is called "stratum 1", provides reference timing 971 to secondary nodes with lower "stratum 2" accuracy, and these in turn 972 provide reference clock to "stratum 3" nodes. This hierarchy of time 973 synchronization is essential for the proper functioning of the 974 network as a whole; for details see [G823,G824]. The use of time 975 standards less accurate than stratum 4 is NOT RECOMMENDED as it may 976 result in service impairments. 978 Packets in IP networks reach their destination with delay that has a 979 random component, known as jitter. When emulating TDM on a PSN, it 980 is possible to overcome this randomness by using a "jitter buffer" on 981 all incoming data, assuming the proper time reference is available. 982 The problem is that the original TDM time reference information is 983 not disseminated through the PSN. 985 In broadest terms there are two methods of overcoming this 986 difficulty; in one the timing information is provided by some means 987 independent of the PSN, while in the other the timing must be 988 transferred over the PSN. 990 For example, if the entire TDM infrastructure (or at least major 991 portions of it) is replaced by TDMoIP timing information MUST be 992 delivered over the PSN, and the reconstructed TDM stream MUST still 993 conform to ITU-T recommendations [G823] for E1 and [G824] for T1 994 trunks. 996 However, TDMoIP is frequently used in a "toll-bypass" scenario, where 997 a PSN link connects two existing TDM networks. In such a case both 998 TDMoIP devices MUST receive accurate timing from the TDM networks to 999 which they connect, and MUST use this local timing when outputting to 1000 the TDM network. 1002 6.3 Jitter and Packet Loss 1004 In order to compensate for packet delay variation that exists in any 1005 IP network a jitter buffer MUST be provided. The length of this 1006 buffer SHOULD be configurable and MAY be dynamic (i.e. grow and 1007 shrink in length according to the statistics of the delay variation). 1009 In order to handle (infrequent) packet loss and misordering a packet 1010 order integrity mechanism MUST be provided. This mechanism MUST 1011 track the serial numbers of packets in the jitter buffer and MUST 1012 take appropriate action when faults are detected. When missing 1013 packet(s) are detected the mechanism MUST output interpolation 1014 packet(s) in order to retain TDM timing. Packets with incorrect 1015 serial numbers or other detectable header errors MAY be discarded. 1016 Packets arriving in incorrect order SHOULD be swapped. Whenever 1017 possible, interpolation packets SHOULD ensure that proper 1018 synchronization bits are sent to the TDM network. 1020 While the insertion of arbitrary interpolation packets may be 1021 sufficient to maintain the TDM timing, for voice traffic packet loss 1022 can cause in gaps or artifacts that result in choppy, annoying or 1023 even unintelligible speech, see [TDM-PLC]. An implementation MAY 1024 blindly insert a preconfigured constant value in place of any lost 1025 speech samples, and this value SHOULD be chosen to minimize the 1026 perceptual effect. Alternatively one MAY replay the previously 1027 received packet. Since a TDMoIP packet is usually declared lost 1028 following the reception of the next packet, when computational 1029 resources are available, implementations SHOULD conceal the packet 1030 loss event by estimating the missing sample values. 1032 7. Security Considerations 1034 TDMoIP does not enhance or detract from the security performance of 1035 the underlying PSN, rather it relies upon the PSN's mechanisms for 1036 encryption, integrity, and authentication whenever required. 1038 TDMoIP does not provide protection against malicious users utilizing 1039 snooping or packet injection during setup or operation. However, 1040 random initialization of sequence numbers makes known-plaintext 1041 attacks on link encryption methods more difficult. 1043 Circuit bundle identifiers SHOULD be selected in an unpredictable 1044 manner rather than sequentially or otherwise in order to deter 1045 session hijacking. When using L2TP randomly selected cookies MAY be 1046 used to validate circuit bundle origin. Sequence numbers SHOULD be 1047 randomly initialized in order to increase the difficulty of 1048 decrypting based on packet headers. 1050 8. IANA Considerations 1052 When used with UDP/IP the destination port number MUST be set to 1053 0x085E (2142), the user port number which has been assigned by the to 1054 TDMoIP. 1056 The format identifiers (FORMID) will need to be standardized. 1058 9. Normative References 1060 [AAL1] ITU-T Recommendation I.363.1 (08/96) B-ISDN ATM Adaptation 1061 Layer (AAL) specification: Type 1 1063 [AAL2] ITU-T Recommendation I.363.2 (11/00) B-ISDN ATM Adaptation 1064 Layer (AAL) specification: Type 2 1066 [CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit 1067 Emulation Service Interoperability Specification Ver. 2.0 1069 [CONNECT] RFC 2678 IPPM Metrics for Measuring Connectivity 1071 [DELAY] RFC 2679 A One-way Delay Metric for IPPM 1073 [G704] ITU-T Recommendation G.704 (10/98) Synchronous frame 1074 structures used at 1544, 6312, 2048, 8448 and 44736 Kbit/s 1075 hierarchical levels 1077 [G823] ITU-T Recommendation G.823 (03/00) The control of jitter and 1078 wander within digital networks which are based on the 2048 Kbit/s 1079 hierarchy 1081 [G824] ITU-T Recommendation G.824 (03/00) The control of jitter and 1082 wander within digital networks which are based on the 1544 Kbit/s 1083 hierarchy 1085 [IPPM] RFC 2330 Framework for IP Performance Metrics 1087 [IPv4] RFC 791 (STD0005) Internet Protocol (IP) 1089 [LES] ATM forum specification atm-vmoa-0145 (LES) Voice and 1090 Multimedia over ATM - Loop Emulation Service Using AAL2 1092 [L2TPv3] draft-ietf-l2tpext-l2tp-base-10.txt (08/03) Layer Two 1093 Tunneling Protocol (L2TPv3), J. Lau et al., work in progress 1095 [MPLS] RFC 3032 MPLS Label Stack encoding 1097 [RTP] RFC 3550 RTP: Transport Protocol for Real-Time Applications 1099 [SAToP] draft-ietf-pwe3-satop-00.txt (09/03) Structure-Agnostic TDM 1100 over Packet (SAToP), A. Vainshtein and Y. Stein, work in 1101 progress 1103 [SSCS] ITU-T Recommendation I.366.2 (02/99) AAL Type 2 service 1104 specific convergence sublayer for trunking 1106 [TRAU] GSM 08.60 (10/01) Digital cellular telecommunications system 1107 (Phase 2+); Inband control of remote transcoders and rate adaptors 1108 for Enhanced Full Rate (EFR) and full rate traffic channels 1110 [UDP] RFC 768 (STD0006) User Datagram Protocol (UDP) 1112 10. Informative References 1114 [CESoPSN] draft-vainshtein-cesopsn-06.txt (03/03), TDM Circuit 1115 Emulation Service over Packet Switched Network, A. Vainshtein et 1116 al, work in progress 1118 [PWE3-ARCH] draft-ietf pwe3-arch-06.txt (10/03), PWE3 Architecture, 1119 Stewart Bryant et al, work in progress 1121 [PWE3-REQ] draft-ietf-pwe3-requirements-06.txt (12/03) Requirements 1122 for Pseudo Wire Emulation Edge-to-Edge (PWE3), XiPeng Xiao et al, 1123 work in progress 1125 [TDM-PLC] draft-stein-pwe3-tdm-packetloss-01.txt (10/03), The Effect 1126 of Packet Loss on Voice Quality for TDM over Pseudowires, Y(J) 1127 Stein and I. Druker, work in progress 1129 [TDM-REQ] draft-ietf-pwe3-tdm-requirements-01.txt (12/03), 1130 Requirements for Edge-to-Edge Emulation of TDM Circuits over 1131 Packet Switching Networks, M. Riegel et al., work in progress 1133 11. Acknowledgments 1135 The authors would like to thank Hugo Silberman, Shimon HaLevy, Tuvia 1136 Segal, and Eitan Schwartz of RAD Data Communications for their 1137 valuable contributions to the technology described herein. 1139 Authors' Addresses 1141 Yaakov (Jonathan) Stein 1142 RAD Data Communications 1143 24 Raoul Wallenberg St., Bldg C 1144 Tel Aviv 69719 1145 ISRAEL 1147 Phone: +972 3 645-5389 1148 EMail: yaakov_s@rad.com 1149 Ronen Shashoua 1150 RAD Data Communications 1151 24 Raoul Wallenberg St., Bldg C 1152 Tel Aviv 69719 1153 ISRAEL 1155 Phone: +972 3 645-5447 1156 EMail: ronen_s@rad.com 1158 Ron Insler 1159 RAD Data Communications 1160 24 Raoul Wallenberg St., Bldg C 1161 Tel Aviv 69719 1162 ISRAEL 1164 Phone: +972 3 645-5445 1165 EMail: ron_i@rad.com 1167 Motty (Mordechai) Anavi 1168 RAD Data Communications 1169 900 Corporate Drive 1170 Mahwah, NJ 07430 1171 USA 1173 Phone: +1 201 529-1100 Ext. 213 1174 EMail: motty@radusa.com 1176 Full Copyright Statement 1178 Copyright (C) The Internet Society (2003). All Rights Reserved. 1180 This document and translations of it may be copied and furnished to 1181 others, and derivative works that comment on or otherwise explain it 1182 or assist in its implementation may be prepared, copied, published 1183 and distributed, in whole or in part, without restriction of any 1184 kind, provided that the above copyright notice and this paragraph are 1185 included on all such copies and derivative works. However, this 1186 document itself may not be modified in any way, such as by removing 1187 the copyright notice or references to the Internet Society or other 1188 Internet organizations, except as needed for the purpose of 1189 developing Internet standards in which case the procedures for 1190 copyrights defined in the Internet Standards process must be 1191 followed, or as required to translate it into languages other than 1192 English. 1194 The limited permissions granted above are perpetual and will not be 1195 revoked by the Internet Society or its successors or assigns. 1197 This document and the information contained herein is provided on an 1198 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1199 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1200 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1201 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1202 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1204 Acknowledgement 1206 Funding for the RFC Editor function is currently provided by the 1207 Internet Society.