idnits 2.17.1 draft-vain-stein-pwe3-satop-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([G.704]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 104 has weird spacing: '...in this doc...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (March 2004) is 7345 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: 'RFC 2212' is mentioned on line 556, but not defined == Unused Reference: 'RFC1122' is defined on line 672, but no explicit reference was found in the text == Unused Reference: 'RFC2112' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'G.751' is defined on line 707, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3086 -- Possible downref: Non-RFC (?) normative reference: ref. 'RTP-TYPES' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.702' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.703' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.704' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.751' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.775' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.826' == 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 -- Unexpected draft version: The latest known version of draft-ietf-pwe3-framework is -01, but you're referring to -05. == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-03 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-iana-allocation-01 Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Vainshtein (Axerra Networks) 3 Y. Stein (RAD Data Communications) 4 Internet Draft 6 Expiration Date: Editors 7 March 2004 9 September 2003 11 Structure-Agnostic TDM over Packet (SAToP) 13 draft-vain-stein-pwe3-satop-00.txt 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with all 18 provisions of section 10 of RFC 2026. 20 Internet-Drafts are working documents of the Internet Engineering Task 21 Force (IETF), its areas, and its working groups. Note that other groups 22 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference material 26 or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document describes a pseudowire encapsulation for TDM (T1, E1, T3, 35 E3) bit-streams that disregards any structure that may be imposed on 36 these streams, in particular the structure imposed by the standard TDM 37 framing [G.704]. 39 Co-Authors 41 The following are co-authors of this document: 43 Motty Anavi RAD Data Communications 44 Tim Frost Zarlink Semiconductors 45 Eduard Metz TNO Telecom 46 Prayson Pate Overture Networks 47 Akiva Sadovski Axerra Networks 48 Israel Sasson Axerra Networks 49 Ronen Shashoua RAD Data Communications 50 Structure-Agnostic TDM over Packet August 2003 52 TABLE OF CONTENTS 54 1. Introduction......................................................2 55 2. Terminology and Reference Models..................................3 56 2.1. Terminology...................................................3 57 2.2. Reference Models..............................................3 58 3. Emulated Services.................................................3 59 4. SAToP Encapsulation Layer.........................................4 60 4.1. SAToP Packet Format...........................................4 61 4.2. PSN and Multiplexing Layer Headers............................4 62 4.3. SAToP Header..................................................4 63 4.3.1. Usage and Structure of the Control Word...................5 64 4.3.2. Usage of RTP Header.......................................6 65 5. SAToP Payload Layer...............................................7 66 6. SAToP Operation...................................................8 67 6.1. Common Considerations.........................................8 68 6.2. IWF operation.................................................8 69 6.2.1. PSN-bound Direction.......................................8 70 6.2.2. CE-bound Direction........................................9 71 6.3. SAToP Defects................................................10 72 6.4. SAToP PW Performance Monitoring..............................10 73 7. QoS Issues.......................................................11 74 8. Congestion Control...............................................11 75 9. Security Considerations..........................................12 76 10. Applicability Statement.........................................12 77 11. IANA Considerations.............................................13 78 12. Intellectual Property Disclaimer................................13 80 1. Introduction 82 This document describes a method for encapsulating TDM bit-streams (T1, 83 E1, T3, E3) as pseudo-wires over packet-switching networks (PSN). It 84 addresses only structure-agnostic transport, i.e., the protocol 85 completely disregards any structure that may possibly be imposed on 86 these signals, in particular the structure imposed by standard TDM 87 framing [G.704]. This emulation is referred to as "emulation of 88 unstructured TDM circuits" in [PWE3-TDM-REQ] and suits applications 89 where the PEs have no need to interpret TDM data or to participate in 90 the TDM signaling. 92 The SAToP solution presented in this document conforms to the PWE3 93 architecture described in [PWE3-ARCH] and satisfies both the relevant 94 general requirements put forward in [PWE3-REQ] and specific 95 requirements for unstructured TDM signals presented in [PWE3-TDM-REQ]. 97 Structure-Agnostic TDM over Packet August 2003 99 2. Terminology and Reference Models 101 2.1. Terminology 103 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 104 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 105 are to be interpreted as described in [RFC2119]. 107 In addition to terms defined in [PWE3-ARCH], the following TDM specific 108 terms are needed: 110 o Loss of Signal (LOS) - a condition of the TDM attachment 111 circuit wherein the incoming signal cannot be detected. 112 Criteria for entering and leaving the LOS condition can be 113 found in [G.775] 114 o Alarm Indication Signal (AIS) - a special bit pattern 115 (described in [G.775]) in the TDM bit stream that indicates 116 presence of an upstream circuit outage. For E1, T1 and E3 117 circuits the AIS pattern is a sequence of binary "1" values of 118 appropriate duration (the "all ones" pattern). 120 2.2. Reference Models 122 The generic models defined in Sections 4.1, 4.2 and 4.4 of [PWE3-ARCH] 123 fully apply to SAToP. 125 The native service addressed in this document is a special case of the 126 bit stream payload type defined in Section 3.3.3 of [PWE3-ARCH]. 128 The Network Synchronization reference model and deployment scenarios 129 for emulation of TDM services are described in [PWE3-TDM-REQ], Section 130 4.2. 132 3. Emulated Services 134 This specification describes edge-to-edge emulation of the following 135 TDM services described in [G.702]: 137 1. E1 (2048 kbit/s) 138 2. T1 (1544 kbit/s) This service is also known as DS1 139 3. E3 (34368 kbit/s) 140 4. T3 (44736 kbit/s) This service is also known as DS3. 142 The protocol used for emulation of these services does not depend on 143 the method in which attachment circuits are delivered to the PEs. For 144 example, a T1 attachment circuit is treated in the same way regardless 145 of whether it is delivered to the PE on copper [G.703], multiplexed in 146 a T3 circuit [T.107], mapped into a virtual tributary of a SONET/SDH 147 circuit [G.707] or carried over an ATM network using unstructured ATM- 148 CES [ATM-CES]. Termination of any specific "carrier layers" used 149 between the PE and CE is performed by an appropriate NSP. 151 Structure-Agnostic TDM over Packet August 2003 153 4. SAToP Encapsulation Layer 154 4.1. SAToP Packet Format 156 The basic format of SAToP packets is shown in Fig. 1 below. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | ... | 162 | PSN and multiplexing layer headers | 163 | ... | 164 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 165 | ... | 166 +-- --+ 167 | SAToP Encapsulation Header | 168 +-- --+ 169 | ... | 170 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 172 | Packetized TDM data (Payload) | 173 | ... | 174 | ... | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 Figure 1. Basic SAToP Packet Format 179 4.2. PSN and Multiplexing Layer Headers 181 The total size of a SAToP packet for a specific PW MUST NOT exceed path 182 MTU between the pair of PEs terminating this PW. SAToP implementations 183 using IPv4 PSN MUST mark the IPv4 datagrams they generate as "Don't 184 Fragment" [RFC791]. 186 4.3. SAToP Header 188 The SAToP header MUST contain the SAToP Control Word (4 bytes) and MAY 189 also contain a fixed RTP header [RFC3550]. If the RTP header is 190 included in the SAToP header, it MUST immediately precede the SAToP 191 control word in case of an IPv4 or IPv6 PSN, and MUST immediately 192 follow it in the case of an MPLS PSN (see Fig. 2a and Fig. 2b below). 194 Note: Such an arrangement complies with the traditional usage of RTP 195 for the IPv4/IPv6 PSN while making SAToP PWs ECMP-safe for the MPLS PSN 196 (see [PWE3-ARCH], Section 5.4.4). 198 Both UDP and L2TPv3 can provide the multiplexing mechanisms for SAToP 199 PWs over an IPv4/IPv6 PSN. The PW label provides the multiplexing 200 mechanism over an MPLS PSN as described in Section 5.4.2 of [PWE3- 201 ARCH]. 203 Structure-Agnostic TDM over Packet August 2003 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | ... | 209 | IPv4/IPv6 and multiplexing layer headers | 210 | ... | 211 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 212 | OPTIONAL | 213 +-- --+ 214 | | 215 +-- --+ 216 | Fixed RTP Header (see [RFC3550]) | 217 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 218 | SAToP Control Word | 219 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 220 | Packetized TDM data (Payload) | 221 | ... | 222 | ... | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | ... | 231 | MPLS Label Stack | 232 | ... | 233 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 234 | SAToP Control Word | 235 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 236 | OPTIONAL | 237 +-- --+ 238 | | 239 +-- --+ 240 | Fixed RTP Header (see [RFC3550]) | 241 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 242 | Packetized TDM data (Payload) | 243 | ... | 244 | ... | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 Figure 2b. SAToP Packet Format for an MPLS PSN 249 4.3.1. Usage and Structure of the Control Word 251 Usage of the SAToP control word allows: 253 1. Detection of packet loss or mis-ordering 254 2. Differentiation between the PSN and attachment circuit 255 problems as causes for the outage of the emulated service 256 Structure-Agnostic TDM over Packet August 2003 258 3. PSN bandwidth conservation by not transferring invalid data 259 (AIS) 260 4. Signaling of faults detected at the PW egress to the PW 261 ingress. 263 The structure of the SAToP Control Word is shown in Fig. 2 below. 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 |0|0|0|0|L|R|RSV|FRG| LEN | Sequence number | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 2. Structure of the SAToP Control Word 273 Bits 0 to 3 MUST be set to 0 as described in [PWE3-ARCH], Section 5.4.4 275 L - if set, indicates that the PSN-bound IWF has detected or has been 276 informed of a TDM fault condition invalidating the data to be 277 transmitted. This bit MAY be used to indicate LOS and MAY be used 278 in conjunction with other faults. When the L bit is set the 279 contents of the packet payload may be meaningless, and the payload 280 MAY be omitted in order to conserve bandwidth. Once set, if the TDM 281 fault is rectified the L bit MUST be cleared. 283 R - if set by the PSN-bound IWF, indicates that its local CE-bound IWF 284 is in the packet loss state, i.e. has lost a preconfigured number 285 of consecutive packets. The R bit MUST be cleared by the PSN-bound 286 IWF once its local CE-bound IWF has exited the packet loss state, 287 i.e. has received a preconfigured number of consecutive packets. 289 RSV (reserved) and FRG (fragmentation) bits (6 to 10) - MUST be set to 290 0 by the PSN-bound IWF and MUST be ignored by the CE-bound IWF. 292 LEN (bits (10 to 15) MAY be used to carry the length of the SAToP 293 packet (defined as the size of the SAToP header + the payload size) if 294 it is less than 64 bytes, and MUST be set to zero otherwise. 296 Sequence number is used to provide the common PW sequencing function as 297 well as detection of lost packets. It MUST be generated in accordance 298 with the rules defined in [RFC3550], Section 5 for the RTP sequence 299 number. 301 4.3.2. Usage of RTP Header 303 When RTP is used, SAToP requires the fields of the fixed RTP header 304 (see [RFC3550], Section 5.1) with P (padding), X (header extension), CC 305 (CSRC count), and M fields (marker) to be set to zero. 307 The PT (payload type) field is used as following: 308 1. One PT value MUST be allocated from the range of dynamic 309 values (see [RTP-TYPES]) for each direction of the PW. The 310 Structure-Agnostic TDM over Packet August 2003 312 same PT value MAY be reused for both directions of the PW and 313 also reused between different PWs 314 2. The PSN-bound IWF MUST set the PT field in the RTP header to 315 the allocated value 316 3. The CE-bound IWF MAY use the received value to detect 317 malformed packets 319 The sequence number field MAY be used to provide the common PW 320 sequencing function as well as detection of lost packets. It MUST be 321 generated in accordance with the rules established in [RFC3550] and 322 MUST be the same as the sequence number in the SAToP control word. 324 Timestamps are used for carrying timing information over the network. 325 Their values are generated in accordance with the rules established in 326 [RFC3550]. 328 The frequency of the clock used for generating timestamps MUST be an 329 integer multiple of 8 kHz. All implementations of SAToP MUST support 330 the 8 kHz clock. Other multiples of 8 kHz MAY be used. 332 The SSRC (synchronization source) value in the RTP header MAY be used 333 for detection of misconnections. 335 Timestamp generation MAY be used in the following modes: 337 1. Absolute mode: the PSN-bound IWF sets timestamps using the 338 clock recovered from the incoming TDM attachment circuit. As a 339 consequence, the timestamps are closely correlated with the 340 sequence numbers. All SAToP implementations that support usage 341 of the RTP header MUST support this mode. 342 2. Differential mode: Both IWFs have access to a common high- 343 quality timing source, and this source is used for timestamp 344 generation. Support of this mode is OPTIONAL. 346 Usage of the fixed RTP header in a SAToP PW and all the options 347 associated with its usage (the time-stamping clock frequency, the time- 348 stamping mode, selected PT and SSRC values) MUST be agreed upon between 349 the two SAToP IWFs at the PW setup 351 5. SAToP Payload Layer 353 In order to facilitate handling of packet loss in the PSN, SAToP 354 REQUIRES all packets belonging to a given SAToP PW to carry a fixed 355 number of bytes filled with TDM data received from the attachment 356 circuit. The packet payload size MUST be defined during the PW setup, 357 MUST be the same for both directions of the PW and MUST remain 358 unchanged for the lifetime of the PW. 360 The CE-bound and PSN-bound IWFs MUST agree on SAToP packet payload size 361 at the PW setup (default payload size values defined below guarantee 362 that such an agreement is always possible). The SAToP packet payload 363 size can be exchanged over the PWE3 control protocol ([PWE3-CONTROL]) 364 by using the CEP Payload Bytes interface parameter ([PWE3-IANA]). 366 Structure-Agnostic TDM over Packet August 2003 368 SAToP uses the following ordering for packetization of the TDM data: 369 o The order of the payload bytes corresponds to their order on 370 the attachment circuit 371 o Consecutive bits coming from the attachment circuit fill each 372 payload byte starting from most significant bit to least 373 significant. 375 All SAToP implementations MUST be capable of supporting the following 376 payload sizes: 378 o E1 - 256 bytes 379 o T1 - 192 bytes 380 o E3 and T3 - 1024 bytes. 382 Notes: 383 1. Whatever the selected payload size, SAToP does not assume 384 alignment to any underlying structure imposed by TDM framing 385 (byte, frame or multiframe alignment). 386 2. When the L bit in the SAToP control word is set, SAToP packets 387 MAY omit invalid TDM data in order to conserve PSN bandwidth. 388 3. Payload sizes that are multiples of 47 bytes MAY be used in 389 conjunction with unstructured ATM-CES [ATM-CES]. 391 6. SAToP Operation 392 6.1. Common Considerations 394 Edge-to-edge emulation of a TDM service using SAToP is only possible 395 when the two PW attachment circuits are of the same type (T1, E1, T3, 396 E3). The service type is exchanged at PW setup as described in [PWE3- 397 CONTROL]. 399 6.2. IWF operation 401 6.2.1. PSN-bound Direction 403 Once the PW is set up, the PSN-bound SAToP IWF operates as follows: 405 TDM data is packetized using the configured number of payload bytes per 406 packet. 408 Sequence numbers, flags, and timestamps (if the RTP header is used) are 409 inserted in the SAToP headers. 411 SAToP, multiplexing layer and PSN headers are prepended to the 412 packetized service data. 414 The resulting packets are transmitted over the PSN. 416 Structure-Agnostic TDM over Packet August 2003 418 6.2.2. CE-bound Direction 420 The CE-bound SAToP IWF SHOULD include a jitter buffer where payload of 421 the received SAToP packets is stored prior to play-out to the local TDM 422 attachment circuit. The size of this buffer SHOULD be locally 423 configurable to allow accommodation to the PSN-specific packet delay 424 variation. 426 The CE-bound SAToP IWF SHOULD use the sequence number in the control 427 word for detection of lost and mis-ordered packets. If the RTP header 428 is used, the RTP sequence numbers MAY be used for the same purposes. 430 The CE-bound SAToP IWF MAY re-order mis-ordered packets. Mis-ordered 431 packets that cannot be reordered MUST be discarded and treated as lost. 433 The payload of the received SAToP packets marked with the L bit set 434 SHOULD be replaced by the equivalent amount of the "all ones" pattern 435 even if it has not been omitted. 437 The payload of each lost SAToP packet MUST be replaced with the 438 equivalent amount of the replacement data. The contents of the 439 replacement data are implementation-specific and MAY be locally 440 configurable. By default, all SAToP implementations MUST support 441 generation of the "all ones" pattern as the replacement data. 442 Before a PW has been set up and after a PW has been torn down, the IWF 443 MUST play out the "all ones" pattern to its TDM attachment circuit. 445 Once the PW has been set up, the CE-bound IWF begins to receive SAToP 446 packets and to store their payload in the jitter buffer but continues 447 to play out the "all ones" pattern to its TDM attachment circuit. This 448 intermediate state persists until a preconfigured amount of TDM data 449 (usually half of the jitter buffer) has been received in consecutive 450 SAToP packets or until a preconfigured intermediate state timer 451 expires. 453 Once the preconfigured amount of the TDM data has been received, the 454 CE-bound SAToP IWF enters its normal operation state where it continues 455 to receive SAToP packets and to store their payload in the jitter 456 buffer while playing out the contents of the jitter buffer in 457 accordance with the required clock. In this state the CE-bound IWF 458 performs clock recovery, MAY monitor PW defects, and MAY collect PW 459 performance monitoring data. 461 If the CE-bound SAToP IWF detects loss of a preconfigured number of 462 consecutive packets or if the intermediate state timer expires before 463 the required amount of TDM data has been received, it enters its packet 464 loss state. While in this state, the local PSN-bound SAToP IWF SHOULD 465 mark every packet it transmits with the R bit set. The CE-bound SAToP 466 IWF leaves this state and transits to the normal one once a 467 preconfigured number of consecutive SAToP packets have been received. 469 Structure-Agnostic TDM over Packet August 2003 471 6.3. SAToP Defects 473 In addition to the packet loss state of the CE-bound SAToP IWF defined 474 above, it MAY detect the following defects: 476 o Stray packets 477 o Malformed packets 478 o Excessive packet loss rate 479 o Buffer overrun 480 o Remote packet loss. 482 Corresponding to each defect is a defect state of the IWF, a detection 483 criterion that triggers transition from the normal operation state to 484 the appropriate defect state, and an alarm that MAY be reported to the 485 management system and thereafter cleared. Alarms are only reported when 486 the defect state persists for a preconfigured amount of time (typically 487 2.5 seconds) and MUST be cleared after the corresponding defect is 488 undetected for a second preconfigured amount of time (typically 10 489 seconds). The trigger and release times for the various alarms may be 490 independent. 492 Stray packets MAY be detected by the PSN and multiplexing layers. When 493 RTP is used, the SSRC field in the RTP header MAY be used for this 494 purpose as well. Stray packets MUST be discarded by the CE-bound IWF 495 and their detection MUST NOT affect mechanisms for detection of packet 496 loss. 498 Malformed packets are detected by mismatch between the expected packet 499 size (taking the value of the L bit into account) and the actual packet 500 size inferred from the PSN and multiplexing layers. When RTP is used, 501 lack of correspondence between the PT value and that allocated for this 502 direction of the PW MAT also be used for this purpose. Malformed in- 503 order packets MUST be discarded by the CE-bound IWF and replacement 504 data generated as for lost packets. 506 Excessive packet loss rate is detected by computing the average packet 507 loss rate over a configurable amount of times and comparing it with a 508 preconfigured threshold. 510 Buffer overrun is detected in the normal operation state when the CE 511 bound IWF's jitter buffer cannot accommodate newly arrived SAToP 512 packets. 514 Remote packet loss is indicated by reception of packets with their R 515 bit set. 517 6.4. SAToP PW Performance Monitoring 519 Performance monitoring (PM) parameters are routinely collected for TDM 520 services and provide an important maintenance mechanism in TDM 521 networks. Ability to collect compatible PM parameters for SAToP PWs 522 enhances their maintenance capabilities. 524 Structure-Agnostic TDM over Packet August 2003 526 Collection of the SAToP PW performance monitoring parameters is 527 OPTIONAL, and if implemented, is only performed after the CE-bound IWF 528 has exited its intermediate state. 530 SAToP defines error events, errored blocks and defects as follows: 532 o A SAToP error event is defined as insertion of a single 533 replacement packet into the jitter buffer (replacement of 534 payload of SAToP packets with the L bit set is not considered 535 as insertion of a replacement packet) 536 o A SAToP errored data block is defined as a block of data 537 played out to the TDM attachment circuit and of size defined 538 in accordance with the [G.826] rules for the corresponding TDM 539 service that has experienced at least one SAToP error event 540 o A SAToP defect is defined as the packet loss state of the CE- 541 bound SAToP IWF. 543 The SAToP PW PM parameters (Errored, Severely Errored and Unavailable 544 Seconds) are derived from these definitions in accordance with [G.826]. 546 7. QoS Issues 548 SAToP can benefit from QoS capabilities of the underlying PSN. 550 If the PSN providing connectivity between PE devices is Diffserv- 551 enabled and provides a PDB [RFC3086] that guarantees low-jitter and 552 low-loss, the SAToP PW SHOULD use this PDB in compliance with the 553 admission and allocation rules the PSN has put in place for that PDB 554 (e.g., marking packets as directed by the PSN). 556 If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC 2212] 557 with the appropriate bandwidth reservation shall be used in order to 558 provide a bandwidth guarantee equal or greater than that of the 559 aggregate TDM traffic. The delay introduced by the PSN should be 560 measured prior to traffic flow, to ensure its compliance with the 561 latency requirement. 563 8. Congestion Control 565 SAToP PWs represent a special case of PWs carrying constant bit rate 566 (CBR) services across the PSN. These services cannot behave in a TCP- 567 friendly manner prescribed by [RFC2914] under congestion. 569 SAToP will use the generic PWE3 approach for handling congestion in PWs 570 carrying CBR services when such an approach has been specified. 572 Structure-Agnostic TDM over Packet August 2003 574 9. Security Considerations 576 SAToP does not enhance or detract from the security performance of the 577 underlying PSN, rather it relies upon the PSN mechanisms for 578 encryption, integrity, and authentication whenever required. 580 Misconnection detection capabilities of SAToP increase its resilience 581 to misconfiguration and some types of DoS attacks. 583 Random initialization of sequence numbers defined in [RFC3550] makes 584 known-plaintext attacks on encryption more difficult. 586 10. Applicability Statement 588 SAToP is an encapsulation layer intended for carrying TDM circuits 589 (E1/T1/E3/T3) over PSN in a structure-agnostic fashion. 591 SAToP fully complies with the principle of minimal intervention, thus 592 minimizing overhead and computational power required for encapsulation. 594 SAToP can be used in conjunction with various clock recovery techniques 595 and does not presume availability of a global synchronous clock at the 596 ends of a PW. However, if the global synchronous clock is available at 597 both ends of a SAToP PW, using RTP and differential timestamp 598 generation may improve the quality of the recovered clock. 600 The option for carrying only the local attachment circuit failure 601 indication enables bandwidth conservation. 603 Being a constant bit rate (CBR) service, SAToP cannot provide TCP- 604 friendly behavior under network congestion. 605 SAToP allows collection of TDM-like faults and performance monitoring 606 parameters hence emulating 'classic' carrier services of TDM. 608 SAToP provides for a carrier-independent ability to detect 609 misconnections and malformed packets. This feature increases resilience 610 of the emulated service to misconfiguration and DoS attacks. 612 SAToP provides for detection of lost packets and allows using various 613 techniques for generation of "replacement packets". These techniques 614 increase resilience of the emulated service to effects of lost packets. 616 SAToP carries indications of outages of incoming attachment circuit 617 across the PSN thus providing for effective fault isolation. 619 Faithfulness of a SAToP PW may be increased by exploiting QoS features 620 of the underlying PSN. 622 SAToP does not provide any mechanisms for protection against PSN 623 outages, and hence its resilience to such outages is limited. However, 624 lost-packet replacement and packet reordering mechanisms increase 625 resilience of the emulated service to fast PSN rerouting events. 627 Structure-Agnostic TDM over Packet August 2003 629 11. IANA Considerations 631 This specification requires assignment of new PW Types services listed 632 in Section 3. 634 12. Intellectual Property Disclaimer 636 This document is being submitted for use in IETF standards discussions. 638 Axerra Networks, Inc. has filed one or more patent applications 639 relating to the SAToP technology outlined in this document. Axerra 640 Networks, Inc. will grant free unlimited licenses for use of this 641 technology to the users who will register and sign up at the Axerra web 642 site. 644 RAD Data Communications, Ltd. has filed one or more patent 645 applications that may relate to the technology outlined in this 646 document. RAD hereby grants free unlimited license for use of its 647 intellectual property to the extent required for compliance with this 648 document. 650 ACKNOWLEDGEMENTS 652 We acknowledge the work of Gil Biran and Hugo Silberman who implemented 653 TDM transport over IP in 1998. 655 We would like to thank Alik Shimelmits for many productive discussions 656 and Ron Insler for his assistance in deploying TDM over PSN. 658 We express deep gratitude to Stephen Casner who has reviewed in detail 659 one of the predecessors of this document and provided valuable feedback 660 regarding various aspects of RTP usage, and to Kathleen Nichols who has 661 provided the current text of the QoS section considering Diffserv- 662 enabled PSN. 664 We thank Robert Biksner, Stewart Bryant, Rao Cherukuri, Ron Cohen, Alex 665 Conta, Shahram Davari, Tom Johnson, Sim Narasimha, Yaron Raz, and 666 Maximilian Riegel for their valuable feedback. 668 NORMATIVE REFERENCES 670 [RFC791] J. Postel (ed), Internet Protocol, RFC 791, IETF, 1981 672 [RFC1122] R. Braden (ed.), Requirements for Internet Hosts -- 673 Communication Layers, RFC 1122, IETF, 1989 675 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels, 676 RFC 2119, IETF, 1997 677 Structure-Agnostic TDM over Packet August 2003 679 [RFC2112] S. Shenker et al, Specification of Guaranteed Quality of 680 Service, IETF, RFC 2212, 1997 682 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 2000 684 [RFC3086] K. Nichols, B. Carpenter, Definition of Differentiated 685 Services Per Domain Behaviors and Rules for their Specification, RFC 686 3086, IETF, 2001 688 [RFC3550] H. Schulzrinne et al, RTP: A Transport Protocol for Real-Time 689 Applications, RFC 3550, IETF, 2003 691 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- 692 parameters 694 [G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit 695 Rates 697 [G.703] ITU-T Recommendation G.703 (10/98) - Physical/Electrical 698 Characteristics of Hierarchical Digital Interfaces 700 [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame 701 structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s 702 hierarchical levels 704 [G.707] ITU-T Recommendation G.707 (03/96) - Network Node Interface for 705 the Synchronous Digital Hierarchy (SDH) 707 [G.751] ITU-T Recommendation G.751 (11/88) - Digital Multiplex 708 Equipments Operating at the Third Order Bit Rate of 34368 kbit/s and 709 the Fourth Order Bit Rate of 139264 kbit/s and Using Positive 710 Justification 712 [G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS), 713 Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) Defect 714 Detection and Clearance Criteria for PDH Signals 716 [G.826] ITU-T Recommendation G.826 (02/99) - Error performance 717 parameters and objectives for international, constant bit rate digital 718 paths at or above the primary rate 720 [T1.107] American National Standard for Telecommunications - Digital 721 Hierarchy - Format Specifications, ANSI T1.107-1988 723 INFORMATIONAL REFERENCES 725 [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation 726 Edge-to-Edge (PWE3), Work in Progress, June 2003, draft-ietf-pwe3- 727 requirements-06.txt 729 [PWE3-TDM-REQ] Maximilian Riegel et al, Requirements for Edge-to-Edge 730 Emulation of TDM Circuits over Packet Switching Networks (PSN), Work in 731 Progress, June 2003, draft-ietf-pwe3-tdm-requirements-01.txt 732 Structure-Agnostic TDM over Packet August 2003 734 [PWE3-ARCH] S. Bryant, P. Pate et al, Framework for Pseudo Wire 735 Emulation Edge-to-Edge (PWE3), Work in progress, August 2003, draft- 736 ietf-pwe3-framework-05.txt 738 [PWE3-CONTROL] L. Martini et al, Pseudowire Setup and Maintenance using 739 LDP, Work in progress, June 2003, draft-ietf-pwe3-control-protocol- 740 03.txt 742 [PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire 743 Edge to Edge Emulation (PWE3), Work in progress, February 2003, draft- 744 ietf-pwe3-iana-allocation-01.txt 746 [ATM-CES] ATM forum specification af-vtoa-0078 (CES 2.0) 747 Circuit Emulation Service Interoperability Specification Ver. 2.0 749 Editors' Addresses 751 Alexander ("Sasha") Vainshtein 752 Axerra Networks 753 24 Raoul Wallenberg St., 754 Tel Aviv 69719, Israel 755 email: sasha@axerra.com 757 Yaakov (Jonathan) Stein 758 RAD Data Communications 759 24 Raoul Wallenberg St., Bldg C 760 Tel Aviv 69719, Israel 761 Email: yaakov_s@rad.com