idnits 2.17.1 draft-manhoudt-pwe3-tsop-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 4, 2014) is 3551 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.813' is mentioned on line 1557, but not defined == Unused Reference: 'G.8263' is defined on line 1257, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'G.707' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.783' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.823' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.825' -- Possible downref: Non-RFC (?) normative reference: ref. 'GR-253' -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT G. Manhoudt 3 Intended Status: Proposed Standard AimValley 4 Expires: February 5, 2015 5 S. Roullot 6 Alcatel-Lucent 8 K.Y. Wong 9 Alcatel-Lucent 11 H.L. Kuo 12 Chunghwa Telecom 14 August 4, 2014 16 Transparent SDH/SONET over Packet 17 draft-manhoudt-pwe3-tsop-05 19 Abstract 21 This document describes the Transparent SDH/SONET over Packet (TSoP) 22 mechanism to encapsulate Synchronous Digital Hierarchy (SDH) or 23 Synchronous Optical NETwork (SONET) bit-streams in a packet format, 24 suitable for Pseudowire (PW) transport over a packet switched network 25 (PSN). The key property of the TSoP method is that it transports 26 the SDH/SONET client signal in its entirety through the PW, i.e., no 27 use is made of any specific characteristic of the SONET/SDH signal 28 format, other than its bit rate. The TSoP transparency includes 29 transporting the timing properties of the SDH/SONET client signal. 30 This ensures a maximum of transparency and a minimum of complexity, 31 both in implementation and during operation. 33 Status of this Memo 35 This Internet-Draft is submitted to IETF in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as 41 Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/1id-abstracts.html 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html 53 Copyright and License Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology and Conventions . . . . . . . . . . . . . . . . . 5 72 2.1. Conventions Used in This Document . . . . . . . . . . . . 5 73 2.2. Acronyms and Terms . . . . . . . . . . . . . . . . . . . . 5 74 3. Emulated STM-N Services . . . . . . . . . . . . . . . . . . . 6 75 3.1. PSN-bound Direction . . . . . . . . . . . . . . . . . . . 9 76 3.2. CE-bound Direction . . . . . . . . . . . . . . . . . . . . 9 77 4. TSoP Encapsulation Layer . . . . . . . . . . . . . . . . . . . 11 78 4.1. TSoP Packet Format . . . . . . . . . . . . . . . . . . . . 11 79 4.2. PSN/PW Headers . . . . . . . . . . . . . . . . . . . . . . 11 80 4.2.1 Transport over an MPLS(-TP) PSN . . . . . . . . . . . . 11 81 4.3. TSoP Encapsulation Headers . . . . . . . . . . . . . . . . 12 82 4.3.1. Location and Order of TSoP Encapsulation Headers . . . 12 83 4.3.2. Usage and Structure of the TSoP Control Word . . . . . 12 84 4.3.3. Usage of the RTP Header . . . . . . . . . . . . . . . 14 85 5. TSoP Payload Field . . . . . . . . . . . . . . . . . . . . . . 16 86 6. TSoP Operation . . . . . . . . . . . . . . . . . . . . . . . . 16 87 6.1. Common Considerations . . . . . . . . . . . . . . . . . . 16 88 6.2. IWF Operation . . . . . . . . . . . . . . . . . . . . . . 17 89 6.2.1. PSN-Bound Direction . . . . . . . . . . . . . . . . . 17 90 6.2.2. CE-Bound Direction . . . . . . . . . . . . . . . . . . 17 91 6.3. TSoP Defects . . . . . . . . . . . . . . . . . . . . . . . 19 92 6.4. TSoP Performance Monitoring . . . . . . . . . . . . . . . 20 93 7. Quality of Service (QoS) Issues . . . . . . . . . . . . . . . 22 94 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 22 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 96 10. Applicability Statements . . . . . . . . . . . . . . . . . . . 24 97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 98 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 13.1. Normative References . . . . . . . . . . . . . . . . . . . 27 101 13.2. Informative References . . . . . . . . . . . . . . . . . . 27 102 Appendix A. Parameter Configuration for TSoP PW Set-up . . . . . . 31 103 Appendix B. Buffer Configuration in the CE-bound IWF . . . . . . . 32 104 Appendix C. Synchronization Considerations for the CE-bound IWF . 34 105 C.1. Layer 1 Synchronized PEs . . . . . . . . . . . . . . . . . 36 106 C.2. Synchronous CEs . . . . . . . . . . . . . . . . . . . . . . 37 107 C.3. Pleisiochronous CEs . . . . . . . . . . . . . . . . . . . . 37 108 Appendix D. Effect of G-AIS Insertion on a Downstream SDH Node . 38 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 111 1. Introduction 113 This document describes the Transparent SDH/SONET over Packet (TSoP) 114 method for encapsulating SDH or SONET signals with bit rates of 115 51.84 Mbit/s or N * 155.52 Mbit/s (where N = 1, 4, 16 or 64) for 116 Pseudowire (PW) transport over a packet switched network (PSN), using 117 circuit emulation techniques. 119 The selected approach for this encapsulation scheme avoids using any 120 particular signal characteristics of the SDH/SONET signal, other than 121 its bit rate. This approach closely follows the SAToP method 122 described in [RFC4553] for PW transport of E1, DS1, E3 or DS3 over a 123 PSN. 125 An alternative to the TSoP method for STM-N transport over PW is 126 known as CEP (Circuit Emulation over Packet) and is described in 127 [RFC4842]. The key difference between the CEP approach and the TSoP 128 approach is that within CEP an incoming STM-N is terminated and 129 demultiplexed to its constituent VCs (Virtual Containers). 130 Subsequently, each VC is individually circuit emulated and 131 encapsulated into a PW and transported over the PSN to potentially 132 different destinations, where they are reassembled into (newly 133 constructed) STM-N signals again. The TSoP approach, on the other 134 hand, is to encapsulate the entire STM-N in a single circuit 135 emulating Pseudowire and transport it to a single destination over 136 the PSN. The essential difference between both methods is that CEP 137 offers more routing flexibility and better bandwidth efficiency than 138 TSoP at the cost of the loss of transparency (overhead, timing, 139 scrambling) at the STM-N layer and at the cost of added complexity 140 associated with the inclusion of what in essence is an SDH/SONET VC 141 cross-connect function in the PEs. 143 Within the context of this document, there is no difference between 144 SONET [GR-253] signals, often denoted as OC-M, and SDH [G.707] 145 signals, usually denoted as STM-N. For ease of reading, this document 146 will only refer to STM-N, but any statement about an STM-N signal 147 should be understood to apply equally to the equivalent OC-M signal, 148 unless it is specifically mentioned otherwise. The equivalency can 149 be described by the following relations between N and M: If N = 0 150 then M = 1 and if N >= 1 then M = 3 * N. 152 The TSoP solution presented in this document conforms to the PWE3 153 architecture described in [RFC3985] and satisfies the relevant 154 general requirements put forward in [RFC3916]. 156 As with all PWs, TSoP PWs may be manually configured or set up using 157 a suitably expanded version of the PWE3 control protocol [RFC4447]. 159 2. Terminology and Conventions 161 2.1. Conventions Used in This Document 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 165 "OPTIONAL" in this document are to be interpreted as described in 166 [RFC2119]. 168 2.2. Acronyms and Terms 170 The following acronyms used in this document are defined in [RFC3985] 171 and [RFC4197]: 173 AC Attachment Circuit 174 CE Customer Edge 175 PE Provider Edge 176 PREP Pre-Processing 177 PSN Packet Switched Network 178 PW Pseudowire 179 SDH Synchronous Digital Hierarchy 180 SONET Synchronous Optical Network 182 In addition, the following specific terms are used in this document: 184 G-AIS Generic Alarm Indication Signal - A specific bit pattern 185 that replaces the normal STM-N signal in the case of certain 186 failure scenarios. The G-AIS pattern [G.709] is constructed 187 by continuously repeating the 2047 bit pseudo random bit 188 sequence based on the generating polynomial 1 + x^9 + x^11 189 according to [O.150]. 191 IWF Interworking Function - A functional block that segments and 192 encapsulates a constant bit-rate signal into PW packets and 193 that in the reverse direction decapsulates PW packets and 194 reconstitutes the constant bit-rate signal. 196 LOF Loss Of Frame - A condition of an STM-N signal in which the 197 frame pattern cannot be detected. Criteria for raising and 198 clearing a LOF condition can be found in [G.783]. 200 LOPS Loss of Packet State - A defect that indicates that the PE 201 at the receiving end of a TSoP carrying PW experiences an 202 interruption in the stream of received TSoP packets. See 203 [RFC5604] 205 LOS Loss Of Signal - A condition of the STM-N attachment circuit 206 in which the incoming signal has an insufficient energy 207 level for reliable reception. Criteria for raising and 208 clearing a LOS condition can be found in [G.783]. 210 NIM Non-Intrusive Monitor - A circuit that monitors a signal in 211 a certain direction of transmission, without changing the 212 binary content of it. A NIM can be used for Fault 213 Management and Performance Monitoring purposes 215 PDV Packet Delay Variation - A (statistical) measure that 216 describes the distribution of the variation in transit times 217 of packets in a certain flow between two reference points in 218 the network. See [G.8260] 220 SF Signal Fail - A control signal, that exists internally in a 221 system, to convey the failed state of an incoming signal, 222 from a server layer process to the adjacent client layer 223 process. See [G.783] 225 3. Emulated STM-N Services 227 A TSoP emulated STM-N service over a Pseudowire makes use of a 228 bi-directional point-to-point connection over the PSN between two 229 TSoP-IWF blocks, located in the PE nodes that terminate the PW that 230 interconnects them, as shown in figure 1. The TSoP-IWF blocks each 231 consist of two half-functions, a PSN-bound IWF and a CE-bound IWF, 232 one for each direction of transmission. As the name implies, the 233 PSN-bound part of the TSoP-IWF performs the conversion of an STM-N 234 bitstream to a packet flow, suitable for transport over the PSN and 235 the CE-bound part of the TSoP-IWF performs the inverse operation. 237 |<------------------ Emulated Service ----------------->| 238 | | 239 | |<-------------- Pseudowire ------------->| | 240 | AC | | AC | 241 |<---->| |<----- PSN ----->| |<---->| 242 | | | | | | 243 | . PE1 . . PE2 . | 244 . +-----------+ +-----------+ . 245 +---+ | | | | +---+ 246 | |----->| PSN-bound |====> . . . ====>| CE-bound |----->| | 247 | C | | IWF | | IWF | | C | 248 | E | | _ _ _ | | _ _ _ | | E | 249 | | | | | | | | 250 | 1 | | | | | | 2 | 251 | |<-----| CE-bound |<==== . . . <====| PSN-bound |<-----| | 252 +---+ | | IWF | | IWF | | +---+ 253 | +-----------+ +-----------+ | 254 | TSoP-IWF TSoP-IWF | 255 native native 256 STM-N STM-N 258 Figure 1. Overview of STM-N emulated service architecture 260 The following list provides the STM-N services, as specified in 261 [G.707] and [GR-253], that can be supported by a TSoP PW: 263 1. STM-0 or OC-1 (51.84 Mbit/s) 264 2. STM-1 or OC-3 (155.52 Mbit/s) 265 3. STM-4 or OC-12 (622.08 Mbit/s) 266 4. STM-16 or OC-48 (2488.32 Mbit/s) 267 5. STM-64 or OC-192 (9953.28 Mbit/s) 269 The TSoP protocol used for emulation of STM-N services does not 270 depend on the method in which the STM-N is delivered to the PE. For 271 example, an STM-1 attachment circuit is treated in the same way 272 regardless of whether it is a copper [G.703] or a fiber optic [G.957] 273 link. 275 Also, in case the STM-N is carried in an OTN signal [G.709], the 276 functionality in the TSoP-IWF operates in the same way, but a PWE3 277 Preprocessing (PREP) functional block will be present between the AC 278 and the PE to perform the OTN (de)multiplexing functions. 280 The TSoP-IWF function in figure 1 is further broken down in 281 functional blocks in figure 2. These individual functional blocks 282 are described in the next two sections. 284 AC TSoP-IWF PSN 285 ------>|<------------------------------------------------->|<-------- 287 +---------------------------------------------------+ 288 | +-------+ | 289 | +-------+ SF | PSN- | CE-side_ | 290 | | |----->| bound | defect +--------+ | 291 STM-N | | STM-N | +->| NIM |------------>| | | 292 =========>| Rx | | +-------+ | | | 293 | | |===0=======================>| PSN- | | Packet 294 | +-------+ +--------+ | bound |===========> 295 | | Subst. | | IWF | | 296 | | Signal |===========>| | | 297 | | Gen. | +-->| | | 298 | +--------+ | +--------+ | 299 | | | 300 | PSN-bound direction | | 301 - - - -|- - - - - - - - - - - - - - - - - -|- - - - - - - -|- - - - - 302 | CE-bound direction | | 303 | | | 304 | +--------+ | PSN-side_ | 305 | | G-AIS | | defect | 306 | | Gen. |====+ | | 307 | +--------+ | | | 308 | | | +--------+ | 309 | +--------+ | +---| | | 310 | +-------+ | |<===+ | | | 311 | | | | STM-N/ | No_Packet | CE- | | 312 <=========| STM-N |<=====| G-AIS |<-----------| bound |<=========== 313 STM-N | | Tx | | Switch | | IWF | | Packet 314 | | | +-->| |<========0==| | | 315 | +-------+ | +--------+ | | | | 316 | | +----------+ | +--------+ | 317 | | | optional | | | 318 | +------| CE-bound |<---+ | 319 | | NIM | | 320 | +----------+ | 321 +---------------------------------------------------+ 323 Figure 2. TSoP functional block diagram 325 3.1. PSN-bound Direction 327 In the PSN-bound direction the STM-N signal is received from the CE 328 via an AC by the STM-N Rx function. This function recovers the 329 optical or electrical signal and converts it to a suitable internal 330 format. In addition, it detects the LOS condition and it asserts the 331 SF signal whenever this is the case. The STM-N Rx block is 332 equivalent to the OSn_TT_Sk & OSn/RSn_A_Sk (in the case of an optical 333 STM-N) or the ESn_TT_Sk & ESn/RSn_A_Sk (in the case of an electrical 334 STM-N interface) function pairs defined in [G.783]. 336 The PSN-bound IWF segments the STM-N ingress bitstream, which it 337 receives from the STM-N Rx function, in blocks of equal length. Each 338 block of bits is supplied with the appropriate TSoP Encapsulation 339 Headers and then delivered to the PSN Multiplexing layer to add the 340 required headers for transport over the PSN. 342 The PSN-bound NIM function controls the state of the CE-side_defect 343 signal. It will assert this signal in case the SF signal is asserted 344 or in case another defect is detected in the incoming STM-N signal. 345 The inclusion of other defects than LOS in the CE-side_defect signal 346 is OPTIONAL. 348 When the CE-side_defect signal is asserted, the PSN-bound IWF will 349 set the corresponding flag (L-bit) in the overhead of the affected 350 packets. Packets in which the L-bit is set MUST have a substitution 351 payload (created by the Substitution Signal Generator function) of 352 the same length as the regular TSoP payload. This substitution 353 payload is RECOMMENDED to be the G-AIS pattern or a fixed "all ones" 354 pattern. 356 Lastly, when the PSN-side_defect state is asserted, the PSN-bound IWF 357 will set the corresponding flag (R-bit) in the overhead of all 358 packets that are transmitted while this signal is in the asserted 359 state. 361 3.2. CE-bound Direction 363 In the CE-bound direction, the CE-bound IWF receives the PW packets 364 from the PSN and strips off the PSN, PW, and TSoP encapsulation 365 headers and writes the payload data in a buffer. The output data 366 stream towards the CE is created by playing out this buffer with a 367 suitable clock signal. The thus reconstructed STM-N signal is 368 forwarded to the STM-N/G-AIS Switch function. 370 The No_Packet signal is asserted by the CE-bound IWF in case the 371 internal packet buffer empties due to lack of input packets from the 372 PSN or in case a packet is missing or invalid. 374 The PSN-side_defect signal is asserted by the CE-bound IWF in case 375 the LOPS condition is detected by the CE-bound IWF (see section 376 6.2.2). The state of this signal controls the value of the R-bit in 377 the overhead of the packets returned towards the far-end TSoP-IWF. 379 The G-AIS Generator generates a G-AIS signal at the nominal frequency 380 of the recovered STM-N signal, +/- 20 ppm. 382 The STM-N/G-AIS Switch normally takes its input from the CE-bound IWF 383 and forwards the recovered STM-N signal towards the STM-N Tx 384 function, but during the time that the No_Packet signal is asserted, 385 it will select the G-AIS Generator as its active input and forward a 386 G-AIS signal towards the STM-N Tx function. 388 The CE-bound NIM function is an OPTIONAL function that can be used to 389 detect additional defects in the recovered CE-bound STM-N signal. 390 The presence of such defects (e.g. STM-N LOF) MAY be used as an 391 additional reason for the STM-N/G-AIS Switch function to select the 392 G-AIS signal as its active input. 394 Lastly, the STM-N Tx function converts the internal signal that is 395 output by the STM-N/G-AIS Switch block into a regular STM-N signal 396 towards the CE via the AC. The STM-N Tx block is equivalent to the 397 OSn_TT_So & OSn/RSn_A_So (in the case of an optical STM-N) or the 398 ESn_TT_So & ESn/RSn_A_So (in the case of an electrical STM-N 399 interface) function pairs defined in [G.783]. 401 4. TSoP Encapsulation Layer 403 4.1. TSoP Packet Format 405 The general format of TSoP packets during transport over the PSN is 406 shown in Figure 3. 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | ... | 412 | PSN/PW Headers | 413 | ... | 414 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 415 | ... | 416 | TSoP Encapsulation Headers | 417 | ... | 418 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 419 | | 420 | ... | 421 | | 422 | TSoP Payload Field | 423 | | 424 | ... | 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Figure 3. Generic TSoP Packet Format 430 4.2. PSN/PW Headers 432 A TSoP PW can be transported over different types of PSNs based on 433 different switching technology. Below the transmission over MPLS is 434 described, but other methods are not precluded. The selected method 435 will determine the format of the PSN/PW Headers part and influence 436 the order of the fields in the TSoP Encapsulation Headers part. 438 4.2.1 Transport over an MPLS(-TP) PSN 440 In case a TSoP PW is forwarded over an MPLS(-TP) PSN, a standard 441 "bottom of stack" PW label as shown in figure 4 is prepended before 442 the TSoP Encapsulation Headers. Subsequently, one or more MPLS(-TP) 443 labels need to be pushed according to the standard MPLS transport 444 methods outlined in [RFC3031] and [RFC3032]. 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Label | TC |S| TTL | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 4. PW Label (S = 1) 454 4.3. TSoP Encapsulation Headers 456 4.3.1. Location and Order of TSoP Encapsulation Headers 458 The TSoP Encapsulation Headers MUST contain the TSoP Control Word 459 (figure 6) and MUST contain a Minimum length RTP Header [RFC3550] 460 (figure 7). The TSoP Encapsulation Headers must immediately follow 461 the PSN/PW header, as shown in figure 5. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | ... | 467 | PSN/PW Headers | 468 | ... | 469 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 470 | TSoP Control Word | 471 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 472 | | 473 +-- --+ 474 | Minimum length RTP Header (see [RFC3550]) | 475 +-- --+ 476 | | 477 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 478 | ... | 479 | STM-N data (Payload) | 480 | ... | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 Figure 5. General TSoP Packet Format 485 4.3.2. Usage and Structure of the TSoP Control Word 487 The purpose of the TSoP control word is to allow: 489 1. Detection of packet loss or misordering 490 2. Differentiation between PSN and attachment circuit problems as a 491 cause for outage of the emulated service 492 3. Signaling of faults detected at the PW egress to the PW ingress 493 The structure of the TSoP Control Word is in accordance with the 494 general PW Control Word format specified in [RFC4385]. The TSoP CW 495 format is shown in Figure 6 below. This TSoP Control Word MUST be 496 present in each TSoP PW packet. 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 |0 0 0 0|L|R|RSV|FRG| LEN | Sequence number | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Figure 6. Structure of the TSoP Control Word 506 The use of Bits 0 to 3 is described in [RFC4385]. These bits MUST be 507 set to zero unless they are being used to indicate the start of an 508 Associated Channel Header (ACH). An ACH is needed if the state of 509 the TSoP PW is being monitored using Virtual Circuit Connectivity 510 Verification [RFC5085] or in case OAM functionality according to 511 [RFC6371] is added. 513 L (bit 4) - If this bit is set, it indicates that the STM-N data 514 ingressing in the PSN-bound IWF is currently experiencing a fault 515 condition. Once set, if the fault is rectified, the L-bit MUST 516 be cleared. For each frame that is transmitted with L-bit = 1, 517 the PSN-bound IWF MUST insert such an amount of substitution data 518 in the TSoP payload field that the TSoP frame length, as it is 519 during normal operation, is maintained. The CE-bound IWF MUST 520 play out an amount of G-AIS data corresponding to the original 521 TSoP Payload Field for each received packet with the L-bit set. 523 Note: This document does not prescribe exactly which STM-N fault 524 conditions are to be treated as invalidating the payload carried 525 in the TSoP packets. An example of such a fault condition would 526 be LOS. 528 R (bit 5) - If this bit is set by the PSN-bound IWF, it indicates 529 that its local CE-bound IWF is in the LOPS state, i.e., it has 530 lost a preconfigured number of consecutive packets. The R-bit 531 MUST be cleared by the PSN-bound IWF once its local CE-bound IWF 532 has exited the LOPS state, i.e., has received a preconfigured 533 number of consecutive packets. See also section 6.2.2. 535 RSV (bits 6 to 7) - This field MUST be set to 0 by the PSN-bound IWF 536 and MUST be ignored by the CE-bound IWF. RSV is reserved. 538 FRG (bits 8 to 9) - This field MUST be set to 0 by the PSN-bound IWF 539 and MUST be ignored by the CE-bound IWF. FRG is fragmentation; 540 see [RFC4623]. 542 LEN (bits 10 to 15) - This field MAY be used to carry the length of 543 the TSoP packet (defined as the length of the TSoP Encapsulation 544 Header + TSoP Payload Field) if it is less than 64 octets, and 545 MUST be set to zero otherwise. When the LEN field is set to 0, 546 the preconfigured size of the TSoP packet payload MUST be assumed 547 to be as described in Section 5, and if the actual packet size is 548 inconsistent with this length, the packet MUST be considered 549 malformed. 551 Sequence number (bits 16 to 31) - This field is used to enable the 552 common PW sequencing function as well as detection of lost 553 packets. It MUST be generated in accordance with the rules 554 defined in Section 5.1 of [RFC3550] for the RTP sequence number: 556 o Its space is a 16-bit unsigned circular space 557 o Its initial value SHOULD be random (unpredictable). 559 It MUST be incremented with each TSoP data packet sent in the 560 specific PW. 562 4.3.3. Usage of the RTP Header 564 A minimum length RTP Header as specified in [RFC3550] MUST be 565 included in the TSoP Encapsulation Header. The reason for mandating 566 the insertion of an RTP Header by the PSN-bound IWF is that it is 567 expected that in most cases the CE-bound IWF will need to use the 568 contained timestamps to be able to recover a clock signal of 569 sufficient quality. By avoiding to make the presence of RTP Headers 570 subject to configuration, the design of the CE-bound IWF can be 571 simplified and another potential source of errors during 572 commissioning is eliminated. 574 The RTP Header fields in the list below (see also figure 7) MUST have 575 the following specific values: 577 V (version) = 2 578 P (padding) = 0 579 X (header extension) = 0 580 CC (CSRC count) = 0 581 M (marker) = 0 583 0 1 2 3 584 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 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | V |P|X| CC |M| PT | Sequence number | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Timestamp | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | SSRC | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Figure 7. Structure of the RTP Header field 595 The PT (payload type) field is used as follows: 597 1. One PT value SHOULD be allocated from the range of dynamic values 598 (see [RTP-TYPE]) for each direction of the PW. The same PT value 599 MAY be reused for both directions of the PW and also reused 600 between different PWs. 601 2. The PSN-bound IWF MUST set the PT field in the RTP header to the 602 allocated value. 603 3. The CE-bound IWF MAY use the received value to detect malformed 604 packets. 606 The sequence number MUST be the same as the sequence number in the 607 TSoP control word. 609 The RTP timestamps are used for carrying timing information over the 610 network. Their values MUST be generated in accordance with the rules 611 established in [RFC3550]. 613 A TSoP implementation MUST support RTP timestamping at the PW ingress 614 with a nominal clock frequency of 25 MHz. This is also the default 615 value. Other clock frequencies MAY be supported to generate the RTP 616 Timestamps. Selection of the applicable clock frequency is done 617 during commissioning of the PW that carries the emulated STM-N 618 service. 620 The SSRC (synchronization source) value in the RTP header MAY be used 621 for detection of misconnections, i.e., incorrect interconnection of 622 attachment circuits. In case this option is not used, this field 623 should contain an all zero pattern. 625 The usage of the options associated with the RTP Header (the 626 timestamping clock frequency, selected PT and SSRC values) MUST be 627 aligned between the two TSoP IWFs during Pseudowire commissioning. 629 5. TSoP Payload Field 631 In order to facilitate handling of packet loss in the PSN, all 632 packets belonging to a given TSoP PW are REQUIRED to carry a fixed 633 number of octets in its TSoP Payload Field. 635 The TSoP Payload Field length MUST be defined during PW 636 commissioning, MUST be the same for both directions of the PW, and 637 MUST remain unchanged for the lifetime of the PW. 639 All TSoP implementations MUST be capable of supporting the following 640 TSoP Payload Field length: 642 o STM-N (for N = 0, 1, 4, 16 and 64) - 810 octets 644 Notes: 646 1. Whatever the selected payload size, TSoP does not assume 647 alignment to any underlying structure imposed by STM-N framing 648 (octet, frame, or multiframe alignment). The STM-N signal 649 remains scrambled through the TSoP encapsulation and 650 decapsulation processes. 652 2. With a payload size of 810 octets, the STM-N emulated service 653 over the PSN will have a nominal packet rate of 8000 packets/s 654 when N = 0 and a nominal packet rate of 24000 * N packets/s for 655 N >= 1. 657 TSoP uses the following ordering for packetization of the STM-N data: 659 o The order of the payload octets corresponds to their order on 660 the attachment circuit. 662 o Consecutive bits coming from the attachment circuit fill each 663 payload octet starting from most significant bit to least 664 significant. 666 6. TSoP Operation 668 6.1. Common Considerations 670 Edge-to-edge emulation of an STM-N service using TSoP is only 671 possible when the two PW attachment circuits are of the same type, 672 i.e., both are STM-N with equal N. 674 6.2. IWF Operation 676 6.2.1. PSN-Bound Direction 678 Once the PW is commissioned, the PSN-bound TSoP IWF operates as 679 follows: 681 The ingressing STM-N bit-stream is segmented, such that each segment 682 contains the configured number of payload octets per packet. This 683 forms the TSoP Payload Field. The STM-N bit-stream MUST NOT be 684 descrambled before segmentation and packetization for PW transport. 686 Subsequently, the TSoP Encapsulation Headers are prepended according 687 to the rules in section 4.3. 689 Lastly, the PSN/PW Headers are added to the packetized service data, 690 and, depending on the applicable layer 1 technology, additional 691 overhead is added. The resulting packets are transmitted over the 692 PSN. 694 6.2.2. CE-Bound Direction 696 Once the PW is commissioned, the CE-bound TSoP IWF operates as 697 follows: 699 Each time a valid TSoP packet is received from the PSN, its sequence 700 number is checked to determine its relative position in the stream of 701 received packets. Packets that are received out-of-order MAY be 702 reordered. Next, the data in the fixed length TSoP payload field of 703 each packet is written into a (jitter) buffer in the order indicated 704 by its sequence number. In case data is missing due to a lost packet 705 or a packet that could not be re-ordered, an equivalent amount of 706 dummy data (G-AIS pattern) is substituted. 708 Subsequently, the STM-N stream towards the CE is reconstructed by 709 playing out the buffer content with a clock that is reconstructed to 710 have the same average frequency as the STM-N clock at the PW ingress. 711 In addition, this clock signal must have such properties that the 712 following requirements can be met: 714 o A reconstructed SDH-type STM-N signal delivered to an 715 Attachment Circuit MUST meet [G.825] and [G.823] jitter and 716 wander requirements (for synchronization interfaces), or, 718 o A reconstructed SONET-type OC-M signal delivered to an 719 Attachment Circuit MUST meet [GR-253] jitter and wander 720 requirements. 722 The size of the buffer in the CE-bound TSoP IWF SHOULD be 723 configurable to allow accommodation to the PSN specific packet delay 724 variation (see appendix B). 726 The CE-bound TSoP IWF MUST use the sequence number in either the TSoP 727 Control Word or in the RTP header for detection of lost and 728 misordered packets. The use of the sequence number in the TSoP 729 Control Word for this purpose is RECOMMENDED. 731 The CE-bound TSoP IWF MAY reorder misordered packets. Misordered 732 packets that can not be reordered MUST be discarded and treated the 733 same way as lost packets. 735 The payload of received TSoP packets marked with the L-bit set MUST 736 be replaced by the equivalent number of bits from the G-AIS pattern. 737 Likewise, the payload of each lost or malformed (see section 6.3) 738 TSoP packet MUST be replaced with the equivalent number of bits from 739 the G-AIS pattern. 741 Before a TSoP PW has been commissioned and after a TSoP PW has been 742 decommissioned, the IWF MUST play out the G-AIS pattern to its STM-N 743 attachment circuit. 745 Once a TSoP PW has been commissioned, the CE-bound IWF begins to 746 receive TSoP packets and to store their payload in the buffer, but 747 continues to play out the G-AIS pattern to its STM-N attachment 748 circuit. This intermediate state persists until a preconfigured 749 degree of filling (for example half of the CE-bound IWF buffer) has 750 been reached by writing consecutive TSoP packets or until a 751 preconfigured intermediate state timer (started when the TSoP 752 commissioning is complete) expires. See appendix B for 753 considerations regarding the configuration of the initial degree of 754 filling of this buffer. 756 Each time an STM-N signal is replaced by a G-AIS signal at the same 757 nominal bitrate, this signal may start at an arbitrary point in its 758 repeating 2047-bit sequence. Once the starting point is selected, 759 the G-AIS signal is sent uninterrupted until the condition that 760 invoked it has been removed. The frequency of the clock that is used 761 to generate this G-AIS signal MUST have an accuracy that is better 762 than +/- 20 ppm relative to the nominal STM-N frequency. Appendix D 763 describes the effect of G-AIS insertion on downstream SDH equipment. 765 Once the preconfigured amount of the STM-N data has been received, 766 the CE-bound TSoP IWF enters its normal operational state where it 767 continues to receive TSoP packets and to store their payload in the 768 buffer while playing out the contents of the jitter buffer in 769 accordance with the required clock. In this state, the CE-bound IWF 770 performs clock recovery, MAY monitor PW defects, and MAY collect PW 771 performance monitoring data. 773 The CE-bound IWF enters the LOPS defect state in case it detects the 774 loss of a preconfigured number of consecutive packets or if the 775 intermediate state timer expires before the required amount of STM-N 776 data has been received. While in this state, the local PSN-bound 777 TSoP IWF SHOULD mark every packet it transmits with the R-bit set. 778 The CE-bound IWF leaves the LOPS defect state and transits to the 779 normal state once a preconfigured number of consecutive valid TSoP 780 packets have been received (successfully reordered packets contribute 781 to the count of consecutive packets). 783 The RTP timestamps inserted in each TSoP packet at the PW ingress 784 allow operation in differential mode, provided that both PW ingress 785 and PW egress IWFs have a local clock that is traceable to a common 786 timing source. 788 The use of adaptive mode clocking mode, i.e., recovering the STM-N 789 clock in the CE-bound IWF by essentially averaging the arrival times 790 of the TSoP packets from the PSN without using RTP information, is 791 not recommended for TSoP-based circuit emulation. Appendix C 792 provides some considerations regarding the implementation and 793 configuration of the CE-bound IWF. 795 6.3. TSoP Defects 797 In addition to the LOPS state defined above, the CE-bound TSoP IWF 798 MAY detect the following defects: 800 o Stray packets 801 o Malformed packets 802 o Excessive packet loss rate 803 o Buffer overrun 804 o Buffer underrun 805 o Remote packet loss 807 Corresponding to each defect is a defect state of the IWF, a 808 detection criterion that triggers transition from the normal 809 operation state to the appropriate defect state, and an alarm that 810 MAY be reported to the management system and thereafter cleared. 811 Alarms are only reported when the defect state persists for a 812 preconfigured amount of time (typically 2.5 seconds) and MUST be 813 cleared after the corresponding defect is undetected for a second 814 preconfigured amount of time (typically 10 seconds). The trigger and 815 release times for the various alarms may be independent. 817 Stray packets MAY be detected by the PSN and PW demultiplexing 818 layers. The SSRC field in the RTP header MAY be used for this 819 purpose as well. Stray packets MUST be discarded by the CE-bound 820 IWF, and their detection MUST NOT affect mechanisms for detection of 821 packet loss. 823 Malformed packets are detected by mismatch between the expected 824 packet size and the actual packet size inferred from the PSN and PW 825 demultiplexing layers (taking the value of the L-bit into account). 826 Differences between the received PT value and the PT value allocated 827 for this direction of the PW MAY also be used for this purpose. 828 Malformed, in-order packets MUST be discarded by the CE-bound IWF and 829 replacement data generated as with lost packets. 831 Excessive packet loss rate is detected by computing the average 832 packet loss rate over a configurable amount of time and comparing it 833 with preconfigured raise and clear thresholds. 835 Buffer overrun is detected in normal operational state when the 836 (jitter) buffer of the CE-bound IWF cannot accommodate newly arrived 837 TSoP packets. 839 Buffer underrun can detected in normal operational state when the 840 (jitter) buffer of the CE-bound IWF has insufficient data to maintain 841 playing out the STM-N signal towards the CE at the recovered clock 842 rate. In this situation G-AIS MUST be substituted until the buffer 843 fill has reached its preconfigured degree of filling again. 845 Remote packet loss is indicated by reception of packets with their 846 R-bit set. 848 6.4. TSoP Performance Monitoring 850 Performance monitoring (PM) parameters are routinely collected for 851 STM-N services and provide an important maintenance mechanism in SDH 852 networks. However, STM-N level PM data provides the information over 853 the performance of the end-to-end STM-N connection, which may extend 854 well beyond the part in which it is carried over a TSoP Pseudowire. 856 It may be important to be able to measure the performance of a TSoP 857 Pseudowire section, which forms a part of the STM-N end-to-end 858 connection, in isolation. For that reason a set of packet level 859 counters are specified that can be used to assess the performance of 860 the TSoP Pseudowire section. Collection of the TSoP PW performance 861 monitoring data is OPTIONAL and, if implemented, is only performed 862 after the CE-bound IWF has exited its intermediate state. 864 The following counters are defined: 866 ENCAP_TXTOTAL_PKTS (counter size: 32 bits) - The total number of 867 TSoP packets that is transmitted towards the PSN by the 868 PSN-bound IWF function. This includes packets with the L-bit 869 set. 871 DECAP_RXTOTAL_PKTS (counter size: 32 bits) - The total number of 872 TSoP packets that is received from the PSN by the CE-bound IWF 873 function. This includes malformed packets, out-of-order 874 packets and packets with the L-bit set. 876 DECAP_REORDERED_PKTS (counter size: 32 bits) - The number of out- 877 of-order TSoP packets that is received from the PSN by the 878 CE-bound IWF, based on the received sequence numbers, for which 879 the ordering could be corrected by the CE-bound IWF. 881 DECAP_MISSING_PKTS (counter size: 32 bits) - The number of TSoP 882 packets that did not arrive at the CE-bound IWF from the PSN, 883 based on the received sequence numbers. 885 DECAP_MALFORMED_PKTS (counter size: 32 bits) - The number of TSoP 886 packets that is received from the PSN by the CE-bound IWF 887 function which contains one of the following RTP related 888 errors: TSoP Payload Field length mismatch, PT-value mismatch 889 (if checked) and/or SSRC mismatch (if checked). 891 DECAP_OUTOFORDER_PKTS (counter size: 32 bits) - The number of out- 892 of-order TSoP packets that is received from the PSN by the 893 CE-bound IWF, based on the received sequence numbers, for which 894 the ordering could not be corrected by the CE-bound IWF. 896 DECAP_OVERRUN_BITS (counter size: 64 bits) - The number of bits of 897 TSoP Payload that is received from the PSN but dropped by the 898 CE-bound IWF due to the fact that the (jitter) buffer has 899 insufficient capacity available to store the complete TSoP 900 Payload Field content. 902 DECAP_UNDERRUN_BITS (counter size: 64 bits) - The number of bits 903 that is not played out towards the CE by the CE-bound IWF 904 because the (jitter) buffer is empty at the moment they need to 905 be played out. 907 DECAP_PLAYEDOUT_PKTS (counter size: 32 bits) - The number of 908 packets that has been successfully played out towards the CE by 909 the CE-bound IWF containing valid STM-N payload, including the 910 packets that have been received with the L-bit set, containing 911 substituted data. Packets which are lost in transmission over 912 the PSN or packets which are (partially) discarded by the 913 CE-bound IWF due to some error condition are not counted. 915 Note that packets with the L-bit set are considered normal data from 916 the perspective of TSoP Pseudowire Performance Monitoring, since in 917 such cases the location of the fault is in the STM-N path, before it 918 ingresses the PSN-bound IWF, so outside the scope of the TSoP PW. 920 7. Quality of Service (QoS) Issues 922 TSoP SHOULD employ existing QoS capabilities of the underlying PSN. 924 If the PSN providing connectivity between PE devices is 925 Diffserv-enabled and provides a PDB [RFC3086] that guarantees low 926 jitter and low loss, the TSoP PW SHOULD use this PDB in compliance 927 with the admission and allocation rules the PSN has put in place for 928 that PDB (e.g., marking packets as directed by the PSN). 930 If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC2212] 931 with the appropriate bandwidth reservation SHOULD be used in order to 932 provide a bandwidth guarantee equal or greater than that of the 933 encapsulated STM-N traffic. 935 8. Congestion Control 937 As explained in [RFC3985], the PSN carrying the PW may be subject to 938 congestion. TSoP PWs represent inelastic constant bit-rate flows and 939 cannot respond to congestion in a TCP-friendly manner prescribed by 940 [RFC2914], although the percentage of total bandwidth they consume 941 remains constant. 943 Unless appropriate precautions are taken, undiminished demand of 944 bandwidth by TSoP PWs can contribute to network congestion that may 945 impact network control protocols. 947 Whenever possible, TSoP PWs SHOULD be carried across traffic- 948 engineered PSNs that provide either bandwidth reservation and 949 admission control or forwarding prioritization and boundary traffic 950 conditioning mechanisms. IntServ-enabled domains supporting 951 Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains 952 [RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide 953 examples of such PSNs. Such mechanisms will negate, to some degree, 954 the effect of the TSoP PWs on the neighboring streams. 956 If TSoP PWs run over a PSN providing best-effort service, they SHOULD 957 monitor packet loss in order to detect "severe congestion". If such 958 a condition is detected, a TSoP PW SHOULD shut down bi-directionally 959 for some period of time as described in Section 6.5 of [RFC3985]. 961 Note that: 963 1. The TSoP IWF can inherently provide packet loss measurement since 964 the expected rate of arrival of TSoP packets is fixed and known 966 2. The results of the TSoP packet loss measurement may not be a 967 reliable indication of presence or absence of severe congestion if 968 the PSN provides enhanced delivery. For example: 970 a) If TSoP traffic takes precedence over non-TSoP traffic, severe 971 congestion can develop without significant TSoP packet loss. 973 b) If non-TSoP traffic takes precedence over TSoP traffic, TSoP 974 may experience substantial packet loss due to a short-term 975 burst of high-priority traffic. 977 3. The availability objectives for the digital paths that are 978 supported by an STM-N signal (see [G.827]) MUST be taken into 979 account when deciding on temporary shutdown of TSoP PWs. 981 This specification does not define the exact criteria for detecting 982 "severe congestion" using the TSoP packet loss rate or the specific 983 methods for bi-directional shutdown the TSoP PWs (when such severe 984 congestion has been detected) and their subsequent re-start after a 985 suitable delay. This is left for further study. However, the 986 following considerations may be used as guidelines for implementing 987 the TSoP severe congestion shutdown mechanism: 989 1. If the TSoP PW has been set up using either PWE3 control protocol 990 [RFC4447], the regular PW teardown procedures of these protocols 991 SHOULD be used. 993 2. If one of the TSoP PW end points stops transmission of packets for 994 a sufficiently long period, its peer (observing 100% packet loss) 995 will necessarily detect "severe congestion" and also stop 996 transmission, thus achieving bi-directional PW shutdown. 998 9. Security Considerations 1000 TSoP does not enhance or detract from the security performance of the 1001 underlying PSN; rather, it relies upon the PSN mechanisms for 1002 encryption, integrity, and authentication whenever required. 1004 TSoP PWs share susceptibility to a number of Pseudowire layer attacks 1005 and will use whatever mechanisms for confidentiality, integrity, and 1006 authentication are developed for general PWs. These methods are 1007 beyond the scope of this document. 1009 Although TSoP PWs MUST employ an RTP header to achieve an explicit 1010 transfer of timing information, SRTP (see [RFC3711]) mechanisms are 1011 NOT RECOMMENDED as a substitute for PW layer security. 1013 Misconnection detection capabilities of TSoP increase its resilience 1014 to misconfiguration. 1016 Random initialization of sequence numbers, in both the control word 1017 and the optional RTP header, makes known plaintext attacks on 1018 encrypted TSoP PWs more difficult. Encryption of PWs is beyond the 1019 scope of this document. 1021 10. Applicability Statements 1023 TSoP is an encapsulation layer intended for carrying SDH STM-N 1024 circuits over the PSN in a structure-agnostic and fully transparent 1025 fashion. 1027 TSoP fully complies with the principle of minimal intervention, 1028 minimizing overhead and computational power required for 1029 encapsulation. 1031 TSoP provides sequencing and synchronization functions needed for 1032 emulation of STM-N bit-streams, including detection of lost or 1033 misordered packets and perform the appropriate compensation. 1034 Furthermore, explicit timing information is provided by the presence 1035 of an RTP timestamp in each TSoP packet. 1037 STM-N bit-streams carried over TSoP PWs may experience delays 1038 exceeding those typical of native SDH networks. These delays include 1039 the TSoP packetization delay, edge-to-edge delay of the underlying 1040 PSN, and the delay added by the jitter buffer. It is recommended to 1041 estimate both delay and delay variation prior to setup of a TSoP PW. 1042 See appendix B for more information on jitter buffer configuration. 1044 TSoP carries STM-N streams over PSN in their entirety, including any 1045 control plane data contained within the data. Consequently, the 1046 emulated STM-N services are sensitive to the PSN packet loss. 1047 Appropriate generation of replacement data can be used to prevent LOF 1048 defects and declaration of severely errored seconds (SES) due to 1049 occasional packet loss. Other effects of packet loss on this 1050 interface (e.g., errored blocks) cannot be prevented. See appendix D 1051 for more information. 1053 TSoP provides for effective fault isolation by forwarding the local 1054 attachment circuit failure indications to the remote attachment 1055 circuit. 1057 TSoP provides for a carrier independent ability to detect 1058 misconnections and malformed packets via the PT and SSRC fields in 1059 the RTP Header. This feature increases resilience of the emulated 1060 service to misconfiguration. 1062 Being a constant bit rate (CBR) service, TSoP cannot provide TCP 1063 friendly behavior under network congestion. 1065 Faithfulness of a TSoP PW may be increased by exploiting QoS features 1066 of the underlying PSN. 1068 TSoP does not provide any mechanisms for protection against PSN 1069 outages, and hence its resilience to such outages is limited. 1070 However, lost packet replacement and packet reordering mechanisms 1071 increase resilience of the emulated service to fast PSN rerouting 1072 events. 1074 A key requirement for TSoP to achieve transparent transport of the 1075 timing information of an STM-N signal, is that the recovered STM-N 1076 signal meets all relevant SDH and SONET jitter/wander requirements 1077 (see section 6.2.2). It will depend on the synchronization situation 1078 of the PSN whether or not a given CE-bound TSoP implementation can 1079 meet this requirement. In appendix C a number of network 1080 synchronization situations are listed, in which it is possible to 1081 meet this requirement with a reasonable CE-bound IWF design. In 1082 other network synchronization scenarios, the application of TSoP is 1083 not generically recommended. 1085 11. IANA Considerations 1087 IANA is requested to assign a new MPLS Pseudowire (PW) type for the 1088 following TSoP encapsulated services: 1090 PW type Description Reference 1091 -------- ---------------- ---------- 1092 0x0020 STM-0 or OC-1 RFC XXXX 1093 0x0021 STM-1 or OC-3 RFC XXXX 1094 0x0022 STM-4 or OC-12 RFC XXXX 1095 0x0023 STM-16 or OC-48 RFC XXXX 1096 0x0024 STM-64 or OC-192 RFC XXXX 1098 The above value is suggested as the next available value and has been 1099 reserved for this purpose by IANA. 1101 RFC Editor: Please replace RFC XXXX above with the RFC number of this 1102 document and remove this note. 1104 12. Acknowledgements 1106 The authors of this document are much indebted to the authors of 1107 [RFC4553]. This latter RFC has been used as a template and example 1108 for the current document. Moreover, many paragraphs and sentences 1109 have been copied from this RFC without alteration or with only slight 1110 modification into the current document. 1112 Furthermore, we thank Zhu Hao, Jeff Towne, Willem van den Bosch, 1113 Peter Roberts and Matthew Bocci for their valuable feedback. 1115 13. References 1117 13.1. Normative References 1119 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1120 Requirement Levels", BCP 14, RFC 2119, March 1997. 1122 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1123 Jacobson, "RTP: A Transport Protocol for Real-Time 1124 Applications", STD 64, RFC 3550, July 2003. 1126 [G.707] ITU-T Recommendation G.707/Y.1322 (01/2007) - Network node 1127 interface for the synchronous digital hierarchy (SDH) 1129 [G.783] ITU-T Recommendation G.783 (03/2006) - Characteristics of 1130 synchronous digital hierarchy (SDH) equipment functional 1131 blocks 1133 [O.150] ITU-T Recommendation O.150 (05/1996) - General 1134 requirements for instrumentation for performance 1135 measurement on digital transmission equipment 1137 [G.823] ITU-T Recommendation G.823 (03/2000) - The control of 1138 jitter and wander within digital networks which are based 1139 on the 2048 kbit/s hierarchy 1141 [G.825] ITU-T Recommendation G.825 (03/2000) - The control of 1142 jitter and wander within digital networks which are based 1143 on the synchronous digital hierarchy (SDH) 1145 [GR-253] Telcordia GR-253-CORE - Synchronous Optical Network 1146 (SONET) Transport Systems: Common Generic Criteria, Issue 1147 5, October 2009 1149 13.2. Informative References 1151 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 1152 of Guaranteed Quality of Service", RFC 2212, September 1153 1997. 1155 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1156 and W. Weiss, "An Architecture for Differentiated 1157 Services", RFC 2475, December 1998. 1159 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 1160 RFC 2914, September 2000. 1162 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1163 Label Switching Architecture", RFC 3031, January 2001. 1165 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1166 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1167 Encoding", RFC 3032, January 2001. 1169 [RFC3086] Nichols, K. and B. Carpenter, "Definition of 1170 Differentiated Services Per Domain Behaviors and Rules for 1171 their Specification", RFC 3086, April 2001. 1173 [RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec, 1174 J., Courtney, W., Davari, S., Firoiu, V., and D. 1175 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1176 Behavior)", RFC 3246, March 2002. 1178 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1179 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1180 RFC 3711, March 2004. 1182 [RFC3916] Xiao, X., Ed., McPherson, D., Ed., and P. Pate, Ed., 1183 "Requirements for Pseudo-Wire Emulation Edge-to-Edge 1184 (PWE3)", RFC 3916, September 2004. 1186 [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation 1187 Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 1189 [RFC4197] Riegel, M., Ed., "Requirements for Edge-to-Edge Emulation 1190 of Time Division Multiplexed (TDM) Circuits over Packet 1191 Switching Networks", RFC 4197, October 2005. 1193 [RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, 1194 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for 1195 Use over an MPLS PSN", RFC 4385, February 2006. 1197 [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and 1198 G. Heron, "Pseudowire Setup and Maintenance Using the 1199 Label Distribution Protocol (LDP)", RFC 4447, April 2006. 1201 [RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure- 1202 Agnostic Time Division Multiplexing (TDM) over Packet 1203 (SAToP)", RFC 4553, June 2006. 1205 [RFC4623] Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to- 1206 Edge (PWE3) Fragmentation and Reassembly", RFC 4623, 1207 August 2006. 1209 [RFC4842] Malis, A., Pate, P., Cohen, R., Ed., and D. Zelig, 1210 "Synchronous Optical Network/Synchronous Digital Hierarchy 1211 (SONET/SDH) Circuit Emulation over Packet (CEP)", 1212 RFC 4842, April 2007. 1214 [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire 1215 Virtual Circuit Connectivity Verification (VCCV): A 1216 Control Channel for Pseudowires", RFC 5085, December 2007. 1218 [RFC5604] Nicklass, O., "Managed Objects for Time Division 1219 Multiplexing (TDM) over Packet Switched Networks (PSNs)", 1220 RFC 5604, July 2009. 1222 [RFC6371] Busi, I., Ed., and D. Allan, Ed., "Operations, 1223 Administration, and Maintenance Framework for MPLS-Based 1224 Transport Networks", RFC 6371, September 2011. 1226 [G.703] ITU-T Recommendation G.703 (11/2001) - Physical/electrical 1227 characteristics of hierarchical digital interfaces 1229 [G.709] ITU-T Recommendation G.709/Y.1331 (12/2009) - Interfaces 1230 for the Optical Transport Network (OTN) 1232 [G.781] ITU-T Recommendation G.781 (09/2008) - Synchronization 1233 layer functions 1235 [G.811] ITU-T Recommendation G.811 (09/1997) - Timing 1236 characteristics of primary reference clocks 1238 [G.827] ITU-T Recommendation G.827 (09/2003) - Availability 1239 performance parameters and objectives for end-to-end 1240 international constant bit-rate digital paths 1242 [G.828] ITU-T Recommendation G.828 (03/2000) - Error performance 1243 parameters and objectives for international, constant bit 1244 rate synchronous digital paths 1246 [G.957] ITU-T Recommendation G.957 (06/1999) - Optical interfaces 1247 for equipments and systems relating to the synchronous 1248 digital hierarchy 1250 [G.8260] ITU-T Recommendation G.8260 (02/2012) - Definitions and 1251 terminology for synchronization in packet networks 1253 [G.8262] ITU-T Recommendation G.8262/Y.1362 (07/2010) - Timing 1254 characteristics of a synchronous Ethernet equipment slave 1255 clock 1257 [G.8263] ITU-T Recommendation G.8263/Y.1363 (02/2012) - Timing 1258 characteristics of packet-based equipment clocks 1260 [RTP-TYPE] RTP PARAMETERS, 1263 Appendix A. Parameter Configuration for TSoP PW Set-up 1265 The following parameters of the TSoP IWF MUST be agreed upon between 1266 the peer IWFs during the PW setup. Such an agreement can be reached 1267 via manual configuration or via one of the PW set-up protocols: 1269 1. Type of attachment circuit, i.e., the value of N of the STM-N 1270 signal, which corresponds to a bit rate as mentioned in section 3. 1272 2. Payload size, i.e., the (constant) number of octets that is 1273 transmitted in the TSoP Payload Field of each TSoP packet. The 1274 default value is 810 octets. 1276 3. Timestamping clock frequency: 25 MHz (default) or an alternative 1277 value. 1279 4. The configurability of the following parameters (see 1280 section 6.2.2) governing the behavior of the CE-bound IWF buffer 1281 is optional: 1283 a) The maximum amount of payload data that may be stored in the 1284 CE-bound IWF payload buffer 1286 b) The desired degree of filling of the CE-bound IWF buffer in 1287 steady state (see appendix B) 1289 c) The "intermediate state" timer, i.e., the maximum amount of 1290 time that the CE-bound IWF waits before it starts to play out 1291 data towards the CE 1293 5. The content of the following RTP header fields must be provided by 1294 the user: 1296 a) The 7-bit RTP Payload Type (PT) value; any value can be 1297 assigned to be used with TSoP PWs. Default is an all zero 1298 pattern. 1300 b) The 32-bit Synchronization Source (SSRC) value. Default is an 1301 all zero pattern. 1303 6. The number of TSoP packets that must be missed consecutively 1304 before the CE-bound IWF enters the LOPS defect state (default: 10) 1305 and the number of TSoP packets that must be received consecutively 1306 to clear the LOPS defect state (default: 2). See section 4.3.2 1307 and [RFC5604] 1309 7. To support the optional excessive packet loss event by the 1310 CE-bound IWF, the following parameters must be configured: 1312 a) The length of the observation period for detecting excessive 1313 packet loss. Default value is 10 s. 1315 b) The minimum number of lost packets that is to be detected in 1316 the observation interval before an excessive packet loss alarm 1317 is raised. Default value is 30% of the expected packets. 1319 c) The maximum number of lost packets that is to be detected in 1320 the observation interval to clear an excessive packet loss 1321 alarm. Default value is 1% of the expected packets. 1323 Appendix B. Buffer Configuration in the CE-bound IWF 1325 The buffer in the CE-bound IWF (often called the "jitter buffer") is 1326 used to compensate the differences in transit time that each bit of 1327 the STM-N signal experiences between the moment it ingresses the 1328 PSN-bound IWF and the moment it ingresses the CE-bound IWF. There 1329 are two mechanisms that cause the transit times of individual bits to 1330 be different: 1332 1. The packetization delay (Tpkt(n)) in the PSN-bound IWF: After 1333 arrival in the PSN-bound IWF, STM-N bit #n has to wait until 1334 sufficient bits have been received to fill the complete Payload 1335 Field of a TSoP packet. Clearly if two STM-N bits end up in the 1336 same TSoP packet, the bit that arrives earlier has to wait longer 1337 than the bit that arrives later. The (variable part of the) 1338 packetization delay, Tpkt(n), varies between zero and the time 1339 between the transmission of two subsequent TSoP packets. 1341 2. The packet delay variation (Tpdv(n)), i.e. the difference in 1342 transit time that the TSoP packet containing bit #n experiences 1343 relative to some reference (minimum) transit time, due to the 1344 presence of non-empty shapers and queues (or any other cause for 1345 variable delay) on its path through the PSN. 1347 ----- direction of transmission -----> 1349 +------+ +-------------+ +-------------+ +------+ 1350 | Clk1 | | Clk2 | | Clk3 | | Clk4 | 1351 |------| |-------------| |-------------| |------| 1352 | | | | | | | | 1353 | | | +---------+ | +---------+ | +---------+ | | | 1354 | SDH1 |----|-| Tpkt(n) |=|==| Tpdv(n) |==|=| Tjbf(n) |-|----| SDH2 | 1355 | | | +---------+ | +---------+ | +---------+ | | | 1356 | | |packetization| packet | jitter | | | 1357 | | | delay | delay | buffer | | | 1358 +------+ +-------------+ variation +-------------+ +------+ 1359 CE1 PE1 PE2 CE2 1361 |----| |===============| |----| 1362 AC1 PSN AC2 1363 (STM-N) (STM-N) 1365 +-----------------------------------+ 1366 | Clk1 is the system clock of CE1 | 1367 | Clk2 is the system clock of PE1 | 1368 | Clk3 is the system clock of PE2 | 1369 | Clk4 is the system clock of CE2 | 1370 +-----------------------------------+ 1372 Figure 8. Delay components in a uni-directional TSoP 1373 Pseudowire (from PE1 to PE2). 1375 Figure 8 schematically shows three contributors to the over-all 1376 transit delay of STM-N bits between ingressing PE1 and egressing PE2: 1377 The paketization delay in PE1 and the packet delay variation over the 1378 PSN, as mentioned above, which cause delay differences between the 1379 bits and the jitter buffer delay in PE2, Tjbf(n), which is intended 1380 to equalize these differences. 1382 When the CE-bound IWF in PE2 starts up, it writes the bits in the 1383 TSoP Payload Field of incoming packets into the jitter buffer until a 1384 preconfigured degree of filling is reached. From this moment onward, 1385 bits are played out from this buffer under control of an STM-N clock 1386 (derived from Clk3) that is locally synthesized in PE2. A necessary 1387 condition to avoid overflow or underflow of the jitter buffer is that 1388 this clock must have the same average frequency as the clock in PE1 1389 (derived from Clk2) that governs the encapsulation process. 1391 The dwelling time of an individual bit in the jitter buffer, Tjbf(n), 1392 is determined by the actual delay time that this bit experienced in 1393 transiting through PE1 and the PSN. Bits traveling fast reside long 1394 in the jitter buffer, while slow bits reside only a short while in 1395 the buffer, such that the total time is equal for all bits. 1397 For a given bit #n, this behavior can be expressed by the relation 1398 Tpkt(n) + Tpdv(n) + Tjbf(n) = constant (within the allowed jitter and 1399 wander limits of an STM-N signal). Since especially Tpdv(n) can vary 1400 significantly, the initial degree of filling of the jitter buffer, 1401 Tjbf(0), should be configured large enough to allow lowering the 1402 buffer fill when at a later time bits arrive that happen to be 1403 slower. This compensating effect of the jitter buffer fill on the 1404 overall transit time requires the frequency of Clk3, and so the 1405 frequency of the outgoing STM-N signal, to change slow compared to 1406 the PDV variations. 1408 Note that the Tjbf(n) term adds to the total delay that an STM-N bit 1409 experiences crossing the TSoP PW section. For this reason the 1410 initial degree of filling of the jitter buffer should not be 1411 configured larger than necessary, i.e. it is a compromise between the 1412 delay permitted by the application and the probability of buffer 1413 underrun due to large PDV excursions. Depending on the requirements 1414 for a particular STM-N client signal, a small probability of buffer 1415 underrun may be acceptable in order to meet the delay specifications. 1416 See appendix D for a description of the effects of jitter buffer 1417 underrun on CE2. 1419 Apart from the initial fill level of the jitter buffer, its total 1420 size can also be configurable (see section 6.2.2). The fill level 1421 increases when a number of faster packets arrives and the buffer 1422 needs sufficient "headroom" to avoid overflow under such conditions. 1423 However, it is not necessary to reserve more "headroom" than is 1424 needed to accommodate the fastest packets, corresponding to the 1425 minimum delay of the PW. 1427 Appendix C. Synchronization Considerations for the CE-bound IWF 1429 In section 6.2.2 the requirements for reconstruction of the STM-N 1430 client signal from the incoming TSoP packets in the CE-bound IWF 1431 function are given, without reference to the quality of the CE-bound 1432 IWF system clock or the method of STM-N clock recovery. This is done 1433 on purpose, to avoid as much as possible restrictions on the 1434 implementation, as these factors depend on the (network) 1435 synchronization situation. This appendix provides information on 1436 this dependency. 1438 Figure 9 shows the reference network that is used to analyze the 1439 dependency of the CE-bound IWF requirements on the synchronization 1440 situation in the network. Since network synchronization operates 1441 uni-directional, only the corresponding direction of transmission is 1442 depicted. The return path will never be used at the same time as a 1443 synchronization reference signal: If Ref4 is derived from AC2, the 1444 S1-byte of the returning STM-N will contain the message "Don't Use 1445 for Synchronization". 1447 ----- direction of transmission -----> 1449 Ref2 Ref3 1450 | | 1451 Ref1 | | Ref4 1452 | V V | 1453 | +--------+ +--------+ | 1454 V | Clk2 | | Clk3 | V 1455 +------+ |--------| |--------| +------+ 1456 | Clk1 | | STM-N /| | TSoP /| | Clk4 | 1457 |------| | / | | -PW / | |------| 1458 | | | / | | / | | | 1459 | SDH1 |--------->| / |============>| / |--------->| SDH2 | 1460 | | STM-N | / | TSoP | / | STM-N | | 1461 | | | / | Packets | / | | | 1462 +------+ | / TSoP | | / | +------+ 1463 CE1 |/ -PW | |/ STM-N | CE2 1464 | +--------+ +--------+ | 1465 | PE1 PE2 | 1466 | | | | | | 1467 |-- AC1 -->| |==== PSN ===>| |-- AC2 -->| 1468 | | | | 1469 | |--------- Pseudowire --------->| | 1470 Up- | | Down- 1471 stream |------------- STM-N (multiplex) section ------------>| stream 1473 +---------------------------------------------------+ 1474 | Clk1 is the system clock of CE1, locked to Ref1 | 1475 | Clk2 is the system clock of PE1, locked to Ref2 | 1476 | Clk3 is the system clock of PE2, locked to Ref3 | 1477 | Clk4 is the system clock of CE2, locked to Ref4 | 1478 +---------------------------------------------------+ 1480 Figure 9. Reference network for analysis of TSoP 1481 synchronization requirements 1483 The intention of the requirements in section 6.2.2 is to ascertain 1484 that the reconstruction of the STM-N client signal in PE2 is 1485 sufficiently faithful that not only its binary content is recovered 1486 but also its timing properties are maintained. This latter aspect 1487 implies that the recovered STM-N signal can still be used as a 1488 synchronization reference signal in the downstream STM-N network as 1489 is required per [G.825] and [GR-253] and that normal processing rules 1490 (see [G.781]) can be applied to the S1-byte. 1492 The requirements regarding maintaining STM-N timing properties of the 1493 reconstructed STM-N are based on two rules: 1495 1. The reconstructed STM-N signal at the TSoP PW egress must have the 1496 same average frequency as the STM-N signal at the TSoP PW ingress. 1498 Since all TSoP packets carry the same number of payload bits and a 1499 sequence numbering mechanism is applied to the TSoP packets, the 1500 TSoP decapsulation function can regenerate an STM-N signal that 1501 has, averaged over time, the same number of bits, as long as the 1502 jitter buffer does not overrun or underrun. 1504 2. The jitter and wander properties of the recovered STM-N signal 1505 must meet the applicable SDH/SONET standards. 1507 The sub-sections below provide the synchronization situations in 1508 the network in which this requirement can be met with a reasonable 1509 design of the CE-bound IWF. The implication is that for other 1510 network synchronization situations such is, in general, not 1511 possible. 1513 The considerations in this appendix are applicable during "normal" 1514 operation. As soon as the input STM-N signal to PE1 is lost or the 1515 TSoP PW itself is failing, PE2 forwards a G-AIS signal towards CE2 at 1516 a frequency that may deviate 20 ppm from the nominal value. A 1517 sustained G-AIS pattern will cause a Loss of Frame condition in CE2, 1518 which will consequently stop reading the contained S1 information and 1519 look for an alternative synchronization reference signal or revert to 1520 hold-over mode. 1522 C.1. Layer 1 Synchronized PEs 1524 The PEs that terminate the TSoP PW operate synchronously in case Ref2 1525 and Ref3 are traceable over the physical layer to the same clock. 1527 In such cases the timing characteristics of the STM-N signal can be 1528 transferred over the PW by applying differential mode, i.e. use the 1529 RTP timestamps in the CE-bound IWF to determine the rate at which the 1530 STM-N bits need to be played out. This will ensure that the average 1531 frequency is maintained over the PW section. 1533 To satisfy the STM-N wander requirements, Clk3 must filter the phase 1534 noise on Ref3 down to the levels specified in [G.825] or [GR-253]. 1535 In case the phase noise on Ref3 stays below the network limit 1536 specified for Synchronous Ethernet [G.8262], it is sufficient that 1537 Clk3 meets the jitter transfer specifications of [G.8262] to achieve 1538 this goal. 1540 C.2. Synchronous CEs 1542 The CEs that terminate the STM-N multiplex section operate 1543 synchronously in case Ref1 and Ref4 are traceable over the physical 1544 layer to the same clock. 1546 In such cases, Ref2 can be derived from Clk1, via AC1 and Ref3 can be 1547 derived from Clk4 via AC2. The timing characteristics of the STM-N 1548 signal can be transferred over the PW by applying differential mode, 1549 i.e. use the RTP timestamps in the CE-bound IWF to determine the rate 1550 at which the STM-N bits need to be played out. This will ensure that 1551 the average frequency is maintained over the PW section. 1553 To satisfy the STM-N wander requirements, Clk3 must filter the phase 1554 noise on Ref3 down to the levels specified in [G.825] or [GR-253]. 1555 In case the phase noise on Ref3 stays below the network limit 1556 specified for STM-N [G.825], it is sufficient if Clk3 meets the 1557 jitter transfer specifications of [G.813] to achieve this goal. 1559 C.3. Pleisiochronous CEs 1561 In case Clk1 and Clk4 are both traceable to different [G.811] type 1562 clocks, the STM-N link operates pleisiochronously, i.e. the long term 1563 frequency difference between both clocks is less than 2E-11. 1565 In such cases, Ref2 can be derived from Clk1, via AC1 and Ref3 can be 1566 derived from Clk4 via AC2. Again, differential mode clock recovery 1567 is assumed in the CE-bound IWF. The very small frequency difference 1568 will cause a re-center action of the jitter buffer in PE2, each time 1569 it overflows or underflows. The time interval between such events 1570 depends on the depth of the buffer and the actual frequency 1571 difference between Ref1 and Ref4. 1573 As an example, if the frequency difference is 2E-11 (this represents 1574 the worst case) and if an overflow or underflow event shifts the 1575 buffer fill by 125 microseconds, a re-center event happens once every 1576 72 days. In the downstream SDH node, a re-center event causes 1577 1 errored second (ES) in all VC paths that are carried over this STM- 1578 N signal (see appendix D). A level of one ES per 72 days is 1579 negligible compared to the ES limits formulated in [G.828] for 1580 VC-paths. 1582 Appendix D. Effect of G-AIS Insertion on a Downstream SDH Node 1584 There are a number of network events that force the CE-bound IWF to 1585 replace the content of the Payload Field of a TSoP packet by the same 1586 number of bits from the local G-AIS pattern generator (see figure 2). 1587 This is the case when: 1589 a) A TSoP packet is lost, or, 1591 b) A TSoP packet arrives out-of-order and its position can't be 1592 restored, or, 1594 c) A TSoP packet arrives with its L-bit set. 1596 In case the STM-N payload of K consecutive TSoP packets is replaced 1597 by G-AIS, the effect is that parity violations are detected in the 1598 downstream SDH Node (CE) for a period T = K / (N * 8000) seconds. As 1599 long as K is small, this will typically lead to counting 1 Errored 1600 Second (ES) event (or occasionally 2 in case the event straddles two 1601 adjacent 1 second monitoring periods) for the STM-N signal itself and 1602 all contained VC-path layers. As long the number of ES that is 1603 induced in a given VC-path by the effects above, remains small 1604 compared to the applicable limit defined in [G.828], this effect of 1605 G-AIS substitution can be tolerated. 1607 A second consequence of G-AIS substitution is that the G-AIS bits may 1608 overwrite the STM-N alignment word (A1 and A2 bytes) in the recovered 1609 STM-N signal. This A1-A2 alignment word repeats every 0.125 ms. The 1610 length of the period T determines the number of framing patterns that 1611 is affected by the inserted G-AIS bits. 1613 Each time an STM-N framing word is changed by G-AIS bits overwriting 1614 it, this will cause a framing anomaly in the downstream SDH Node. 1615 Such anomalies have no effect on the STM-N framer as long as a next 1616 A1-A2 word is correct and is still in its expected location. Only in 1617 case the G-AIS streak lasts for a 3 ms or longer period, these 1618 persistent anomalies will cause a LOF defect (see [G.783]) to be 1619 raised and consequently the declaration of a Severely Errored Second 1620 (SES). Note that the limits for SES events are much stricter than 1621 for ES event (see [G.828]). On the other hand, the probability of 1622 losing 3 ms worth of TSoP packets (e.g. 72 consecutive TSoP packets 1623 for STM-1/OC-3) is much lower than losing one or a few packets in a 1624 row. 1626 In case the jitter buffer is re-centered, for instance due to a 1627 buffer overrun or underrun, the position of the A1-A2 framing pattern 1628 will in general shift once by an amount of time that is not an 1629 integral multiple of 0.125 ms. Also such an event will not cause a 1630 LOF defect in the downstream STM-N node, because an STM-N framer that 1631 conforms to [G.783] must be able to detect the out-of-frame condition 1632 within 0.625 ms and find the new frame position within 0.250 ms, so 1633 the entire operation is completed well within 3 ms (the minimum time 1634 to declare a LOF defect). 1636 Note that in case of buffer underrun, G-AIS is transmitted while the 1637 CE-bound IWF waits for the buffer to reach its configured initial 1638 fill level. This waiting time has to be added to the STM-N out-of- 1639 frame detection time and frame recovery time mentioned above, to 1640 assess the overall impact on the downstream SDH node. This implies 1641 that if the initial fill level is configured somewhat larger than 1642 2 ms (actually, 3 - 0.625 - 0.250 = 2.125 ms), an underrun event can 1643 trigger a LOF defect and consequently a SES event in the downstream 1644 SDH network. So while a larger jitter buffer diminishes the 1645 probability of an underrun event, the consequences of such an event 1646 are more severe once this ~2 ms threshold is crossed. This must be 1647 weighed carefully. 1649 Authors' Addresses 1651 Gert Manhoudt 1652 AimValley B.V. 1653 Utrechtseweg 38 1654 1213 TV Hilversum 1655 The Netherlands 1656 E-mail: gmanhoudt@aimvalley.nl 1658 Stephan Roullot 1659 Alcatel-Lucent Centre de Villarceaux 1660 Route de Villejust 1661 91620 Nozay 1662 France 1663 E-mail: stephan.roullot@alcatel-lucent.com 1665 Kin Yee Wong 1666 Alcatel-Lucent 1667 600 March Road 1668 Kanata, Ontario, K2K 2E6 1669 Canada 1670 E-mail: kin-yee.wong@alcatel-lucent.com 1672 Kuo, Huei-Long 1673 Chunghwa Telecom Co. Ltd. 1674 No.21-3, Sec. 1, Xinyi Rd. 1675 Zhongzheng Dist., Taipei City 100 1676 Taiwan 1677 E-mail: hlkuo@cht.com.tw