idnits 2.17.00 (12 Aug 2021) /tmp/idnits32159/draft-malis-pwe3-sonet-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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. ** The abstract seems to contain references ([3]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 801 has weird spacing: '...vals if neces...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: As discussed in section 5, a CEP de-packetizer MAY or MAY NOT support re-ordering of mis-ordered packets. -- 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 (November 2001) is 7492 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: '481' is mentioned on line 586, but not defined -- Looks like a reference, but probably isn't: '485v2' on line 593 -- Looks like a reference, but probably isn't: 'GR-253' on line 819 == Outdated reference: draft-ietf-pwe3-requirements has been published as RFC 3916 ** Downref: Normative reference to an Informational draft: draft-ietf-pwe3-requirements (ref. '3') == Outdated reference: A later version (-03) exists of draft-pate-pwe3-framework-01 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: draft-malis-sonet-ces-mpls has been published as RFC 5143 ** Downref: Normative reference to an Historic draft: draft-malis-sonet-ces-mpls (ref. '7') == Outdated reference: A later version (-02) exists of draft-danenberg-pw-cem-mib-01 -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' Summary: 6 errors (**), 0 flaws (~~), 9 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PWE3 Working Group Andrew G. Malis 3 Internet Draft Ken Hsu 4 Expiration Date: May 2002 Vivace Networks, Inc. 6 Tom Johnson Jeremy Brayley 7 Marlene Drost Steve Vogelsang 8 Ed Hallman John Shirron 9 Litchfield Communications, Inc. Laurel Networks, Inc. 11 Jim Boyle Luca Martini 12 Protocol Driven Networks, Inc. Craig White 13 Level 3 Communications, LLC. 14 Ron Cohen 15 Lycium Networks David Zelig 16 Corrigent Systems, LTD. 17 Prayson Pate 18 Overture Networks, Inc. 20 November 2001 22 SONET/SDH Circuit Emulation over Packet (CEP) 23 draft-malis-pwe3-sonet-01.txt 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of section 10 of RFC 2026 [1]. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Abstract 48 Generic requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3) have 49 been described in [3]. This draft lists SONET specific requirements 50 and provides encapsulation formats and semantics for connecting SONET 51 edge networks through a core packet network using IP, L2TP or MPLS. 52 This basic application of SONET interworking will allow SONET service 53 providers to take advantage of new technologies in the core in order to 54 provide SONET services. 56 Table of Contents 58 1 Conventions used in this document...........................2 59 2 Introduction................................................2 60 3 Scope.......................................................3 61 4 CEP Encapsulation Format....................................4 62 5 CEP Operation...............................................9 63 6 SONET/SDH Maintenance Signals..............................12 64 7 SONET/SDH Transport Timing.................................16 65 8 SONET/SDH Pointer Management...............................17 66 9 CEP Performance Monitors...................................18 67 10 Open Issues................................................20 68 11 Security Considerations....................................20 69 12 Intellectual Property Disclaimer...........................20 70 13 References.................................................22 71 14 Acknowledgments............................................23 72 15 Author's Addresses.........................................23 74 1 Conventions used in this document 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC 2119 [2]. 80 2 Introduction 82 This document describes a protocol that performs SONET Emulation 83 over a variety of Packet-Switched Networks (PSNs) as part of the 84 PWE3 Working Group. The document assumes that the reader is 85 familiar with the PWE3 terminology and concepts described in PWE3 86 requirements and framework documents [3] and [4]. The protocol is 87 titled "Circuit Emulation over Packet" (CEP). 89 The transmission system for circuit-oriented TDM signals is the 90 Synchronous Optical Network (SONET) [5], [9] / Synchronous Digital 91 Hierarchy (SDH) [6]. To support TDM traffic (which includes voice, 92 data, and private leased line services) PSNs must emulate the 93 circuit characteristics of SONET/SDH payloads. A circuit identifer 94 and a CEP header are used to encapsulate the SONET/SDH TDM signals 95 for transmission over an arbitrary PSN. 97 This document also describes an optional extension to CEP called 98 Dynamic Bandwidth Allocation (DBA). This is a method for 99 dynamically reducing the bandwidth utilized by emulated SONET/SDH 100 circuits in the packet network. This bandwidth reduction is 101 accomplished by not sending the SONET/SDH payload through the packet 102 network under certain conditions such as AIS-P or STS SPE 103 Unequipped. 105 This document is based on a previous document describing a method 106 for encapsulating SONET signals for carriage over MPLS networks 107 (CEM) [7]. This document is closely related to [8] which describes 108 a MIB for controlling and observing CEP services. 110 3 Scope 112 This document describes how to provide CEP for the following digital 113 signals: 115 1. SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 117 2. STS-Nc SPE (N = 3, 12, 48, or 192)/SDH VC-4, VC-4-4c, VC-4-16c, 118 or VC-4-64c 120 For the remainder of this document, these constructs will be 121 referred to as SONET/SDH channels. 123 Although this document currently covers up to OC-192c/VC-4-64c, 124 future revision MAY address higher rates. 126 Other SONET/SDH signals, such as virtual tributary (VT) structured 127 sub-rate mapping, are not explicitly discussed in this document; 128 however, it can be extended in the future to support VT and lower 129 speed non-SONET/SDH services. 131 4 CEP Encapsulation Format 133 In order to transport SONET/SDH SPEs through a packet-oriented 134 network, the SPE is broken into fragments. A Circuit ID Word and 135 CEP Header are pre-pended to each fragment. The basic CEP packet 136 appears in Figure 1. 138 +-----------------------------------+ 139 | Circuit ID Word | 140 +-----------------------------------+ 141 | CEP Header | 142 +-----------------------------------+ 143 | | 144 | | 145 | SONET/SDH SPE Fragment | 146 | | 147 | | 148 +-----------------------------------+ 150 Figure 1. Basic CEP Packet 152 The Circuit ID Word is a 32-bit field that contains an arbitrary 153 value that is used to map CEP packets to specific SONET/SDH 154 channels. The circuit ID word is intentionally designed to match 155 the format of an MPLS shim. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Circuit ID | Exp |S| TTL | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 2. CEP Circuit ID Word 165 Circuit ID: Matches the Label Position in an MPLS shim. It SHOULD 166 be used to map individual packet streams to SONET channels. 168 Exp: Experimental Use, 3 bits. SHOULD conform to use of Exp bits 169 within an MPLS shim. 171 S: Bottom of Stack, 1 bit. SHOULD be set to 1 to indicate the 172 bottom of an MPLS label stack. 174 TTL: Time to Live, 8 bits. SHOULD be utilized in a manner 175 consistent with the TTL field of an MPLS Shim. 177 The CEP Header supports a basic and extended mode. The Basic CEP 178 Header provides the minimum functionality necessary to accurately 179 emulate a TDM SONET over a PSN. Bit 0 of the first 32-bit CEP 180 header indicates whether or not the extended header is present. 181 When this bit is 0, then no extended header is present. When this 182 bit is 1, then an extended header is present. At this time, the 183 contents of the extended header are for future study. However, it 184 is expected that this field will provide support for payload 185 compression, header protection, enhanced performance monitoring, 186 and/or other extensions to the base protocol. 188 The Basic CEP header has the following format: 190 0 1 2 3 191 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 2 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 3. Basic CEP Header Format 198 The Extended CEP header appears below: 200 0 1 2 3 201 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 2 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |1|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Reserved | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 4. Extended CEP Header Format 210 The above fields are defined as follows: 212 R bit: CEP-RDI. This bit is set to one to signal to the remote CEP 213 function that a loss of packet synchronization has occurred. See 214 section 5.4 for details. 216 D bit: Signals DBA Mode. MUST be set to zero for Normal Operation. 217 MUST be set to one if CEP is currently in DBA mode. DBA is an 218 optional mode during which trivial SPEs are not transmitted into the 219 packet network. See Table 1 and section 5 for further details. 221 The N and P bits: MAY be used to explicitly relay negative and 222 positive pointer adjustment events across the PSN. They are also 223 used to relay SONET/SDH maintenance signals such as AIS-P. See 224 Table 1 and sections 6 and 8 for more details. 226 +---+---+---+----------------------------------------------+ 227 | D | N | P | Interpretation | 228 +---+---+---+----------------------------------------------+ 229 | 0 | 0 | 0 | Normal Mode - No Ptr Adjustment | 230 | 0 | 0 | 1 | Normal Mode - Positive Ptr Adjustment | 231 | 0 | 1 | 0 | Normal Mode - Negative Ptr Adjustment | 232 | 0 | 1 | 1 | Normal Mode - AIS-P | 233 | | | | | 234 | 1 | 0 | 0 | DBA Mode - STS SPE Unequipped | 235 | 1 | 0 | 1 | DBA Mode - STS SPE Unequipped Pos Ptr Adj | 236 | 1 | 1 | 0 | DBA Mode - STS SPE Unequipped Neg Ptr Adj | 237 | 1 | 1 | 1 | DBA Mode - AIS-P | 238 +---+---+---+----------------------------------------------+ 240 Table 1. Interpretation of D, N, and P bits 242 Sequence Number[0:13]: This is a packet sequence number, which MUST 243 continuously cycle from 0 to 0x3FFF. It SHOULD begin at zero when a 244 CEP channel is created. 246 Structure Pointer[0:12]: The Structure Pointer MUST contain the 247 offset of the J1 byte within the CEP SPE Fragment. The value is 248 from 0 to 0x1FFE, where 0 means the first byte after the CEP header. 249 The Structure Pointer MUST be set to 0x1FFF if a packet does not 250 carry the J1 byte. See [5], [6] and [9] for more information on the 251 J1 byte and the SONET/SDH payload pointer. Implementations MUST 252 support SPE Fragments of up to 1023 bytes and MAY support SPE 253 fragments of up to 8191 bytes. 255 Note: CEP packets are fixed in length for all of the packets of a 256 particular emulated TDM stream. This length is statically 257 provisioned for each TDM stream. Therefore, the length of each CEP 258 packet does not need to be carried in the CEP header. 260 4.1 PSN Encapsulation 262 In principle, CEP packets can be carried over any packet-oriented 263 network. The following sections describe specifically how CEP 264 packets MUST be encapsulated for carriage over MPLS or IP networks. 266 4.1.1 MPLS Encapsulation 268 To transport a CEP packet over an MPLS network, an MPLS label-stack 269 MUST be pushed on top of the CEP packet. 271 +-----------------------------------+ 272 | MPLS Label Stack | 273 +-----------------------------------+ 274 | Circuit ID Word | 275 +-----------------------------------+ 276 | CEP Header | 277 +-----------------------------------+ 278 | | 279 | | 280 | SONET/SDH SPE Fragment | 281 | | 282 | | 283 +-----------------------------------+ 285 Figure 5. Typical MPLS Transport Encapsulation 287 4.1.2 IP Encapsulation 289 It is highly desirable to define a single encapsulation format that 290 will work for both IP and MPLS. Furthermore, it is desirable that 291 the encapsulation mechanism be as efficient as possible. 293 One way to achieve these goals is to map CEP directly onto IP. 294 Because the Circuit ID Word is essentially an MPLS Shim, the CEP 295 packet may be treated as an MPLS packet. A mechanism for carrying 296 MPLS over IP is described in [10]. 298 Using this encapsulation scheme would result in the packet format 299 illustrated in figure 6. 301 +-----------------------------------+ 302 | | 303 | IPv6/v4 Header [10] | 304 | | 305 +-----------------------------------+ 306 | Circuit ID Word | 307 +-----------------------------------+ 308 | CEP Header | 309 +-----------------------------------+ 310 | | 311 | | 312 | SONET/SDH SPE Fragment | 313 | | 314 | | 315 +-----------------------------------+ 317 Figure 6. MPLS Transport Encapsulation 319 4.1.3 L2TP Encapsulation 321 Encapsulation for L2TP PSNs is for future study. 323 5 CEP Operation 325 The following sections describe CEP operation. 327 5.1 Introduction and Terminology 329 CEP MUST support a normal mode of operation and MAY support an 330 optional extension called Dynamic Bandwidth Allocation (DBA). 331 During normal operation, SONET/SDH payloads are fragmented, pre- 332 pended with the CEP Header, the Circuit ID Word, and the PSN header, 333 and then transmitted into the packet network. During DBA mode, only 334 the CEP header, the Circuit ID Word, and PSN header are transmitted. 335 This is done to conserve bandwidth when meaningful user data is not 336 present in the SPE, such as during AIS-P or STS SPE Unequipped. 338 5.1.1 CEP Packetizer and De-Packetizer 340 As with all adaptation functions, CEP has two distinct components: 341 adapting TDM SONET/SDH into a CEP packet stream, and converting the 342 CEP packet stream back into a TDM SONET/SDH. The first function 343 will be referred to as CEP Packetizer and the second as CEP De- 344 Packetizer. This terminology is illustrated in figure 7. 346 +------------+ +---------------+ 347 | | | | 348 SONET --> | CEP | --> PSN --> | CEP | --> SONET 349 SDH | Packetizer | | De-Packetizer | SDH 350 | | | | 351 +------------+ +---------------+ 353 Figure 7. CEP Terminology 355 Note: the CEP de-packetizer requires a buffering mechanism to 356 account for delay variation in the CEP packet stream. This 357 buffering mechanism will be generically referred to as the CEP 358 jitter buffer. 360 5.1.2 CEP DBA 362 DBA is an optional mode of operation that only transmits the CEP 363 Header, the Circuit ID Word, and PSN Header into the packet network 364 under certain circumstances such as AIS-P or STS Unequipped. 366 If DBA is supported by a CEP implementation, the user SHOULD be able 367 to configure if DBA will be triggered by AIS-P, STS Unequipped, 368 both, or neither on a per channel basis. 370 If DBA is supported, the determination of AIS-P and STS Unequipped 371 MUST be based on the state of SONET/SDH Section, Line, and Path 372 Overhead bytes. 374 During AIS-P, there is no valid payload pointer, so pointer 375 adjustments cannot occur. During STS Unequipped, the SONET/SDH 376 payload pointer is valid, and therefore pointer adjustments MUST be 377 supported even during DBA. See Table 1 for details. 379 5.2 Description of Normal CEP Operation 381 During normal operation, the CEP packetizer will receive a fixed 382 rate byte stream from a SONET/SDH interface. When a packets worth 383 of data has been received from a SONET/SDH channel, the CEP Header, 384 the Circuit ID Word, and PSN Header are pre-pended to the SPE 385 fragment and the resulting CEP packet is transmitted into the packet 386 network. Because all CEP packets associated with a specific 387 SONET/SDH channel will have the same length, the transmission of CEP 388 packets for that channel SHOULD occur at regular intervals. 390 At the far end of the packet network, the CEP de-packetizer will 391 receive packets into a jitter buffer and then play out the received 392 byte stream at a fixed rate onto the corresponding SONET/SDH 393 channel. The jitter buffer SHOULD be adjustable in length to 394 account for varying network delay behavior. The receive packet rate 395 from the packet network should be exactly balanced by the 396 transmission rate onto the SONET/SDH channel, on average. The time 397 over which this average is taken corresponds to the depth of the 398 jitter buffer for a specific CEP channel. 400 The CEP sequence numbers provide a mechanism to detect lost and/or 401 mis-ordered packets. The CEP de-packetizer MUST detect lost or mis- 402 ordered packets. The CEP de-packetizer SHOULD play out an all ones 403 pattern (AIS) in place of any dropped packets. The CEP de- 404 packetizer MAY re-order packets received out of order. If the CEP 405 de-packetizer does not support re-ordering, it must drop mis-ordered 406 packets. 408 5.3 Description of CEP Operation during DBA 410 There are several issues that should be addressed by a workable CEP 411 DBA mechanism. First, when DBA is invoked, there should be a 412 substantial savings in bandwidth utilization in the packet network. 413 The second issue is that the transition in and out of DBA should be 414 tightly coordinated between the local CEP packetizer and CEP de- 415 packetizer at the far side of the packet network. A third is that 416 the transition in and out of DBA should be accomplished with minimal 417 disruption to the adapted data stream. 419 Another goal is that the reduction of CEP traffic due to DBA should 420 not be mistaken for a fault in the packet network or vice-versa. 421 Finally, the implementation of DBA should require minimal 422 modifications beyond what is necessary for the nominal CEP case. 423 The mechanism described below is a reasonable balance of these 424 goals. 426 During DBA, packets MUST be emitted at exactly the same rate as they 427 would be during normal operation. This SHOULD be accomplished by 428 transmitting each DBA packet after a complete packet of data has 429 been received from the SONET/SDH channel. The only change from 430 normal operation is that the CEP packets during DBA MUST only carry 431 the CEP header, the Circuit ID Word, and the PSN Header. Because 432 some links have a minimum supported packet size, the CEP packetizer 433 MAY append a configurable number of bytes immediately after the CEP 434 header to pad out the CEP packet to reach the mimumum supported 435 packet size. The D-bit MUST be set to one, to indicate that DBA is 436 active. 438 The CEP de-packetizer MUST assume that each packet received with the 439 D-bit set represents a normal-sized packet containing an AIS-P or 440 SPE Unequipped payload as noted by N and P. See Table 1. The CEP 441 de-packetizer MUST accept DBA packets with or without padding. 443 This allows the CEP packetization and de-packetization logic during 444 DBA to be similar to the nominal case. It ensures that the correct 445 SONET/SDH indication is reliably transmitted between CEP adaptation 446 points. It minimizes the risk of under or over running the jitter 447 buffer during the transition in and out of DBA, since packets are 448 continuously transmitted during DBA. And, it guarantees that faults 449 in the packet network are recognized as distinctly different from 450 line conditioning on the SONET/SDH interfaces. 452 5.4 Packet Synchronization 454 A key component in declaring the state of a CEP service is whether 455 or not the CEP de-packetizer is in or out of packet synchronization. 456 The following paragraphs describe how that determination is made. 458 As discussed in section 5, a CEP de-packetizer MAY or MAY NOT 459 support re-ordering of mis-ordered packets. 461 As packets are received from the PSN, they are placed into a jitter 462 buffer prior to play out on the SONET interface. If a CEP de- 463 packetizer supports re-ordering, any packet received before it's 464 play out time will still be considered valid. 466 If a CEP de-packetizer does not support re-ordering, a number of 467 approaches may be used to minimize the impact of mis-ordered or lost 468 packets on the final re-assembled SONET stream. For example, AAL1 469 [11] uses a simple state-machine to re-order packets in a sub-set of 470 possible cases. The algorithm for these state-machines is outside 471 of the scope of CEP. 473 However, the final determination as to whether or not to declare 474 acquisition or loss of packet synchronization MUST be based on the 475 same criteria regardless of whether an implementation supports or 476 does not support re-ordering. 478 Therefore, the determination of acquisition or loss of packet 479 synchronization is always made at SONET play-out time. During SONET 480 play-out, the CEP de-packetizer will play received CEP packets onto 481 the SONET interface. However, if the jitter buffer is empty or the 482 packet to be played out has not been received, the CEP de-packetizer 483 will have to play out an empty packet onto the SONET interface in 484 place of the unavailable packet. 486 The acquisition of packet synch is based on the number of sequential 487 CEP packets that are played onto the SONET interface. While, loss 488 of packet synch is based on the number of sequential 'empty' packets 489 that are played onto the SONET interface. Specific details of these 490 two cases is described below. 492 5.4.1 Acquisition of Packet Synchronization 494 At startup, a CEP de-packetizer will be out of packet 495 synchronization by default. To declare packet synchronization at 496 startup or after a loss of packet synchronization, the CEP de- 497 packetizer must play-out a configurable number of CEP packets with 498 sequential sequence numbers towards the SONET interface. 500 5.4.2 Loss of Packet Synchronization 502 Once a CEP de-packetizer is in packet sync, it may encounter a set 503 of events that will cause it to lose packet synchronization. 505 If the CEP de-packetizer encounters more than a configurable number 506 of sequentialempty packets, the CEP de-packetizer MUST declare loss 507 of packet synchronization. 509 6 SONET/SDH Maintenance Signals 511 There are several issues that must be considered in the mapping of 512 maintenance signals between SONET/SDH and a PSN. A description of 513 how these signals and conditions are mapped between the two domains 514 is described below. 516 For clarity, the mappings are split into two groups: SONET/SDH to 517 PSN, and PSN to SONET/SDH. 519 6.1 SONET/SDH to PSN 520 The following sections describe how SONET/SDH Maintenance Signals 521 and Alarm conditions are mapped into a Packet Switched Network. 523 6.1.1 AIS-P Indication 525 In a SONET/SDH network, SONET Path outages are signaled using 526 maintenance alarms such as Path AIS (AIS-P). In particular, AIS-P 527 indicates that the SONET/SDH Path is not currently transmitting 528 valid end-user data, and the SPE contains all ones. 530 It should be noted that nearly every type of service-effecting 531 section or line defect will result in an AIS-P condition. 533 The SONET/SDH hierarchy is illustrated below. 535 +----------+ 536 | PATH | 537 +----------+ 538 ^ 539 | 540 AIS-P 541 | 542 | 543 +----------+ 544 | LINE | 545 + ---------+ 546 ^ ^ 547 | | 548 AIS-L +------ LOP 549 | 550 | 551 +----------+ 552 | SECTION | 553 +----------+ 554 ^ ^ 555 | | 556 | | 557 LOS LOF 559 Figure 8. SONET/SDH Fault Hierarchy. 561 Should the Section Layer detect a Loss of Signal (LOS) or Loss of 562 Frame (LOF) condition, it sends AIS-L up to the Line Layer. If the 563 Line Layer detects AIS-L or Loss of Path (LOP), it sends AIS-P to 564 the Path Layer. 566 In normal mode during AIS-P, CEP packets are generated as usual. 567 The N and P bits MUST be set to 11 binary to signal AIS-P explicitly 568 through the packet network. The D-bit MUST be set to zero to 569 indicate that the SPE is being carried through the packet network. 570 Normal CEP packets with the SPE fragment, CEP Header, the Circuit ID 571 Word, and PSN Header MUST be transmitted into the packet network. 573 However, to conserve network bandwidth during AIS-P, DBA MAY be 574 employed. If DBA has been enabled for AIS-P and AIS-P is currently 575 occurring, the N and P bits MUST be set to 11 binary to signal AIS, 576 and the D-bit MUST be set to one to indicate that the SPE is not 577 being carried through the packet network. Only the CEP header, the 578 Circuit ID Word, and the PSN Header MUST be transmitted into the 579 packet network. 581 6.1.2 STS SPE Unequipped Indication 583 The declaration of STS SPE unequipped MUST conform to [9]. Quoted 584 below: 586 "R6-135 [481] STS PTE shall detect an STS Path Unequipped (UNEQ-P) 587 defect within 10 ms of the onset of at least five consecutive 588 samples (which may or may not be consecutive frames) of unequipped 589 STS Signal Labels (C2 byte), as specified in Table 6-2" 591 The termination of STS SPE unequipped MUST also conform to [9]. 593 "R6-137 [485v2] STS PTE shall terminate an UNEQ-P defect within 10 594 ms of the onset of at least five consecutive samples (which may or 595 may not be consecutive frames) of STS Signal Labels that are not 596 unequipped or all-ons, as specified in Table 6-2" 598 For normal operation during SPE Unequipped, the N and P bits MUST be 599 interpreted as usual. The SPE MUST be transmitted into the packet 600 network along with the CEP Header, the Circuit ID Word, and PSN 601 Header, and the D-Bit MUST be set to zero. 603 If DBA has been enabled for STS SPE Unequipped and the Unequipped is 604 occurring on the SONET/SDH channel, the D-bit MUST be set to one to 605 indicate DBA is active. Only the CEP Header, the Circuit ID Word, 606 and PSN Header MUST be transmitted into the packet network. The N 607 and P bits MAY be used to signal pointer adjustments as normal. See 608 Table 1 and section 5 for details. 610 6.1.3 CEP-RDI 612 The CEP function MUST send CEP-RDI towards the packet network during 613 loss of packet synchronization. This MUST be accomplished by 614 setting the R bit to one in the CEP header. 616 6.2 PSN to SONET/SDH 618 The following sections discuss how the various conditions on the 619 packet network are converted into SONET/SDH indications. 621 6.2.1 AIS-P Indication 622 There are several conditions in the packet network that will cause 623 the CEP de-packetization function to play out an AIS-P indication 624 towards a SONET/SDH channel. 626 The first of these is the receipt of CEP packets with the N and P 627 bits set to one, and the D-bit set to zero. This is an explicit 628 indication of AIS-P being received at the far-end of the packet 629 network, with DBA disabled for AIS-P. The CEP de-packetizer MUST 630 play out the received SPE fragment (which will incidentally be 631 carrying all ones), and MUST configure the SONET/SDH Overhead to 632 signal AIS-P as defined in [5], [6], and [9]. 634 The second case is the receipt of CEP packets with the N and P bits 635 set to one, and the D-bit set to one. This indicates that AIS-P is 636 being received at the far-end of the packet network, with DBA 637 enabled for AIS-P. The CEP de-packetizer MUST play out one packet's 638 worth of all ones for each packet received, and MUST configure the 639 SONET/SDH Overhead to signal AIS-P as defined in [5], [6], and [9]. 641 A third case that will cause a CEP de-packetization function to play 642 out an AIS-P indication onto a SONET/SDH channel is during loss of 643 packet synchronization. The CEP de-packetizer MUST configure the 644 SONET/SDH Overhead to signal AIS-P as defined in [5], [6], and [9]. 646 6.2.2 STS SPE Unequipped Indication 648 There are three conditions in the packet network that will cause the 649 CEP function to transmit STS SPE Unequipped indications onto the 650 SONET/SDH channel. 652 The first, which is transparent to CEP, is the receipt of regular 653 CEP packets that happen to be carrying an SPE that contains the 654 appropriate Path overhead to signal STS SPE unequipped. This case 655 does not require any special processing on the part of the CEP de- 656 packetizer. 658 The second case is the receipt of CEP packets that have the D-bit 659 set to one to indicate DBA active and the N and P bits set to 00 660 binary, 01 binary, or 10 binary to indicate SPE Unequipped with or 661 without pointer adjustments. The CEP de-packetizer MUST use this 662 information to transmit a packet of all zeros onto the SONET/SDH 663 interface, and adjust the payload pointer as necessary. 665 The third case when a CEP de-packetizer MUST play out an STS SPE 666 Unequipped Indication towards the SONET interface is when the VC- 667 label has been withdrawn due to de-provisioning of the circuit. 669 7 SONET/SDH Transport Timing 671 It is assumed that the distribution of SONET/SDH Transport timing 672 information is addressed through external mechanisms such as 673 Building Integrated Timing System (BITS), Global Positioning System 674 (GPS) or other such methods and is therefore outside of the scope of 675 this specification. 677 8 SONET/SDH Pointer Management 679 A pointer management system is defined as part of the definition of 680 SONET/SDH. Details on SONET/SDH pointer management can be found in 681 [5], [6], and [9]. If there is a frequency offset between the frame 682 rate of the transport overhead and that of the SONET/SDH SPE, then 683 the alignment of the SPE shall periodically slip back or advance in 684 time through positive or negative stuffing. 686 The emulation of this aspect of SONET networks may be accomplished 687 using a variety of techniques including (but not limited to) 688 explicit pointer adjustment relay (EPAR) and adaptive pointer 689 management (APM). 691 In any case, the handling of the SPE data by the CEP packetizer is 692 the same. 694 During a negative pointer adjustment event, the CEP packetizer MUST 695 incorporate the H3 byte from the SONET/SDH stream into the CEP 696 packet payload in order with the rest of the SPE. During a positive 697 pointer adjustment event, the CEP de-packetizer MUST strip the stuff 698 byte from the CEP packet payload. 700 When playing out a negative pointer adjustment event, the 701 appropriate byte of the CEP payload MUST be placed into the H3 byte 702 of the SONET/SDH stream. When playing out a positive pointer 703 adjustment, the CEP de-packetizer MUST insert a stuff-byte into the 704 appropriate position within the SONET/SDH stream. 706 The details regarding the use of the H3 byte and stuff byte during 707 positive and negative pointer adjustments can be found in [5], [6], 708 and [9]. 710 8.1 Explicit Pointer Adjustment Relay (EPAR) 712 CEP provides an OPTIONAL mechanism to explicitly relay pointer 713 adjustment events from one side of the PSN to the other. This 714 technique will be referred to as Explicit Pointer Adjustment Relay 715 (EPAR). The mechanics of EPAR are described below. 717 The following text only applies to implementations that choose to 718 implement EPAR. Any CEP implementation that does not support EPAR 719 MUST either set the N and P bits to zero or utilize them to relay 720 AIS-P and STS Unequipped as shown in table 1. 722 If EPAR is being used, the pointer adjustment event MUST be 723 transmitted in three consecutive packets by the packetizer. The de- 724 packetizer MUST play out the pointer adjustment event when any one 725 packet with N/P bit set is received. 727 References [5],[6],and [9] specify that pointer adjustment events 728 MUST be separated by three SONET/SDH frames without a pointer 729 adjustment event. In order to explicitly relay all legal pointer 730 adjustment events, the packet size for a specific circuit SHOULD be 731 no larger than (783 * 4 * N)/3, where N is the STS-Nc multiplier. 733 However, there are many SONET implementations which will allow 734 pointer adjustments to occur in back to back SONET/SDH frames. In 735 order to support this possibility, EPAR implementations SHOULD set 736 the packet size for a particular circuit to be no larger than 737 (783*N)/3. Where N is the STS-Nc multiplier. 739 Since the minimum value of N is one, EPAR implementations SHOULD 740 support a minimum payload length of 783/3 or 261 bytes. 742 For EPAR implementations, the CEP de-packetizer MUST utilize the CEP 743 sequence numbers to insure that SONET/SDH pointer adjustment events 744 are not played any more frequently than once per every three CEP 745 packets transmitted by the remote CEP packetizer. 747 If both bits are set, then an AIS-P event has occurred (this is 748 further discussed in section 6). 750 When DBA is invoked (i.e. the D-bit = 1), N and P have additional 751 meanings. See Table 1 and section 5. 753 8.2 Adaptive Pointer Management (APM) 755 Another OPTIONAL method that may be used to emulate SONET pointer 756 management is Adaptive Pointer Management (APM). In basic terms, 757 APM uses information about the depth of the CEP jitter buffers to 758 introduce pointer adjustments in the reassembled SONET SPE. 760 Details about specific APM algorithms is for future study. 762 9 CEP Performance Monitors 764 SONET/SDH as defined in [5], [6], and [9], includes the definition 765 of several counters that may be used to monitor the performance of 766 SONET/SDH services. These counters are referred to as Performance 767 Monitors. 769 In order for CEP to be utilized by traditional SONET/SDH network 770 operators, CEP SHOULD provide similar functionality. To this end, 771 the following sections describe a number of counters that will 772 collectively be referred to as CEP Performance Monitors. 774 9.1 Near-End Performance Monitors 776 These performance monitors are maintained by the CEP De-Packetizer 777 during reassembly of the SONET stream. 779 The performance monitors are based on two types of defects. 781 Type 1 defect is defined as: missing or dropped packet. 782 Type 2 defect is defined as: buffer under run, buffer over-run, 783 LOPS. 785 Each second that contain at least one type 1 defect SHALL be 786 declared as ES-CEP. 788 Each second that contain type 2 defect, or missing packets above 789 pre-defined, configurable threshold of missing/dropped packets SHALL 790 be declared both SES-CEP and ES-CEP. Default value for missing 791 packet to SES is 3. 793 UAS-CES shall be declared after X consecutives SES-CEP, cleared 794 after X consecutive seconds without SES-CEP. Default value of X is 795 10 seconds. 797 Once unavailability is declared, ES and SES counts shall be 798 inhibited up to the point where the unavailability was started. Once 799 unavailability is removed, ES that occurred along the X seconds 800 clearing period shall be added to the ES counts. An update is 801 required even for closed intervals if necessary. 803 LOPS failure is declared after 2.5 +/- 0.5 seconds of LOPS defect, 804 and cleared after 10 seconds free of LOPS defect state. The VC is 805 considered down as long as LOPS failure is declared. 807 FC-CEP is the number of time type 1 or type 2 defect states were 808 declared. The NE shall have thresholding on ES-CEP, SES-CEP and 809 UAS-CEP (thresholding mean activate a notification if more than pre- 810 defined # of seconds are declared as ES, etc. in 15 minutes 811 interval). 813 9.2 Far-End Performance Monitors 815 These performance monitors provide insight into the CEM De- 816 packetizer at the far-end of the PSN. 818 Far end statistics are based on the RDI-CEP bit. Limited 819 functionality is supported compared to [GR-253] for simplicity and 820 because it is assumed that all relevant statistics are available 821 from the end point of the PW. CEP-FE defect is declared when CEP-RDI 822 is set in the incoming CEP packets. 824 CEP-FE failure declared after 2.5 +/- 0.5 seconds of CEP-FE defect, 825 and cleared after 10 seconds free of CES-FE defect state. Sending 826 notification to the OS for CEP-FE failure is local policy. 828 This draft does not attempt to define SES-CEPFE, UAS-CEPFE and FC- 829 CEPFE, but they can be added if to fully emulate GR-253 far end PM 830 (thresholding is required too here except for FC-CEPFE). (Note that 831 ES-CEPFE is not relevant since CEP does not report back missing 832 packets - only LOPS which is SES). 834 The definition of additional performance monitors is for future 835 study. 837 10 Open Issues 839 This version of the draft does not address payload compression 840 within the emulated SONET. Payload compression is expected to be 841 supported by future versions of this draft by utilizing the extended 842 CEP header. 844 This version of the draft does not tie into PWE3 maintenance 845 mechanisms for the setup and tear down of services. That short- 846 coming will be addressed in future revisions of this document. 848 Underlying MPLS QoS requirements are not covered by this revision of 849 the draft. Future revisions may discuss underlying QoS 850 requirements. 852 Support for VT and lower speed non-SONET/SDH services are not 853 covered in this revision of the draft. Future revisions may address 854 VT and non-SONET/SDH TDM services. 856 An alternate version of DBA has been suggested that would suppress 857 transmission of the entire CEP packet stream under certain 858 circumstances. Future versions of this draft may define such a 859 mechanism. 861 11 Security Considerations 863 This document does not address or modify security issues within the 864 relevant PSNs. 866 12 Intellectual Property Disclaimer 867 This document is being submitted for use in IETF standards 868 discussions. Vivace Networks, Inc. has filed one or more patent 869 applications relating to the CEP technology outlined in this 870 document. Vivace Networks, Inc. will grant free unlimited licenses 871 for use of this technology. 873 13 References 875 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 876 BCP 9, RFC 2026, October 1996. 878 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 879 Levels", BCP 14, RFC 2119, May 1997 881 [3] Xiao et al, " Requirements for Pseudo-Wire Emulation Edge-to- 882 Edge (PWE3)", draft-ietf-pwe3-requirements-01.txt, work in 883 progress, July 2001 885 [4] Pate et al, "Framework for Pseudo Wire Emulation Edge-to-Edge 886 (PWE3)", draft-pate-pwe3-framework-01.txt, work in progress, 887 July 13, 2001 889 [5] American National Standards Institute, "Synchronous Optical 890 Network (SONET) - Basic Description including Multiplex 891 Structure, Rates and Formats," ANSI T1.105-1995. 893 [6] ITU Recommendation G.707, "Network Node Interface For The 894 Synchronous Digital Hierarchy", 1996. 896 [7] Malis et al, "SONET/SDH Circuit Emulation Service Over MPLS 897 (CEM) Encapsulation", draft-malis-sonet-ces-mpls-05.txt, work 898 in progress, July 2001. 900 [8] Danenberg et al, "SONET/SDH Circuit Emulation Service Over PSN 901 (CEP) Management Information Base Using SMIv2", draft- 902 danenberg-pw-cem-mib-01.txt, work in progress, July 2001. 904 [9] Telcordia Technologies, "Synchronous Optical Network (SONET) 905 Transport Systems: Common Generic Criteria", GR-253-CORE, Issue 906 3, November 2000. 908 [10] Worster, "MPLS Label Stack Encapsulation in IP", draft- 909 worster-mpls-in-ip-05, work in progress, July 2001. 911 [11] ITU-T, "Recommendation I.363.1, B-ISDN Adaptation Layer 912 Specification: Type AAL1", Appendix III, August 1996. 914 14 Acknowledgments 916 The authors would like to thank all the members of the PWE3 WG who 917 have contributed to this effort. 919 15 Author's Addresses 921 Andrew G. Malis 922 Vivace Networks, Inc. 923 2730 Orchard Parkway 924 San Jose, CA 95134 925 Email: Andy.Malis@vivacenetworks.com 927 Ken Hsu 928 Vivace Networks, Inc. 929 2730 Orchard Parkway 930 San Jose, CA 95134 931 Email: Ken.Hsu@vivacenetworks.com 933 Jeremy Brayley 934 Laurel Networks, Inc. 935 2706 Nicholson Rd. 936 Sewickley, PA 15143 937 Email: jbrayley@laurelnetworks.com 939 Steve Vogelsang 940 Laurel Networks, Inc. 941 2706 Nicholson Rd. 942 Sewickley, PA 15143 943 Email: sjv@laurelnetworks.com 945 John Shirron 946 Laurel Networks, Inc. 947 2607 Nicholson Rd. 948 Sewickley, PA 15143 949 Email: jshirron@laurelnetworks.com 951 Luca Martini 952 Level 3 Communications, LLC. 953 1025 Eldorado Blvd. 954 Broomfield, CO 80021 955 Email: luca@level3.net 957 Tom Johnson 958 Litchfield Communications, Inc. 959 76 Westbury Park Rd. 960 Watertown, CT 06795 961 Email: tom_johnson@litchfieldcomm.com 962 Ed Hallman 963 Litchfield Communications, Inc. 964 76 Westbury Park Rd. 965 Watertown, CT 06795 966 Email: ed_hallman@litchfieldcomm.com 968 Marlene Drost 969 Litchfield Communications, Inc. 970 76 Westbury Park Rd. 971 Watertown, CT 06795 972 Email: marlene_drost@litchfieldcomm.com 974 Jim Boyle 975 Protocol Driven Networks, Inc. 976 1381 Kildaire Farm #288 977 Cary, NC 27511 978 Email: jboyle@pdnets.com 980 David Zelig 981 Corrigent Systems LTD. 982 126, Yigal Alon st. 983 Tel Aviv, ISRAEL 984 Email: davidz@corrigent.com 986 Ron Cohen 987 Lycium Networks 988 Hamanofim 9, POB 12256 989 Herzeliya, Israel 46733 990 Email: ronc@lyciumnetworks.com 992 Prayson Pate 993 Overture Networks 994 P. O. Box 14864 995 RTP, NC, USA 27709 996 Email: prayson.pate@overturenetworks.com 998 Craig White 999 Level3 Communications, LLC. 1000 1025 Eldorado Blvd, 1001 Broomfield CO 80021 1002 Email: Craig.White@Level3.com 1003 Appendix A. SONET/SDH Rates and Formats 1005 For simplicity, the discussion in this section uses SONET 1006 terminology, but it applies equally to SDH as well. SDH-equivalent 1007 terminology is shown in the tables. 1009 The basic SONET modular signal is the synchronous transport signal- 1010 level 1 (STS-1). A number of STS-1s may be multiplexed into higher- 1011 level signals denoted as STS-N, with N synchronous payload envelopes 1012 (SPEs). The optical counterpart of the STS-N is the Optical Carrier- 1013 level N, or OC-N. Table 2 lists standard SONET line rates discussed 1014 in this document. 1016 OC Level OC-1 OC-3 OC-12 OC-48 OC-192 1017 SDH Term - STM-1 STM-4 STM-16 STM-64 1018 Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280 1020 Table 2. Standard SONET Line Rates 1022 Each SONET frame is 125 us and consists of nine rows. An STS-N frame 1023 has nine rows and N*90 columns. Of the N*90 columns, the first N*3 1024 columns are transport overhead and the other N*87 columns are SPEs. 1025 A number of STS-1s may also be linked together to form a super-rate 1026 signal with only one SPE. The optical super-rate signal is denoted 1027 as OC-Nc, which has a higher payload capacity than OC-N. 1029 The first 9-byte column of each SPE is the path overhead (POH) and 1030 the remaining columns form the payload capacity with fixed stuff 1031 (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 1032 columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed 1033 stuff, STS-12c has three columns of fixed stuff, and so on. 1035 The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The 1036 payload capacity of an STS-1 is 86 columns (774 bytes) per frame. 1037 The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. 1038 Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 1039 bytes per frame. As another example, the payload capacity of an STS- 1040 192c is 149,760 bytes, which is 64 times the capacity of an STS-3c. 1042 There are 8,000 SONET frames per second. Therefore, the SPE size, 1043 (POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 1044 Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame 1045 or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760 1046 bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 2 1047 lists the SPE and payload rates supported. 1049 SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c 1050 SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c 1051 Payload Size(Bytes) 774 2,340 9,360 37,440 149,760 1052 Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640 1053 SPE Size(Bytes) 783 2,349 9,396 37,584 150,336 1054 SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504 1056 Table 2. Payload Size and Rate 1058 To support circuit emulation, the entire SPE of a SONET STS or SDH 1059 VC level is encapsulated into packets, using the encapsulation 1060 defined in section 4, for carriage across packet-switched networks. 1062 Full Copyright Statement 1064 Copyright (C) The Internet Society (2001). All Rights Reserved. This 1065 document and translations of it may be copied and furnished to 1066 others, and derivative works that comment on or otherwise explain it 1067 or assist in its implementation may be prepared, copied, published 1068 and distributed, in whole or in part, without restriction of any 1069 kind, provided that the above copyright notice and this paragraph 1070 are included on all such copies and derivative works. However, this 1071 document itself may not be modified in any way, such as by removing 1072 the copyright notice or references to the Internet Society or other 1073 Internet organizations, except as needed for the purpose of 1074 developing Internet standards in which case the procedures for 1075 copyrights defined in the Internet Standards process must be 1076 followed, or as required to translate it into languages other than 1077 English. 1079 The limited permissions granted above are perpetual and will not be 1080 revoked by the Internet Society or its successors or assigns. 1082 This document and the information contained herein is provided on an 1083 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1084 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1085 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1086 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1087 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1089 Acknowledgement 1091 Funding for the RFC Editor function is currently provided by the 1092 Internet Society.