idnits 2.17.00 (12 Aug 2021) /tmp/idnits27942/draft-vainshtein-cesopsn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1465 has weird spacing: '... errors and p...' -- 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 (February 2002) is 7400 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: 'G.703' is mentioned on line 134, but not defined == Missing Reference: 'IANA' is mentioned on line 754, but not defined == Missing Reference: 'RFC 1889' is mentioned on line 1024, but not defined ** Obsolete undefined reference: RFC 1889 (Obsoleted by RFC 3550) == Missing Reference: 'RFC2508' is mentioned on line 1321, but not defined == Missing Reference: 'G.783' is mentioned on line 1807, but not defined == Unused Reference: 'PWE3-SONET' is defined on line 1489, but no explicit reference was found in the text == Unused Reference: 'L2TPv3' is defined on line 1747, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 1517, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1520, but no explicit reference was found in the text == Unused Reference: 'RFC 2508' is defined on line 1524, but no explicit reference was found in the text == Unused Reference: 'RFC3140' is defined on line 1543, but no explicit reference was found in the text == Unused Reference: 'NANOG' is defined on line 1585, but no explicit reference was found in the text == Outdated reference: draft-ietf-pwe3-requirements has been published as RFC 3916 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. 'PWE3-REQ') == Outdated reference: A later version (-01) exists of draft-ietf-pwe3-framework-00 -- Possible downref: Normative reference to a draft: ref. 'PWE3-FW' -- Possible downref: Non-RFC (?) normative reference: ref. 'PWE3-LAYERS' == Outdated reference: draft-malis-sonet-ces-mpls has been published as RFC 5143 ** Downref: Normative reference to an Historic draft: draft-malis-sonet-ces-mpls (ref. 'MALIS') == Outdated reference: A later version (-03) exists of draft-malis-pwe3-sonet-00 -- Possible downref: Normative reference to a draft: ref. 'PWE3-SONET' == Outdated reference: A later version (-03) exists of draft-kompella-ppvpn-l2vpn-00 -- Possible downref: Normative reference to a draft: ref. 'KOMPELLA' == Outdated reference: draft-martini-l2circuit-trans-mpls has been published as RFC 4906 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. 'MARTINI-TRANS') == Outdated reference: draft-martini-l2circuit-encap-mpls has been published as RFC 4905 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. 'MARTINI-ENCAP') -- Possible downref: Non-RFC (?) normative reference: ref. 'L2TPv3' ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: draft-ietf-diffserv-rfc2598bis has been published as RFC 3246 ** Obsolete normative reference: RFC 2833 (Obsoleted by RFC 4733, RFC 4734) -- Possible downref: Non-RFC (?) normative reference: ref. 'RTP-TYPES' -- 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.802' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.826' -- Possible downref: Non-RFC (?) normative reference: ref. 'NANOG' Summary: 12 errors (**), 0 flaws (~~), 24 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alexander ("Sasha") Vainshtein 3 Israel Sasson 4 Akiva Sadovski 5 Internet Draft Axerra Networks 7 Expiration Date: Eduard Metz 8 August 2002 KPNQwest 10 Tim Frost 11 Zarlink Semiconductor 13 February 2002 15 TDM Circuit Emulation Service over Packet Switched Network (CESoPSN) 17 draft-vainshtein-cesopsn-02.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of section 10 of RFC 2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six 29 months and may be updated, replaced, or obsoleted by other documents 30 at any time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 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 method for encapsulating TDM digital 40 signals defined in the plesiochronous digital hierarchy (PDH) 41 as a pseudo-wire (PW) over various packet-switched networks (PSN). 42 In this regard this document complements similar work for SONET/SDH 43 circuits. 45 Proposed PW encapsulation uses RTP for clock recovery and supports 46 signaling between Provider Edge (PE) devices. 47 Encapsulation proposed in this document may be extended to low-rate 48 SONET/SDH traffic as well. 50 TABLE OF CONTENTS 52 1. Introduction 3 53 2. Summary of Changes from the -01 Revision 3 54 TDM Circuit Emulation Service over PSN August 2002 56 3. Terminology and Reference Models 4 57 3.1. Terminology 4 58 3.2. Reference Models 5 59 3.2.1. Generic Models 5 60 3.2.2. Synchronization Considerations and Deployment Scenarios 5 61 3.2.3. Service Examples 6 62 4. Scope and Requirements 7 63 4.1. Emulated Services 7 64 4.1.1. PDH Circuits 7 65 4.1.2. SONET/SDH Circuits 7 66 4.2. Scope 7 67 4.3. Generic Requirements 7 68 4.3.1. Relevant Common PW Requirements 7 69 4.3.2. Common Circuit Payload Requirements 8 70 4.3.3. The Principle of Minimal Intervention 8 71 4.4. Service-Specific Requirements 8 72 4.4.1. Interworking 8 73 4.4.2. Network Synchronization Schemes 8 74 4.4.3. CE Signaling 9 75 4.4.4. Latency and Encapsulation Effectiveness 9 76 4.4.5. Fault Detection and Handling 10 77 4.4.6. Performance Monitoring 10 78 4.4.7. Bandwidth Saving 10 79 4.4.8. Adaptation of the Jitter Buffer 10 80 5. CESoPSN Encapsulation 10 81 5.1. Generic CESoPSN Format 10 82 5.2. CESoPSN Header 11 83 5.2.1. Usage of RTP Header 11 84 5.2.2. Usage and Structure of the Control Word 12 85 5.3. Payload Data Format 13 86 5.3.1. Transparent N*DS0 Circuits 14 87 5.3.2. N*DS0 circuits with CAS 15 88 5.3.3. Unstructured TDM Circuits 16 89 6. CESoPSN Operation 17 90 6.1. Payload Parameters 18 91 6.1.1. PW Type 18 92 6.1.2. Circuit Bit Rate 18 93 6.2. Encapsulation Layer Parameters 19 94 6.2.1. Usage of Control Word 19 95 6.2.2. RTP Payload Type 19 96 6.2.3. Payload Bytes 19 97 6.2.4. Timestamp Resolution 20 98 6.2.5. Synchronization Source ID 20 99 6.2.6. Timestamp Generation Mode 20 100 6.3. End Service Inactivity Behavior 20 101 6.4. Description of the IWF operation 20 102 6.4.1. PSN-bound Direction 20 103 6.4.2. CE-bound Direction - Normal Operation 21 104 6.4.3. IWF Loopback 22 105 6.5. CESoPSN Defects 22 106 6.5.1. Misconnection 22 107 6.5.2. Re-Ordering and Loss of Packets 23 108 6.5.3. Malformed Packets 23 109 TDM Circuit Emulation Service over PSN August 2002 111 6.5.4. Loss of Synchronization 24 112 6.6. Performance Monitoring 24 113 6.6.1. Errored Data Blocks 24 114 6.6.2. Errored, Severely Errored and Unavailable Seconds 25 115 6.7. QoS Issues 25 116 7. RTP Payload Format Considerations 25 117 7.1. Resilience to moderate loss of individual packets 25 118 7.2. Ability to interpret every single packet 25 119 7.3. Non-usage of the RTP Header Extensions 25 120 7.4. Compression of RTP headers 25 121 8. Congestion Control (RFC 2914) Conformance 26 122 9. FFS Issues 26 123 10. Security Considerations 26 124 11. Applicability Statement 26 125 12. IANA Considerations 28 126 13. Intellectual Property Considerations 28 127 ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN 32 128 ANNEX B. EMULATION OF SONET/SDH CIRCUITS 34 130 1. Introduction 132 This document describes requirements for edge-to-edge emulation of 133 time division multiplexed (TDM) digital signals defined in 134 Plesiochronous Digital Hierarchy (PDH), see [G.703], [G.704], 135 [T.107] [T1.103] and [T1.107a] and a corresponding encapsulation 136 technique. 138 To support TDM traffic, which includes voice, data, and private 139 leased line service, the network must emulate the circuit 140 characteristics of a TDM network. A new circuit emulation header 141 and RTP-based mechanisms for carrying clock over PSN are used to 142 encapsulate TDM signals and provide the Circuit Emulation Service 143 over PSN (CESoPSN). 145 Primary application of the technique described in this document is 146 emulation of PDH circuits in situations when native PDH traffic is 147 generated by CE devices and does not depend upon the way this 148 traffic reaches PE devices. However, its use may be extended to 149 carrying SDH traffic as "unstructured TDM", thus providing an 150 alternative to the approach defined in [MALIS]. 152 The CESoPSN solution presented in this document fits the framework 153 for PW services as described in [PWE3-FW] and satisfies the general 154 requirements put forward in [PWE3-REQ]. 156 2. Summary of Changes from the -01 Revision 158 Note: This section will be removed from the final document. 160 1. A section on generic and service-specific requirements for 161 edge-to-edge emulation of TDM circuits has been added 162 2. Fractional E1/T1 has been consistently replaced with N*DS0 163 TDM Circuit Emulation Service over PSN August 2002 165 3. Support of channel-associated CE signaling (CAS) for N*DS0 166 services based upon the techniques defined in [RFC2833] has 167 been added 168 4. The structure of the control word has been aligned with the 169 [MARTINI-ENCAP] 170 5. References have been updated in accordance with the latest 171 developments 172 6. RTP Payload Types have been decoupled from PW types. Dynamic 173 allocation of PT values will be used instead 174 7. Most of the text that should logically belong to more generic 175 PWE3 documents and/or tutorials has been removed 176 8. In-band CESoPSN loopback commands have been removed 177 9. G.826-compatible PM parameters for CESoPSN have been defined 178 10. A brief description of adaptive jitter buffer behavior has 179 been added. 181 3. Terminology and Reference Models 183 3.1. Terminology 185 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 186 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 187 document are to be interpreted as described in [RFC2119]. 189 The terms defined in [PWE3-FW], Section 1.4 are consistently used, 190 usually without additional explanations. However: 191 o The terms 'CE-bound' and 'PSN-bound' are consistently used 192 instead of 'outbound' and 'inbound' when describing traffic 193 directions 194 o The term "Interworking function" (IWF) is often used for 195 describing the protocol operation with explicit references to 196 CE-bound or PSN-bound direction of the IWF. 198 Some terms and acronyms are commonly used in conjunction with the 199 TDM services. In particular: 200 o Alarm Indication Signal (AIS) is a common term denoting a 201 special bit pattern in the TDM bit stream that indicates 202 presence of an upstream circuit outage 203 o Channel-Associated Signaling (CAS) is one of several signaling 204 techniques used by the telephony applications to convey 205 various states of these applications (e.g., off-hook and ob- 206 hook). CAS uses a certain, circuit-specific multiframe 207 structure that is imposed on the TDM bit stream and a 208 predefined association between the relative timeslot (= 209 channel) number within this stream and position of certain 210 bits within this multiframe structure. Up to 16 application 211 states can be distinguished and signaled (see [G.704] for 212 details). 214 TDM Circuit Emulation Service over PSN August 2002 216 3.2. Reference Models 217 3.2.1. Generic Models 219 Generic models that have been defined in Sections 3.1 (Network 220 Reference Model), 3.2 (Maintenance Reference Model), 3.4 (Protocol 221 Stack Reference Model) and 3.5(Logical Protocol Layering Model) of 222 [PWE3-FW] are fully applicable for the purposes of this document 223 without any modifications. 225 All the services considered in this document represent special cases 226 of the generic circuit-oriented payload type defined in Section 227 3.5.2.1 of [PWE3-FW]. 229 3.2.2. Synchronization Considerations and Deployment Scenarios 231 Two basic issues must taken into account regarding possible 232 synchronization techniques for emulation of circuit-oriented 233 services: 234 o Can all the PE devices of the given pseudo-wire domain (PWD) 235 be synchronized? Or, in more precise terms, is the same high- 236 quality synchronization source available to all the PE devices 237 in the given PWD? 238 o Is the CE device synchronized to the same source as its 239 'local' PE? 240 The answer to the first question depends upon design of the specific 241 PSN. E.g. PE devices in a PSN based entirely on POS links can be 242 easily synchronized while PE devices of a PSN based on Gigabit 243 Ethernet links (or on a mix of Gigabit Ethernet and POS) would as 244 often as not remain unsynchronized. 246 The answer to the second question depends on specifics of the 247 customers served by the PSN operator. In particular, if the CE 248 devices are just nodes in the customers' TDM networks with their own 249 synchronization schemes, they would probably continue to use these 250 schemes even if the PSN is fully synchronized. 252 Combinations of answers to these basic questions provide at least 253 three viable deployment scenarios: 254 1. "One Synchronous Network" Scenario, i.e.: 255 a. The same high-precision synchronization source is 256 available in all the PE devices of the given PSN 257 b. This synchronization source is also used by all the CE 258 devices terminating TDM end services of PWs crossing the 259 PSN 260 c. The PW mechanisms must provide compensation only for the 261 packets inter-arrival jitter introduced by the PSN 262 2. "Synchronous Carriers' Carrier" Scenario, i.e.: 263 a. The same high-precision synchronization source is 264 available in all the PE devices of the given PSN 265 b. Each Emulated circuit connects two CEs that are either 266 loop-timed to the corresponding PE or synchronized to 267 their own synchronization source 268 TDM Circuit Emulation Service over PSN August 2002 270 c. The PW must carry the difference between the PSN clock and 271 the CE clock over the PSN as well as compensate the 272 packets' inter-arrival jitter introduced by the PSN 273 3. "Asynchronous Carriers' Carrier" Scenario, i.e.: 274 a. Each PE uses its own synchronization source. The quality 275 of this source is selected in accordance with requirements 276 of the emulated services (e.g., a Stratum 4 clock is 277 sufficient for E1 and T1 services) 278 b. Each emulated circuit connects two CEs that are either 279 loop-timed to the corresponding PE or synchronized to 280 their own synchronization source 281 c. Every direction of the PW must carry the original line 282 clock of its end service across the PSN as well as 283 compensate for the packets' inter-arrival jitter 284 introduced by the PSN. 286 3.2.3. Service Examples 288 Fig.1 below presents several examples of a T1 Emulated Service. 290 _/_ \ / \ / \ 291 +------+ Physical /+-+ \__/ \ _ Hub Site 292 |Site A| T1 / |P| +---+ \ (CE-3) 293 |T1 #1=|====================|E|=| R | +---+ +-+ \ OC12+------+ 294 |(CE-1)| \ |1| | |===| | | |---------| | 295 +------+ / +-+ +---+ | | | | ========|=T1 #1| 296 / | R |=|P| | | 297 +------+ T1 +---+ DS3 / +-+ +---+ | | |E| ========|=T1 #2| 298 |Site B| | |-----------|P| | R |===| | |3|---------| | 299 |T1 #2=|====|M13|===========|E|=| | +---+ +-+ / +------+ 300 |(CE-2)| | |-----------|2| +---+ / 301 +------+ +---+ \ +-+ / 302 \ ___ ___ / 303 \_/ \____/ \___/ 305 Figure 1: T1 Emulation Example Diagram 307 In this diagram, T1 circuits are attached to the PE devices in three 308 different ways: 309 o As a physical T1 line (between CE-1 and PE-1) 310 o As a virtual T1 signal multiplexed in DS3 using one of 311 possible multiplexing formats (between CE-2 and PE-2, see 312 [T1.103] for details). M23 is a PDH multiplexor 313 o As a virtual T1 signal mapped into an appropriate SONET 314 virtual tributary, the latter being multiplexed in OC-12 315 (between CE-3 and PE-3 - see [T1.105] or [G.707] for details). 317 TDM Circuit Emulation Service over PSN August 2002 319 4. Scope and Requirements 320 4.1. Emulated Services 321 4.1.1. PDH Circuits 323 This specification describes service-specific encapsulation layer 324 for edge-to-edge emulation of the following TDM services over a PSN: 326 1. Structured services: 327 a. Transparent N*DS0, 1 <= N <= 31 as described in [G.704]. 328 b. N*DS0 with channel-associated signaling (CAS) as described 329 in [G.704], 1<= N <= 30 330 2. Unstructured services 331 a. Unstructured E1 as described in [G.704] 332 b. Unstructured T1 (DS1) as described in [T.157a] 333 c. Unstructured E3 as defined in [G.751] 334 d. Unstructured T3 (DS3) as described in [T.157a] 336 4.1.2. SONET/SDH Circuits 338 Encapsulation layer described in this specification MAY be, with 339 some modifications, also used for emulation of unstructured "low- 340 rate" (STS-1/STM-0, STS-3c/STM-1) SONET/SDH circuits. Details are 341 discussed in Annex B. 343 4.2. Scope 345 This specification defines only the encapsulation layer for edge-to- 346 edge emulation of TDM services mentioned in Section 4.1. 348 In accordance with the logical protocol layering architecture for 349 PWE3, the encapsulation layer MUST NOT be dependent upon specific 350 instantiations of: 351 1. The PSN layer (i.e. IPv4, IPv6 or MPLS). In order to satisfy 352 this requirement, encapsulation should be used on packets of 353 fixed size to avoid possible need in the PSN-specific optional 354 length service 355 2. Multiplexing layer. In order to satisfy this requirement and, 356 at the same time, to allow detection of 'stray packets' the 357 encapsulation header SHOULD provide some means for identifying 358 the packets as belonging to the PW. 360 4.3. Generic Requirements 362 Note: This and the following section should be split into a separate 363 requirements document. 365 4.3.1. Relevant Common PW Requirements 367 The encapsulation layer for TDM services considered in this document 368 should comply with the following common PW requirements defined in 369 [PWE3-REQ]: 370 1. Conveyance of Necessary L2/L1 Header Information - relevant 371 only for TDM structured services 372 TDM Circuit Emulation Service over PSN August 2002 374 2. Support of Multiplexing and Demultiplexing if supported by 375 the native services - relevant for N*DS0 circuits with or 376 without CAS 377 3. Handling Control Messages of the Native Services - relevant 378 only for structured TDM services 380 4. Consideration of the PSN Tunnel Header Overhead (see also 381 Section 4.4.4 below) 382 5. Detection and handling of PW faults (see also Section 4.4.5 383 below). In particular, ability to detect loss of packets 384 SHOULD be supported in order to allow differentiation 385 between outages of the emulated service resulting from PSN 386 problems and these resulting from problems beyond the PSN 387 6. Clock Recovery (see also Section 4.4.2 below). 389 4.3.2. Common Circuit Payload Requirements 391 All the services considered in this document belong to the generic 392 'Circuit Payload' type defined in [PWE3-FW], Section 3.5.2.1.1. 394 Accordingly, the encapsulation layer MUST provide the common 395 Sequencing service and SHOULD provide timing information. 397 The encapsulation layer for the Circuit Payload services does not 398 necessarily have to provide the length service. 400 4.3.3. The Principle of Minimal Intervention 402 The encapsulation layer SHOULD comply with the principle of minimal 403 intervention as described in [PWE3-LAYERS], Section 4.3.5. 405 4.4. Service-Specific Requirements 407 4.4.1. Interworking 409 1. The encapsulation layer MUST support network interworking 410 between end services of the same type and bit-rate. 411 2. The encapsulation layer SHOULD remain unaffected by specific 412 characteristics of connection between the end services and PE 413 devices at the two ends of the PW (see service examples in 414 Section 3.2.3 above). 416 4.4.2. Network Synchronization Schemes 418 The encapsulation layer MUST be applicable to all the network 419 synchronization schemes mentioned in Section 3.2.2. 421 If the same high-quality synchronization source is available to all 422 the PE devices in the given domain the encapsulation layer SHOULD be 423 able to infer additional benefits (e.g., facilitate better 424 reconstruction of the native service clock) from this fact. 426 TDM Circuit Emulation Service over PSN August 2002 428 4.4.3. CE Signaling 430 Unstructured TDM services do not usually require any special 431 mechanisms for carrying CE signals as these would be carried as part 432 of the emulated service. 434 Structured TDM services may require application-specific CE 435 signaling. 437 In some cases this signaling may require synchronization with the 438 data. E.g., code-associated signaling (CAS) reflects the state of 439 telephony applications (like off-hook and on-hook) that must be 440 passed across the emulated service and synchronized with data to 441 allow normal operation of these applications. 443 The encapsulation layer SHOULD support signaling of state of CE 444 applications for the relevant services providing for: 445 o Multiplexing of application-specific CE signals and data of 446 the emulated service in the same PW 447 o Synchronization (within the application-specific tolerance 448 limits) between CE signals and data at the PW egress 449 o Probabilistic recovery against possible accidental loss of 450 signaling packets in the PSN 451 o Deterministic recovery of the CE application state after PW 452 setup and network outages. 454 Some types of CE signaling associated with the TDM circuits (e.g., 455 performance monitoring requests and responses, requests to operate 456 and release loopbacks etc.) do not reflect application state and 457 hence do not require synchronization with data. As a consequence, 458 these signals can be passed out-of-band and do not have to be 459 supported by the encapsulation layer. 461 The payload format for the 'signaling' packets MAY be application- 462 specific. 464 4.4.4. Latency and Encapsulation Effectiveness 466 The encapsulation layer SHOULD allow for an effective trade-off 467 between the following requirements: 468 1. Effective PSN bandwidth utilization. Assuming that the size of 469 encapsulation layer header does not depend on the size of its 470 payload, increase in the packet payload size results in 471 increased efficiency. 472 2. Low edge-to-edge latency. Low end-to-end latency is the common 473 requirement for Voice applications over TDM services. 474 Packetization latency is one of the components comprising 475 edge-to-edge latency and decreases with the packet payload 476 size. 478 TDM Circuit Emulation Service over PSN August 2002 480 4.4.5. Fault Detection and Handling 482 The encapsulation layer for edge-to-edge emulation of TDM services 483 SHOULD, separately or in conjunction with the lower layers of the 484 pWE3 stack, provide for detection of the following defects: 485 1. Misconnection 486 2. Loss of packets. Special importance of detection of this 487 defect has been explained in Section 4.3.1 above 488 3. Malformed packets 489 4. Loss of synchronization. 491 4.4.6. Performance Monitoring 493 The encapsulation layer for edge-to-edge emulation of TDM services 494 should provide for collection of performance monitoring (PM) data 495 that is compatible with the parameters defined for 'classic', TDM- 496 based carriers of these services (see [G.826] for details). 498 4.4.7. Bandwidth Saving 500 The encapsulation layer should provide for saving the PSN bandwidth 501 by not sending invalid data. 503 4.4.8. Adaptation of the Jitter Buffer 505 The encapsulation layer SHOULD allow adaptation of the jitter buffer 506 size to the actually observed level of the packets' inter-arrival 507 jitter while maintaining acceptable levels of errors that are 508 introduced by such an adaptation. 510 Note: The meaning of 'acceptable level of errors' depends on the 511 application using the emulated service. In particular, Voice 512 applications can tolerate loss or insertion of a single octet in a 513 contiguous sequence of several non-erroneous octets. (In case of 514 insertion, it is customary to repeat the previous, non-erroneous, 515 octet.) 517 5. CESoPSN Encapsulation 519 5.1. Generic CESoPSN Format 521 CESoPSN packets use format shown in Fig. 2 below. 523 TDM Circuit Emulation Service over PSN August 2002 525 0 1 2 3 526 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 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | ... | 529 | PSN and multiplexing layer headers | 530 | ... | 531 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 532 | Fixed | 533 +-- --+ 534 | RTP | 535 +-- --+ 536 | Header (see [RFC1889]) | 537 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 538 | CESoPSN Control Word (optional) | 539 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 540 | Packetized TDM data or CE signaling data | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 Figure 2. CESoPSN Format 545 5.2. CESoPSN Header 547 The CESoPSN header includes a fixed RTP header (12 octets) and an 548 optional CESoPSN Control Word (4 octets). 550 5.2.1. Usage of RTP Header 552 CESoPSN uses the fields of the fixed RTP header (see [RFC1889], 553 Section 5.1) in the following way: 555 o V (version) is always set to 2 556 o P (padding) is always set to 0 557 o X (header extension) is always set to 0 558 o CC (CSRC count) is always set to 0 559 o M (marker) is set to 0 to for CESoPSN packets carrying PDH 560 circuits. CESoPSN packets carrying unstructured SONET/SDH 561 circuits MAY set this bit to 1 to distinguish packets that 562 carry the framing octets 563 o PT (payload type) is used to distinguish between packets 564 carrying the packetized TDM data and packets carrying CE 565 signaling. At least one PT value should be allocated from the 566 range of dynamic values (see [RTP-TYPES]) for every CESoPSN 567 PW. Allocation is done during the PW setup and MUST be the 568 same for both PW directions. The PE at the PW ingress MUST set 569 the PT value in the RTP header to the allocated value. The PE 570 at the PW egress MAY use this value to detect malformed 571 packets. An additional PT value from the same range MUST be 572 allocated for CESoPSN PWs supporting in-band CE signaling (see 573 Section 5.3.2 below) 574 o Sequence number is used primarily to provide the common PW 575 sequencing function as well as detection of lost packets. It 576 is generated and processed in accordance with the rules 577 established in [RFC1889] 578 TDM Circuit Emulation Service over PSN August 2002 580 o Timestamp is used primarily for carrying timing information 581 over the network. Their values are used in accordance with the 582 rules established in [RFC1889]. Frequency of the clock used 583 for generating timestamps MUST be a multiple of 8 KHz. 584 Possible modes of timestamp generation are discussed below 585 o The SSRC (synchronization source) value in the RTP header MAY 586 be used for detection of misconnections. 588 Note: The same PT value can be safely allocated for different PWs. 590 The RTP header in CESoPSN can be used in conjunction with at least 591 the following modes of timestamp generation: 593 1. Absolute mode: the ingress PE sets time stamps using the clock 594 recovered from the incoming TDM bit stream 595 2. Differential mode: PE devices connected by the PW have access 596 to the same high-quality synchronization source, and this 597 synchronization source is used for timestamp generation. 599 Usage of other timestamp generation modes is left for further study. 601 Absolute mode allows operation in the Asynchronous Carrier's Carrier 602 deployment scenario. Differential mode may improve quality of the 603 recovered clock in the One Synchronous Network and Synchronous 604 Carrier's Carrier deployment scenarios. 606 5.2.2. Usage and Structure of the Control Word 608 Usage of the CESoPSN control word allows: 610 o Differentiation between the PSN problems and the problems 611 beyond the PSN as causes for the emulated service outages 612 o Saving bandwidth by not transferring invalid data (AIS, idle 613 code) 614 o Signaling problems detected at the PW egress to its ingress 616 Consequently, usage of the CESoPSN Control Word is the recommended 617 default. The PE peers MAY agree not to use it in a specific CESoPSN 618 PW as part of the PW setup process. 620 Note: Alternative techniques for conveying forward and backward 621 indications without using the control word are left for further 622 study. 624 The structure of the CESoPSN Control Word is shown in Fig. 3 below. 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 |0|0|0|0|A|I|L|T|Z| Reserved | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 Figure 3. Structure of the CESoPSN Control Word 633 TDM Circuit Emulation Service over PSN August 2002 635 o Bits 0-3 MUST be set to 0 at ingress and MUST be ignored at 636 egress 637 o Bit A - carries Local AIS indication. If set, represents AIS 638 of the carried unstructured circuit. A packet with the A bit 639 set MAY carry no payload 640 o Bit I - carries Local Idle Code indication. If set, represents 641 the Idle Code in the payload of a N*DS0, a N*DS0 with CAS or 642 an unstructured T3 circuit. A packet with the I bit set MAY 643 carry no payload 644 o Bit L - carries Remote Loss of Packets indication of the PW 645 carrying CESoPSN, i.e., this bit is set in packets transmitted 646 by PE-2 to PE-1 if PE-2 detected loss of packets in the stream 647 received from PE-1 648 o Bit T - carries Remote Synchronization Problem indication. 649 o Bit Z - if set, indicates that the CESoPSN IWF operates under 650 a PW loopback command (regardless of the origin of this 651 command). If cleared, indicates normal CESoPSN IWF operation 652 o Reserved - these bits are reserved for possible future use. 653 Currently they MUST be set to 0 at ingress and ignored at 654 egress. 655 Notes: 656 1. Either A or I bit (but not both) can be set in the CESoPSN 657 control word. 658 2. Information about lost packets (carried via the L bit) can be 659 used at ingress as an indication to resynchronize CE 660 application state, see Section 5.3.2 below. 662 5.3. Payload Data Format 664 A single CESoPSN packet always contains one or more native circuit 665 frames of the carried circuit. This provides for emulation of 666 performance monitoring parameters of "classic" carriers of TDM 667 circuits (e.g., SONET/SDH). 669 Note: The native circuit frames for all the circuits considered in 670 this document save from unstructured T1 are octet-aligned. The T1 671 native circuit frame (193 bits) is not, and hence requires special 672 treatment - see Section 5.3.4 below. 674 The PSN operator selects the number of native service frames in a 675 CESoPSN packet for a specific PW taking into account the following 676 considerations: 677 o Packetization latency requirements vs. bandwidth utilization 678 (see Section 4.4.4 above) 679 o Path MTU limitations in order to avoid fragmentation of 680 CESoPSN packets 682 This specification assumes that the number of native service frames 683 in a CESoPSN packet is: 684 o Defined during the PW setup and remains constant for the 685 duration of a PW. Such an arrangement simplifies 686 implementation because it implies that the CESoPSN packets are 687 transmitted at a constant rate 688 TDM Circuit Emulation Service over PSN August 2002 690 o The same for both directions of the PW. Such an arrangement 691 simplifies signaling and processing of backwards problem 692 indications. 694 5.3.1. Transparent N*DS0 Circuits 696 The payload data format for transparent N*DS0 circuits is shown in 697 Fig. 4 below (N - number of timeslots in the circuit, M = number of 698 the native circuit frames in a CESoPSN packet, the 1st timeslot of 699 the 1st native frame is the 1st octet of the payload). The matrix 700 shown in this diagram is mapped into array of payload octets row by 701 row. 703 Timeslots ->| 1 | 2 | ... | N | 704 ------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 705 N C F 1| | | ... | | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 a i r 2| | | ... | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 t r a ...| | | ... | | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 i c m ...| | | ... | | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 v u e ...| | | ... | | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 e i s ...| | | ... | | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 t M| | | ... | | 718 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 720 Figure 4. Payload structure for a N*DS0 Circuit 722 CESoPSN-based emulation of a transparent N*DS0 TDM circuit can be 723 considered as "bundling" of N independent DS0 circuits (see [PWE3- 724 REQ], Section 2.1.3). 726 The payload structure described provides for adaptation of the 727 jitter buffer size for Voice applications while maintaining 728 acceptable level of errors: 729 o Actual size of the jitter buffer can be decreased by 730 "shortening" the payload of some of the packets already in the 731 buffer by the one "row" (native circuit frame) when they are 732 transmitted. This is equivalent to dropping one octet from 733 each timeslot 734 o Actual size of the jitter buffer can be increased by 735 "lengthening" the payload of some of the packets already in 736 the buffer by one "row" (native circuit frames) when they are 737 transmitted. This is equivalent to insertion of a single octet 738 into each timeslot; the values carried in the last actual row 739 of the matrix are repeated. 741 TDM Circuit Emulation Service over PSN August 2002 743 5.3.2. N*DS0 circuits with CAS 745 A PW that emulates an N*DS0 circuit with CAS assumes that CE devices 746 are PSTN switches that synchronize the state of each of N DS0 747 channels using channel-associated signaling. This PW carries TDM 748 data in format described in the previous section. 750 In addition, it carries the CAS state vector of each CE in special 751 signaling packets using: 753 o An additional PT value allocated for this purpose from the 754 range of unused values (see [IANA]). This value MUST be 755 different from one allocated for the TDM data packets for the 756 same PW 757 o An additional SSRC value that MUST be different from one used 758 for the data packets in order to allow a separate numbering 759 sequence for the signaling packets 760 o A sequence numbering scheme that does not depend on one used 761 for the data packets. This allows re-use of common sequence 762 numbers-based mechanisms (like reordering and detection of 763 lost packets) for the data packets for all types of circuits 764 o The signaling payload format described in Fig. 5 below. Format 765 of the 32-bit timeslot signaling word is defined in [RFC2833] 766 Section 3.5 and Section 3.14, and numbering of timeslots 767 corresponds to that of the "columns" in the data packets' 768 payload, see Fig. 4. 770 0 1 2 3 771 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 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Timeslot signaling word for TS-1 | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Timeslot signaling word for TS-2 | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 | ... | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Timeslot signaling word for TS-N | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 782 Figure 5. Payload of a Signaling Packet for a N*DS0 Circuit with CAS 784 Note: The "volume" field defined in the [RFC2833] Section 3.5 is not 785 used with CAS events. 787 CESoPSN does not require handling of loss of signaling packets; as a 788 consequence, detection of loss of these packets is not required 789 either. On the other hand, the same synchronization source MUST be 790 used for timestamps in both signaling and data packets in order to 791 synchronize data and signaling within reasonable limits. 793 TDM Circuit Emulation Service over PSN August 2002 795 Signaling packets are generated by the ingress PE in accordance with 796 the following logic (adapted from [RFC2833]): 798 1. The CESoPSN signaling packet with the same information is 799 sent 3 times at an interval of 5 ms under one of the 800 following conditions: 801 a. The CESoPSN PW has been set up 802 b. A change in CAS state of one of the timeslots has been 803 detected. If another change of CAS state has been detected 804 during the 15 ms period, this process continues 805 c. Loss of packets defect has been cleared 806 d. Remote Loss of Packets indication has been cleared (after 807 previously being set) 808 2. Otherwise, the CESoPSN signaling packet with the current 809 CAS state information is sent every 5 seconds. 811 These rules allow fast probabilistic recovery after loss of a single 812 signaling packet as well as deterministic (but, possibly, slow) 813 recovery following PW setup and PSN outages. 815 5.3.3. Unstructured TDM Circuits 817 Basically, unstructured TDM circuits do not require framers in the 818 PE devices, and are transferred as bit streams. However, presence of 819 a framer allows detection of some outages of the end services. As a 820 consequence, efficiency of the CESoPSN operation under such outages 821 may be increased. 823 The payload of a CESoPSN packet carrying an unstructured TDM circuit 824 with an octet-aligned native circuit frame MUST contain one or more 825 native circuit frames of the carried circuit, but no alignment with 826 the framing structure of the service is required. 828 5.3.3.1 "T1-in-E1" Mode for Unstructured T1 Circuits 830 As mentioned above, unstructured T1 represents the only case of a 831 TDM circuit considered in this document with a non-octet aligned 832 native circuit frame. In order to accommodate this type of circuit 833 into the general CESoPSN framework, a special "T1 in E1" payload 834 format (similar to one defined in [G.802]) is used as shown in Fig 5 835 below (M = number of native frames in the CESoPSN packet, D denotes 836 the payload data bits). 838 TDM Circuit Emulation Service over PSN August 2002 840 "Timeslots" | 1 | ... | 24 | 25 | 841 |0 1 2 3 4 5 6 7| ... |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| 842 ------------+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 843 N C F 1|D D D D D D D D| ... |D D D D D D D D|D| padding | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 a i r 2|D D D D D D D D| ... |D D D D D D D D|D| padding | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 t r a ...|D D D D D D D D| ... |D D D D D D D D|D| padding | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 i c m ...|D D D D D D D D| ... |D D D D D D D D|D| padding | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 v u e ...|D D D D D D D D| ... |D D D D D D D D|D| padding | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 e i s ...|D D D D D D D D| ... |D D D D D D D D|D| padding | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 t M|D D D D D D D D| ... |D D D D D D D D|D| padding | 856 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 858 Figure 6. The "T1-in-E1" CESoPSN Payload Format 860 Note: Each row in the matrix presented in Fig. 6 contains exactly 861 193 payload data bits (and 7 padding bits). However, no alignment of 862 the rows with the T1 framing structure is implied and hence support 863 of this mode does not require a T1 framer in PE. 865 6. CESoPSN Operation 867 Note: This section includes non-normative information and 868 implementation considerations. These elements will be moved to an 869 appropriate Appendix in the next update. 871 Edge-to-edge circuit emulation of a TDM circuit using CESoPSN 872 assumes the following elements: 873 o Two PW end services of the same type and bit rate 874 o Packetizer at the PW ingress 875 o Jitter buffer and de-packetizer at the PW egress. 877 Setup of a CESoPSN PW assumes exchange of the following information: 878 o Types of end services. In order to be connected by a CESoPSN 879 PW, these types MUST be the same and define the PW type. PW 880 types supported by CESoPSN MUST be accommodated into the 881 common enumeration of PW types 882 o Bit rates of end services. In order to be connected, bit rates 883 of the two end services MUST be the same and define the PW bit 884 rate 885 o Encapsulation layer-specific parameters that define specific 886 instantiation of the protocol 888 This document defines how the values of these parameters should be 889 encoded. The actual signaling protocols for exchanging these 891 parameters between the PE peers ("PE/PW signaling" in terms of 892 [PWE3-FW]) are out of scope of this document. 894 TDM Circuit Emulation Service over PSN August 2002 896 Description of the CESoPSN-based edge-to-edge circuit emulation 897 includes the following elements: 898 o Definition of the end service inactive state behavior towards 899 the CE 900 o Description of the IWF operation in CE-bound and PSN-bound 901 direction. 903 Details are presented below. 905 6.1. Payload Parameters 906 6.1.1. PW Type 908 PW types (a.k.a. VC types) have been defined in [MARTINI-TRANS]. PW 909 types used for CESoPSN PW are assigned in such a way as to avoid 910 overlap with types assigned in other PWE3 documents. 912 The following PW types are defined in this document for CESoPSN- 913 based PWs: 915 o Transparent N*DS0 - 65 916 o N*DS0 with CAS - 66 917 o Unstructured E1 - 67 918 o Unstructured T1, bit stream mode - 68 (not defined in this 919 specification) 920 o Unstructured T1, T1-in-E1 mode - 69 921 o Unstructured E3 - 70 922 o Unstructured T3 - 71 923 o Unstructured SONET/SDH - 72 (see Annex B). 925 6.1.2. Circuit Bit Rate 927 The circuit bit rate is encoded as the number of "timeslots" in the 928 matrix structure of the corresponding CESoPSN data packet. 930 The following values are used: 932 o Transparent N*DS0 - N, 1 <= N <= 31 933 o N*DS0 with CAS - N, 1 <= N <= 30 934 o Unstructured E1 - 32 935 o Unstructured T1, T1-in-E1 mode - 25 936 o Unstructured E3 - 537 937 o Unstructured T3 - 699 938 o Unstructured STS-1 - 810 939 o Unstructured STM-1 - 2430 941 Note: N*DS0, unstructured E1 and unstructured T1 circuits can be 942 carried over any PSN implementing the minimal MTU as defined in 943 [RFC1122]. Unstructured E3 and T3 can be carried over any PSN 944 providing Path MTU of 1.5 Kbytes. Unstructured STS-1 and STM1 are 945 considered in Annex A. 947 TDM Circuit Emulation Service over PSN August 2002 949 6.2. Encapsulation Layer Parameters 950 6.2.1. Usage of Control Word 952 TRUE value (default) of this Boolean parameter means that the 953 CESoPSN control word is used. 955 CESoPSN MAY allow negotiation of this parameter, so that the control 956 word will not be used if both sides agree to that. 958 6.2.2. RTP Payload Type 960 1. One PT value MUST be allocated from the range of 961 dynamically allocated payload types for each CESoPSN PW for 962 use in the data packets: 963 a. The same value MUST be allocated for both directions of 964 the PW 965 b. Ingress PW MUST set the PT in the RTP header of all the 966 data packets to the allocated value 967 c. Egress PW MAY use this value to detect non-data PW 968 packets. These packets can be either relegated to 969 signaling or considered as malformed 970 2. For emulation of a N*DS0 circuit with CAS, an additional PT 971 value MUST be allocated from the range of dynamically 972 allocated payload types for each CESoPSN PW for use in the 973 data packets: 974 a. It MUST be different from the PT value allocated for data 975 packets 976 b. The same value MUST be allocated for both directions of 977 the PW 978 c. Ingress PW MUST set the PT in the RTP header of all the 979 signaling packets to the allocated value 980 3. Egress PW MAY use this value to distinguish signaling PW 981 packets. 983 Note: The same PT value may be allocated for multiple PWs. 985 6.2.3. Payload Bytes 987 This parameter has been defined in [MARTINI-TRANS]. In order to 988 establish a CESoPSN-based PW, the following conditions MUST be met: 989 o The number of payload bytes MUST be the same for both 990 directions of the PW 991 o The number of payload bytes MUST be a multiple of the encoded 992 Circuit Bit Rate (see Section 6.1.2 above). E.g., the value of 993 this parameter for an Unstructured E1 circuit (Circuit Bit Rate 994 = 32) with M native circuit frames packet into a single CESoPSN 995 packet will be 32*M, while for an Unstructured T1 it will be 996 25*M 998 o The size of the resulting PW packet (including all the headers) 999 SHOULD NOT exceed the path MTU between the participating PEs as 1000 provided by the Carrier layer. 1002 TDM Circuit Emulation Service over PSN August 2002 1004 Note: For N*DS0 with CAS circuits this parameter defines the number 1005 of payload bytes in the data packets only. The number of payload 1006 bytes in the signaling packets is inferred from the encoded circuit 1007 bit rate in the obvious way. 1009 6.2.4. Timestamp Resolution 1011 This parameter encodes the rate of the clock used for setting 1012 timestamps in RTP headers as a multiple of the basic 8 KHz rate. 1014 6.2.5. Synchronization Source ID 1016 The same 32-bit SSRC value MUST be assigned to all the data packets 1017 of a given direction of a CESoPSN PW. The CE-bound direction of the 1018 IWF MAY be use this value for misconnection detection, especially if 1019 such a service is not provided by the PSN and/or multiplexing 1020 layer(s). 1022 If data and signaling packets are multiplexed in the same PW, the 1023 signaling packets MUST use a separate SSRC value. This arrangement 1024 complies with the RTP specification [RFC 1889] and allows effective 1025 compression of the PW headers by the standard compressors. 1027 6.2.6. Timestamp Generation Mode 1029 This parameter accepts at least the following two values 1030 corresponding to operation modes described in Section 5.2.1: 1032 o Absolute (1) 1033 o Differential (2). 1035 6.3. End Service Inactivity Behavior 1037 While the PW is inactive: 1038 o Each unstructured end service MUST send AIS to its prospective 1039 CE 1040 o Each structured end service MUST send an appropriate Idle Code 1041 to its prospective CE 1043 6.4. Description of the IWF operation 1045 Once the PW is set up, the CESoPSN IWF operates like following: 1047 6.4.1. PSN-bound Direction 1049 1. End service data is packetized in accordance with the number 1050 of payload bytes specified. For N*DS0 services, the 1051 packetized data are aligned with the native circuit frames as 1052 described in Section 5.3.1 1053 2. Sequence numbers and timestamps representing the selected 1054 synchronization clock are inserted in the CESoPSN headers 1055 TDM Circuit Emulation Service over PSN August 2002 1057 3. CESoPSN, multiplexing and PSN headers are prepended to the 1058 packetized circuit data 1059 4. Resulting packets are transmitted via the PSN 1060 5. If the PE detects any outage of the incoming an unstructured 1061 end service that natively would result in sending the 1062 "downstream AIS", the CESoPSN IWF using the control word MUST 1063 set the local AIS indication flag (bit A) in the control word. 1064 The packet payload MAY be omitted in order to save the PSN 1065 bandwidth. 1066 6. If the PE detects an Idle Code condition of the incoming an 1067 unstructured T3 end service, or an AIS-producing condition is 1068 detected in the incoming 'carrier service' of an N*DS0 end 1069 service, the CESoPSN IWF using the control word MUST set the 1070 local Idle Code indication flag (bit I) in the control word. 1071 The packet payload MAY be omitted in order to save the PSN 1072 bandwidth. 1074 Local AIS and Idle Code indications in the CESoPSN control word 1075 provide for the following functionality: 1076 o Ability to distinguish between the PSN problems and ones 1077 beyond the PSN as causes of outages of the emulated service 1078 o Ability to save the PSN bandwidth (but not its switching 1079 capacity) by not sending invalid data across the PSN. 1081 The techniques to save the PSN switching capacity in case of an end 1082 service outage are left for further study. 1084 6.4.2. CE-bound Direction - Normal Operation 1086 1. The CE-bound IWF includes a jitter buffer that accumulates 1087 data from incoming CESoPSN packets with their respective 1088 timestamps. The length of this buffer SHOULD be configurable 1089 to allow adaptation to various network delay behavior 1090 patterns. Size of the jitter buffer is a local parameter of 1091 the CESoPSN IWF. Since any CESoPSN data packet carries a fixed 1092 number of native data frames of the emulated service, the 1093 jitter buffer can be considered as a matrix with "rows" 1094 corresponding to native service frames, too. 1095 2. Initially the Jitter buffer is filled with the appropriate 1096 inactivity (AIS or Idle) code. 1097 3. Immediately after start, IWF: 1098 a. Begins reception of incoming CESoPSN packets. PSN and 1099 multiplexing layer headers are stripped from the received 1100 packets, and packetized TDM data from the received packets 1101 is stored in the jitter buffer 1102 b. Continues to play out its appropriate inactivity code into 1103 its end service as long as the jitter buffer has not yet 1104 accumulated sufficient amount of data 1105 c. Signals the CE-bound direction of the local IWF to transmit 1106 CESoPSN packets with the T bit set (if control word is 1107 used) 1108 4. Once the jitter buffer contains sufficient amount of data 1109 (usually half of its capacity), the IWF starts replay of this 1110 TDM Circuit Emulation Service over PSN August 2002 1112 data in its end service in accordance with its (locally 1113 defined) 8 KHz transmission clock, so that a single "row" of 1114 the jitter buffer matrix is replayed per "tick" of the clock. 1115 At the same moment it signals the PSN-bound direction of IWF 1116 to clear the T bit in the CESoPSN packets it transmits (if the 1117 control word is used) 1118 5. If transmission clock must be recovered from the PW, the 1119 timestamps of data packets SHOULD be used for correcting 1120 initial transmission clock frequency in accordance with the 1121 specified mode of their generation. 1122 6. If adaptation of the jitter buffer size is implemented, it 1123 SHOULD NOT introduce additional wander of the transmission 1124 clock. It MAY introduce additional errors (e.g., in accordance 1125 with the techniques described in Section 5.3.1 above) 1126 7. The CE-bound direction of the IWF: 1127 a. Performs detection, correlation and handling of CESoPSN 1128 faults as described in Section 6.5 below 1129 b. Collects the PW Performance Monitoring data as defined in 1130 Section 6.6 below 1131 8. CE application state signals received in the signaling packets 1132 SHOULD be synchronized with data using the timestamps and 1133 inserted (in an appropriate format) into the CE-bound TDM 1134 stream. Signals that cannot be inserted into the CE-bound TDM 1135 stream due to the local format limitations MUST BE ignored. 1136 Any aspects of translation of values of CE signals are out of 1137 scope of this specification. 1139 6.4.3. IWF Loopback 1141 An IWF loopback for the CESoPSN IWF MAY be set and cleared by an 1142 external (management) command. 1144 Once such a loopback is set, the IWF will loop packets coming from 1145 the PSN back to the PSN. In addition it will mark these packets by 1146 setting Z bit in the CESoPSN control word. 1148 Once the loopback is cleared, the IWF resumes its normal operation. 1150 6.5. CESoPSN Defects 1151 6.5.1. Misconnection 1153 Some combinations of PSN and multiplexing layers (see Annex A) 1154 inherently provide for detection of packets that do not belong to 1155 the PW ('stray packets'). 1157 CESoPSN MAY use the SSRC field in the RTP header for detection of 1158 'stray packets' even if such a capability is provided by the 1159 specific combination of PSN and multiplexing layers. 1161 Regardless of the way in which a stray packet has been detected: 1162 o It MUST be discarded by the CE-bound IWF 1163 o A counter of 'stray packets' must be incremented 1164 TDM Circuit Emulation Service over PSN August 2002 1166 o If reception of stray packets persists, the Misconnection 1167 alarm should be reported to the management system. 1169 The IWF mechanisms for detection of lost packets (e.g., expected next 1170 sequence number) MUST NOT be affected by reception of 'stray packets'. 1171 6.5.2. Re-Ordering and Loss of Packets 1173 CESoPSN implementations SHOULD use sequence numbers in the RTP 1174 header and expected rate of transmission of data packets for 1175 detection of our-of-order delivery and packets' loss. In particular, 1176 they MAY maintain the next expected sequence number value that would 1177 be: 1178 o Advanced every time a packet belonging to this PW with an 1179 equal or greater (mod 65536) sequence number has been received 1180 or a timeout defined by the expected packet arrival rate has 1181 expired 1182 o Used as the center of a sliding window for packet reordering. 1183 The size of this window SHOULD be limited by the size of the 1184 jitter buffer. 1186 Out-of-order packets that cannot be reordered MUST be considered as 1187 lost. 1189 If loss of one or more CESoPSN packets has been detected at the 1190 egress of the CESoPSN PW, its jitter buffer MUST be filled with the 1191 appropriate amount of the AIS (or Idle - depending on the service 1192 type) code to be replayed into the relevant PWES. In addition: 1193 o If the CESoPSN control word is used, the Remote Lost Packets 1194 Indication flag (bit L) MUST be set in the next packet to be 1195 sent in the opposite direction of the PW 1196 o A counter of lost packets must be incremented 1197 o If the loss-of-packets condition persists, an alarm should be 1198 sent to the management system. 1200 6.5.3. Malformed Packets 1202 CESoPSN PW detects a malformed packet using the following rules: 1203 o The PT value in its RTP header does not correspond to one 1204 of the PT values allocated for this PW 1205 o The actual packet payload size can be unambiguously 1206 inferred from the data link, PSN or multiplexing layer of 1207 the PW and does not match the payload size defined for the 1208 packets of this type in this PW. 1210 If a malformed in-order packet has been received at the egress of a 1211 CESoPSN PW, then: 1213 o Its jitter buffer MUST be filled with the appropriate amount 1214 of the AIS (or Idle) code replay to be replayed into the 1215 relevant PWES 1216 o A counter of malformed packets must be incremented 1217 o If the payload mistype condition persists, an appropriate 1218 alarm should be sent to the management system. 1220 TDM Circuit Emulation Service over PSN August 2002 1222 6.5.4. Loss of Synchronization 1224 The CESoPSN IWF MAY detect two types of loss of synchronization 1225 errors: 1227 6.4.5.1 Jitter Buffer Overrun 1229 This fault is detected if the jitter buffer at the PW egress cannot 1230 accommodate the newly arrived CESoPSN packet in its entirety. 1232 A CESoPSN packet that cannot be stored in the jitter buffer MUST be 1233 discarded. 1235 If the jitter buffer overrun condition persists, an appropriate 1236 alarm should be sent to the management system. In addition, the 1237 Remote Loss of Synchronization (bit T) flag SHOULD be set in the 1238 next packet to be send in the opposite direction of the service. 1240 6.5.4.2. Jitter Buffer Underrun 1242 This fault is detected if the jitter buffer at the PW egress becomes 1243 empty before arrival of a new CESoPSN packet while loss of packets 1244 has not been detected. CESoPSN implementations MAY never detect the 1245 Jitter Buffer Underrun condition if their packets' loss detection 1246 mechanisms do not allow it. 1248 If the jitter buffer underrun condition persists, an appropriate 1249 alarm should be sent to the management system. In addition, the 1250 Remote Loss of Synchronization (bit T) flag SHOULD be set in the 1251 next packet to be send in the opposite direction of the service. 1253 6.6. Performance Monitoring 1254 6.6.1. Errored Data Blocks 1256 [G.826] defines the concept of an errored data block that serves as 1257 the basis of for collection of performance monitoring parameters. It 1258 also defines the size of the data block for most TDM circuits. These 1259 definitions are aligned with the 'native circuit frame' size of 1260 these circuits so that every G.826-compatible data block contains an 1261 integer multiple of native circuit frames, e.g.: 1262 o For E1 and T1 circuits, a data block contains 4 native service 1263 frames 1264 o For E3 and T3 circuits, a data block contains one native 1265 service frame etc. 1267 The following definitions of error events and errored data blocks 1268 for CESoPSN provide for collection of [G.826]-compatible performance 1269 monitoring parameters: 1270 o An error event is insertion of a single native service frame 1271 of inactivity code into the jitter buffer if it does not stem 1272 from receiving a CESoPSN packet with an AIS or Idle Code 1273 indication 1274 TDM Circuit Emulation Service over PSN August 2002 1276 o An errored data block is a data block defined in accordance 1277 with [G.826] that has experienced at least one error event. 1279 6.6.2. Errored, Severely Errored and Unavailable Seconds 1281 The definition of an errored data block presented above can be used 1282 to define Errored Seconds, Severely Errored Seconds and Unavailable 1283 Seconds in accordance with [G.826]. 1285 6.7. QoS Issues 1287 If the PSN providing connectivity between PE devices is Diffserv- 1288 enabled and implements EF PHB (see [RFC2598bis]), all the CESoPSN 1289 data packets should be marked for EF PHB at ingress. Such an 1290 arrangement results in decrease of the packets' inter-arrival jitter 1291 and hence in decrease of latency introduced by the TDM circuit 1292 emulation. 1294 7. RTP Payload Format Considerations 1296 In accordance with guidelines specified in [RFC2736], the following 1297 issues are addressed by this specification: 1299 7.1. Resilience to moderate loss of individual packets 1301 The impact of loss of an individual data packet may be decreased by 1302 decreasing the packet size (with the associated loss of efficiency). 1304 Resilience to loss of an individual signaling packet is provided for 1305 by the rules described in Section 5.3.2 above. 1307 7.2. Ability to interpret every single packet 1309 This requirement is met since every CESoPSN packet carries a 1310 multiple of the native frame of the carried service. 1312 7.3. Non-usage of the RTP Header Extensions 1314 This recommendation is met, since RTP-wise, the CESoPSN Control Word 1315 is part of the RTP payload. Alignment with this requirement 1316 facilitates usage of standard header compression mechanisms if 1317 CESoPSN uses UDP/IP as its PSN and multiplexing layers. 1319 7.4. Compression of RTP headers 1321 Existing relevant standards ([RFC2508], [RFC3095]) deal with 1322 compression of RTP/UDP/IP headers on specific P2P links. Compression 1323 techniques defined in these documents are fully applicable for 1324 CESoPSN if it uses UDP/IP as PSN and multiplexing layers 1325 respectively. Standard compression of CESoPSN/UDP/IP headers will be 1326 very effective, since: 1327 o Value of the SSRC field in the CESoPSN header of data packets 1328 remains constant for the duration of a CESoPSN session 1329 TDM Circuit Emulation Service over PSN August 2002 1331 o Value of the Timestamp field in the CESoPSN header is usually 1332 incremented by a fixed value from packet to packet 1333 o CESoPSN control word is NOT defined as RTP header extension. 1335 As a consequence, a PSN-independent end-to-end compression technique 1336 of RTP headers seems not justified. 1338 8. Congestion Control (RFC 2914) Conformance 1340 CESoPSN PWs carry constant bit rate (CBR) services. These services, 1341 by definition, cannot behave in a TCP-friendly manner prescribed by 1342 [RFC2914] under congestion while retaining any value for the user. 1344 Devices implementing CESoPSN and using IP as their PSN layer: 1345 o MUST set the ECN bits of the IP header (see [RFC3168]) to non- 1346 ECT ('00') value at ingress (to prevent routers in the network 1347 from setting them to the CE ('11') value 1348 o SHOULD ignore these bits at egress. 1350 9. FFS Issues 1352 Note: This section will be removed from the final revision of the 1353 document. 1355 The following issues will be addressed in the next revisions of this 1356 document: 1358 o Techniques for saving the PSN switching capacity when the PW 1359 experiences an end service outage or does not carry any valid 1360 data 1361 o Usage of RTCP. One particular application to be considered is 1362 retrieval of remote problems' indications without the control 1363 word 1364 o Effect of timestamp resolution on quality of clock recovery in 1365 Differential mode. 1367 10. Security Considerations 1369 This document does not affect the underlying security issues of 1370 specific PSN. 1371 In addition, it defines misconnection detection capabilities of 1372 CESoPSN. These capabilities increase resilience of CESoPSN to 1373 misconfiguration and some types of DoS attacks. 1375 11. Applicability Statement 1377 CESoPSN is an encapsulation layer intended for carrying TDM circuits 1378 (transparent N*DS0, transparent N*DS0 with CAS, unstructured E1/T1 1379 and unstructured E3/T3) over PSN. 1381 Applicability of CESoPSN MAY be extended to low-rate SONET/SDH 1382 circuits with minimal modifications. 1384 TDM Circuit Emulation Service over PSN August 2002 1386 CESoPSN allows carrying both data and clock of TDM circuits across 1387 multiple types of PSN. 1389 CESoPSN allows carrying CE signaling that requires synchronization 1390 with data (e.g., channel-associated signaling (CAS) for Voice 1391 applications) in-band in separate signaling packets. The RTP Payload 1392 Type (PT) is used to distinguish between data and signaling packets, 1393 while the Timestamp field is used for synchronization. This makes 1394 CESoPSN extendable to support different types of CE signaling 1395 without affecting the data path in the PE devices. 1397 CESoPSN does not presume availability of a global synchronous clock 1398 at the ends of a PW. This makes it suitable for Asynchronous 1399 Carriers' Carrier applications. 1401 CESoPSN uses RTP for carrying the clock across the PSN. The 1402 additional CESoPSN header (if used) is a payload format header and 1403 hence standard header compression techniques for RTP/UDP/IP profile 1404 over links slow and/or error-prone links are fully applicable to 1405 CESoPSN PWs. 1407 CESoPSN allows the PSN bandwidth conservation by carrying only AIS 1408 and/or Idle Code indications instead of data. 1410 Being a constant bit rate (CBR) service, CESoPSN cannot provide TCP- 1411 friendly behavior under network congestion. 1413 CESoPSN allows collection of TDM-like faults and performance 1414 monitoring parameters hence emulating 'classic' carrier services of 1415 TDM circuits (e.g., SONET/SDH). Similarity with these services is 1416 increased by the CESoPSN ability to carry 'far end error' 1417 indications. 1419 CESoPSN provides for a carrier-independent ability to detect 1420 misconnections and malformed packets. This feature increases 1421 resilience of the emulated service to misconfiguration and DoS 1422 attacks. 1424 CESoPSN provides for detection of lost packets and hence allows to 1425 distinguish between the PSN problems and ones beyond the PSN as 1426 causes of outages of the emulated service. 1428 Faithfulness of a CESoPSN PW may be increased if the carrying PSN is 1429 Diffserv-enabled and implements EF PHB. 1431 CESoPSN does not provide any mechanisms for protection against PSN 1432 outages. As a consequence, resilience of the emulated service to 1433 such outages is defined by the PSN behavior. On the other hand, the 1434 jitter buffer and packets' reordering mechanisms associated with 1435 CESoPSN increase resilience of the emulated service to fast PSN 1436 rerouting events. 1438 TDM Circuit Emulation Service over PSN August 2002 1440 12. IANA Considerations 1442 This specification requires assignment of new PW Types for CESoPSN 1443 PWs as described in Section 6.1. 1445 13. Intellectual Property Considerations 1447 This document is being submitted for use in IETF standards 1448 discussions. Axerra Networks, Inc. has filed one or more patent 1449 applications relating to the CESoPSN technology outlined in this 1450 document. Where there is a necessary dependence upon such patents 1451 and patent applications in implementing an IETF adopted standard 1452 resulting from this document, Axerra Networks will license on fair, 1453 reasonable, and non-discriminatory terms to all parties, any patent 1454 claims it owns covering such technology, solely to the extent such 1455 technology is essential to comply with such standard. Any such 1456 license to a party shall start on the date that Axerra Networks and 1457 the party enter into an agreement related thereto and shall be 1458 granted on the condition that any such party grants to Axerra 1459 Networks and its corporate affiliates a reciprocal license under 1460 such party's patents for which there is also a necessary dependence. 1462 ACKNOWLEDGEMENTS 1464 We express deep gratitude to Stephen Casner who reviewed this 1465 document in detail, corrected some serious errors and provided many 1466 valuable inputs. Some of his inputs will be explored in the next 1467 revisions of the draft. 1469 We thank Sim Narasimha and Yaron Raz for valuable feedbacks. 1471 We thank Alik Shimelmits for many fruitful discussions. 1473 REFERENCES 1475 [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation 1476 Edge-to-Edge (PWE3), Work in Progress, July-2001, draft-ietf-pwe3- 1477 requirements-01.txt 1479 [PWE3-FW] Prayson Pate et al, Framework for Pseudo Wire Emulation 1480 Edge-to-Edge (PWE3), Work in progress, February 2002, draft-ietf- 1481 pwe3-framework-00.txt 1483 [PWE3-LAYERS], Stewart Bryant et al., Protocol Layering in PWE3, 1484 Work in Progress, February 2002, pwe3-protocol-layering-01.txt 1485 [MALIS] Andrew G. Malis et al, SONET/SDH Circuit Emulation Service 1486 Over MPLS (CEM) Encapsulation, Work in progress, April 2001, draft- 1487 malis-sonet-ces-mpls-04.txt 1489 [PWE3-SONET] Andrew G. Malis et al, SONET/SDH Circuit Emulation over 1490 Packet (CEP), Work in progress, September 2001, draft-malis-pwe3- 1491 sonet-00.txt 1492 TDM Circuit Emulation Service over PSN August 2002 1494 [KOMPELLA] MPLS-based Layer 2 VPNs, Work in Progress, July 2001, 1495 draft-kompella-ppvpn-l2vpn-00.txt 1497 [MARTINI-TRANS] Luca Martini et al, Transport of Layer 2 Frames Over 1498 MPLS, Work in progress, November 2001, draft-martini-l2circuit- 1499 trans-mpls-08.txt 1501 [MARTINI-ENCAP] Luca Martini et al, Encapsulation Methods for 1502 Transport of Layer 2 Frames Over MPLS, Work in progress, November 1503 2001, draft-martini-l2circuit-encap-mpls-04.txt 1505 [L2TPv3] J.Lau et al, Layer Two Tunneling Protocol "L2TP", Work in 1506 progress, October 2001, draft-ietf-l2tpext-l2tp-base-01.txt 1508 [RFC1122] R. Braden (ed.), Requirements for Internet Hosts -- 1509 Communication Layers, RFC 1122, IETF, 1989 1511 [RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real- 1512 Time Applications, RFC 1889, IETF, 1996 1514 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement 1515 Levels, RFC 2119, IETF, 1997 1517 [RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA 1518 Considerations Section in RFCs, RFC 2434, IETF, 1998 1520 [RFC2474] K. Nichols et al., Definition of the Differentiated 1521 Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC 2474, 1522 IETF, 1998 1524 [RFC 2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for 1525 Low-Speed Serial Links, RFC 2508, IETF, 1999 1527 [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP 1528 Payload Format Specifications, RFC 2736, IETF, 1999 1530 [RFC2598bis] Bruce Davie (ed.), An Expedited Forwarding PHB, Work in 1531 Progress, April 2001, draft-ietf-diffserv-rfc2598bis-01.txt 1533 [RFC2833] H. Schulzrinne, S. Petrack, RTP Payload for DTMF Digits, 1534 Telephony Tones and Telephony Signals. RFC 2833, IETF, 2000 1536 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 1537 2000 1539 [RFC3095] C.Bormann (Ed.), RObust Header Compression (ROHC): 1540 Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC 1541 3095, IETF, 2001 1543 [RFC3140] D. Black et al, Per Hop Behavior Identification Codes, RFC 1544 3140, IETF, June 2001 1545 TDM Circuit Emulation Service over PSN August 2002 1547 [RFC3168] K. Ramakrishnan, S. Floyd, D. Black, The Addition of 1548 Explicit Congestion Notification (ECN) to IP, RFC 3168, IETF, 2001 1550 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- 1551 parameters 1553 [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame 1554 structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s 1555 hierarchical levels 1557 [G.707] ITU-T Recommendation G.707 (10/00) - Network Node Interface 1558 for Synchronous Digital Hierarchy (SDH) 1560 [G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex 1561 equipments operating at the third order bit rate of 34 368 Kbit/s 1562 and the fourth order bit rate of 139 264 Kbit/s and using positive 1563 justification 1565 [G.802] ITU-T Recommendation G.802 (11/88) - Interworking between 1566 networks based on different digital hierarchies and speech encoding 1567 laws 1569 [G.826] ITU-T Recommendation G.826 (02/99) - Error performance 1570 parameters and objectives for international, constant bit rate 1571 digital paths at or above the primary rate 1573 [T1.103] ANSI T1.103 - 1987. Digital Hierarchy - Synchronous DS3 1574 Format Specification 1576 [T1.105] ANSI T1.105-1991. Digital Hierarchy - Optical Interface 1577 Rates and Format Specifications (SONET} 1579 [T1.107] ANSI T1.107 - 1988. Digital Hierarchy - Format 1580 Specification 1582 [T1.107a] ANSI T1.107a - 1990. Digital Hierarchy - Supplement to 1583 Format Specifications (DS3 Format Specifications) 1585 [NANOG] St. Casner, C. Alaettinoglu, Ch. Kuan, A fine-grained view 1586 of high-performance networking, NANOG-22, May 2001 1588 AUTHORS' ADDRESSES 1590 Alexander ("Sasha") Vainshtein 1592 Axerra Networks 1594 24 Raoul Wallenberg St. 1596 Tel Aviv 69719, Israel 1597 email: sasha@axerra.com 1598 TDM Circuit Emulation Service over PSN August 2002 1600 Israel Sasson 1602 Axerra Networks 1604 24 Raoul Wallenberg St. 1606 Tel Aviv 69719, Israel 1608 email: israel@axerra.com 1610 Akiva Sadovski 1612 Axerra Networks 1614 24 Raoul Wallenberg St. 1616 Tel Aviv 69719, Israel 1618 email: akiva@axerra.com 1620 Eduard Metz 1622 KPNQwest 1623 Scorpius 60 1624 2130 GE Hoofddorp, The Netherlands 1625 email: eduard.metz@kpnqwest.com 1627 Tim Frost 1629 Zarlink Semiconductor 1631 Tamerton Road, Roborough, Plymouth, PL6 7BQ, UK 1633 email: tim.frost@zarlink.com 1635 FULL COPYRIGHT STATEMENT 1637 Copyright (C) The Internet Society (2001). All Rights Reserved. This 1638 document and translations of it may be copied and furnished to 1639 others, and derivative works that comment on or otherwise explain it 1640 or assist in its implementation may be prepared, copied, published 1641 and distributed, in whole or in part, without restriction of any 1642 kind, provided that the above copyright notice and this paragraph 1643 are included on all such copies and derivative works. However, this 1644 document itself may not be modified in any way, such as by removing 1645 the copyright notice or references to the Internet Society or other 1646 Internet organizations, except as needed for the purpose of 1647 developing Internet standards in which case the procedures for 1648 copyrights defined in the Internet Standards process must be 1649 TDM Circuit Emulation Service over PSN August 2002 1651 followed, or as required to translate it into languages other than 1652 English. 1653 The limited permissions granted above are perpetual and will not be 1654 revoked by the Internet Society or its successors or assigns. 1655 This document and the information contained herein is provided on an 1656 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1657 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1658 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1659 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1660 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1662 ACKNOWLEDGEMENT 1664 Funding for the RFC Editor function is currently provided by the 1665 Internet Society. 1667 ANNEX A. CESoPSN IN DIFFERENT TYPES OF PSN 1669 A1. IP PSN 1671 CESoPSN is RTP-based, and UDP flows are a natural way to convey RTP 1672 traffic (see [RFC1889]). 1673 If this technique is used for conveying CESoPSN, then: 1674 o Unused even UDP ports must be allocated at both PE nodes 1675 terminating a CESoPSN PW as part of the PW establishment 1676 process 1677 o IP and UDP headers must be prepended to each CESoPSN packet 1678 o These packets will be transmitted by each PE node to its peer 1679 using the standard IP routing mechanisms. 1681 UDP flows represent a multiplexing layer with limited ability to 1682 detect misconnections. As a consequence, SSRC-based misconnection 1683 detection by CESoPSN MAY be disabled. 1685 IP represents a Carrier layer with inherent ability to infer the 1686 payload size from the header. As a consequence, detection of 1687 malformed packets SHOULD take the actual payload size into 1688 consideration. 1690 By default, manual signaling can be used for setup and teardown of 1691 CESoPSN PWs over UDP flows. As a consequence, parameters defined in 1692 Section 6 should be incorporated into to the appropriate service- 1693 specific MIB module. 1695 [RFC1889] defines a convention for associating an RTCP session with 1696 each RTP/UDP/IP one. Possible usage of RTCP for CESoPSN is left for 1697 further study. 1699 A2. MPLS PSN 1701 Note: The text below does not define a generic RTP/MPLS stack. Such 1702 a work is clearly out of scope of this document. 1704 TDM Circuit Emulation Service over PSN August 2002 1706 This section is concerned with the case of MPLS being used as both 1707 the PSN and multiplexing layer for the CESoPSN PW. 1709 In this case, CESoPSN packet MUST be prepended with an MPLS label 1710 stack including: 1711 o A VC label entry (see [MARTINI-TRANS] or [KOMPELLA]). This 1712 entry acts as the multiplexing layer header. It MUST be 1713 present in the stack and MUST be marked as residing at the 1714 bottom of the stack 1715 o A tunnel label entry. This label, if present, acts as the PSN 1716 header and must immediately precede the VC label entry. It MAY 1717 be omitted in some situations. 1719 This combination of PSN and multiplexing layers does not provide 1720 either frame length information or ability to detect misconnections. 1721 The former is not necessary for CESoPSN but limits ability to detect 1722 malformed packets in case of a very short packet payload. The 1723 misconnection detection functionality can be provided using the 1724 following considerations: 1725 1. The pattern in the first four bits following the bottom label 1726 ('1000') can be used as indication of an RTP header as it is 1727 distinct from any of the following: 1728 a. IPv4 pattern ('0100') 1729 b. IPv6 pattern ('0110') 1730 c. Pattern produced by Layer 2 services over MPLS encapsulated 1731 in accordance with [MARTINI-ENCAP] and using control word 1732 ('0000') 1733 2. The SSRC field of the RTP header can be further used to detect 1734 misconnection. 1736 MPLS tunnels are conventionally established using various signaling 1737 protocols. As a consequence, parameters used for setup and teardown 1738 of CESoPSN tunnels should be mapped to data elements of these 1739 protocols. 1741 A3. L2TP PSN 1743 Note: The text below does not define a generic RTP/L2TPv3 stack. 1744 Such a work is clearly out of scope of this document. 1746 CESoPSN packets may be carried in L2TPv3 tunnels over IP (see 1747 [L2TPv3]) that would act as an alternative multiplexing layer over 1748 IP. 1750 Since L2TPv3 provides both data and control plane for tunnel 1751 establishment, parameters describing payload and encapsulation 1752 layers should be defined as AVPs to allow single-ended setup and 1753 teardown of CESoPSN PWs. 1755 L2TPv3 tunnels represent a multiplexing layer with an optional 1756 ability to detect misconnections using 32-bit or 64-bit "cookies". 1757 As a consequence, the PSN operator may choose between the L2TPv3- 1758 TDM Circuit Emulation Service over PSN August 2002 1760 based and SSRC-based misconnection detection techniques for CESoPSN 1761 PWs. 1763 IP represents a PSN layer with inherent ability to infer the payload 1764 size from the header. As a consequence, malformed packets detection 1765 should consider actual payload size. 1767 ANNEX B. EMULATION OF SONET/SDH CIRCUITS 1769 B1. Relevant Types of SONET/SDH circuits 1771 o STS-1 1772 o STM-1 1774 B2. Native Frame Size and Payload Format 1776 Natural delineation of SONET/SDH frames (of abovementioned rates) 1777 will produce packets exceeding minimal MTU in some cases. As a 1778 consequence, a SONET/SDH frame must be fragmented into several 1779 CESoPSN packets will be used. 1781 Usage of CESoPSN for unstructured SONET/SDH circuits requires 1782 presence of an appropriate framer in the ingress and egress PEs. 1784 Each SONET/SDH frame will be fragmented into the Protocol Data Units 1785 (PDUs) of equal size. Data belonging to two and more different 1786 frames MUST NOT be combined into one PDU. For each SONET/SDH frame 1788 only one CESoPSN packet will contain the framing octets (A1, A2) of 1789 this frame. Such a packet: 1791 o MUST contain these bytes aligned with its payload data 1792 (i.e., the 1st octet of the payload MUST contain the 1st A1 1793 byte of a SONET/SDH frame 1794 o SHOULD be marked with M bit set to 1 in the RTP header. 1796 B3. Synchronization modes 1798 External clock sources traceable (in terms of G.781) to the same 1799 high quality (at least as defined in G.812) clock source should be 1800 available at both PEs for External or Differential timing. 1802 B.3. Structure of the Control Word 1804 The same bits as defined in Section 5.2.2 are used. However the 1805 meaning of the bits are slightly different: 1807 o Bit A - if set, represents LOS (e.g., as specified in [G.783]) 1808 of the incoming SONET/SDH signal. A packet with the A bit set 1809 should not carry any data 1810 o Bit I - if set, represents an Out-of-Frame (OOF) condition 1811 (e.g., as specified in [G.707]) of the incoming SONET/SDH 1812 signal. A packet with the I bit set should not carry any data 1813 TDM Circuit Emulation Service over PSN August 2002 1815 B4. Packetization and de-packetization 1817 During normal operation, the CESoPSN packetizer will receive a fixed 1818 rate byte stream from a (physical or logical) SONET/SDH interface. 1819 When the whole SONET/SDH frame will be received, it will be 1820 partitioned into several blocks of equal size. After that, PSN and 1821 multiplexing headers are prepended to it and the resulting CESoPSN 1822 packets are transmitted into the PSN. 1823 Because all normal CESoPSN packets associated with a specific 1824 SONET/SDH channel will have the same length, the transmission of 1825 CESoPSN packets for that channel SHOULD occur at regular intervals. 1826 At the far end of the packet network, the CESoPSN de-packetizer will 1827 receive packets into a jitter buffer, rebuild native SONET/SDH 1828 frames, and then play out the received byte stream at a fixed rate 1829 onto the corresponding PDH channel. The jitter buffer SHOULD be 1830 configurable to account for various network delay behavior patterns. 1831 The received packet rate from the packet network should be exactly 1832 balanced by the transmission rate onto the SONET/SDH channel, on 1833 average. The time over which this average is taken corresponds to 1834 the depth of the jitter buffer for a specific CESoPSN channel. 1835 The RTP sequence numbers in the CESoPSN heard provide a mechanism to 1836 detect lost and/or reordered packets. The CESoPSN de-packetizer 1837 MUST detect lost or reordered packets. 1839 B6. PSN to SONET/SDH Signals 1841 Only CESoPSN defects requiring non-standard treatment are 1842 considered. 1844 The CESoPSN de-packetizer MAY re-order packets received out of 1845 order. If the CESoPSN de-packetizer does not support re-ordering, 1846 it MUST drop out-of-order packets. 1848 If any of the PDUs comprising a native SONET/SDH frame is lost, the 1849 scrambled pattern consisting of valid framing bytes ([G.707], 1850 [T1.105]) and all other bytes set to all 1s will be played out. The 1851 same pattern will be played out if a malformed packet has been 1852 detected. 1854 The rationale for this behavior: an SDH node at the egress of a 1855 CESoPSN service may continue using the SDH signal received from the 1856 egress PE node as its clock source.