idnits 2.17.1 draft-ietf-pwe3-satop-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1118. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 896. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 151 has weird spacing: '...d hence can o...' == Line 1078 has weird spacing: '... amount of va...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 2006) is 6457 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: 'RFC3931' is mentioned on line 222, but not defined == Missing Reference: 'RFC 2212' is mentioned on line 704, but not defined == Unused Reference: 'G.751' is defined on line 956, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 ** 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.802' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.826' == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-cesopsn-06 == Outdated reference: A later version (-06) exists of draft-ietf-pwe3-tdmoip-03 == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-tdm-control-protocol-extensi-00 == Outdated reference: A later version (-18) exists of draft-ietf-pwe3-segmented-pw-00 == Outdated reference: A later version (-15) exists of draft-ietf-pwe3-vccv-05 Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 15 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(J) Stein (RAD Data Communications) 4 Internet Draft Editors 6 Expiration Date: 7 August 2006 9 February 2006 11 Structure-Agnostic TDM over Packet (SAToP) 13 draft-ietf-pwe3-satop-05.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware have 19 been or will be disclosed, and any of which he or she becomes aware 20 will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes a pseudowire encapsulation for TDM (T1, E1, T3, 40 E3) bit-streams that disregards any structure that may be imposed on 41 these streams, in particular the structure imposed by the standard TDM 42 framing. 44 Co-Authors 46 The following are co-authors of this document: 48 Motty Anavi RAD Data Communications 49 Tim Frost Zarlink Semiconductors 50 Eduard Metz TNO Telecom 51 Prayson Pate Overture Networks 52 Akiva Sadovski 53 Israel Sasson Axerra Networks 54 Ronen Shashoua RAD Data Communications 55 Structure-Agnostic TDM over Packet February 2006 57 TABLE OF CONTENTS 59 1. Introduction......................................................2 60 2. Terminology and Reference Models..................................3 61 2.1. Terminology...................................................3 62 2.2. Reference Models..............................................3 63 3. Emulated Services.................................................4 64 4. SAToP Encapsulation Layer.........................................4 65 4.1. SAToP Packet Format...........................................4 66 4.2. PSN and Multiplexing Layer Headers............................5 67 4.3. SAToP Header..................................................5 68 4.3.1. Usage and Structure of the Control Word...................7 69 4.3.2. Usage of RTP Header.......................................8 70 5. SAToP Payload Layer...............................................9 71 5.1. General Payloads..............................................9 72 5.2. Octet-aligned T1.............................................10 73 6. SAToP Operation..................................................11 74 6.1. Common Considerations........................................11 75 6.2. IWF operation................................................11 76 6.2.1. PSN-bound Direction......................................11 77 6.2.2. CE-bound Direction.......................................11 78 6.3. SAToP Defects................................................13 79 6.4. SAToP PW Performance Monitoring..............................13 80 7. QoS Issues.......................................................14 81 8. Congestion Control...............................................14 82 9. Security Considerations..........................................16 83 10. Applicability Statement.........................................16 84 11. IANA Considerations.............................................17 85 12. Disclaimer of Validity..........................................17 86 13. NORMATIVE REFERENCES............................................18 87 14. INFORMATIONAL REFERENCES........................................19 88 Annex A. Old Mode of SATOP Encapsulation over L2TPv3................20 89 ANNEX B. Parameters that must be agreed upon during the PW setup....21 91 1. Introduction 93 This document describes a method for encapsulating TDM bit-streams (T1, 94 E1, T3, E3) as pseudo-wires over packet-switching networks (PSN). It 95 addresses only structure-agnostic transport, i.e., the protocol 96 completely disregards any structure that may possibly be imposed on 97 these signals, in particular the structure imposed by standard TDM 98 framing [G.704]. This emulation is referred to as "emulation of 99 unstructured TDM circuits" in [RFC4197] and suits applications where 100 the PEs have no need to interpret TDM data or to participate in the TDM 101 signaling. 103 The SAToP solution presented in this document conforms to the PWE3 104 architecture described in [RFC3985] and satisfies both the relevant 105 general requirements put forward in [RFC3916] and specific requirements 106 for unstructured TDM signals presented in [RFC4197]. 108 Structure-Agnostic TDM over Packet February 2006 110 As with all PWs, SAToP PWs may be manually configured or set up using 111 the PWE3 control protocol. Extensions to the PWE3 control protocol 112 required for setup and maintenance of SAToP pseudo-wires and 113 allocations of code points used for this purpose are described in 114 separate documents ([PWE3-TDM-CONTROL] and [PWE3-IANA] respectively). 116 2. Terminology and Reference Models 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 120 document are to be interpreted as described in [RFC2119]. 122 2.1. Terminology 124 The following acronyms used in this document are defined in [RFC3985] 125 and [RFC4197]: 127 ATM Asynchronous Transfer Mode 128 CE Customer Edge 129 CES Circuit Emulation Service 130 NSP Native Service Processing 131 PE Provider Edge 132 PDH Plesiochronous Digital Hierarchy 133 PW Pseudo-Wire 134 SDH Synchronous Digital Hierarchy 135 SONET Synchronous Optical Network 136 TDM Time Domain Multiplexing 138 In addition, the following TDM-specific terms are needed: 140 o Loss of Signal (LOS) - a condition of the TDM attachment 141 circuit wherein the incoming signal cannot be detected. 142 Criteria for entering and leaving the LOS condition can be 143 found in [G.775] 144 o Alarm Indication Signal (AIS) - a special bit pattern (e.g. as 145 described in [G.775]) in the TDM bit stream that indicates 146 presence of an upstream circuit outage. For E1, T1 and E3 147 circuits the AIS pattern is a sequence of binary "1" values of 148 appropriate duration (the "all ones" pattern) and hence it can 149 be detected and generated by structure-agnostic means. The T3 150 AIS pattern requires T3 framing (see [G.704], Section 151 2.5.3.6.1) and hence can only be handled by a structure-aware 152 NSP. 154 We also use the term Interworking Function (IWF) to describe the 155 functional block that segments and encapsulates TDM into SAToP packets 156 and in the reverse direction decapsulates SAToP packets and 157 reconstitutes TDM. 159 2.2. Reference Models 160 Structure-Agnostic TDM over Packet February 2006 162 The generic models defined in Sections 4.1, 4.2 and 4.4 of [RFC3985] 163 fully apply to SAToP. 165 The native service addressed in this document is a special case of the 166 bit stream payload type defined in Section 3.3.3 of [RFC3985]. 168 The Network Synchronization reference model and deployment scenarios 169 for emulation of TDM services are described in [RFC4197], Section 4.3. 171 3. Emulated Services 173 This specification describes edge-to-edge emulation of the following 174 TDM services described in [G.702]: 176 1. E1 (2048 kbit/s) 177 2. T1 (1544 kbit/s) This service is also known as DS1 178 3. E3 (34368 kbit/s) 179 4. T3 (44736 kbit/s) This service is also known as DS3. 181 The protocol used for emulation of these services does not depend on 182 the method in which attachment circuits are delivered to the PEs. For 183 example, a T1 attachment circuit is treated in the same way regardless 184 of whether it is delivered to the PE on copper [G.703], multiplexed in 185 a T3 circuit [T1.107], mapped into a virtual tributary of a SONET/SDH 186 circuit [G.707] or carried over an ATM network using unstructured ATM 187 Circuit Emulation Service (CES) [ATM-CES]. Termination of any specific 188 "carrier layers" used between the PE and CE is performed by an 189 appropriate NSP. 191 4. SAToP Encapsulation Layer 193 4.1. SAToP Packet Format 195 The basic format of SAToP packets is shown in Fig. 1 below. 197 Structure-Agnostic TDM over Packet February 2006 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | ... | 203 | PSN and multiplexing layer headers | 204 | ... | 205 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 206 | ... | 207 +-- --+ 208 | SAToP Encapsulation Header | 209 +-- --+ 210 | ... | 211 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 213 | Packetized TDM data (Payload) | 214 | ... | 215 | ... | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 1. Basic SAToP Packet Format 220 4.2. PSN and Multiplexing Layer Headers 222 Both UDP and L2TPv3 [RFC3931] can provide the multiplexing mechanisms 223 for SAToP PWs over an IPv4/IPv6 PSN. The PW label provides the 224 multiplexing mechanism over an MPLS PSN as described in Section 5.4.2 225 of [RFC3985]. 227 The total size of a SAToP packet for a specific PW MUST NOT exceed path 228 MTU between the pair of PEs terminating this PW. SAToP implementations 229 using IPv4 PSN MUST mark the IPv4 datagrams they generate as "Don't 230 Fragment" [RFC791] (see also [PWE3-FRAG]). 232 4.3. SAToP Header 234 The SAToP header MUST contain the SAToP Control Word (4 bytes) and MAY 235 also contain a fixed RTP header [RFC3550]. If the RTP header is 236 included in the SAToP header, it MUST immediately follow the SAToP 237 control word in all cases except UDP multiplexing, where it 238 MUST precede it (see Fig. 2a, Fig. 2b and Fig. 2c below). 240 Note: Such an arrangement complies with the traditional usage of RTP 241 for the IPv4/IPv6 PSN with UDP multiplexing while making SAToP PWs 242 ECMP-safe for the MPLS PSN by providing for PW-IP packet discrimination 243 (see [RFC3985], Section 5.4.3) and facilitating seamless stitching of 244 L2TPv3-based and MPLS-based segments of SAToP PWs (see [PWE3-MS]). 246 Structure-Agnostic TDM over Packet February 2006 248 0 1 2 3 249 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 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | ... | 252 | IPv4/IPv6 and UDP (multiplexing layer) headers | 253 | ... | 254 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 255 | OPTIONAL | 256 +-- --+ 257 | | 258 +-- --+ 259 | Fixed RTP Header (see [RFC3550]) | 260 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 261 | SAToP Control Word | 262 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 263 | Packetized TDM data (Payload) | 264 | ... | 265 | ... | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN with 269 UDP Multiplexing 271 0 1 2 3 272 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 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | ... | 275 | IPv4/IPv6 and L2TPv3 (multiplexing layer) headers | 276 | ... | 277 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 278 | SAToP Control Word | 279 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 280 | OPTIONAL | 281 +-- --+ 282 | | 283 +-- --+ 284 | Fixed RTP Header (see [RFC3550]) | 285 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 286 | Packetized TDM data (Payload) | 287 | ... | 288 | ... | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Figure 2b. SAToP Packet Format for an IPv4/IPv6 PSN with 292 L2TPv3 Demultiplexing 293 Structure-Agnostic TDM over Packet February 2006 295 0 1 2 3 296 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 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | ... | 299 | MPLS Label Stack | 300 | ... | 301 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 302 | SAToP Control Word | 303 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 304 | OPTIONAL | 305 +-- --+ 306 | | 307 +-- --+ 308 | Fixed RTP Header (see [RFC3550]) | 309 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 310 | Packetized TDM data (Payload) | 311 | ... | 312 | ... | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Figure 2c. SAToP Packet Format for an MPLS PSN 317 4.3.1. Usage and Structure of the Control Word 319 Usage of the SAToP control word allows: 321 1. Detection of packet loss or mis-ordering 322 2. Differentiation between the PSN and attachment circuit 323 problems as causes for the outage of the emulated service 324 3. PSN bandwidth conservation by not transferring invalid data 325 (AIS) 326 4. Signaling of faults detected at the PW egress to the PW 327 ingress. 329 The structure of the SAToP Control Word is shown in Fig. 3 below. 331 0 1 2 3 332 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 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 |0|0|0|0|L|R|RSV|FRG| LEN | Sequence number | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 3. Structure of the SAToP Control Word 339 The use of Bits 0 to 3 is described in [PWE3-CW]. These bits MUST 340 be set to zero unless they are being used to indicate the start of an 341 Associated Channel Header (ACH). An ACH is needed if the state of the 342 SAToP PW is being monitored using Virtual Circuit Connectivity 343 Verification [PWE3-VCCV]. 345 L - if set, indicates that TDM data carried in the payload is invalid 346 due an attachment circuit fault. When the L bit is set the payload 347 Structure-Agnostic TDM over Packet February 2006 349 MAY be omitted in order to conserve bandwidth. The CE-bound IWF 350 MUST play out an appropriate amount of filler data regardless of 351 the payload size. Once set, if the fault is rectified the L bit 352 MUST be cleared. 354 Note: This document does not specify which TDM fault conditions are 355 treated as invalidating the data carried in the SAToP packets. Possible 356 examples include, but are not limited to LOS and AIS. 358 R - if set by the PSN-bound IWF, indicates that its local CE-bound IWF 359 is in the packet loss state, i.e. has lost a preconfigured number 360 of consecutive packets. The R bit MUST be cleared by the PSN-bound 361 IWF once its local CE-bound IWF has exited the packet loss state, 362 i.e. has received a preconfigured number of consecutive packets. 364 RSV (reserved) and FRG (fragmentation, see [PWE3-FRAG]) bits (6 to 9) - 365 MUST be set to 0 by the PSN-bound IWF and MUST be ignored by the CE- 366 bound IWF. 368 LEN (bits 10 to 15) MAY be used to carry the length of the SAToP packet 369 (defined as the size of the SAToP header + the payload size) if it is 370 less than 64 bytes, and MUST be set to zero otherwise. When the LEN 371 field is set to 0, the preconfigured size of the SAToP packet payload 372 MUST be assumed as described in Section 5.1, and if the actual packet 373 size is inconsistent with this length, the packet MUST be considered to 374 be malformed. 376 The sequence number is used to provide the common PW sequencing 377 function as well as detection of lost packets. It MUST be generated in 378 accordance with the rules defined in Section 5.1 of [RFC3550], for the 379 RTP sequence number, i.e.: 381 o Its space is a 16-bit unsigned circular space 382 o Its initial value SHOULD be random (unpredictable). 384 It MUST be incremented with each SAToP data packet sent in the specific 385 PW. 387 4.3.2. Usage of RTP Header 389 When RTP is used, SAToP requires the fields of the fixed RTP header 390 (see [RFC3550], Section 5.1) with P (padding), X (header extension), CC 391 (CSRC count), and M fields (marker) to be set to zero. 393 The PT (payload type) field is used as following: 394 1. One PT value MUST be allocated from the range of dynamic 395 values (see [RTP-TYPES]) for each direction of the PW. The 396 same PT value MAY be reused for both directions of the PW and 397 also reused between different PWs 398 2. The PSN-bound IWF MUST set the PT field in the RTP header to 399 the allocated value 400 3. The CE-bound IWF MAY use the received value to detect 401 malformed packets 402 Structure-Agnostic TDM over Packet February 2006 404 The sequence number MUST be the same as the sequence number in the 405 SAToP control word. 407 The RTP timestamps are used for carrying timing information over the 408 network. Their values are generated in accordance with the rules 409 established in [RFC3550]. 411 The frequency of the clock used for generating timestamps MUST be an 412 integer multiple of 8 kHz. All implementations of SAToP MUST support 413 the 8 kHz clock. Other multiples of 8 kHz MAY be used. 415 The SSRC (synchronization source) value in the RTP header MAY be used 416 for detection of misconnections, i.e. incorrect interconnection of 417 attachment circuits. 419 Timestamp generation MAY be used in the following modes: 421 1. Absolute mode: the PSN-bound IWF sets timestamps using the 422 clock recovered from the incoming TDM attachment circuit. As a 423 consequence, the timestamps are closely correlated with the 424 sequence numbers. All SAToP implementations that support usage 425 of the RTP header MUST support this mode. 426 2. Differential mode: Both IWFs have access to a common high- 427 quality timing source, and this source is used for timestamp 428 generation. Support of this mode is OPTIONAL. 430 Usage of the fixed RTP header in a SAToP PW and all the options 431 associated with its usage (the time-stamping clock frequency, the time- 432 stamping mode, selected PT and SSRC values) MUST be agreed upon between 433 the two SAToP IWFs at the PW setup as described in [PWE3-TDM-CONTROL]. 434 Other, RTP-specific, methods (e.g., see [RFC3551]) MUST NOT be used. 436 5. SAToP Payload Layer 437 5.1. General Payloads 439 In order to facilitate handling of packet loss in the PSN, all packets 440 belonging to a given SAToP PW are REQUIRED to carry a fixed number of 441 bytes filled with TDM data received from the attachment circuit. The 442 packet payload size MUST be defined during the PW setup, MUST be the 443 same for both directions of the PW and MUST remain unchanged for the 444 lifetime of the PW. 446 The CE-bound and PSN-bound IWFs MUST agree on SAToP packet payload size 447 at the PW setup (default payload size values defined below guarantee 448 that such an agreement is always possible). The SAToP packet payload 449 size can be exchanged over the PWE3 control protocol ([PWE3-TDM- 450 CONTROL]) by using the CEP/TDM Payload Bytes sub-TLV of the Interface 451 Parameters TLV([PWE3-IANA]). 453 SAToP uses the following ordering for packetization of the TDM data: 454 o The order of the payload bytes corresponds to their order on 455 the attachment circuit 456 Structure-Agnostic TDM over Packet February 2006 458 o Consecutive bits coming from the attachment circuit fill each 459 payload byte starting from most significant bit to least 460 significant. 462 All SAToP implementations MUST be capable of supporting the following 463 payload sizes: 465 o E1 - 256 bytes 466 o T1 - 192 bytes 467 o E3 and T3 - 1024 bytes. 469 Notes: 470 1. Whatever the selected payload size, SAToP does not assume 471 alignment to any underlying structure imposed by TDM framing 472 (byte, frame or multiframe alignment). 473 2. When the L bit in the SAToP control word is set, SAToP packets 474 MAY omit invalid TDM data in order to conserve PSN bandwidth. 475 3. Payload sizes that are multiples of 47 bytes MAY be used in 476 conjunction with unstructured ATM-CES [ATM-CES]. 478 5.2. Octet-aligned T1 480 An unstructured T1 attachment circuit is sometimes provided already 481 padded to an integer number of bytes, as described in Annex B of 482 [G.802]. This occurs when the T1 is de-mapped from a SONET/SDH virtual 483 tributary/container, or when it is deframed by a dual-mode E1/T1 484 framer. 486 In order to facilitate operation in such cases, SAToP defines a special 487 "octet-aligned T1" transport mode. When operating in this mode, the 488 SAToP payload consists of a number of 25-byte subframes, each subframe 489 carrying 193 bits of TDM data and 7 bits of padding. This mode is 490 depicted in Fig. 4 below. 492 | 1 | 2 | ... | 25 | 493 |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ... |0 1 2 3 4 5 6 7| 494 |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 495 | TDM Data | padding | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | ................................. | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | TDM Data | padding | 500 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 502 Figure 4. SAToP Payload Format for Octet-Aligned T1 Transport 504 Notes: 506 1. No alignment with the framing structure that may be imposed on the 507 T1 bit-stream is implied. 508 2. An additional advantage of the octet-aligned T1 transport mode is 509 ability to select the SAToP packetization latency as an arbitrary 510 integer multiple of 125 microseconds. 512 Structure-Agnostic TDM over Packet February 2006 514 Support of the octet-aligned T1 transport mode is OPTIONAL. An octet- 515 aligned T1 SAToP PW is not interoperable with a T1 SAToP PW that 516 carries a non-aligned bit-stream, as described in the previous section. 518 Implementations supporting octet-aligned T1 transport mode MUST be 519 capable of supporting a payload size of 200 bytes (i.e., a payload of 520 eight 25-byte subframes) corresponding to precisely 1 millisecond of 521 TDM data. 523 6. SAToP Operation 524 6.1. Common Considerations 526 Edge-to-edge emulation of a TDM service using SAToP is only possible 527 when the two PW attachment circuits are of the same type (T1, E1, T3, 528 E3). The service type is exchanged at PW setup as described in [PWE3- 529 CONTROL]. 531 6.2. IWF operation 533 6.2.1. PSN-bound Direction 535 Once the PW is set up, the PSN-bound SAToP IWF operates as follows: 537 TDM data is packetized using the configured number of payload bytes per 538 packet. 540 Sequence numbers, flags, and timestamps (if the RTP header is used) are 541 inserted in the SAToP headers. 543 SAToP, multiplexing layer and PSN headers are prepended to the 544 packetized service data. 546 The resulting packets are transmitted over the PSN. 548 6.2.2. CE-bound Direction 550 The CE-bound SAToP IWF SHOULD include a jitter buffer where the payload 551 of the received SAToP packets is stored prior to play-out to the local 552 TDM attachment circuit. The size of this buffer SHOULD be locally 553 configurable to allow accommodation to the PSN-specific packet delay 554 variation. 556 The CE-bound SAToP IWF SHOULD use the sequence number in the control 557 word for detection of lost and mis-ordered packets. If the RTP header 558 is used, the RTP sequence numbers MAY be used for the same purposes. 560 Note: With SAToP, a valid sequence number can be always found in bits 561 16 - 31 of the first 32-bit word immediately following the multiplexing 562 header regardless of the specific PSN type, multiplexing method, usage 563 or non-usage of the RTP header etc. This approach simplifies 564 Structure-Agnostic TDM over Packet February 2006 566 implementations supporting multiple encapsulation types as well as 567 implementation of multi-segment (MS) PWs using different encapsulation 568 types in different segments. 570 The CE-bound SAToP IWF MAY re-order mis-ordered packets. Mis-ordered 571 packets that cannot be reordered MUST be discarded and treated as lost. 573 The payload of the received SAToP packets marked with the L bit set 574 SHOULD be replaced by the equivalent amount of the "all ones" pattern 575 even if it has not been omitted. 577 The payload of each lost SAToP packet MUST be replaced with the 578 equivalent amount of the replacement data. The contents of the 579 replacement data are implementation-specific and MAY be locally 580 configurable. By default, all SAToP implementations MUST support 581 generation of the "all ones" pattern as the replacement data. 582 Before a PW has been set up and after a PW has been torn down, the IWF 583 MUST play out the "all ones" pattern to its TDM attachment circuit. 585 Once the PW has been set up, the CE-bound IWF begins to receive SAToP 586 packets and to store their payload in the jitter buffer but continues 587 to play out the "all ones" pattern to its TDM attachment circuit. This 588 intermediate state persists until a preconfigured amount of TDM data 589 (usually half of the jitter buffer) has been received in consecutive 590 SAToP packets or until a preconfigured intermediate state timer 591 (started when the PW setup is completed) expires. 593 Once the preconfigured amount of the TDM data has been received, the 594 CE-bound SAToP IWF enters its normal operation state where it continues 595 to receive SAToP packets and to store their payload in the jitter 596 buffer while playing out the contents of the jitter buffer in 597 accordance with the required clock. In this state the CE-bound IWF 598 performs clock recovery, MAY monitor PW defects, and MAY collect PW 599 performance monitoring data. 601 If the CE-bound SAToP IWF detects loss of a preconfigured number of 602 consecutive packets or if the intermediate state timer expires before 603 the required amount of TDM data has been received, it enters its packet 604 loss state. While in this state, the local PSN-bound SAToP IWF SHOULD 605 mark every packet it transmits with the R bit set. The CE-bound SAToP 606 IWF leaves this state and transitions to the normal one once a 607 preconfigured number of consecutive valid SAToP packets have been 608 received. (Successfully re-ordered packets contribute to the count of 609 consecutive packets.) 611 The CE-bound SAToP IWF MUST provide an indication of TDM data validity 612 to the CE. This can be done by transporting or by generating the native 613 AIS indication. As mentioned above, T3 AIS cannot be detected or 614 generated by structure-agnostic means and hence a structure-aware NSP 615 MUST be used when generating a valid AIS pattern. 617 Structure-Agnostic TDM over Packet February 2006 619 6.3. SAToP Defects 621 In addition to the packet loss state of the CE-bound SAToP IWF defined 622 above, it MAY detect the following defects: 624 o Stray packets 625 o Malformed packets 626 o Excessive packet loss rate 627 o Buffer overrun 628 o Remote packet loss. 630 Corresponding to each defect is a defect state of the IWF, a detection 631 criterion that triggers transition from the normal operation state to 632 the appropriate defect state, and an alarm that MAY be reported to the 633 management system and thereafter cleared. Alarms are only reported when 634 the defect state persists for a preconfigured amount of time (typically 635 2.5 seconds) and MUST be cleared after the corresponding defect is 636 undetected for a second preconfigured amount of time (typically 10 637 seconds). The trigger and release times for the various alarms may be 638 independent. 640 Stray packets MAY be detected by the PSN and multiplexing layers. When 641 RTP is used, the SSRC field in the RTP header MAY be used for this 642 purpose as well. Stray packets MUST be discarded by the CE-bound IWF 643 and their detection MUST NOT affect mechanisms for detection of packet 644 loss. 646 Malformed packets are detected by mismatch between the expected packet 647 size (taking the value of the L bit into account) and the actual packet 648 size inferred from the PSN and multiplexing layers. When RTP is used, 649 lack of correspondence between the PT value and that allocated for this 650 direction of the PW MAY also be used for this purpose. Malformed in- 651 order packets MUST be discarded by the CE-bound IWF and replacement 652 data generated as with lost packets. 654 Excessive packet loss rate is detected by computing the average packet 655 loss rate over a configurable amount of times and comparing it with a 656 preconfigured threshold. 658 Buffer overrun is detected in the normal operation state when the 659 jitter buffer of the CE-bound IWF cannot accommodate newly arrived 660 SAToP packets. 662 Remote packet loss is indicated by reception of packets with their R 663 bit set. 665 6.4. SAToP PW Performance Monitoring 667 Performance monitoring (PM) parameters are routinely collected for TDM 668 services and provide an important maintenance mechanism in TDM 669 networks. Ability to collect compatible PM parameters for SAToP PWs 670 enhances their maintenance capabilities. 672 Structure-Agnostic TDM over Packet February 2006 674 Collection of the SAToP PW performance monitoring parameters is 675 OPTIONAL, and if implemented, is only performed after the CE-bound IWF 676 has exited its intermediate state. 678 SAToP defines error events, errored blocks and defects as follows: 680 o A SAToP error event is defined as insertion of a single 681 replacement packet into the jitter buffer (replacement of 682 payload of SAToP packets with the L bit set is not considered 683 as insertion of a replacement packet) 684 o A SAToP errored data block is defined as a block of data 685 played out to the TDM attachment circuit and of size defined 686 in accordance with the [G.826] rules for the corresponding TDM 687 service that has experienced at least one SAToP error event 688 o A SAToP defect is defined as the packet loss state of the CE- 689 bound SAToP IWF. 691 The SAToP PW PM parameters (Errored, Severely Errored and Unavailable 692 Seconds) are derived from these definitions in accordance with [G.826]. 694 7. QoS Issues 696 SAToP SHOULD employ existing QoS capabilities of the underlying PSN. 698 If the PSN providing connectivity between PE devices is Diffserv- 699 enabled and provides a PDB [RFC3086] that guarantees low-jitter and 700 low-loss, the SAToP PW SHOULD use this PDB in compliance with the 701 admission and allocation rules the PSN has put in place for that PDB 702 (e.g., marking packets as directed by the PSN). 704 If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC 2212] 705 with the appropriate bandwidth reservation SHOULD be used in order to 706 provide a bandwidth guarantee equal or greater than that of the 707 aggregate TDM traffic. 709 8. Congestion Control 711 As explained in [RFC3985], the PSN carrying the PW may be subject to 712 congestion. SAToP PWs represent inelastic constant bit-rate (CBR) flows 713 and cannot respond to congestion in a TCP-friendly manner prescribed by 714 [RFC2914], although the percentage of total bandwidth they consume 715 remains constant. 717 Unless appropriate precautions are taken, undiminished demand of 718 bandwidth by SAToP PWs can contribute to network congestion that may 719 impact network control protocols. 721 Whenever possible, SAToP PWs SHOULD be carried across traffic- 722 engineered PSNs that provide either bandwidth reservation and admission 723 control or forwarding prioritization and boundary traffic conditioning 724 Structure-Agnostic TDM over Packet February 2006 726 mechanisms. IntServ-enabled domains supporting Guaranteed Service (GS) 727 [RFC2212] and DiffServ-enabled domains [RFC2475] supporting Expedited 728 Forwarding (EF) [RFC3246] provide examples of such PSNs. Such 729 mechanisms will negate, to some degree, the effect of the SAToP PWs on 730 the neighboring streams. In order to facilitate boundary traffic 731 conditioning of SAToP traffic over IP PSNs, the SAToP IP packets SHOULD 732 NOT use the DiffServ Code Point (DSCP) value reserved for the Default 733 PHB[RFC2474]. 735 If SAToP PWs run over a PSN providing best-effort service, they SHOULD 736 monitor packet loss in order to detect "severe congestion". If such a 737 condition is detected, a SAToP PW SHOULD shut down bi-directionally for 738 some period of time as described in Section 6.5 of [RFC3985]. 740 Note that: 742 1. The SAToP IWF can inherently provide packet loss measurement since 743 the expected rate of arrival of SAToP packets is fixed and known 744 2. The results of the SAToP packet loss measurement may not be a 745 reliable indication of presence or absence of severe congestion if 746 the PSN provides enhanced delivery, e.g.: 747 a) If SAToP traffic takes precedence over non-SAToP traffic, severe 748 congestion can develop without significant SAToP packet loss 749 b) If non-SAToP traffic takes precedence over SAToP traffic, SAToP 750 may experience substantial packet loss due to a short-term burst 751 of high-priority traffic 752 3. The TDM services emulated by the SAToP PWs have high availability 753 objectives (see [G.826]) that MUST be taken into account when 754 deciding on temporary shutdown of SAToP PWs. 756 This specification does not define the exact criteria for detecting 757 "severe congestion" using the SAToP packet loss rate or the specific 758 methods for bi-directional shutdown the SAToP PWs (when such severe 759 congestion has been detected) and their consequent re-start after a 760 suitable delay. This is left for further study. However, the following 761 considerations may be used as guidelines for implementing the SAToP 762 severe congestion shutdown mechanism: 764 1. SAToP Performance Monitoring techniques (see Section 6.4) provide 765 entry and exit criteria for the SAToP PW "Unavailable" state that 766 make it closely correlated with the "Unavailable" state of the 767 emulated TDM circuit as specified in [G.826]. Using the same 768 criteria for "severe congestion" detection may decrease the risk of 769 shutting down the SAToP PW while the emulated TDM circuit is still 770 considered available by the CE. 771 2. If the SAToP PW has been set up using either PWE3 control protocol 772 [PWE3-CONTROL] or L2TPv3 [RFC 3931], the regular PW teardown 773 procedures of these protocols SHOULD be used. 774 3. If one of the SAToP PW end points stops transmission of packets for 775 a sufficiently long period, its peer (observing 100% packet loss) 776 will necessarily detect "severe congestion" and also stop 777 transmission, thus achieving bi-directional PW shutdown. 779 Structure-Agnostic TDM over Packet February 2006 781 9. Security Considerations 783 SAToP does not enhance or detract from the security performance of the 784 underlying PSN, rather it relies upon the PSN mechanisms for 785 encryption, integrity, and authentication whenever required. 787 SAToP PWs share susceptibility to a number of pseudowire-layer attacks, 788 and will use whatever mechanisms for confidentiality, integrity, and 789 authentication that are developed for general PWs. These methods are 790 beyond the scope of this document. 792 Although SAToP PWs MAY employ an RTP header when explicit transfer of 793 timing information is required, SRTP (see [RFC3711]) mechanisms are NOT 794 RECOMMENDED as a substitute for PW layer security. 796 Misconnection detection capabilities of SAToP increase its resilience 797 to misconfiguration and some types of DoS attacks. 799 Random initialization of sequence numbers, in both the control word and 800 the optional RTP header, makes known-plaintext attacks on encrypted 801 SAToP PWs more difficult. Encryption of PWs is beyond the scope of this 802 document. 804 10. Applicability Statement 806 SAToP is an encapsulation layer intended for carrying TDM circuits 807 (E1/T1/E3/T3) over PSN in a structure-agnostic fashion. 809 SAToP fully complies with the principle of minimal intervention, thus 810 minimizing overhead and computational power required for encapsulation. 812 SAToP provides sequencing and synchronization functions needed for 813 emulation of TDM bit-streams, including detection of lost or mis- 814 ordered packets and appropriate compensation. 816 TDM bit-streams carried over SAToP PWs may experience delays exceeding 817 those typical of native TDM networks. These delays include the SAToP 818 packetization delay, edge-to-edge delay of the underlying PSN and the 819 delay added by the jitter buffer. It is recommended to estimate both 820 delay and delay variation prior to setup of a SAToP PW. 822 SAToP carries TDM streams over PSN in their entirety including any TDM 823 signaling contained within the data. Consequently the emulated TDM 824 services are sensitive to the PSN packet loss. Appropriate generation 825 of replacement data can be used to prevent shutting down the CE TDM 826 interface due to occasional packet loss. Other effects of packet loss 827 on this interface (e.g., errored blocks) cannot be prevented. 829 Note: Structure-aware TDM emulation (see [CESoPSN] or [TDMoIP]) 830 completely hides effects of the PSN packet loss on the CE TDM interface 831 (because framing and CRCs are generated locally) and allows usage of 832 Structure-Agnostic TDM over Packet February 2006 834 application-specific packet loss concealment methods to minimize 835 effects on the applications using the emulated TDM service. 837 SAToP can be used in conjunction with various network synchronization 838 scenarios (see [PWE3-TDM-REQ)] and clock recovery techniques. The 839 quality of the TDM clock recovered by the SAToP IWF may be 840 implementation-specific. The quality may be improved by using RTP if a 841 common clock is available at both ends of the SAToP PW. 843 SAToP provides for effective fault isolation by carrying the local 844 attachment circuit failure indications. 846 The option not to carry invalid TDM data enables PSN bandwidth 847 conservation. 849 SAToP allows collection of TDM-like faults and performance monitoring 850 parameters hence emulating 'classic' carrier services of TDM. 852 SAToP provides for a carrier-independent ability to detect 853 misconnections and malformed packets. This feature increases resilience 854 of the emulated service to misconfiguration and DoS attacks. 856 Being a constant bit rate (CBR) service, SAToP cannot provide TCP- 857 friendly behavior under network congestion. 859 Faithfulness of a SAToP PW may be increased by exploiting QoS features 860 of the underlying PSN. 862 SAToP does not provide any mechanisms for protection against PSN 863 outages, and hence its resilience to such outages is limited. However, 864 lost-packet replacement and packet reordering mechanisms increase 865 resilience of the emulated service to fast PSN rerouting events. 867 11. IANA Considerations 869 Allocation of PW Types for the corresponding SAToP PWs is defined in 870 [PWE3-IANA]. 872 12. Disclaimer of Validity 874 The IETF takes no position regarding the validity or scope of any 875 Intellectual Property Rights or other rights that might be claimed 876 to pertain to the implementation or use of the technology 877 described in this document or the extent to which any license 878 under such rights might or might not be available; nor does it 879 represent that it has made any independent effort to identify any 880 such rights. Information on the procedures with respect to rights 881 in RFC documents can be found in BCP 78 and BCP 79. 883 Copies of IPR disclosures made to the IETF Secretariat and any 884 assurances of licenses to be made available, or the result of an 885 attempt made to obtain a general license or permission for the use 886 of such proprietary rights by implementers or users of this 887 Structure-Agnostic TDM over Packet February 2006 889 specification can be obtained from the IETF on-line IPR repository 890 at http://www.ietf.org/ipr. 892 The IETF invites any interested party to bring to its attention 893 any copyrights, patents or patent applications, or other 894 proprietary rights that may cover technology that may be required 895 to implement this standard. Please address the information to the 896 IETF at ietf-ipr@ietf.org. 898 ACKNOWLEDGEMENTS 900 We acknowledge the work of Gil Biran and Hugo Silberman who implemented 901 TDM transport over IP in 1998. 903 We would like to thank Alik Shimelmits for many productive discussions 904 and Ron Insler for his assistance in deploying TDM over PSN. 906 We express deep gratitude to Stephen Casner who has reviewed in detail 907 one of the predecessors of this document and provided valuable feedback 908 regarding various aspects of RTP usage, and to Kathleen Nichols who has 909 provided the current text of the QoS section considering Diffserv- 910 enabled PSN. 912 We thank William Bartholomay, Robert Biksner, Stewart Bryant, Rao 913 Cherukuri, Ron Cohen, Alex Conta, Shahram Davari, Tom Johnson, Sim 914 Narasimha, Yaron Raz, and Maximilian Riegel for their valuable 915 feedback. 917 13. NORMATIVE REFERENCES 919 [RFC791] J. Postel (ed), Internet Protocol, RFC 791, IETF, 1981 921 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels, 922 RFC 2119, 1997 924 [RFC2474] K. Nichols et al, Definition of the Differentiated Services 925 Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, 19998 927 [RFC2475] S. Blake et al, An Architecture for Differentiated Services, 928 RFC 2475, 1998 930 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, 2000 932 [RFC3086] K. Nichols, B. Carpenter, Definition of Differentiated 933 Services Per Domain Behaviors and Rules for their Specification, RFC 934 3086, 2001 936 [RFC3550] H. Schulzrinne et al, RTP: A Transport Protocol for Real-Time 937 Applications, RFC 3550, 2003 939 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- 940 parameters 941 Structure-Agnostic TDM over Packet February 2006 943 [G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit 944 Rates 946 [G.703] ITU-T Recommendation G.703 (10/98) - Physical/Electrical 947 Characteristics of Hierarchical Digital Interfaces 949 [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame 950 structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s 951 hierarchical levels 953 [G.707] ITU-T Recommendation G.707 (03/96) - Network Node Interface for 954 the Synchronous Digital Hierarchy (SDH) 956 [G.751] ITU-T Recommendation G.751 (11/88) - Digital Multiplex 957 Equipments Operating at the Third Order Bit Rate of 34368 kbit/s and 958 the Fourth Order Bit Rate of 139264 kbit/s and Using Positive 959 Justification 961 [G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS), 962 Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) Defect 963 Detection and Clearance Criteria for PDH Signals 965 [G.802] ITU-T Recommendation G.802 (11/88) - Interworking between 966 Networks Based on Different Digital Hierarchies and Speech Encoding 967 Laws 969 [G.826] ITU-T Recommendation G.826 (02/99) - Error performance 970 parameters and objectives for international, constant bit rate digital 971 paths at or above the primary rate 973 [T1.107] American National Standard for Telecommunications - Digital 974 Hierarchy - Format Specifications, ANSI T1.107-1988 976 [PWE3-CW] S. Bryant et al, PWE3 Control Word for use over an MPLS PSN, 977 Work in progress, October 2005, draft-ietf-pwe3-cw-06.txt 979 [PWE3-CONTROL] L. Martini et al, Pseudowire Setup and Maintenance using 980 LDP, Work in progress, June 2005, draft-ietf-pwe3-control-protocol- 981 17.txt 983 [PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire 984 Edge to Edge Emulation (PWE3), Work in progress, November 2005, draft- 985 ietf-pwe3-iana-allocation-15.txt 987 [RFC 3931] J. Lau, M.Townsley, I. Goyret, Layer Two Tunneling Protocol 988 - Version 3 (L2TPv3), RFC 3931, 2005 990 14. INFORMATIONAL REFERENCES 992 [RFC3916] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation 993 Edge-to-Edge (PWE3), RFC 3916, 2004 994 Structure-Agnostic TDM over Packet February 2006 996 [RFC4197] Maximilian Riegel, Requirements for Edge-to-Edge Emulation of 997 TDM Circuits over Packet Switching Networks (PSN), RFC 4197, 2005 999 [RFC3985] S. Bryant, P. Pate, PWE3 Architecture, RFC 3985, 2005 1001 [ATM-CES] ATM forum specification af-vtoa-0078 (CES 2.0) 1002 Circuit Emulation Service Interoperability Specification Ver. 2.0 1004 [CESoPSN] A.Vainshtein et al, TDM Circuit Emulation Service over Packet 1005 Switched Network (CESoPSN), Work in Progress, November 2005, draft- 1006 ietf-pwe3-cesopsn-06.txt 1008 [TDMoIP] Y. Stein, TDMoIP, Work in Progress, February 2005, draft-ietf- 1009 pwe3-tdmoip-03.txt 1011 [PWE3-TDM-CONTROL] A. Vainshtein, Y. Stein, Control Protocol Extensions 1012 for Setup of TDM Pseudowires, Work in Progress, July 2005, draft-ietf- 1013 pwe3-tdm-control-protocol-extensi-00.txt 1015 [PWE3-MS] L. Martini et al, Segmented Pseudo Wire, Work in Progress, 1016 July 2005, draft-ietf-pwe3-segmented-pw-00.txt 1018 [PWE3-VCCV] T. Nadeau, R. Aggarwal, Pseudo Wire Virtual Circuit 1019 Connectivity, Work in Progress, August 2005, draft-ietf-pwe3-vccv- 1020 05.txt 1022 [PWE3-FRAG] A. Malis, M. Townsley, PWE3 Fragmentation and Reassembly, 1023 Work in Progress, November 2005, draft-ietf-pwe3-fragmentation-10.txt 1025 [RFC3551] H. Schulzrinne, S. Casner, RTP Profile for Audio and Video 1026 Conferences with Minimal Control, RFC 3551, 2003 1028 [RFC3711] M. Baugher et al, The Secure Real-time Transport Protocol 1029 (SRTP), RFC 3711, 2004 1031 [RFC2212] S. Shenker et al, Specification of Guaranteed Quality of 1032 Service, RFC 2212, 1997 1034 [RFC3246], B. Davie et al, An Expedited Forwarding PHB (Per-Hop 1035 Behavior), RFC 3246, 2002 1037 ANNEX A. OLD MODE OF SATOP ENCAPSULATION OVER L2TPV3 1039 Previous versions of this specification defined a SAToP PW 1040 encapsulation over L2TPv3, which differs from one, described in Section 1041 4.3 and Diagram 2b. In these versions the RTP header, if used, precedes 1042 the SAToP control word. 1044 Structure-Agnostic TDM over Packet February 2006 1046 Existing implementations of the old encapsulation mode MUST be 1047 distinguished from the encapsulations conforming to this specification 1048 via the SAToP PW setup. 1050 ANNEX B. PARAMETERS THAT MUST BE AGREED UPON DURING THE PW SETUP 1052 The following parameters of the SAToP IWF MUST be agreed upon between 1053 the peer IWFs during the PW setup. Such an agreement can be reached via 1054 manual configuration or via one of the PW setup protocols: 1056 1. Type of the Attachment Circuit (AC): 1057 a) As mentioned in Section 3 above, SAToP supports the following AC 1058 types: 1059 i) E1 (2048 kbit/s) 1060 ii) T1 (1544 kbit/s) This service is also known as DS1 1061 iii) E3(34368 kbit/s) 1062 b) T3 (44736 kbit/s) This service is also known as DS3SAToP PWs 1063 cannot be established between ACs of different types 1064 2. Usage of octet-aligned mode for T1 1065 a) This OPTIONAL mode of emulating T1 bit-streams with SAToP PWs is 1066 described in Section 5.2 1067 b) Both sides MUST agree on using this mode for a SAToP PW to be 1068 operational 1069 3. Payload size, i.e. the amount of valid TDM data in a SAToP packet: 1070 a) As mentioned in Section 5.1 above: 1071 i) The same payload size MUST be used in both directions of 1072 the SAToP PW 1073 ii) The payload size cannot be changed once the PW has been set 1074 up 1075 b) In most cases any mutually agreed upon value can be used. 1076 However, if octet-aligned T1 encapsulation mode is used, the 1077 payload size MUST be an integral multiple of 25 and expresses 1078 the amount of valid TDM data including padding 1079 4. Usage of the RTP header in the encapsulation 1080 a) Both sides MUST agree on using RTP header in the SAToP PW 1081 b) In the case of a SAToP PW over L2TPv3 using the RTP header, both 1082 sides MUST agree on usage of the "old mode" described in Annex A 1083 above 1084 5. RTP-dependent parameters. These following parameters MUST be agreed 1085 upon if usage of the RTP header for the SAToP PW has been agreed 1086 upon: 1087 a) Timestamping mode (absolute or differential). This mode MAY be 1088 different for the two directions of the PW, but the receiver and 1089 transmitter MUST agree on the timestamping mode for each 1090 direction of the PW 1091 b) Timestamping clock frequency: 1092 i) The timestamping frequency MUST be a integral multiple of 1093 8kHz 1094 ii) The timestamping frequency MAY be different for the two 1095 directions of the PW, but the receiver and transmitter MUST 1096 agree on the timestamping mode for each direction of the PW 1097 c) RTP Payload Type (PT) value. 1098 Any dynamically assigned value can be used with SAToP PWs 1099 Structure-Agnostic TDM over Packet February 2006 1101 d) Synchronization Source (SSRC) value. The transmitter MUST agree 1102 to send the SSRC value requested by the receiver. 1104 Full Copyright Statement 1106 Copyright (C) The Internet Society (2006). 1108 This document is subject to the rights, licenses and restrictions 1109 contained in BCP 78, and except as set forth therein, the authors 1110 retain all their rights. 1112 This document and the information contained herein are provided on an 1113 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1114 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1115 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1116 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1117 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1118 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1120 Acknowledgement 1122 Funding for the RFC Editor function is currently provided by the 1123 Internet Society. 1125 Editors' Addresses 1127 Alexander ("Sasha") Vainshtein 1128 Axerra Networks 1129 24 Raoul Wallenberg St., 1130 Tel Aviv 69719, Israel 1131 email: sasha@axerra.com 1133 Yaakov (Jonathan) Stein 1134 RAD Data Communications 1135 24 Raoul Wallenberg St., Bldg C 1136 Tel Aviv 69719, Israel 1137 Email: yaakov_s@rad.com