idnits 2.17.1 draft-ietf-pwe3-tdm-requirements-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1036. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1042. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 10, 2005) is 6955 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) ** Downref: Normative reference to an Informational RFC: RFC 3916 (ref. 'PWE3-REQ') ** Downref: Normative reference to an Informational RFC: RFC 3985 (ref. 'PWE3-ARCH') -- Possible downref: Non-RFC (?) normative reference: ref. 'G.702' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.704' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.706' -- 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.810' -- Possible downref: Non-RFC (?) normative reference: ref. 'G.826' ** Downref: Normative reference to an Informational RFC: RFC 1958 -- Possible downref: Non-RFC (?) normative reference: ref. 'TR-NWT-170' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Riegel, Ed. 3 Internet-Draft Siemens AG 4 Expires: October 12, 2005 April 10, 2005 6 Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet 7 Switching Networks 8 draft-ietf-pwe3-tdm-requirements-08.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 12, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document defines the specific requirements for edge-to-edge 41 emulation of circuits carrying Time Division Multiplexed (TDM) 42 digital signals of the Plesiochronous Digital Hierarchy as well as 43 the Synchronous Optical NETwork/Synchronous Digital Hierarchy over 44 packet-switched networks. It is aligned to the common architecture 45 for Pseudo Wire Emulation Edge-to-Edge (PWE3). 46 It makes references to the generic requirements for PWE3 where 47 applicable and complements them by defining requirements originating 48 from specifics of TDM circuits. 50 Contributors Section 52 The following have contributed to this document: 54 Sasha Vainshtein Axerra Networks 55 sasha@axerra.com 57 Yaakov Stein RAD Data Communication 58 yaakov_s@rad.com 60 Prayson Pate Overture Networks, Inc. 61 prayson.pate@overturenetworks.com 63 Ron Cohen Lycium Networks 64 ronc@lyciumnetworks.com 66 Tim Frost Zarlink Semiconductor 67 tim.frost@zarlink.com 69 Changes from the last revision: 71 - Expanded security considerations section due to IESG review 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 1.1 TDM circuits belonging to the PDH hierarchy . . . . . . . 4 77 1.1.1 TDM structure and transport modes . . . . . . . . . . 5 78 1.2 SONET/SDH circuits . . . . . . . . . . . . . . . . . . . . 5 79 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 81 4. Reference Models . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1 Generic PWE3 Models . . . . . . . . . . . . . . . . . . . 8 83 4.2 Clock Recovery . . . . . . . . . . . . . . . . . . . . . . 8 84 4.3 Network Synchronization Reference Model . . . . . . . . . 8 85 4.3.1 Synchronous Network Scenarios . . . . . . . . . . . . 11 86 4.3.2 Relative Network Scenario . . . . . . . . . . . . . . 13 87 4.3.3 Adaptive Network Scenario . . . . . . . . . . . . . . 13 88 5. Emulated Services . . . . . . . . . . . . . . . . . . . . . . 14 89 5.1 Structure-Agnostic Transport of signals out of the PDH 90 hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 14 91 5.2 Structure-Aware Transport of signals out of the PDH 92 hierarchy . . . . . . . . . . . . . . . . . . . . . . . . 15 93 5.3 Structure-Aware Transport of SONET/SDH Circuits . . . . . 15 94 6. Generic Requirements . . . . . . . . . . . . . . . . . . . . . 15 95 6.1 Relevant Common PW Requirements . . . . . . . . . . . . . 15 96 6.2 Common Circuit Payload Requirements . . . . . . . . . . . 16 97 6.3 General Design Issues . . . . . . . . . . . . . . . . . . 17 98 7. Service-Specific Requirements . . . . . . . . . . . . . . . . 17 99 7.1 Connectivity . . . . . . . . . . . . . . . . . . . . . . . 17 100 7.2 Network Synchronization . . . . . . . . . . . . . . . . . 17 101 7.3 Robustness . . . . . . . . . . . . . . . . . . . . . . . . 18 102 7.3.1 Packet loss . . . . . . . . . . . . . . . . . . . . . 18 103 7.3.2 Out-of-order delivery . . . . . . . . . . . . . . . . 18 104 7.4 CE Signaling . . . . . . . . . . . . . . . . . . . . . . . 18 105 7.5 PSN bandwidth utilization . . . . . . . . . . . . . . . . 19 106 7.6 Packet Delay Variation . . . . . . . . . . . . . . . . . . 20 107 7.7 Compatibility with the Existing PSN Infrastructure . . . . 20 108 7.8 Congestion Control . . . . . . . . . . . . . . . . . . . . 20 109 7.9 Fault Detection and Handling . . . . . . . . . . . . . . . 21 110 7.10 Performance Monitoring . . . . . . . . . . . . . . . . . . 21 111 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23 114 Intellectual Property and Copyright Statements . . . . . . . . 24 116 1. Introduction 118 This document defines the specific requirements for edge-to-edge 119 emulation of circuits carrying time division multiplexed digital 120 signals of the Plesiochronous Digital Hierarchy (PDH) as well as the 121 Synchronous Optical NETwork (SONET)/Synchronous Digital Hierarchy 122 (SDH) over Packet-Switched Networks (PSN). It is aligned to the 123 common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as 124 defined in [PWE3-ARCH]. 125 It makes references to requirements in [PWE3-REQ] where applicable 126 and complements [PWE3-REQ] by defining requirements originating from 127 specifics of TDM circuits. 129 The term "TDM" will be used in this documents as a general descriptor 130 for the synchronous bit streams belonging to either the PDH or the 131 SONET/SDH hierarchies. 133 1.1 TDM circuits belonging to the PDH hierarchy 135 The bit rates traditionally used in various regions of the world are 136 detailed in the normative reference [G.702]. For example, in North 137 America the T1 bit stream of 1.544 Mbps and the T3 bit stream of 138 44.736 Mbps are mandated, while in Europe the E1 bit stream of 2.048 139 Mbps and the E3 bit stream of 34.368 Mbps are utilized. 141 Although TDM can be used to carry unstructured bit streams at the 142 rates defined in [G.702], there is a standardized method of carrying 143 bit streams in larger units called frames, each frame containing the 144 same number of bits. 145 Related to the sampling frequency of voice traffic the bitrate is 146 always a multiple of 8000, hence the T1 frame consists of 193 bits 147 and the E1 frame of 256 bits. The number of bits in a frame is 148 called the frame size. 150 The framing is imposed by introducing a periodic pattern into the bit 151 stream to identify the boundaries of the frames (e.g. 1 framing bit 152 per T1 frame, a sequence of 8 framing bits per E1 frame). The 153 details of how these framing bits are generated and used are 154 elucidated in [G.704], [G.706] and [G.751]. Unframed TDM has all 155 bits available for payload. 157 Framed TDM is often used to multiplex multiple channels (e.g., voice 158 channels each consisting of 8000 8bit-samples per second) in a 159 sequence of "timeslots" recurring in the same position in each frame. 160 This multiplexing is called "channelized TDM" and introduces 161 additional structure. 163 In some cases framing also defines groups of consecutive frames 164 called multiframes. Such grouping imposes an additional level of 165 structure on the TDM bit-stream. 167 1.1.1 TDM structure and transport modes 169 Unstructured TDM: 170 TDM that consists of a raw bit-stream of rate defined in [G.702], 171 with all bits available for payload. 173 Structured TDM: 174 TDM with one or more levels of structure delineation, including 175 frames, channelization, and multiframes (e.g. as defined in [G.704], 176 [G.751], [T1.107]). 178 Structure-Agnostic Transport: 179 Transport of unstructured TDM, or of structured TDM when the 180 structure is deemed inconsequential from the transport point of view. 181 In structure-agnostic transport any structural overhead that may be 182 present is transparently transported along with the payload data, and 183 the encapsulation provides no mechanisms for its location or 184 utilization. 186 Structure-Aware Transport: 187 Transport of structured TDM taking at least some level of the 188 structure into account. In structure-aware transport there is no 189 guarantee that all bits of the TDM bit-stream will be actually 190 transported over the PSN network (specifically, the synchronization 191 bits and related overhead may be stripped at ingress and usually will 192 be regenerated at egress), or that bits transported are always 193 situated in the packet in their original order (but in this case, bit 194 order is usually recovered at egress; one known exception is loss of 195 multiframe synchronization between the TDM data and CAS bits 196 introduced by a digital cross-connect acting as a Native Service 197 Processing (NSP) block, see [TR-NWT-170]). 199 1.2 SONET/SDH circuits 201 The term SONET refers to the North American Synchronous Optical 202 NETwork as specified by [T1.105]. It is based on the concept of a 203 Nx783 byte payload container repeated every 125us. This payload is 204 referred as an STS-1 SPE and may be concatenated into higher 205 bandwidth circuits (e.g. STS-Nc) or sub-divided into lower bandwidth 206 circuits (Virtual Tributaries). The higher bandwidth concatenated 207 circuits can be used to carry anything from IP Packets to ATM cells 208 to Digital Video Signals. Individual STS-1 SPEs are frequently used 209 to carry individual DS3 or E3 TDM circuits. When the 783 byte 210 containers are sub-divided for lower rate payloads, they are 211 frequently used to carry individual T1 or E1 TDM circuits. 213 The Synchronous Digital Hierarchy (SDH) is the international 214 equivalent and enhancement of SONET and is specified by [G.707]. 216 Both SONET and SDH include a substantial amount of transport overhead 217 that is used for performance monitoring, fault isolation, and other 218 maintenance functions along different types of optical or electrical 219 spans. This also includes a pointer based mechanism for carrying 220 payloads asynchronously. In addition, the payload area includes 221 dedicated overhead for end-to-end performance monitoring, fault 222 isolation, and maintenance for the service being carried. If the 223 main payload area is sub-divided into lower rate circuits (such as 224 T1/E1), additional overhead is included for end-to-end monitoring of 225 the individual T1/E1 circuits. 227 This document discusses the requirements for emulation of SONET/SDH 228 services. These services include end-to-end emulation of the SONET 229 payload (STS-1 SPE), emulation of concatenated payloads (STS-Nc SPE), 230 as well as emulation of a variety of sub-STS-1 rate circuits jointly 231 referred to as Virtual Tributaries (VT) and their SDH analogs. 233 2. Motivation 235 [PWE3-REQ] specifies common requirements for edge-to-edge-emulation 236 of circuits of various types. However, these requirements, as well 237 as references in [PWE3-ARCH] do not cover specifics of PWs carrying 238 TDM circuits. 240 The need for a specific document complementing [PWE3-REQ] addressing 241 edge-to-edge-emulation of TDM circuits arises from following: 243 o Specifics of the TDM circuits, 244 e.g.: 246 * the need for balance between the clock of ingress and egress 247 attachment circuits in each direction of the Pseudo Wire (PW), 249 * the need to maintain jitter and wander of the clock of the 250 egress end service within the limits imposed by the appropriate 251 normative documents in the presence of the packet delay 252 variation produced by the PSN. 254 o Specifics of applications using TDM circuits, 255 e.g. voice applications: 257 * put special emphasis on minimization of one-way delay, 259 * are relatively tolerant to errors in data. 261 Other applications might have different specifics. 262 e.g. transport of signaling information: 264 * is relatively tolerant to one-way delay, 266 * is sensitive to errors in transmitted data. 268 o Specifics of the customers' expectations regarding end-to-end 269 behavior of services that contain emulated TDM circuits, 270 e.g., experience with carrying such services over SONET/SDH 271 networks increases the need for: 273 * isolation of problems introduced by the PSN from those 274 occurring beyond the PSN bounds, 276 * sensitivity to misconnection, 278 * sensitivity to unexpected connection termination, etc. 280 3. Terminology 282 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 283 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 284 document are to be interpreted as described in [RFC2119]. 286 The terms defined in [PWE3-ARCH], Section 1.4 are consistently used. 287 However some terms and acronyms are used in conjunction with the TDM 288 services. In particular: 290 TDM networks employ Channel-Associated Signaling (CAS) or Common 291 Channel Signaling (CCS) to supervise and advertise status of 292 telephony applications, provide alerts to these applications (as to 293 requests to connect or disconnect), and to transfer routing and 294 addressing information. These signals must be reliably transported 295 over the PSNs for the telephony end-systems to function properly. 297 CAS (Channel-Associated Signaling) 298 CAS is carried in the same T1 or E1 frame as the voice signals, 299 but not in the speech band. Since CAS signaling may be 300 transferred at a rate slower than the TDM traffic in a timeslot, 301 one need not update all the CAS bits every TDM frame. Hence CAS 302 systems cycle through all the signaling bits only after some 303 number of TDM frames, defining a new structure known as a 304 multiframe or superframe. Common multiframes are 12, 16, or 24 305 frames in length, corresponding to 1.5, 2 and 3 milliseconds in 306 duration. 308 CCS (Common Channel Signaling) 309 CCS signaling uses a separate digital channel to carry 310 asynchronous messages pertaining to the state of telephony 311 applications over related TDM timeslots of a TDM trunk. This 312 channel may be physically situated in one or more adjacent 313 timeslots of the same TDM trunk (trunk associated CCS) or may be 314 transported over an entirely separate network. 315 CCS is typically HDLC-based, with idle codes or keep-alive 316 messages being sent until a signaling event (e.g. on-hook or off- 317 hook) occurs. Examples of HDLC-based CCS systems are SS7 [Q.700] 318 and ISDN PRI signaling [Q.931]. 320 Note: For the TDM network we use the terms "jitter" and "wander" as 321 defined in [G.810] to describe short- and long-term variance of the 322 significant instants of the digital signal, while for the PSN we use 323 the term packet delay variation (PDV) (see [RFC3393]). 325 4. Reference Models 327 4.1 Generic PWE3 Models 329 Generic models that have been defined in [PWE3-ARCH] in Sections 330 - 4.1 (Network Reference Model), 331 - 4.2 (PWE3 Pre-processing), 332 - 4.3 (Maintenance Reference Model), 333 - 4.4 (Protocol Stack Reference Model) and 334 - 4.5 (Pre-processing Extension to Protocol Stack Reference Model). 335 They are fully applicable for the purposes of this document without 336 modification. 338 All the services considered in this document represent special cases 339 of the Bit-stream and Structured bit-stream payload type defined in 340 Section 3.3 of [PWE3-ARCH]. 342 4.2 Clock Recovery 344 Clock recovery is extraction of the transmission bit timing 345 information from the delivered packet stream. Extraction of this 346 information from a highly jittered source such as a packet stream may 347 be a complex task. 349 4.3 Network Synchronization Reference Model 351 A generic network synchronization reference model is shown in Figure 352 1 below: 354 +---------------+ +---------------+ 355 | PE1 | | PE2 | 356 K | +--+ | | +--+ | G 357 | | | J| | | | H| | | 358 v | v | | | v | | v 359 +---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+ 360 | | | |P| |D| |P| | | | | | | |P| |E| |P| | | | 361 | |<===|h|<:|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| | 362 | | | |y| |c| |y| | | | | | | |y| |c| |y| | | | 363 | C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C | 364 | E | | | |S1| |S2| | | | E | 365 | 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 | 366 | | | |P| |E| |P| | | | | | | |P| |D| |P| | | | 367 | |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| | 368 | | | |y| |c| |y| | | | | | | |y| |c| |y| | | | 369 +---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+ 370 ^ ^ | | ^ | | | ^ | ^ ^ 371 | | | |B | |<------+------>| | | | | | 372 | A | +--+ | | | +--+-E | F | 373 | +---------------+ +-+ +---------------+ | 374 | ^ |I| ^ | 375 | | +-+ | | 376 | C D | 377 +-----------------------------L-----------------------------+ 379 Figure 1: The Network Synchronization Reference Model 381 The following notation is used in Figure 1: 383 CE1, CE2 384 Customer edge devices terminating TDM circuits to be emulated. 386 PE1, PE2 387 Provider edge devices adapting these end services to PW. 389 S1, S2 390 Provider core routers 392 Phy 393 Physical interface terminating the TDM circuit. 395 Enc 396 PSN-bound interface of the PW, where the encapsulation takes 397 place. 399 Dec 400 CE-bound interface of the PW, where the decapsulation takes place. 401 It contains a compensation buffer (also known as the "jitter 402 buffer") of limited size. 404 "==>" 405 TDM attachment circuits 407 "::>" 408 PW providing edge-to-edge-emulation for the TDM circuit. 410 The characters "A" - "L" denote various clocks: 412 "A" 413 The clock used by CE1 for transmission of the TDM attachment 414 circuit towards CE1. 416 "B" 417 The clock recovered by PE1 from the incoming TDM attachment 418 circuit. "A" and "B" always have the same frequency. 420 "G" 421 The clock used by CE2 for transmission of the TDM attachment 422 circuit towards CE2. 424 "H" 425 The clock recovered by PE2 from the incoming TDM attachment 426 circuit. "G" and "H" always have the same frequency. 428 "C", "D" 429 Local oscillators available to PE1 and PE2 respectively. 431 "E" 432 Clock used by PE2 to transmit the TDM attachment service circuit 433 to CE2 (the recovered clock). 435 "F" 436 Clock recovered by CE2 from the incoming TDM attachment service 437 ("E and "F" have the same frequency). 439 "I" 440 If the clock exists, it is the common network reference clock 441 available to PE1 and PE2. 443 "J" 444 Clock used by PE1 to transmit the TDM attachment service circuit 445 to CE1 (the recovered clock). 447 "K" 448 Clock recovered by CE1 from the incoming TDM attachment service 449 ("J" and "K" have the same frequency). 451 "L" 452 If it exists, it is the common reference clock of CE1 and CE2. 453 Note that different pairs of CE devices may use different common 454 reference clocks. 456 A requirement of edge-to-edge-emulation of a TDM circuit is that 457 clock "B" and "E" as well as clock "H" and "J" are of the same 458 frequency. The most appropriate method will depend on the network 459 synchronization scheme. 461 The following groups of synchronization scenarios can be considered: 463 4.3.1 Synchronous Network Scenarios 465 Depending on which part of the network is synchronized by a common 466 clock there are two scenarios: 468 o PE Synchronized Network: 470 Figure 2 below, an adapted version of the generic network 471 reference model, presents the PE synchronized network scenario. 473 The common network reference clock "I" is available to all the PE 474 devices, and local oscillators "C" and "D" are locked to "I": 476 * Clocks "E" and "J" are the same as "D" and "C" respectively. 478 * Clocks "A" and "G" are the same as "K" and "F" respectively 479 (i.e., CE1 and CE2 use loop timing). 481 +-----+ +-----+ 482 +-----+ | |- - -|=================|- - -| | +-----+ 483 | /-- |<---------|............PW1..............|<---------| <-\ | 484 || CE | | | PE1 | | PE2 | | |CE2 || 485 | \-> |--------->|............PW2..............|--------->| --/ | 486 +-----+ | |- - -|=================|- - -| | +-----+ 487 +-----+ +-----+ 488 ^ ^ 489 |C |D 490 +-----------+-----------+ 491 | 492 +-+ 493 |I| 494 +-+ 496 Figure 2: PE synchronized scenario 498 o CE Synchronized Network: 500 Figure 3 below, an adapted version of the generic network 501 reference model, presents the CE synchronized network scenario. 503 The common network reference clock "L" is available to all the CE 504 devices, and local oscillators "A" and "G" are locked to "L": 506 * Clocks "E" and "J" are the same as "G" and "A" respectively 507 (i.e., PE1 and PE2 use loop timing). 509 +-----+ +-----+ 510 +-----+ | |- - -|=================|- - -| | +-----+ 511 | |<---------|............PW1..............|<---------| | 512 | CE1 | | | PE1 | | PE2 | | | CE2 | 513 | |--------->|............PW2..............|--------->| | 514 +-----+ | |- - -|=================|- - -| | +-----+ 515 ^ +-----+ +-----+ ^ 516 |A G| 517 +----------------------------+------------------------------+ 518 | 519 +-+ 520 |L| 521 +-+ 523 Figure 3: CE synchronized scenario 525 No timing information has to be transferred in these cases. 527 4.3.2 Relative Network Scenario 529 In this case each CE uses its own transmission clock source that must 530 be carried across the PSN and recovered by the remote PE, 531 respectively. The common PE clock "I" can be used as reference for 532 this purpose. 534 Figure 4 below shows the relative network scenario. 536 The common network reference clock "I" is available to all the PE 537 devices, and local oscillators "C" and "D" are locked to "I": 539 o Clocks "A" and "G" are generated locally without reference to a 540 common clock. 542 o Clocks "E" and "J" are generated in reference to a common clock 543 available at all PE devices. 545 In a slight modification of this scenario, one (but not both!) of the 546 CE devices may use its receive clock as its transmission clock (i.e. 547 use loop timing). 549 |G 550 +-----+ +-----+ v 551 +-----+ | |- - -|=================|- - -| | +-----+ 552 | |<---------|............PW1..............|<---------| | 553 | CE1 | | | PE1 | | PE2 | | | CE2 | 554 | |--------->|............PW2..............|--------->| | 555 +-----+ | |- - -|=================|- - -| | +-----+ 556 ^ +-----+<-------+------->+-----+ 557 |A | 558 +-+ 559 |I| 560 +-+ 562 Figure 4: Relative network scenario 564 Timing information (the difference between the common reference clock 565 "I" and the incoming clock "A") MUST be explicitly transferred in 566 this case from the ingress PE to the egress PE. 568 4.3.3 Adaptive Network Scenario 570 The adaptive scenario is characterized by: 572 o No common network reference clock "I" is available to PE1 and PE2. 574 o No common reference clock "L" is available to CE1 and CE2. 576 Figure 5 below presents the adaptive network scenario. 578 |J |G 579 v | 580 +-----+ +-----+ v 581 +-----+ | |- - -|=================|- - -| | +-----+ 582 | |<---------|............PW1..............|<---------| | 583 | CE1 | | | PE1 | | PE2 | | | CE2 | 584 | |--------->|............PW2..............|--------->| | 585 +-----+ | |- - -|=================|- - -| | +-----+ 586 ^ +-----+ +-----+ 587 | ^ 588 A| E| 590 Figure 5: Adaptive scenario 592 Synchronizing clocks "A" and "E" in this scenario is more difficult 593 than it is in the other scenarios. 595 Note that the tolerance between clocks "A" and "E" must be small 596 enough to ensure that the jitter buffer does not overflow or 597 underflow. 599 Timing information MAY be explicitly transferred in this case from 600 the ingress PE to the egress PE, e. g. by RTP. 602 5. Emulated Services 604 This section defines requirements for the payload and encapsulation 605 layers for edge-to-edge emulation of TDM services with bit-stream 606 payload as well as structured bit-stream payload. 608 Wherever possible, the requirements specified in this document SHOULD 609 be satisfied by appropriate arrangements of the encapsulation layer 610 only. The (rare) cases when the requirements apply to both the 611 encapsulation and payload layers (or even only to the payload layer 612 only) will be explicitly noted. 614 The service-specific encapsulation layer for edge-to-edge emulation 615 comprises the following services over a PSN. 617 5.1 Structure-Agnostic Transport of signals out of the PDH hierarchy 619 Structure-agnostic transport is considered for the following signals: 621 o E1 as described in [G.704]. 623 o T1 (DS1) as described in [G.704]. 625 o E3 as defined in [G.751]. 627 o T3 (DS3) as described in [T.107]. 629 5.2 Structure-Aware Transport of signals out of the PDH hierarchy 631 Structure-aware transport is considered for the following signals: 633 o E1/T1 with one of the structures imposed by framing as described 634 in [G.704] 636 o NxDS0 with or without CAS 638 5.3 Structure-Aware Transport of SONET/SDH Circuits 640 Structure-aware transport is considered for the following SONET/SDH 641 circuits: 643 o SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 645 o SONET STS-Nc SPE (N = 3, 12, 48, 192) / SDH VC-4, VC-4-4c, VC-4- 646 16c, VC-4-64c 648 o SONET VT-N (N = 1.5, 2, 3, 6) / SDH VC-11, VC-12, VC-2 650 o SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3 652 Note: There is no requirement for the structure-agnostic transport of 653 SONET/SDH. It would seem that structure must be taken into account 654 for this case. 656 6. Generic Requirements 658 6.1 Relevant Common PW Requirements 660 The encapsulation and payload layers MUST conform to the common PW 661 requirements defined in [PWE3-REQ]: 663 1. Conveyance of Necessary Header Information: 665 A. For structure-agnostic transport, this functionality MAY be 666 provided by the payload layer. 668 B. For structure-aware transport, the necessary information MUST 669 be provided by the encapsulation layer. 671 C. Structure-aware transport of SONET/SDH circuits MUST preserve 672 path overhead information as part of the payload. Relevant 673 components of the transport overhead MAY be carried in the 674 encapsulation layer. 676 2. Support of Multiplexing and Demultiplexing if supported by the 677 native services. This is relevant for Nx DS0 circuits with or 678 without signaling and Nx VT-x in a single STS-1 SPE or VC-4.: 680 A. For these circuits the combination of encapsulation and 681 payload layers MUST provide for separate treatment of every 682 sub-circuit. 684 B. Enough information SHOULD be provided by the pseudo wire to 685 allow multiplexing and demultiplexing by the NSP. Reduction 686 of the complexity of the PW emulation by using NSP circuitry 687 for multiplexing and demultiplexing MAY be the preferred 688 solution. 690 3. Intervention or transparent transfer of Maintenance Messages of 691 the Native Services depending on the particular scenario. 693 4. Consideration of Per-PSN Packet Overhead (see also Section 7.5 694 below). 696 5. Detection and handling of PW faults. The list of faults is given 697 in Section 7.9 below. 699 Fragmentation indications MAY be used for structure-aware transport 700 when the structures in question either exceed desired packetization 701 delay or exceed Path MTU between the pair of PEs. 703 The following requirement listed in [PWE3-REQ] is not applicable to 704 emulation of TDM services: 706 o Support of variable length PDUs. 708 6.2 Common Circuit Payload Requirements 710 Structure-agnostic transport treats TDM circuits as belonging to the 711 'Bit-stream' payload type defined in [PWE3-ARCH]. 713 Structure-aware transport treats these circuits as belonging to the 714 "Structured bit-stream" payload type defined in [PWE3-ARCH]. 716 Accordingly, the encapsulation layer MUST provide the common 717 Sequencing service and SHOULD provide Timing information 718 (Synchronization services) when required (see Section 4.3 above). 720 Note: Length service MAY be provided by the encapsulation layer but 721 is not required. 723 6.3 General Design Issues 725 The combination of payload and encapsulation layers SHOULD comply 726 with the general design principles of the Internet protocols as 727 presented in [RFC1958], Section 3 and [PWE3-ARCH]. 729 If necessary, the payload layer MAY use some forms of adaptation of 730 the native TDM payload in order to achieve specific well-documented 731 design objectives. In these cases standard adaptation techniques 732 SHOULD be used. 734 7. Service-Specific Requirements 736 7.1 Connectivity 738 1. The emulation MUST support the transport of signals between 739 Attachment Circuits (ACs) of the same type (see Section 5) and, 740 wherever appropriate, bit-rate. 742 2. The encapsulation layer SHOULD remain unaffected by specific 743 characteristics of connection between the ACs and PE devices at 744 the two ends of the PW. 746 7.2 Network Synchronization 748 1. The encapsulation layer MUST provide synchronization services 749 that are sufficient to: 751 A. match the ingress and egress end service clocks regardless of 752 the specific network synchronization scenario, 754 B. keep the jitter and wander of the egress service clock within 755 the service-specific limits as defined by the appropriate 756 normative references. 758 2. If the same high-quality synchronization source is available to 759 all the PE devices in the given domain, the encapsulation layer 760 SHOULD be able to make use of it (e.g., for better reconstruction 761 of the native service clock). 763 7.3 Robustness 765 The robustness of the emulated service depends not only upon the 766 edge-to-edge-emulation protocol but also upon proper implementation 767 of the following procedures. 769 7.3.1 Packet loss 771 Edge-to-edge-emulation of TDM circuits MAY assume very low 772 probability of packet loss between ingress and egress PE. In 773 particular, no retransmission mechanisms are required. 775 In order to minimize effect of lost packets on the egress service, 776 the encapsulation layer SHOULD: 778 1. Enable independent interpretation of TDM data in each packet by 779 the egress PE (see [RFC2736]). This requirement MAY be 780 disregarded if the egress PE needs to interpret structures that 781 exceed the path MTU between the ingress and egress PEs. 783 2. Allow reliable detection of lost packets (see next section). In 784 particular, it SHOULD allow estimation of the arrival time of the 785 next packet and detection of lost packets based on this estimate. 787 3. Minimize possible effect of lost packets on recovery of the 788 circuit clock by the egress PE. 790 4. Increase the resilience of the CE TDM interface to packet loss by 791 allowing the egress PE to substitute appropriate data. 793 7.3.2 Out-of-order delivery 795 The encapsulation layer MUST provide the necessary mechanisms to 796 guarantee ordered delivery of packets carrying the TDM data over the 797 PSN. Packets that have arrived out-of-order: 799 1. MUST be detected, 801 2. SHOULD be reordered if not judged to be too late or too early for 802 playout. 804 Out-of-order packets that cannot be reordered MUST be treated as 805 lost. 807 7.4 CE Signaling 809 Unstructured TDM circuits would not usually require any special 810 mechanism for carrying CE signaling as this would be carried as part 811 of the emulated service. 813 Some CE applications using structured TDM circuits (e.g., telephony) 814 require specific signaling that conveys changes of state of these 815 applications relative to the TDM data. 817 The encapsulation layer SHOULD support signaling of state of CE 818 applications for the relevant circuits providing for: 820 1. Ability to support different signaling schemes with minimal 821 impact on encapsulation of TDM data, 823 2. Multiplexing of application-specific CE signals and data of the 824 emulated service in the same PW, 826 3. Synchronization (within the application-specific tolerance 827 limits) between CE signals and data at the PW egress, 829 4. Probabilistic recovery against possible occasional loss of 830 packets in the PSN, 832 5. Deterministic recovery of the CE application state after PW setup 833 and network outages. 835 CE signaling that is used for maintenance purposes (loopback 836 commands, performance monitoring data retrieval, etc.) SHOULD use 837 the generic PWE3 maintenance protocol. 839 7.5 PSN bandwidth utilization 841 1. The encapsulation layer SHOULD allow for an effective trade-off 842 between the following requirements: 844 A. Effective PSN bandwidth utilization. Assuming that the size 845 of encapsulation layer header does not depend on the size of 846 its payload, increase in the packet payload size results in 847 increased efficiency. 849 B. Low edge-to-edge latency. Low end-to-end latency is the 850 common requirement for Voice applications over TDM services. 851 Packetization latency is one of the components comprising 852 edge-to-edge latency and decreases with the packet payload 853 size. 855 The compensation buffer used by the CE-bound IWF increases 856 latency to the emulated circuit. Additional delay introduced by 857 this buffer SHOULD NOT exceed the packet delay variation observed 858 in the PSN. 860 2. The encapsulation layer MAY provide for saving PSN bandwidth by 861 not sending corrupted TDM data across the PSN. 863 3. The encapsulation layer MAY provide the ability to save the PSN 864 bandwidth for the structure-aware case by not sending channels 865 that are permanently inactive. 867 4. The encapsulation layer MAY enable the dynamic suppression of 868 temporarily unused channels from transmission for the structure- 869 aware case. 870 If used, dynamic suppression of temporarily unused channels 871 MUST NOT violate integrity of the structures delivered over the 872 PW. 874 5. For NxDS0 the encapsulation layer MUST provide the ability to 875 keep the edge-to-edge delay independent of the service rate. 877 7.6 Packet Delay Variation 879 The encapsulation layer SHOULD provide for ability to compensate for 880 packet delay variation while maintaining jitter and wander of the 881 egress end service clock with tolerances specified in the normative 882 references. 884 The encapsulation layer MAY provide for run-time adaptation of delay 885 introduced by the jitter buffer if the packet delay variation varies 886 with time. Such an adaptation MAY introduce a low level of errors 887 (within the limits tolerated by the application) but SHOULD NOT 888 introduce additional wander of the egress end service clock. 890 7.7 Compatibility with the Existing PSN Infrastructure 892 The combination of encapsulation and PSN tunnel layers used for edge- 893 to-edge emulation of TDM circuits SHOULD be compatible with existing 894 PSN infrastructures. In particular, compatibility with the 895 mechanisms of header compression over links where capacity is at a 896 premium SHOULD be provided. 898 7.8 Congestion Control 900 TDM circuits run at a constant rate, and hence offer constant traffic 901 loads to the PSN. The rate varying mechanism that TCP uses to match 902 demand to the network congestion state is therefore not applicable. 904 The ability to shut down a TDM PW when congestion has been detected 905 MUST be provided. 907 Precautions should be taken to avoid situations wherein multiple TDM 908 PWs are simultaneously shut down or re-established, thus leading to 909 PSN instability. 911 Further congestion considerations are discussed in chapter 6.5 of 912 [PWE3-ARCH]. 914 7.9 Fault Detection and Handling 916 The encapsulation layer for edge-to-edge emulation of TDM services 917 SHOULD, separately or in conjunction with the lower layers of the 918 PWE3 stack, provide for detection, handling and reporting of the 919 following defects: 921 1. Misconnection, or Stray Packets. The importance of this 922 requirement stems from customer expectation due to reliable 923 misconnection detection in SONET/SDH networks. 925 2. Packet Loss. Packet loss detection required in order to maintain 926 clock integrity, as discussed in Section 7.3.1 above. In 927 addition, packet loss detection mechanisms SHOULD provide for 928 localization of the outage in the end-to-end emulated service. 930 3. Malformed packets. 932 7.10 Performance Monitoring 934 The encapsulation layer for edge-to-edge emulation of TDM services 935 SHOULD provide for collection of performance monitoring (PM) data 936 that is compatible with the parameters defined for 'classic', TDM- 937 based carriers of these services. The applicability of [G.826] is 938 left for further study. 940 8. Security Considerations 942 The security considerations in [PWE3-REQ] are fully applicable to the 943 emulation of TDM services. In addition TDM services are sensitive to 944 packet delay variation [Section 7.6], and need to be protected from 945 this as a method of attack. 947 9. References 949 [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation 950 Edge-to- Edge (PWE3), RFC3916, IETF, 2004 952 [PWE3-ARCH] Stewart Bryant et al, Pseudo Wire Emulation Edge-to-Edge 953 (PWE3) Architecture, RFC3985, March 2005 955 [G.702] ITU-T Recommendation G.702 (11/88) - Digital hierarchy bit 956 rates 958 [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame 959 structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s 960 hierarchical levels 962 [G.706] ITU-T Recommendation G.706 (04/91) - Frame alignment and 963 cyclic redundancy check (CRC) procedures relating to basic frame 964 structures defined in Recommendation G.704 966 [G.707] ITU-T Recommendation G.707 (10/00) - Network node interface 967 for the synchronous digital hierarchy (SDH) 969 [G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex 970 equipments operating at the third order bit rate of 34 368 Kbit/s and 971 the fourth order bit rate of 139 264 Kbit/s and using positive 972 justification 974 [G.810] ITU-T Recommendation G.810 (08/96) - Definitions and 975 terminology for synchronization networks 977 [G.826] ITU-T Recommendation G.826 (02/99) - Error performance 978 parameters and objectives for international, constant bit rate 979 digital paths at or above the primary rate 981 [Q.700] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT 982 Signalling System No. 7 984 [Q.931] ITU-T Recommendation Q.931 (05/98) - ISDN user-network 985 interface layer 3 specification for basic call control 987 [RFC1958] B. Carpenter (ed.), Architectural Principles of the 988 Internet, RFC 1958, IETF, 1996 990 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement 991 Levels, RFC 2119, IETF, 1997 993 [RFC2736] M. Handley, C. Perkins, Guidelines for Writers of RTP 994 Payload Format Specifications, RFC 2736, IETF, 1999 996 [RFC3393] C. Demichelis, P. Chimento, IP Packet Delay Variation 997 Metric for IPPM, RFC 3393, IETF, 2002 999 [T1.105] ANSI T1.105 - 2001 Synchronous Optical Network (SONET) - 1000 Basic Description including Multiplex Structure, Rates, and Formats, 1001 May 2001 1003 [T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format 1004 Specification 1006 [TR-NWT-170] Digital Cross Connect Systems - Generic Requirements and 1007 Objectives, Bellcore, TR-NWT-170, January 1993 1009 Author's Address 1011 Maximilian Riegel 1012 Siemens AG 1013 St-Martin-Str 76 1014 Munich 81541 1015 Germany 1017 Phone: +49-89-636-75194 1018 Email: maximilian.riegel@siemens.com 1020 Intellectual Property Statement 1022 The IETF takes no position regarding the validity or scope of any 1023 Intellectual Property Rights or other rights that might be claimed to 1024 pertain to the implementation or use of the technology described in 1025 this document or the extent to which any license under such rights 1026 might or might not be available; nor does it represent that it has 1027 made any independent effort to identify any such rights. Information 1028 on the procedures with respect to rights in RFC documents can be 1029 found in BCP 78 and BCP 79. 1031 Copies of IPR disclosures made to the IETF Secretariat and any 1032 assurances of licenses to be made available, or the result of an 1033 attempt made to obtain a general license or permission for the use of 1034 such proprietary rights by implementers or users of this 1035 specification can be obtained from the IETF on-line IPR repository at 1036 http://www.ietf.org/ipr. 1038 The IETF invites any interested party to bring to its attention any 1039 copyrights, patents or patent applications, or other proprietary 1040 rights that may cover technology that may be required to implement 1041 this standard. Please address the information to the IETF at 1042 ietf-ipr@ietf.org. 1044 The IETF has been notified of intellectual property rights claimed in 1045 regard to some or all of the specification contained in this 1046 document. For more information consult the online list of claimed 1047 rights. 1049 Disclaimer of Validity 1051 This document and the information contained herein are provided on an 1052 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1053 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1054 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1055 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1056 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1057 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1059 Copyright Statement 1061 Copyright (C) The Internet Society (2005). This document is subject 1062 to the rights, licenses and restrictions contained in BCP 78, and 1063 except as set forth therein, the authors retain all their rights. 1065 Acknowledgment 1067 Funding for the RFC Editor function is currently provided by the 1068 Internet Society.