idnits 2.17.1 draft-malis-sonet-ces-mpls-09.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 25. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1011. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1022. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1029. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1035. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC4842]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 6.2, a CEM 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 (August 16, 2007) is 6069 days in the past. Is this intentional? Checking references for intended status: Historic ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 985 ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Andrew G. Malis 3 INTERNET-DRAFT Verizon Communications 4 Expiration Date: February 16, 2008 5 Category: Historic Jeremy Brayley 6 John Shirron 7 ECI Telecom Inc. 9 Luca Martini 10 Cisco Systems 12 Steve Vogelsang 13 Alcatel-Lucent 15 August 16, 2007 17 SONET/SDH Circuit Emulation Service over MPLS (CEM) Encapsulation 18 draft-malis-sonet-ces-mpls-09.txt 20 Status of this Memo 22 By submitting this Internet-Draft, each author represents that any 23 applicable patent or other IPR claims of which he or she is aware 24 have been or will be disclosed, and any of which he or she becomes 25 aware will be disclosed, in accordance with Section 6 of BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on December 6, 2007. 45 Copyright Notice 47 Copyright (C) The IETF Trust (2007). 49 Abstract 51 This document describes a historical method for encapsulating 52 SONET/SDH Path signals for transport across packet-switched networks 53 (PSNs). The PSNs explicitly supported by this document include MPLS 54 and IP. Note that [RFC4842] describes the standards-track protocol 55 for this functionality, and new implementations must use [RFC4842] 56 rather than this document except when interoperability with older 57 implementations is desired. 59 1. Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in [RFC2119]. 65 2. Introduction 67 This document describes a historical method for encapsulating 68 SONET/SDH Path signals for transport across packet-switched networks 69 (PSNs). 71 The transmission system for circuit-oriented TDM signals is the 72 Synchronous Optical Network (SONET) [T1.105], [GR-253]/Synchronous 73 Digital Hierarchy (SDH) [G.707]. To support TDM traffic (which 74 includes voice, data, and private leased line services) PSNs must 75 emulate the circuit characteristics of SONET/SDH payloads. MPLS 76 labels and a new circuit emulation header are used to encapsulate 77 TDM signals and provide the Circuit Emulation Service over MPLS (CEM) 78 function. The MPLS encapsulation may be further encapsulated in IP 79 for carriage across IP PSNs [RFC4023]. 81 This document also describes an optional extension to CEM called 82 Dynamic Bandwidth Allocation (DBA). This is a method for 83 dynamically reducing the bandwidth utilized by emulated SONET/SDH 84 circuits in the packet network. This bandwidth reduction is 85 accomplished by not sending the SONET/SDH payload through the packet 86 network under certain conditions such as AIS-P or STS SPE 87 Unequipped. 89 3. Scope 91 This document describes how to provide CEM for the following digital 92 signals: 94 1. SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 96 2. STS-Nc SPE (N = 3, 12, or 48)/SDH VC-4, VC-4-4c, VC-4-16c 97 3. Unstructured SONET Emulation, where the entire SONET bit-stream 98 (including the transport overhead) is packetized and transported 99 across the PSN. 101 For the remainder of this document, these constructs will be 102 referred to as SONET/SDH channels. 104 Other SONET/SDH signals, such as virtual tributary (VT) structured 105 sub-rate mapping, are not explicitly discussed in this document; 106 however, it can be extended in the future to support VT and lower 107 speed non-SONET/SDH services. OC-192c SPE/VC-4-64c are also not 108 included at this point, since most PSNs use OC-192c or slower 109 trunks, and thus would not have sufficient capacity. As trunk 110 capacities increase in the future, the scope of this document can be 111 accordingly extended. 113 4. CEM Encapsulation Format 115 In order to transport SONET/SDH SPEs through a packet-oriented 116 network, the SPE is broken into fragments. A 32-bit CEM Header is 117 pre-pended to each fragment. The Basic CEM packet appears in Figure 118 1. 120 +-----------------------------------+ 121 | CEM Header | 122 +-----------------------------------+ 123 | | 124 | | 125 | SONET/SDH SPE Fragment | 126 | | 127 | | 128 +-----------------------------------+ 130 Figure 1. Basic CEM Packet 132 The 32-bit CEM header has the following format: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 |D|R|Rvd| Sequence Num | Structure Pointer |N|P| ECC-6 | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 Figure 2. CEM Header Format 142 The above fields are defined as follows: 144 D bit: Signals DBA Mode. MUST be set to zero for Normal Operation. 145 MUST be set to one if CEM is currently in DBA mode. DBA is an 146 optional mode during which trivial SPEs are not transmitted into the 147 packet network. See Table 1 and sections 7 and 8 for further 148 details. Note: for unstructured CEM, the D-bit MUST be set to zero. 150 R bit: CEM-RDI. This bit is set to one to signal to the remote CEM 151 function that a loss of packet synchronization has occurred. 153 Rvd: These bits are reserved for future use, and MUST be set to 154 zero. 156 Sequence Number: This is a packet sequence number, which MUST 157 continuously cycle from 0 to 1023. It SHOULD begin at zero when a 158 CEM LSP is created. 160 Structure Pointer: The Structure Pointer MUST contain the offset of 161 the J1 byte within the CEM payload. The value is from 0 to 1,022, 162 where 0 means the first byte after the CEM header. The Structure 163 Pointer MUST be set to 0x3FF (1,023) if a packet does not carry the 164 J1 byte. See [T1.105], [G.707], and [GR-253] for more information 165 On the J1 byte and the SONET/SDH payload pointer. Note: for 166 unstructured CEM, the Structure Pointer field MUST be set to 0x3FF. 168 The N and P bits: Indicate negative and positive pointer adjustment 169 events. They are also used to relay SONET/SDH maintenance signals 170 such as AIS-P. See Table 1 and sections 7 and 8 for more details. 171 Note: for unstructured CEM, the N and P bits MUST both be set to 0. 173 +---+---+---+----------------------------------------------+ 174 | D | N | P | Interpretation | 175 +---+---+---+-------------+--------------------------------+ 176 | 0 | 0 | 0 | Normal Mode | No Ptr Adjustment | 177 | 0 | 0 | 1 | Normal Mode | Positive Ptr Adjustment | 178 | 0 | 1 | 0 | Normal Mode | Negative Ptr Adjustment | 179 | 0 | 1 | 1 | Normal Mode | AIS-P | 180 | | | | | | 181 | 1 | 0 | 0 | DBA Mode | STS SPE Unequipped | 182 | 1 | 0 | 1 | DBA Mode | STS SPE Unequipped Pos Ptr Adj | 183 | 1 | 1 | 0 | DBA Mode | STS SPE Unequipped Neg Ptr Adj | 184 | 1 | 1 | 1 | DBA Mode | AIS-P | 185 +---+---+---+-------------+--------------------------------+ 187 Table 1. Interpretation of D, N, and P bits 189 ECC-6: An Error Correction Code to protect the CEM header. This 190 offers the ability to correct single bit errors and detect up to two 191 bit errors. The ECC algorithm is described in Appendix B. The ECC- 192 6 can be optionally disabled at provisioning time. If the ECC-6 is 193 not utilized it MUST be set to zero. 195 Note: Normal CEM packets are fixed in length for all of the packets 196 of a particular emulated TDM stream. This length is signaled using 197 the CEM Payload Bytes parameter defined in [RFC4447], or is 198 statically provisioned for each TDM stream. Therefore, the length 199 of each CEM packet does not need to be carried in the CEM header. 201 Note: Setting the D bit to 0 and the R bit to 1 violates the Best 202 Current Practice defined in [RFC4928] when operating on MPLS networks. 203 In this situation, MPLS networks could mistake a CEM payload as the 204 first nibble of an IPv4 packet, potentially causing misordering of 205 packets on the pseudowire in the presence of IP ECMP in the MPLS 206 network. The use of this CEM header preceded the use of MPLS ECMP. 207 As stated earlier, [RFC4842] describes the standards-track protocol 208 for this functionality, and it does not share this violation. 210 4.1 Transport Encapsulation 212 In principle, CEM packets can be transported over any packet- 213 oriented network. The following sections describe specifically how 214 CEM packets MUST be encapsulated for transport over MPLS or IP 215 networks. 217 4.1.1 MPLS Transport 219 To transport a CEM packet over an MPLS network, an MPLS label-stack 220 MUST be pushed on top of the CEM packet. 222 The last two labels prior to the CEM header are referred to as the 223 Tunnel and Virtual Circuit (VC) labels. 225 The VC label is required, and is the last label prior to the CEM 226 Header. The VC label MUST be used to identify the CEM connection 227 within the MPLS tunnel. 229 The optional tunnel label is immediately above the VC label on the 230 label stack. If present, the tunnel label MUST be used to identify 231 the MPLS LSP used to tunnel the TDM packets through the MPLS network 232 (the tunnel LSP). 234 This is similar to the label stack usage defined in [RFC4447]. 236 +-----------------------------------+ 237 | Additional MPLS Labels (Optional) | 238 +-----------------------------------+ 239 | Tunnel Label (Optional) | 240 +-----------------------------------+ 241 | VC Label | 242 +-----------------------------------+ 243 | CEM Header | 244 +-----------------------------------+ 245 | | 246 | | 247 | SONET/SDH SPE Fragment | 248 | | 249 | | 250 +-----------------------------------+ 252 Figure 3. Typical MPLS Transport Encapsulation 254 4.1.2 IP Transport 256 It is highly desirable to define a single encapsulation format that 257 will work for both IP and MPLS. Furthermore, it is desirable that 258 the encapsulation mechanism be as efficient as possible. 260 One way to achieve these goals is to map CEM directly onto IP by 261 mapping the previously described MPLS packets onto IP. 263 A mechanism for carrying MPLS over IP is described in [RFC4023]. 265 Using this encapsulation scheme would result in the packet format 266 illustrated in figure 4. 268 +-----------------------------------+ 269 | | 270 | IPv6/v4 Header [RFC4023] | 271 | | 272 +-----------------------------------+ 273 | Tunnel Label (Optional) | 274 +-----------------------------------+ 275 | VC Label | 276 +-----------------------------------+ 277 | CEM Header | 278 +-----------------------------------+ 279 | | 280 | | 281 | SONET/SDH SPE Fragment | 282 | | 283 | | 284 +-----------------------------------+ 286 Figure 4. MPLS Transport Encapsulation 288 5. CEM Operation 290 The following sections describe CEM operation. 292 5.1 Introduction and Terminology 294 There are two types of CEM: structured and unstructured. 296 Unstructured CEM packetizes the entire SONET/SDH bit-stream 297 (including transport overhead). 299 Structured CEM terminates the transport overhead and packetizes 300 individual channels (STS-1/Nc) within the SONET/SDH frame. Because 301 structured CEM terminates the transport overhead, structured CEM 302 implementations SHOULD meet the generic requirements for SONET/SDH 303 Line Terminating Equipment as defined in [T1.105], [G.707], and 304 [GR-253]. 306 Implementations MUST support structured CEM and MAY support 307 unstructured CEM. 309 Structured CEM MUST support a normal mode of operation and MAY 310 support an optional extension called Dynamic Bandwidth Allocation 311 (DBA). During normal operation, SONET/SDH payloads are fragmented, 312 pre-pended with the CEM Header, the VC label, and the PSN header, 313 and then transmitted into the packet network. During DBA mode, only 314 the CEM header, the VC label, and PSN header are transmitted. This 315 is done to conserve bandwidth when meaningful user data is not 316 present in the SPE, such as during AIS-P or STS SPE Unequipped. 318 5.1.1 CEM Packetizer and De-Packetizer 320 As with all adaptation functions, CEM has two distinct components: 321 adapting TDM SONET/SDH into a CEM packet stream, and converting the 322 CEM packet stream back into a TDM SONET/SDH. The first function 323 will be referred to as CEM Packetizer and the second as CEM De- 324 Packetizer. This terminology is illustrated in figure 5. 326 +------------+ +---------------+ 327 | | | | 328 SONET --> | CEM | --> PSN --> | CEM | --> SONET 329 SDH | Packetizer | | De-Packetizer | SDH 330 | | | | 331 +------------+ +---------------+ 333 Figure 5. CEM Terminology 335 Note: the CEM de-packetizer requires a buffering mechanism to 336 account for delay variation in the CEM packet stream. This 337 buffering mechanism will be generically referred to as the CEM 338 jitter buffer. 340 5.1.2 CEM DBA 342 DBA is an optional mode of operation for structured CEM that only 343 transmits the CEM Header, the VC label, and PSN Header into the 344 packet network under certain circumstances such as AIS-P or STS 345 Unequipped. 347 If DBA is supported by a CEM implementation, the user SHOULD be able 348 to configure if DBA will be triggered by AIS-P, STS Unequipped, 349 both, or neither on a per channel basis. 351 If DBA is supported, the determination of AIS-P and STS Unequipped 352 MUST be based on the state of SONET/SDH Section, Line, and Path 353 Overhead bytes. DBA based on pattern detection within the SPE (i.e. 354 all zeros, 7Es, or ATM idle cells) is for further study. 356 During AIS-P, there is no valid payload pointer, so pointer 357 adjustments cannot occur. During STS Unequipped, the SONET/SDH 358 payload pointer is valid, and therefore pointer adjustments MUST be 359 supported even during DBA. See Table 1 for details. 361 5.2 Description of Normal CEM Operation 363 During normal operation, the CEM packetizer will receive a fixed 364 rate byte stream from a SONET/SDH interface. When a packet's worth 365 of data has been received from a SONET/SDH channel, the CEM Header, 366 the VC Label, and PSN Header are pre-pended to the SPE fragment and 367 the resulting CEM packet is transmitted into the packet network. 368 Because all normal CEM packets associated with a specific SONET/SDH 369 channel will have the same length, the transmission of CEM packets 370 for that channel SHOULD occur at regular intervals. 372 At the far end of the packet network, the CEM de-packetizer will 373 receive packets into a jitter buffer and then play out the received 374 byte stream at a fixed rate onto the corresponding SONET/SDH 375 channel. The jitter buffer SHOULD be adjustable in length to 376 account for varying network delay behavior. The receive packet rate 377 from the packet network should be exactly balanced by the 378 transmission rate onto the SONET/SDH channel, on average. The time 379 over which this average is taken corresponds to the depth of the 380 jitter buffer for a specific CEM channel. 382 The CEM sequence numbers provide a mechanism to detect lost and/or 383 mis-ordered packets. The CEM de-packetizer MUST detect lost or mis- 384 ordered packets. The CEM de-packetizer MUST play out a programmable 385 byte pattern in place of any dropped packets. The CEM de-packetizer 386 MAY re-order packets received out of order. If the CEM de- 387 packetizer does not support re-ordering, it MUST drop mis-ordered 388 packets. 390 5.3 Description of CEM Operation during DBA 392 (Note: DBA is only applicable to structured CEM.) 394 There are several issues that should be addressed by a workable CEM 395 DBA mechanism. First, when DBA is invoked, there should be a 396 substantial savings in bandwidth utilization in the packet network. 397 The second issue is that the transition in and out of DBA should be 398 tightly coordinated between the local CEM packetizer and CEM de- 399 packetizer at the far side of the packet network. A third is that 400 the transition in and out of DBA should be accomplished with minimal 401 disruption to the adapted data stream. 403 Another goal is that the reduction of CEM traffic due to DBA should 404 not be mistaken for a fault in the packet network or vice-versa. 405 Finally, the implementation of DBA should require minimal 406 modifications beyond what is necessary for the nominal CEM case. 407 The mechanism described below is a reasonable balance of these 408 goals. 410 During DBA, packets MUST be emitted at exactly the same rate as they 411 would be during normal operation. This SHOULD be accomplished by 412 transmitting each DBA packet after a complete packet of data has 413 been received from the SONET/SDH channel. The only change from 414 normal operation is that the CEM packets during DBA MUST only carry 415 the CEM header, the VC Label, and the PSN Header. 417 Because some links have a minimum supported packet size, the CEM 418 packetizer MAY append a configurable number of bytes immediately 419 after the CEM-header to pad out the CEM packet to reach the minimum 420 supported packet size. The value of the padding bytes is 421 implementation specific. The D-bit MUST be set to one, to indicate 422 that DBA is active. 424 The CEM de-packetizer MUST assume that each packet received with the 425 D-bit set represents a normal-sized packet containing an AIS-P or 426 SPE Unequipped payload as noted by N and P. See Table 1. The CEM 427 de-packetizer MUST accept DBA packets with or without padding. 429 This allows the CEM packetization and de-packetization logic during 430 DBA to be similar to the nominal case. It insures that the correct 431 SONET/SDH indication is reliably transmitted between CEM adaptation 432 points. It minimizes the risk of under or over running the jitter 433 buffer during the transition in and out of DBA. And, it guarantees 434 that faults in the packet network are recognized as distinctly 435 different from line conditioning on the SONET/SDH interfaces. 437 5.4 Packet Synchronization 439 A key component in declaring the state of a CEM service is whether 440 or not the CEM de-packetizer is in or out of packet synchronization. 441 The following paragraphs describe how that determination is made. 443 5.4.1 Acquisition of Packet Synchronization 445 At startup, a CEM de-packetizer will be out of packet 446 synchronization by default. To declare packet synchronization at 447 startup or after a loss of packet synchronization, the CEM de- 448 packetizer must receive a configurable number of CEM packets with 449 sequential sequence numbers. 451 5.4.2 Loss of Packet Synchronization 453 Once a CEM de-packetizer is in packet sync, it may encounter a set 454 of events that will cause it to lose packet synchronization. 456 As discussed in section 6.2, a CEM de-packetizer MAY or MAY NOT 457 support re-ordering of mis-ordered packets. 459 If a CEM de-packetizer supports re-ordering, then the determination 460 that packet synchronization has been lost cannot be made at the time 461 the packets are received from the PSN. Instead, the determination 462 MUST be made as the packets are being played out onto the SONET/SDH 463 interface. This is because it is only at play-out time that the 464 determination can be made as to whether the entire emulated 465 SONET/SDH stream was received from the PSN. 467 If a CEM de-packetizer does not support re-ordering, a number of 468 approaches may be used to minimize the impact of mis-ordered or lost 469 packets on the final re-assembled SONET/SDH stream. For example, 470 AAL1 [I.363.1] uses a simple state-machine to re-order packets in a 471 subset of possible cases. The algorithm for these state-machines is 472 outside of the scope of CEM. However, the final determination as to 473 whether or not to declare loss of packet synchronization MUST be 474 based on the same criteria as for implementations that do support 475 re-ordering. 477 Whether or not a CEM implementation supports re-ordering, the 478 declaration of loss of packet synchronization MUST be based on the 479 following criteria. 481 As packets are played out towards the SONET/SDH interface, the CEM 482 de-packetizer will encounter empty packets in the place of packets 483 that were dropped by the PSN, or effectively dropped due to 484 limitations of the CEM implementation. If the CEM de-packetizer 485 encounters more than a configurable number of sequential dropped 486 packets, the CEM de-packetizer MUST declare loss of packet 487 synchronization. 489 6. SONET/SDH Maintenance Signals 491 There are several issues that must be considered in the mapping of 492 maintenance signals between SONET/SDH and a PSN. A description of 493 how these signals and conditions are mapped between the two domains 494 is described below. 496 For clarity, the mappings are split into two groups: SONET/SDH to 497 PSN, and PSN to SONET/SDH. 499 6.1 SONET/SDH to PSN 501 The following sections describe how SONET/SDH Maintenance Signals 502 and Alarm conditions are mapped into a Packet Switched Network. 504 6.1.1 AIS-P Indication 506 In a SONET/SDH network, SONET/SDH Path outages are signaled using 507 maintenance alarms such as Path AIS (AIS-P). In particular, AIS-P 508 indicates that the SONET/SDH Path is not currently transmitting 509 valid end-user data, and the SPE contains all ones. 511 It should be noted that for structured CEM nearly every type of 512 service-effecting section or line defect will result in an AIS-P 513 condition. 515 The SONET/SDH hierarchy is illustrated below. 517 +----------+ 518 | PATH | 519 +----------+ 520 ^ 521 | 522 AIS-P 523 | 524 | 525 +----------+ 526 | LINE | 527 + ---------+ 528 ^ ^ 529 | | 530 AIS-L +------ LOP 531 | 532 | 533 +----------+ 534 | SECTION | 535 +----------+ 536 ^ ^ 537 | | 538 | | 539 LOS LOF 541 Figure 6. SONET/SDH Fault Hierarchy. 543 Should the Section Layer detect a Loss of Signal (LOS) or Loss of 544 Frame (LOF) condition, it sends AIS-L up to the Line Layer. If the 545 Line Layer detects AIS-L or Loss of Path (LOP), it sends AIS-P to 546 the Path Layer. 548 In normal mode during AIS-P, structured CEM packets are generated as 549 usual. The N and P bits MUST be set to 11 binary to signal AIS-P 550 explicitly through the packet network. The D-bit MUST be set to 551 zero to indicate that the SPE is being carried through the packet 552 network. Normal CEM packets with the SPE fragment, CEM Header, the 553 VC Label, and PSN Header MUST be transmitted into the packet 554 network. 556 However, to conserve network bandwidth during AIS-P, DBA MAY be 557 employed. If DBA has been enabled for AIS-P and AIS-P is currently 558 occurring, the N and P bits MUST be set to 11 binary to signal AIS, 559 and the D-bit MUST be set to one to indicate that the SPE is not 560 being carried through the packet network. Only the CEM header, the 561 VC Label, and the PSN Header MUST be transmitted into the packet 562 network. 564 Also note that this differs from the outage mechanism in [RFC4447], 565 which withdraws the VC label as a result of an endpoint outage. TDM 566 circuit emulation requires the ability to distinguish between the 567 de-provisioning of a circuit (which causes the VC label to be 568 withdrawn), and temporary outages (which are signaled using AIS-P). 570 6.1.2 STS SPE Unequipped Indication 572 The STS SPE Unequipped Indication is a slightly different case than 573 AIS-P. When byte C2 of the Path Overhead (STS path signal label) is 574 00h and Byte B3 (STS Path BIP-8) is valid, it indicates that the SPE 575 is unequipped. Note: this is typically signaled by setting the 576 entire SPE to zeros. 578 For normal structured CEM operation during SPE Unequipped, the N and 579 P bits MUST be interpreted as usual. The SPE MUST be transmitted 580 into the packet network along with the CEM Header, the VC Label, and 581 PSN Header, and the D-Bit MUST be set to zero. 583 If DBA has been enabled for STS SPE Unequipped and the Unequipped 584 condition is occurring on the SONET/SDH channel, the D-bit MUST be 585 set to one to indicate DBA is active. Only the CEM Header, the VC 586 Label, and PSN Header MUST be transmitted into the packet network. 587 The N and P bits MUST be used to signal pointer adjustments as 588 normal. See Table 1 and section 8 for details. 590 6.1.3 CEM-RDI 592 The CEM function MUST send CEM-RDI towards the packet network during 593 loss of packet synchronization. This MUST be accomplished by 594 setting the R bit to one in the CEM header. This applies for both 595 structured and unstructured CEM. 597 6.2 PSN to SONET/SDH 599 The following sections discuss how the various conditions on the 600 packet network are converted into SONET/SDH indications. 602 6.2.1 AIS-P Indication 604 There are several conditions in the packet network that will cause 605 the structured CEM de-packetization function to send an AIS-P 606 indication onto a SONET/SDH channel. 608 The first of these is the receipt of structured CEM packets with the 609 N and P bits set to one, and the D-bit set to zero. This is an 610 explicit indication of AIS-P being received at the far-end of the 611 packet network, with DBA disabled for AIS-P. The CEM de-packetizer 612 MUST play out the received SPE fragment (which will incidentally be 613 carrying all ones), and MUST configure the SONET/SDH Overhead to 614 signal AIS-P as defined in [T1.105], [G.707], and [GR-253]. 616 The second case is the receipt of structured CEM packets with the N 617 and P bits set to one, and the D-bit set to one. This is an 618 explicit indication of AIS-P being received at the far-end of the 619 packet network, with DBA enabled for AIS-P. The CEM de-packetizer 620 MUST play out one packet's worth of all ones for each packet 621 received, and MUST configure the SONET/SDH Overhead to signal AIS-P 622 as defined in [T1.105], [G.707], and [GR-253]. 624 A third case that will cause a structured CEM de-packetization 625 function to send an AIS-P indication onto a SONET/SDH channel is 626 loss of packet synchronization. 628 6.2.2 STS SPE Unequipped Indication 630 There are three conditions in the packet network that will cause the 631 CEM function to transmit STS SPE Unequipped indications onto the 632 SONET/SDH channel. 634 The first, which is transparent to CEM, is the receipt of regular 635 CEM packets that happen to be carrying an SPE that contains the 636 appropriate Path overhead to signal STS SPE unequipped. This case 637 does not require any special processing on the part of the CEM de- 638 packetizer. 640 The second case is the receipt of structured CEM packets that have 641 the D-bit set to one to indicate DBA active and the N and P bits set 642 to 00 binary, 01 binary, or 10 binary to indicate SPE Unequipped 643 with or without pointer adjustments. The CEM de-packetizer MUST use 644 this information to transmit a packet of all zeros onto the 645 SONET/SDH interface, and adjust the payload pointer as necessary. 647 The third case when a structured CEM de-packetizer MUST send an STS 648 SPE Unequipped Indication towards the SONET/SDH interface is when 649 the VC-label has been withdrawn due to de-provisioning of the 650 circuit. 652 7. Clocking Modes 654 It is necessary to be able to regenerate the input service clock at 655 the output interface. Two clocking modes are supported: synchronous 656 and asynchronous. Selection of the clocking mode is made as part of 657 service provisioning. Both ends of the emulated circuit must be 658 configured with the same clocking mode. 660 7.1 Synchronous 662 When synchronous SONET/SDH timing is available at both ends of the 663 circuit, the issue of clock recovery becomes much simpler. 665 7.1.1 Synchronous Unstructured CEM 667 For unstructured CEM, the external clock is used to clock each bit 668 onto the optical carrier. 670 7.1.2 Synchronous Structured CEM 672 For structured CEM, the external clock is used to clock the 673 SONET/SDH carrier. The N and P bits are used to signal negative or 674 positive pointer justification events between structured CEM end- 675 points. 677 If there is a frequency offset between the frame rate of the 678 transport overhead and that of the SONET/SDH SPE, then the alignment 679 of the SPE shall periodically slip back or advance in time through 680 positive or negative stuffing. The N and P bits are used to replay 681 the pointer adjustment events and eliminate transport jitter. 683 During a negative pointer adjustment event, the H3 byte from the 684 SONET/SDH stream is incorporated into the CEM packet payload in 685 order with the rest of the SPE. During a positive pointer 686 adjustment event, the stuff byte is not included in the CEM packet 687 payload. 689 The pointer adjustment event MUST be transmitted in three 690 consecutive packets by the packetizer. The de-packetizer MUST play 691 out the pointer adjustment event when the first packet of the three 692 with N/P bit set is received. 694 The CEM de-packetizer MUST utilize the CEM sequence numbers to 695 insure that SONET/SDH pointer adjustment events are not played any 696 more frequently than once per every three CEM packets transmitted by 697 the remote CEM packetizer. 699 References [T1.105], [G.707],and [GR-253] specify that pointer 700 adjustment events MUST be separated by three SONET/SDH frames 701 without a pointer adjustment event. In order to relay all legal 702 pointer adjustment events, the packet size for a specific circuit 703 MUST be no larger than (783 * 4 * N)/3, where N is the STS-Nc 704 multiplier. 706 However, some SONET/SDH equipment allows pointer adjustments to 707 occur in back to back SONET/SDH frames. In order to support this 708 possibility, the packet size for a particular circuit SHOULD be no 709 larger than (783*N)/3. Where N is the STS-Nc multiplier. 711 Since the minimum value of N is one, CEM implementations SHOULD 712 support a minimum payload length of 783/3 or 261 bytes. Smaller 713 payload lengths MAY be supported as an option. 715 7.2 Asynchronous 717 If synchronous timing is not available, other methods MAY be 718 employed to regenerate the circuit timing. 720 For structured CEM, the CEM packetizer SHOULD generate the N and P 721 bits as usual. However, without external synchronization, this 722 information is not sufficient to reliably justify the SPE within the 723 SONET/SDH transport framing at the CEM de-packetizer. The de- 724 packetizer MAY employ an adaptive algorithm to introduce pointer 725 adjustment events to map the CEM SPE to the SONET/SDH transport 726 framing. Regardless of whether the N and P bits are used by the de- 727 packetizer as part of the adaptive clock recovery algorithm, they 728 MUST still be used in conjunction with the D-bit to signal AIS-P, 729 SPE Unequipped, and DBA. 731 For unstructured CEM, the CEM de-packetizer MAY use an adaptive 732 clock recovery technique to regenerate the SONET/SDH transport 733 clock. 735 An example adaptive clock recovery method can be found in section 736 3.4.2 of [VTOA]. 738 8. CEM LSP Signaling 740 For maximum network scaling in MPLS applications, CEM LSP signaling 741 may be performed using the LDP Extended Discovery mechanism as 742 augmented by the PWid FEC Element defined in [RFC4447]. MPLS traffic 743 tunnels may be dedicated to CEM, or shared with other MPLS-based 744 services. The value 0x8008 is used for the PWE3 PW Type in the PWid 745 FEC Element in order to signify that the LSP being signaled is to 746 carry CEM. Note that the generic control word defined in [GR-253] 747 is not used, as its functionality is included in the CEM 748 encapsulation header. 750 Alternatively, static label assignment may be used, or a dedicated 751 traffic engineered LSP may be used for each CEM service. 753 Normal CEM packets are fixed in length for all of the packets of a 754 particular emulated TDM stream. This length is signaled using the 755 CEM Payload Bytes parameter defined in [RFC4447], or is statically 756 provisioned for each CEM service. 758 At this time, other aspects of the CEM service MUST be statically 759 provisioned. 761 9. Security Considerations 763 The CEM encapsulation is subject to all of the general security 764 considerations discussed in [RFC3985] and [RFC4447]. In addition, 765 this document specifies only encapsulations, and not the protocols 766 used to carry the encapsulated packets across the PSN. Each such 767 protocol may have its own set of security issues, but those issues 768 are not affected by the encapsulations specified herein. Note that 769 the security of the transported CEM service will only be as good as 770 the security of the PSN. This level of security may be less rigorous 771 then that available from a native TDM service due to the inherent 772 differences between circuit-switched and packet-switched public 773 networks. 775 10. IANA Considerations 777 IANA has already allocated the PWE3 PW Type value 0x0008 for this 778 specification. No further actions are required. 780 11. References 782 11.1 Normative References 784 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 785 Requirement Levels", BCP 14, RFC 2119, March 1997. 787 [T1.105] American National Standards Institute, "Synchronous Optical 788 Network (SONET) - Basic Description including Multiplex 789 Structure, Rates and Formats," ANSI T1.105-1995. 791 [G.707] ITU Recommendation G.707, "Network Node Interface For The 792 Synchronous Digital Hierarchy", 1996. 794 [RFC4447] Martini, L. et al, "Pseudowire Setup and Maintenance using 795 the Label Distribution Protocol (LDP)", RFC 4447, April 2006. 797 [GR-253] Telcordia Technologies, "Synchronous Optical Network 798 (SONET) Transport Systems: Common Generic Criteria", 799 GR-253-CORE, Issue 3, September 2000. 801 [RFC4023] Worster, T. et al, "Encapsulating MPLS in IP or Generic 802 Routing Encapsulation (GRE)", RFC 4023, March 2005. 804 [I.363.1] ITU-T, "Recommendation I.363.1, B-ISDN Adaptation Layer 805 Specification: Type AAL1", Appendix III, August 1996. 807 [VTOA] ATM Forum, "Circuit Emulation Service Interoperability 808 Specification Version 2.0", af-vtoa-0078.000, January 1997. 810 [RFC4842] Malis, A. et al, "Synchronous Optical Network/Synchronous 811 Digital Hierarchy (SONET/SDH) Circuit Emulation over Packet 812 (CEP)", RFC 4842, April 2007 814 [RFC4928] Swallow, G. et al, "Avoiding Equal Cost Multipath Treatment 815 in MPLS Networks", RFC 4928, June 2007. 817 11.2 Informative References 819 [RFC3985] Bryant, S. and P. Pate, "PWE3 Architecture", RFC 3985, 820 March 2005. 822 12. Acknowledgments 824 The authors would like to thank Mitri Halabi, Bob Colvin, and Ken 825 Hsu, all formerly of Vivace Networks and Tellabs, and Tom Johnson, 826 Marlene Drost, Ed Hallman, and Dave Danenberg, all formerly of 827 Litchfield Communications, for their contributions to the document. 829 13. Authors' Addresses 831 Andrew G. Malis 832 Verizon Communications 833 40 Sylvan Road 834 Waltham, MA 02451 835 Email: andrew.g.malis@verizon.com 837 Jeremy Brayley 838 ECI Telecom Inc. 839 Omega Corporate Center 840 1300 Omega Drive 841 Pittsburgh, PA 15205 842 Email: jeremy.brayley@ecitele.com 844 John Shirron 845 ECI Telecom Inc. 846 Omega Corporate Center 847 1300 Omega Drive 848 Pittsburgh, PA 15205 849 Email: john.shirron@ecitele.com 851 Luca Martini 852 Cisco Systems, Inc. 853 9155 East Nichols Avenue, Suite 400 854 Englewood, CO, 80112 855 Email: lmartini@cisco.com 857 Steve Vogelsang 858 Alcatel-Lucent 859 600 March Road 860 Kanata, ON K2K 2T6 861 Canada 862 Email: steve.vogelsang@alcatel-lucent.com 864 Appendix A. SONET/SDH Rates and Formats 866 For simplicity, the discussion in this section uses SONET 867 terminology, but it applies equally to SDH as well. SDH-equivalent 868 terminology is shown in the tables. 870 The basic SONET modular signal is the synchronous transport signal- 871 level 1 (STS-1). A number of STS-1s may be multiplexed into higher- 872 level signals denoted as STS-N, with N synchronous payload envelopes 873 (SPEs). The optical counterpart of the STS-N is the Optical Carrier- 874 level N, or OC-N. Table 2 lists standard SONET line rates discussed 875 in this document. 877 OC Level OC-1 OC-3 OC-12 OC-48 OC-192 878 SDH Term - STM-1 STM-4 STM-16 STM-64 879 Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280 881 Table 2. Standard SONET Line Rates 883 Each SONET frame is 125 us and consists of nine rows. An STS-N frame 884 has nine rows and N*90 columns. Of the N*90 columns, the first N*3 885 columns are transport overhead and the other N*87 columns are SPEs. 886 A number of STS-1s may also be linked together to form a super-rate 887 signal with only one SPE. The optical super-rate signal is denoted 888 as OC-Nc, which has a higher payload capacity than OC-N. 890 The first 9-byte column of each SPE is the path overhead (POH) and 891 the remaining columns form the payload capacity with fixed stuff 892 (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 893 columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed 894 stuff, STS-12c has three columns of fixed stuff, and so on. 896 The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The 897 payload capacity of an STS-1 is 86 columns (774 bytes) per frame. 898 The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. 899 Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 900 bytes per frame. As another example, the payload capacity of an STS- 901 192c is 149,760 bytes, which is exactly 64 times larger than the 902 STS-3c. 904 There are 8,000 SONET frames per second. Therefore, the SPE size, 905 (POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 906 Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame 907 or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760 908 bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 2 909 lists the SPE and payload rates supported. 911 SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c 912 SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c 913 Payload Size(Bytes) 774 2,340 9,360 37,440 149,760 914 Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640 915 SPE Size(Bytes) 783 2,349 9,396 37,584 150,336 916 SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504 918 Table 2. Payload Size and Rate 920 To support circuit emulation, the entire SPE of a SONET STS or SDH 921 VC level is encapsulated into packets, using the encapsulation 922 defined in section 5, for carriage across packet-switched networks. 924 Appendix B. ECC-6 Definition 926 ECC-6 is an Error Correction Code to protect the CEM header. This 927 provides single bit correction and the ability to detect up to two 928 bit errors. 930 Error Correction Code: 932 |---------------Header bits 0-25 -------------------| ECC-6 code| 933 0 1 2 3 934 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 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 |1 1 1 1 1 0 0 0 1 0 0 0 1 1 1 1 1 0 1 0 0 0 1 0 1 1|1 0 0 0 0 0| 937 |1 1 1 1 0 1 0 0 0 1 0 0 1 0 0 0 0 1 0 1 1 1 1 1 1 1|0 1 0 0 0 0| 938 |1 0 0 0 1 1 1 1 0 0 1 0 1 1 1 0 0 0 1 1 1 1 0 0 1 1|0 0 1 0 0 0| 939 |0 1 0 0 1 1 1 1 0 0 0 1 1 0 0 1 1 1 1 1 0 0 1 1 0 1|0 0 0 1 0 0| 940 |0 0 1 0 0 0 1 0 1 1 1 1 1 1 0 0 1 1 1 1 1 0 1 0 1 0|0 0 0 0 1 0| 941 |0 0 0 1 0 0 0 1 1 1 1 1 0 0 1 1 0 0 1 1 0 1 1 1 1 1|0 0 0 0 0 1| 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Figure 7. ECC-6 Check Matrix X 946 The ECC-6 code protects the 32 bit CEM header as follows: 948 The encoder generates the 6 bit ECC using the matrix shown in Figure 949 7. In brief, the encoder builds another 26 column by 6 row matrix 950 and calculates even parity over the rows. The matrix columns 951 represent CEM header bits 0 through 25. 953 Denote each column of the ECC-6 check matrix by X[], and each column 954 of the intermediate encoder matrix as Y[]. CEM[] denotes the CEM 955 header and ECC[] is the error correction code that is inserted into 956 CEM header bits 26 through 31. 958 for i = 0 to 25 { 959 if CEM[i] = 0 { 960 Y[i] = 0; 961 } else { 962 Y[i] = X[i]; 963 } 964 } 966 In other words, for each CEM header bit (i) set to 1, set the 967 resulting matrix column Y[i] according to Figure 7. 969 The final ECC-6 code is calculated as even parity of each row in Y 970 (i.e. ECC[k]=CEM[25+k]=even parity of row k). 972 The receiver also uses matrix X to calculate an intermediate matrix 973 Y' based on all 32 bits of the CEM header. Therefore Y' is 32 974 columns wide and includes the ECC-6 code. 976 for i = 0 to 31 { 977 if CEM[i] = 0 { 978 Y'[i] = 0; 979 } else { 980 Y'[i] = X[i]; 981 } 982 } 984 The receiver then appends the incoming ECC-6 code to Y as column 32 985 (ECC[0] should align with row 0) and calculates even parity for each 986 row. The result is a single 6 bit column Z. If all 6 bits are 0, 987 there are no bit errors (or at least no detectable errors). 988 Otherwise, it uses Z to perform a reverse lookup on X[] from Figure 989 7. If Z matches column X[i], then there is a single bit error. The 990 receiver should invert bit CEM[i] to correct the header. If Z fails 991 to match any column of X, then the CEM header contains more than one 992 bit error and the CEM packet MUST be discarded. 994 Note that the ECC-6 code provides single bit correction and 2-bit 995 detection of errors within the received ECC-6 code itself. 997 Full Copyright Statement 999 Copyright (C) The IETF Trust (2007). 1001 This document is subject to the rights, licenses and restrictions 1002 contained in BCP 78, and except as set forth therein, the authors 1003 retain all their rights. 1005 This document and the information contained herein are provided on an 1006 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1007 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1008 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1009 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1010 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1011 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1013 Intellectual Property 1015 The IETF takes no position regarding the validity or scope of any 1016 Intellectual Property Rights or other rights that might be claimed to 1017 pertain to the implementation or use of the technology described in 1018 this document or the extent to which any license under such rights 1019 might or might not be available; nor does it represent that it has 1020 made any independent effort to identify any such rights. Information 1021 on the procedures with respect to rights in RFC documents can be 1022 found in BCP 78 and BCP 79. 1024 Copies of IPR disclosures made to the IETF Secretariat and any 1025 assurances of licenses to be made available, or the result of an 1026 attempt made to obtain a general license or permission for the use of 1027 such proprietary rights by implementers or users of this 1028 specification can be obtained from the IETF on-line IPR repository at 1029 http://www.ietf.org/ipr. 1031 The IETF invites any interested party to bring to its attention any 1032 copyrights, patents or patent applications, or other proprietary 1033 rights that may cover technology that may be required to implement 1034 this standard. Please address the information to the IETF at 1035 ietf-ipr@ietf.org. 1037 Acknowledgment 1039 Funding for the RFC Editor function is provided by the IETF 1040 Administrative Support Activity (IASA).