idnits 2.17.1 draft-malis-sonet-ces-mpls-05.txt: ** The Abstract section seems to be numbered -(468): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(745): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(807): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(814): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(904): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 20 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The 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 (July 2001) is 8318 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: '0' is mentioned on line 1006, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' == Outdated reference: A later version (-19) exists of draft-martini-l2circuit-trans-mpls-06 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-12) exists of draft-martini-l2circuit-encap-mpls-02 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. '7') -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' == Outdated reference: A later version (-02) exists of draft-danenberg-pw-cem-mib-01 -- Possible downref: Normative reference to a draft: ref. '11' Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 10 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 Ken Hsu 4 Expiration Date: February 2002 Vivace Networks, Inc. 6 Jeremy Brayley 7 Steve Vogelsang 8 John Shirron 9 Laurel Networks, Inc. 11 Luca Martini 12 Level 3 Communications, LLC. 14 Tom Johnson 15 Marlene Drost 16 Ed Hallman 17 Litchfield Communications, Inc. 19 July 2001 21 SONET/SDH Circuit Emulation Service Over MPLS (CEM) Encapsulation 22 draft-malis-sonet-ces-mpls-05.txt 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of section 10 of RFC 2026 [1]. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt. 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html. 45 1. Abstract 47 This document describes a method for encapsulating SONET/SDH Path 48 signals for transport across packet-switched networks (PSNs). The PSNs 49 explicitly supported by this document include MPLS and IP. 51 2. Conventions used in this document 53 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 54 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 55 document are to be interpreted as described in RFC 2119 [2]. 57 3. Introduction 59 This document describes a method for encapsulating time division 60 multiplexed (TDM) digital signals for transmission over packet- 61 switched networks. 63 The transmission system for circuit-oriented TDM signals is the 64 Synchronous Optical Network (SONET) [3], [6] / Synchronous Digital 65 Hierarchy (SDH) [4]. To support TDM traffic (which includes voice, 66 data, and private leased line services) PSNs must emulate the 67 circuit characteristics of SONET/SDH payloads. MPLS labels and a 68 new circuit emulation header are used to encapsulate TDM signals and 69 provide the Circuit Emulation Service over MPLS (CEM) function. The 70 MPLS encapsulation may be further encapsulated in IP for carriage 71 across IP PSNs [8]. 73 This document also describes an optional extension to CEM called 74 Dynamic Bandwidth Allocation (DBA). This is a method for 75 dynamically reducing the bandwidth utilized by emulated SONET/SDH 76 circuits in the packet network. This bandwidth reduction is 77 accomplished by not sending the SONET/SDH payload through the packet 78 network under certain conditions such as AIS-P or STS SPE 79 Unequipped. 81 This document is closely related to references [5], which describes 82 the control protocol methods used to signal the usage of CEM, [7], 83 which describes a related method of encapsulating Layer 2 frames 84 over MPLS and which shares the same signaling, and [11] which 85 describes a MIB for controlling and observing CEM services. 87 4. Scope 89 This document describes how to provide CEM for the following digital 90 signals: 92 1. SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 94 2. STS-Nc SPE (N = 3, 12, or 48)/SDH VC-4, VC-4-4c, VC-4-16c 96 3. Unstructured SONET Emulation, where the entire SONET bit-stream 97 (including the transport overhead) is packetized and transported 98 across the PSN. 100 For the remainder of this document, these constructs will be 101 referred to as SONET/SDH channels. 103 Other SONET/SDH signals, such as virtual tributary (VT) structured 104 sub-rate mapping, are not explicitly discussed in this document; 105 however, it can be extended in the future to support VT and lower 106 speed non-SONET/SDH services. OC-192c SPE/VC-4-64c are also not 107 included at this point, since most PSNs use OC-192c or slower 108 trunks, and thus would not have sufficient capacity. As trunk 109 capacities increase in the future, the scope of this document can be 110 accordingly extended. 112 5. CEM Encapsulation Format 114 In order to transport SONET/SDH SPEs through a packet-oriented 115 network, the SPE is broken into fragments. A 32-bit CEM Header is 116 pre-pended to each fragment. The Basic CEM packet appears in Figure 117 1. 119 +-----------------------------------+ 120 | CEM Header | 121 +-----------------------------------+ 122 | | 123 | | 124 | SONET/SDH SPE Fragment | 125 | | 126 | | 127 +-----------------------------------+ 129 Figure 1. Basic CEM Packet 131 The 32-bit CEM header has the following format: 133 0 1 2 3 134 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 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 |D|R|Rvd| Sequence Num | Structure Pointer |N|P| ECC-6 | 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 Figure 2. CEM Header Format 141 The above fields are defined as follows: 143 D bit: Signals DBA Mode. MUST be set to zero for Normal Operation. 144 MUST be set to one if CEM is currently in DBA mode. DBA is an 145 optional mode during which trivial SPEs are not transmitted into the 146 packet network. See Table 1 and sections 7 and 8 for further 147 details. Note: for unstructured CEM, the D-bit MUST be set to zero. 149 R bit: CEM-RDI. This bit is set to one to signal to the remote CEM 150 function that a loss of packet synchronization has occurred. 152 Rvd: These bits are reserved for future use, and MUST be set to 153 zero. 155 Sequence Number: This is a packet sequence number, which MUST 156 continuously cycle from 0 to 1023. It SHOULD begin at zero when a 157 CEM LSP is created. 159 Structure Pointer: The Structure Pointer MUST contain the offset of 160 the J1 byte within the CEM payload. The value is from 0 to 1,022, 161 where 0 means the first byte after the CEM header. The Structure 162 Pointer MUST be set to 0x3FF (1,023) if a packet does not carry the 163 J1 byte. See [3], [4] and [6] for more information on the J1 byte 164 and the SONET/SDH payload pointer. Note: for unstructured CEM, the 165 Structure Pointer field MUST be set to 0x3FF. 167 The N and P bits: Indicate negative and positive pointer adjustment 168 events. They are also used to relay SONET/SDH maintenance signals 169 such as AIS-P. See Table 1 and sections 7 and 8 for more details. 170 Note: for unstructured CEM, the N and P bits MUST both be set to 0. 172 +---+---+---+----------------------------------------------+ 173 | D | N | P | Interpretation | 174 +---+---+---+----------------------------------------------+ 175 | 0 | 0 | 0 | Normal Mode � No Ptr Adjustment | 176 | 0 | 0 | 1 | Normal Mode � Positive Ptr Adjustment | 177 | 0 | 1 | 0 | Normal Mode � Negative Ptr Adjustment | 178 | 0 | 1 | 1 | Normal Mode � AIS-P | 179 | | | | | 180 | 1 | 0 | 0 | DBA Mode � STS SPE Unequipped | 181 | 1 | 0 | 1 | DBA Mode � STS SPE Unequipped Pos Ptr Adj | 182 | 1 | 1 | 0 | DBA Mode � STS SPE Unequipped Neg Ptr Adj | 183 | 1 | 1 | 1 | DBA Mode � AIS-P | 184 +---+---+---+----------------------------------------------+ 186 Table 1. Interpretation of D, N, and P bits 188 ECC-6: An Error Correction Code to protect the CEM header. This 189 offers the ability to correct single bit errors and detect up to two 190 bit errors. The ECC algorithm is described in Appendix B. The ECC- 191 6 can be optionally disabled at provisioning time. If the ECC-6 is 192 not utilized it MUST be set to zero. 194 Note: Normal CEM packets are fixed in length for all of the packets 195 of a particular emulated TDM stream. This length is signaled using 196 the CEM Payload Bytes parameter defined in [5], or is statically 197 provisioned for each TDM stream. Therefore, the length of each CEM 198 packet does not need to be carried in the CEM header. 200 5.1 Transport Encapsulation 201 In principle, CEM packets can be transported over any packet- 202 oriented network. The following sections describe specifically how 203 CEM packets MUST be encapsulated for transport over MPLS or IP 204 networks. 206 5.1.1 MPLS Transport 208 To transport a CEM packet over an MPLS network, an MPLS label-stack 209 MUST be pushed on top of the CEM packet. 211 The last two labels prior to the CEM header are referred to as the 212 Tunnel and Virtual Circuit (VC) labels. 214 The VC label is required, and is the last label prior to the CEM 215 Header. The VC label MUST be used to identify the CEM connection 216 within the MPLS tunnel. 218 The optional tunnel label is immediately above the VC label on the 219 label stack. If present, the tunnel label MUST be used to identify 220 the MPLS LSP used to tunnel the TDM packets through the MPLS network 221 (the tunnel LSP). 223 This is similar to the label stack usage defined in [5] and [7]. 225 +-----------------------------------+ 226 | Additional MPLS Labels (Optional) | 227 +-----------------------------------+ 228 | Tunnel Label (Optional) | 229 +-----------------------------------+ 230 | VC Label | 231 +-----------------------------------+ 232 | CEM Header | 233 +-----------------------------------+ 234 | | 235 | | 236 | SONET/SDH SPE Fragment | 237 | | 238 | | 239 +-----------------------------------+ 241 Figure 3. Typical MPLS Transport Encapsulation 243 5.1.1 IP Transport 245 It is highly desirable to define a single encapsulation format that 246 will work for both IP and MPLS. Furthermore, it is desirable that 247 the encapsulation mechanism be as efficient as possible. 249 One way to achieve these goals is to map CEM directly onto IP by 250 mapping the previously described MPLS packets onto IP. 252 A mechanism for carrying MPLS over IP is described in [8]. 254 Using this encapsulation scheme would result in the packet format 255 illustrated in figure 4. 257 +-----------------------------------+ 258 | | 259 | IPv6/v4 Header [8] | 260 | | 261 +-----------------------------------+ 262 | Tunnel Label (Optional) | 263 +-----------------------------------+ 264 | VC Label | 265 +-----------------------------------+ 266 | CEM Header | 267 +-----------------------------------+ 268 | | 269 | | 270 | SONET/SDH SPE Fragment | 271 | | 272 | | 273 +-----------------------------------+ 275 Figure 4. MPLS Transport Encapsulation 277 6. CEM Operation 279 The following sections describe CEM operation. 281 6.1 Introduction and Terminology 283 There are two types of CEM: structured and unstructured. 285 Unstructured CEM packetizes the entire SONET/SDH bit-stream 286 (including transport overhead). 288 Structured CEM terminates the transport overhead and packetizes 289 individual channels (STS-1/Nc) within the SONET/SDH frame. Because 290 structured CEM terminates the transport overhead, structured CEM 291 implementations SHOULD meet the generic requirements for SONET/SDH 292 Line Terminating Equipment as defined in [3], [4], and [6]. 294 Implementations MUST support structured CEM and MAY support 295 unstructured CEM. 297 Structured CEM MUST support a normal mode of operation and MAY 298 support an optional extension called Dynamic Bandwidth Allocation 299 (DBA). During normal operation, SONET/SDH payloads are fragmented, 300 pre-pended with the CEM Header, the VC label, and the PSN header, 301 and then transmitted into the packet network. During DBA mode, only 302 the CEM header, the VC label, and PSN header are transmitted. This 303 is done to conserve bandwidth when meaningful user data is not 304 present in the SPE, such as during AIS-P or STS SPE Unequipped. 306 6.1.1 CEM Packetizer and De-Packetizer 308 As with all adaptation functions, CEM has two distinct components: 309 adapting TDM SONET/SDH into a CEM packet stream, and converting the 310 CEM packet stream back into a TDM SONET/SDH. The first function 311 will be referred to as CEM Packetizer and the second as CEM De- 312 Packetizer. This terminology is illustrated in figure 5. 314 +------------+ +---------------+ 315 | | | | 316 SONET --> | CEM | --> PSN --> | CEM | --> SONET 317 SDH | Packetizer | | De-Packetizer | SDH 318 | | | | 319 +------------+ +---------------+ 321 Figure 5. CEM Terminology 323 Note: the CEM de-packetizer requires a buffering mechanism to 324 account for delay variation in the CEM packet stream. This 325 buffering mechanism will be generically referred to as the CEM 326 jitter buffer. 328 6.1.2 CEM DBA 330 DBA is an optional mode of operation for structured CEM that only 331 transmits the CEM Header, the VC label, and PSN Header into the 332 packet network under certain circumstances such as AIS-P or STS 333 Unequipped. 335 If DBA is supported by a CEM implementation, the user SHOULD be able 336 to configure if DBA will be triggered by AIS-P, STS Unequipped, 337 both, or neither on a per channel basis. 339 If DBA is supported, the determination of AIS-P and STS Unequipped 340 MUST be based on the state of SONET/SDH Section, Line, and Path 341 Overhead bytes. DBA based on pattern detection within the SPE (i.e. 342 all zeros, 7Es, or ATM idle cells) is for further study. 344 During AIS-P, there is no valid payload pointer, so pointer 345 adjustments cannot occur. During STS Unequipped, the SONET/SDH 346 payload pointer is valid, and therefore pointer adjustments MUST be 347 supported even during DBA. See Table 1 for details. 349 6.2 Description of Normal CEM Operation 351 During normal operation, the CEM packetizer will receive a fixed 352 rate byte stream from a SONET/SDH interface. When a packets worth 353 of data has been received from a SONET/SDH channel, the CEM Header, 354 the VC Label, and PSN Header are pre-pended to the SPE fragment and 355 the resulting CEM packet is transmitted into the packet network. 356 Because all normal CEM packets associated with a specific SONET/SDH 357 channel will have the same length, the transmission of CEM packets 358 for that channel SHOULD occur at regular intervals. 360 At the far end of the packet network, the CEM de-packetizer will 361 receive packets into a jitter buffer and then play out the received 362 byte stream at a fixed rate onto the corresponding SONET/SDH 363 channel. The jitter buffer SHOULD be adjustable in length to 364 account for varying network delay behavior. The receive packet rate 365 from the packet network should be exactly balanced by the 366 transmission rate onto the SONET/SDH channel, on average. The time 367 over which this average is taken corresponds to the depth of the 368 jitter buffer for a specific CEM channel. 370 The CEM sequence numbers provide a mechanism to detect lost and/or 371 mis-ordered packets. The CEM de-packetizer MUST detect lost or mis- 372 ordered packets. The CEM de-packetizer MUST play out a programmable 373 byte pattern in place of any dropped packets. The CEM de-packetizer 374 MAY re-order packets received out of order. If the CEM de- 375 packetizer does not support re-ordering, it MUST drop mis-ordered 376 packets. 378 6.3 Description of CEM Operation during DBA 380 (Note: DBA is only applicable to structured CEM.) 381 There are several issues that should be addressed by a workable CEM 382 DBA mechanism. First, when DBA is invoked, there should be a 383 substantial savings in bandwidth utilization in the packet network. 384 The second issue is that the transition in and out of DBA should be 385 tightly coordinated between the local CEM packetizer and CEM de- 386 packetizer at the far side of the packet network. A third is that 387 the transition in and out of DBA should be accomplished with minimal 388 disruption to the adapted data stream. 390 Another goal is that the reduction of CEM traffic due to DBA should 391 not be mistaken for a fault in the packet network or vice-versa. 392 Finally, the implementation of DBA should require minimal 393 modifications beyond what is necessary for the nominal CEM case. 394 The mechanism described below is a reasonable balance of these 395 goals. 397 During DBA, packets MUST be emitted at exactly the same rate as they 398 would be during normal operation. This SHOULD be accomplished by 399 transmitting each DBA packet after a complete packet of data has 400 been received from the SONET/SDH channel. The only change from 401 normal operation is that the CEM packets during DBA MUST only carry 402 the CEM header, the VC Label, and the PSN Header. 404 Because some links have a minimum supported packet size, the CEM 405 packetizer MAY append a configurable number of bytes immediately 406 after the CEM-header to pad out the CEM packet to reach the mimumum 407 supported packet size. The value of the padding bytes is 408 implementation specific. The D-bit MUST be set to one, to indicate 409 that DBA is active. 411 The CEM de-packetizer MUST assume that each packet received with the 412 D-bit set represents a normal-sized packet containing an AIS-P or 413 SPE Unequipped payload as noted by N and P. See Table 1. The CEM 414 de-packetizer MUST accept DBA packets with or without padding. 416 This allows the CEM packetization and de-packetization logic during 417 DBA to be similar to the nominal case. It insures that the correct 418 SONET/SDH indication is reliably transmitted between CEM adaptation 419 points. It minimizes the risk of under or over running the jitter 420 buffer during the transition in and out of DBA. And, it guarantees 421 that faults in the packet network are recognized as distinctly 422 different from line conditioning on the SONET/SDH interfaces. 424 6.4 Packet Synchronization 426 A key component in declaring the state of a CEM service is whether 427 or not the CEM de-packetizer is in or out of packet synchronization. 428 The following paragraphs describe how that determination is made. 430 6.4.1 Acquisition of Packet Synchronization 431 At startup, a CEM de-packetizer will be out of packet 432 synchronization by default. To declare packet synchronization at 433 startup or after a loss of packet synchronization, the CEM de- 434 packetizer must receive a configurable number of CEM packets with 435 sequential sequence numbers. 437 6.4.2 Loss of Packet Synchronization 439 Once a CEM de-packetizer is in packet sync, it may encounter a set 440 of events that will cause it to lose packet synchronization. 442 As discussed in section 6.2, a CEM de-packetizer MAY or MAY NOT 443 support re-ordering of mis-ordered packets. 445 If a CEM de-packetizer supports re-ordering, then the determination 446 that packet synchronization has been lost cannot be made at the time 447 the packets are received from the PSN. Instead, the determination 448 MUST be made as the packets are being played out onto the SONET/SDH 449 interface. This is because it is only at play-out time that the 450 determination can be made as to whether the entire emulated 451 SONET/SDH stream was received from the PSN. 453 If a CEM de-packetizer does not support re-ordering, a number of 454 approaches may be used to minimize the impact of mis-ordered or lost 455 packets on the final re-assembled SONET/SDH stream. For example, 456 AAL1 [9] uses a simple state-machine to re-order packets in a sub- 457 set of possible cases. The algorithm for these state-machines is 458 outside of the scope of CEM. However, the final determination as to 459 whether or not to declare loss of packet synchronization MUST be 460 based on the same criteria as for implementations that do support 461 re-ordering. 463 Whether or not a CEM implementation supports re-ordering, the 464 declaration of loss of packet synchronization MUST be based on the 465 following criteria. 467 As packets are played out towards the SONET/SDH interface, the CEM 468 de-packetizer will encounter �empty� packets in the place of packets 469 that were dropped by the PSN, or effectively dropped due to 470 limitations of the CEM implementation. If the CEM de-packetizer 471 encounters more than a configurable number of sequential dropped 472 packets, the CEM de-packetizer MUST declare loss of packet 473 synchronization. 475 7. SONET/SDH Maintenance Signals 477 There are several issues that must be considered in the mapping of 478 maintenance signals between SONET/SDH and a PSN. A description of 479 how these signals and conditions are mapped between the two domains 480 is described below. 482 For clarity, the mappings are split into two groups: SONET/SDH to 483 PSN, and PSN to SONET/SDH. 485 7.1 SONET/SDH to PSN 486 The following sections describe how SONET/SDH Maintenance Signals 487 and Alarm conditions are mapped into a Packet Switched Network. 489 7.1.1 AIS-P Indication 491 In a SONET/SDH network, SONET/SDH Path outages are signaled using 492 maintenance alarms such as Path AIS (AIS-P). In particular, AIS-P 493 indicates that the SONET/SDH Path is not currently transmitting 494 valid end-user data, and the SPE contains all ones. 496 It should be noted that for structured CEM nearly every type of 497 service-effecting section or line defect will result in an AIS-P 498 condition. 500 The SONET/SDH hierarchy is illustrated below. 502 +----------+ 503 | PATH | 504 +----------+ 505 ^ 506 | 507 AIS-P 508 | 509 | 510 +----------+ 511 | LINE | 512 + ---------+ 513 ^ ^ 514 | | 515 AIS-L +------ LOP 516 | 517 | 518 +----------+ 519 | SECTION | 520 +----------+ 521 ^ ^ 522 | | 523 | | 524 LOS LOF 526 Figure 6. SONET/SDH Fault Hierarchy. 528 Should the Section Layer detect a Loss of Signal (LOS) or Loss of 529 Frame (LOF) condition, it sends AIS-L up to the Line Layer. If the 530 Line Layer detects AIS-L or Loss of Path (LOP), it sends AIS-P to 531 the Path Layer. 533 In normal mode during AIS-P, structured CEM packets are generated as 534 usual. The N and P bits MUST be set to 11 binary to signal AIS-P 535 explicitly through the packet network. The D-bit MUST be set to 536 zero to indicate that the SPE is being carried through the packet 537 network. Normal CEM packets with the SPE fragment, CEM Header, the 538 VC Label, and PSN Header MUST be transmitted into the packet 539 network. 541 However, to conserve network bandwidth during AIS-P, DBA MAY be 542 employed. If DBA has been enabled for AIS-P and AIS-P is currently 543 occurring, the N and P bits MUST be set to 11 binary to signal AIS, 544 and the D-bit MUST be set to one to indicate that the SPE is not 545 being carried through the packet network. Only the CEM header, the 546 VC Label, and the PSN Header MUST be transmitted into the packet 547 network. 549 Also note that this differs from the outage mechanism in [5], which 550 withdraws the VC label as a result of an endpoint outage. TDM 551 circuit emulation requires the ability to distinguish between the 552 de-provisioning of a circuit (which causes the VC label to be 553 withdrawn), and temporary outages (which are signaled using AIS-P). 555 7.1.2 STS SPE Unequipped Indication 557 The STS SPE Unequipped Indication is a slightly different case than 558 AIS-P. When byte C2 of the Path Overhead (STS path signal label) is 559 00h and Byte B3 (STS Path BIP-8) is valid, it indicates that the SPE 560 is unequipped. Note: this is typically signaled by setting the 561 entire SPE to zeros. 563 For normal structured CEM operation during SPE Unequipped, the N and 564 P bits MUST be interpreted as usual. The SPE MUST be transmitted 565 into the packet network along with the CEM Header, the VC Label, and 566 PSN Header, and the D-Bit MUST be set to zero. 568 If DBA has been enabled for STS SPE Unequipped and the Unequipped 569 condition is occurring on the SONET/SDH channel, the D-bit MUST be 570 set to one to indicate DBA is active. Only the CEM Header, the VC 571 Label, and PSN Header MUST be transmitted into the packet network. 572 The N and P bits MUST be used to signal pointer adjustments as 573 normal. See Table 1 and section 8 for details. 575 7.1.3 CEM-RDI 577 The CEM function MUST send CEM-RDI towards the packet network during 578 loss of packet synchronization. This MUST be accomplished by 579 setting the R bit to one in the CEM header. This applies for both 580 structured and unstructured CEM. 582 7.2 PSN to SONET/SDH 584 The following sections discuss how the various conditions on the 585 packet network are converted into SONET/SDH indications. 587 7.2.1 AIS-P Indication 589 There are several conditions in the packet network that will cause 590 the structured CEM de-packetization function to send an AIS-P 591 indication onto a SONET/SDH channel. 593 The first of these is the receipt of structured CEM packets with the 594 N and P bits set to one, and the D-bit set to zero. This is an 595 explicit indication of AIS-P being received at the far-end of the 596 packet network, with DBA disabled for AIS-P. The CEM de-packetizer 597 MUST play out the received SPE fragment (which will incidentally be 598 carrying all ones), and MUST configure the SONET/SDH Overhead to 599 signal AIS-P as defined in [3], [4], and [6]. 601 The second case is the receipt of structured CEM packets with the N 602 and P bits set to one, and the D-bit set to one. This is an 603 explicit indication of AIS-P being received at the far-end of the 604 packet network, with DBA enabled for AIS-P. The CEM de-packetizer 605 MUST play out one packet�s worth of all ones for each packet 606 received, and MUST configure the SONET/SDH Overhead to signal AIS-P 607 as defined in [3], [4], and [6]. 609 A third case that will cause a structured CEM de-packetization 610 function to send an AIS-P indication onto a SONET/SDH channel is 611 loss of packet synchronization. 613 7.2.2 STS SPE Unequipped Indication 615 There are three conditions in the packet network that will cause the 616 CEM function to transmit STS SPE Unequipped indications onto the 617 SONET/SDH channel. 619 The first, which is transparent to CEM, is the receipt of regular 620 CEM packets that happen to be carrying an SPE that contains the 621 appropriate Path overhead to signal STS SPE unequipped. This case 622 does not require any special processing on the part of the CEM de- 623 packetizer. 625 The second case is the receipt of structured CEM packets that have 626 the D-bit set to one to indicate DBA active and the N and P bits set 627 to 00 binary, 01 binary, or 10 binary to indicate SPE Unequipped 628 with or without pointer adjustments. The CEM de-packetizer MUST use 629 this information to transmit a packet of all zeros onto the 630 SONET/SDH interface, and adjust the payload pointer as necessary. 632 The third case when a structured CEM de-packetizer MUST send an STS 633 SPE Unequipped Indication towards the SONET/SDH interface is when 634 the VC-label has been withdrawn due to de-provisioning of the 635 circuit. 637 8. Clocking Modes 639 It is necessary to be able to regenerate the input service clock at 640 the output interface. Two clocking modes are supported: synchronous 641 and asynchronous. Selection of the clocking mode is made as part of 642 service provisioning. Both ends of the emulated circuit must be 643 configured with the same clocking mode. 645 8.1 Synchronous 647 When synchronous SONET/SDH timing is available at both ends of the 648 circuit, the issue of clock recovery becomes much simpler. 650 8.1.1 Synchronous Unstructured CEM 652 For unstructured CEM, the external clock is used to clock each bit 653 onto the optical carrier. 655 8.1.2 Synchronous Structured CEM 657 For structured CEM, the external clock is used to clock the 658 SONET/SDH carrier. The N and P bits are used to signal negative or 659 positive pointer justification events between structured CEM end- 660 points. 662 If there is a frequency offset between the frame rate of the 663 transport overhead and that of the SONET/SDH SPE, then the alignment 664 of the SPE shall periodically slip back or advance in time through 665 positive or negative stuffing. The N and P bits are used to replay 666 the pointer adjustment events and eliminate transport jitter. 668 During a negative pointer adjustment event, the H3 byte from the 669 SONET/SDH stream is incorporated into the CEM packet payload in 670 order with the rest of the SPE. During a positive pointer 671 adjustment event, the stuff byte is not included in the CEM packet 672 payload. 674 The pointer adjustment event MUST be transmitted in three 675 consecutive packets by the packetizer. The de-packetizer MUST play 676 out the pointer adjustment event when the first packet of the three 677 with N/P bit set is received. 679 The CEM de-packetizer MUST utilize the CEM sequence numbers to 680 insure that SONET/SDH pointer adjustment events are not played any 681 more frequently than once per every three CEM packets transmitted by 682 the remote CEM packetizer. 684 References [3],[4],and [6] specify that pointer adjustment events 685 MUST be separated by three SONET/SDH frames without a pointer 686 adjustment event. In order to relay all legal pointer adjustment 687 events, the packet size for a specific circuit MUST be no larger 688 than (783 * 4 * N)/3, where N is the STS-Nc multiplier. 690 However, some SONET/SDH equipment allows pointer adjustments to 691 occur in back to back SONET/SDH frames. In order to support this 692 possibility, the packet size for a particular circuit SHOULD be no 693 larger than (783*N)/3. Where N is the STS-Nc multiplier. 695 Since the minimum value of N is one, CEM implementations SHOULD 696 support a minimum payload length of 783/3 or 261 bytes. Smaller 697 payload lengths MAY be supported as an option. 699 8.2 Asynchronous 701 If synchronous timing is not available, other methods MAY be 702 employed to regenerate the circuit timing. 704 For structured CEM, the CEM packetizer SHOULD generate the N and P 705 bits as usual. However, without external synchronization, this 706 information is not sufficient to reliably justify the SPE within the 707 SONET/SDH transport framing at the CEM de-packetizer. The de- 708 packetizer MAY employ an adaptive algorithm to introduce pointer 709 adjustment events to map the CEM SPE to the SONET/SDH transport 710 framing. Regardless of whether the N and P bits are used by the de- 711 packetizer as part of the adaptive clock recovery algorithm, they 712 MUST still be used in conjunction with the D-bit to signal AIS-P, 713 SPE Unequipped, and DBA. 715 For unstructured CEM, the CEM de-packetizer MAY use an adaptive 716 clock recovery technique to regenerate the SONET/SDH transport 717 clock. 719 An example adaptive clock recovery method can be found in section 720 3.4.2 of [10]. 722 9. CEM LSP Signaling 724 For maximum network scaling in MPLS applications, CEM LSP signaling 725 may be performed using the LDP Extended Discovery mechanism as 726 augmented by the VC FEC Element defined in [5]. MPLS traffic 727 tunnels may be dedicated to CEM, or shared with other MPLS-based 728 services. The value 8008 is used for the VC Type in the VC FEC 729 Element in order to signify that the LSP being signaled is to carry 730 CEM. Note that the generic control word defined in [6] is not used, 731 as its functionality is included in the CEM encapsulation header. 733 Alternatively, static label assignment may be used, or a dedicated 734 traffic engineered LSP may be used for each CEM service. 736 Normal CEM packets are fixed in length for all of the packets of a 737 particular emulated TDM stream. This length is signaled using the 738 CEM Payload Bytes parameter defined in [5], or is statically 739 provisioned for each CEM service. 741 At this time, other aspects of the CEM service MUST be statically 742 provisioned. The CEM-MIB [11] provides a method for statically 743 provisioning CEM services. 745 In [5], Parameter ID 0x05 is allocated for �CEM Options�. At this 746 time, the CEM Options parameter is reserved and MUST be set to zero. 747 The use of the CEM Options parameter is for future consideration. 749 10. Open Issues 751 Future revisions of this document may discuss the following items. 753 Underlying MPLS QoS requirements are not covered by this revision of 754 the draft. Future revisions may discuss underlying QoS 755 requirements. 757 Support for VT and lower speed non-SONET/SDH services are not 758 covered in this revision of the draft. Future revisions may address 759 VT and non-SONET/SDH TDM services. 761 Use of the CEM Options parameter in [5] is currently undefined. 762 Future revision of this draft will determine how the CEM Options 763 word will be used. 765 The CEM-MIB[11] calls out a number of CEM performance parameters 766 such as Errored Seconds, Severely Errored Seconds, and Unavailable 767 Seconds. These terms are currently not defined in this draft. The 768 definition of these terms is for future consideration. 770 The current draft only considers DBA based on SONET/SDH Overhead. 771 It may be desirable to extending DBA to include pattern-based 772 suppression such as long runs of HDLC flags (i.e. 0x7E). 774 11. Security Considerations 776 As with [5], this document does not affect the underlying security 777 issues of MPLS. 779 12. Intellectual Property Disclaimer 781 This document is being submitted for use in IETF standards 782 discussions. Vivace Networks, Inc. has filed one or more patent 783 applications relating to the CEM technology outlined in this 784 document. Vivace Networks, Inc. will grant free unlimited licenses 785 for use of this technology. 787 13. References 789 [1] Bradner, S., "The Internet Standards Process -- Revision 3", 790 BCP 9, RFC 2026, October 1996. 792 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 793 Levels", BCP 14, RFC 2119, March 1997 795 [3] American National Standards Institute, "Synchronous Optical 796 Network (SONET) - Basic Description including Multiplex 797 Structure, Rates and Formats," ANSI T1.105-1995. 799 [4] ITU Recommendation G.707, "Network Node Interface For The 800 Synchronous Digital Hierarchy", 1996. 802 [5] Martini et al, "Transport of Layer 2 Frames Over MPLS", draft- 803 martini-l2circuit-trans-mpls-06.txt, work in progress, July 804 2001. 806 [6] Telcordia Technologies, �Synchronous Optical Network (SONET) 807 Transport Systems: Common Generic Criteria�, GR-253-CORE, Issue 808 3, September 2000. 810 [7] Martini et al, "Encapsulation Methods for Transport of Layer 2 811 Frames Over MPLS", draft-martini-l2circuit-encap-mpls-02.txt, 812 work in progress, July 2001. 814 [8] Worster, �MPLS Label Stack Encapsulation in IP�, draft-worster- 815 mpls-in-ip-05, work in progress, July 2001. 817 [9] ITU-T, �Recommendation I.363.1, B-ISDN Adaptation Layer 818 Specification: Type AAL1�, Appendix III, August 1996. 820 [10] ATM Forum, "Circuit Emulation Service Interoperability 821 Specification Version 2.0", af-vtoa-0078.000, January 1997. 823 [11] Danenberg et al, "SONET/SDH Circuit Emulation Service Over MPLS 824 (CEM) Management Information Base Using SMIv2", draft- 825 danenberg-pw-cem-mib-01.txt, work in progress, July 2001. 827 14. Acknowledgments 828 The authors would like to thank Mitri Halabi and Bob Colvin, both of 829 Vivace Networks, for their comments and suggestions. 831 15. Authors' Addresses 833 Andrew G. Malis 834 Vivace Networks, Inc. 835 2730 Orchard Parkway 836 San Jose, CA 95134 837 Email: Andy.Malis@vivacenetworks.com 839 Ken Hsu 840 Vivace Networks, Inc. 841 2730 Orchard Parkway 842 San Jose, CA 95134 843 Email: Ken.Hsu@vivacenetworks.com 845 Jeremy Brayley 846 Laurel Networks, Inc. 847 2706 Nicholson Rd. 848 Sewickley, PA 15143 849 Email: jbrayley@laurelnetworks.com 851 Steve Vogelsang 852 Laurel Networks, Inc. 853 2706 Nicholson Rd. 854 Sewickley, PA 15143 855 Email: sjv@laurelnetworks.com 857 John Shirron 858 Laurel Networks, Inc. 859 2607 Nicholson Rd. 860 Sewickley, PA 15143 861 Email: jshirron@laurelnetworks.com 863 Luca Martini 864 Level 3 Communications, LLC. 865 1025 Eldorado Blvd. 866 Broomfield, CO 80021 867 Email: luca@level3.net 869 Thomas K. Johnson 870 Litchfield Communications, Inc. 871 76 Westbury Park Rd. 872 Watertown, CT 06795 873 Email: tom_johnson@litchfieldcomm.com 875 Ed Hallman 876 Litchfield Communications, Inc. 877 76 Westbury Park Rd. 878 Watertown, CT 06795 879 Email: ed_hallman@litchfieldcomm.com 880 Marlene Drost 881 Litchfield Communications, Inc. 882 76 Westbury Park Rd. 883 Watertown, CT 06795 884 Email: marlene_drost@litchfieldcomm.com 885 Appendix A. SONET/SDH Rates and Formats 887 For simplicity, the discussion in this section uses SONET 888 terminology, but it applies equally to SDH as well. SDH-equivalent 889 terminology is shown in the tables. 891 The basic SONET modular signal is the synchronous transport signal- 892 level 1 (STS-1). A number of STS-1s may be multiplexed into higher- 893 level signals denoted as STS-N, with N synchronous payload envelopes 894 (SPEs). The optical counterpart of the STS-N is the Optical Carrier- 895 level N, or OC-N. Table 2 lists standard SONET line rates discussed 896 in this document. 898 OC Level OC-1 OC-3 OC-12 OC-48 OC-192 899 SDH Term - STM-1 STM-4 STM-16 STM-64 900 Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280 902 Table 2. Standard SONET Line Rates 904 Each SONET frame is 125 �s and consists of nine rows. An STS-N frame 905 has nine rows and N*90 columns. Of the N*90 columns, the first N*3 906 columns are transport overhead and the other N*87 columns are SPEs. 907 A number of STS-1s may also be linked together to form a super-rate 908 signal with only one SPE. The optical super-rate signal is denoted 909 as OC-Nc, which has a higher payload capacity than OC-N. 911 The first 9-byte column of each SPE is the path overhead (POH) and 912 the remaining columns form the payload capacity with fixed stuff 913 (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 914 columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed 915 stuff, STS-12c has three columns of fixed stuff, and so on. 917 The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The 918 payload capacity of an STS-1 is 86 columns (774 bytes) per frame. 919 The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. 920 Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 921 bytes per frame. As another example, the payload capacity of an STS- 922 192c is 149,760 bytes, which is exactly 64 times larger than the 923 STS-3c. 925 There are 8,000 SONET frames per second. Therefore, the SPE size, 926 (POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 927 Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame 928 or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760 929 bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 2 930 lists the SPE and payload rates supported. 932 SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c 933 SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c 934 Payload Size(Bytes) 774 2,340 9,360 37,440 149,760 935 Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640 936 SPE Size(Bytes) 783 2,349 9,396 37,584 150,336 937 SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504 939 Table 2. Payload Size and Rate 941 To support circuit emulation, the entire SPE of a SONET STS or SDH 942 VC level is encapsulated into packets, using the encapsulation 943 defined in section 5, for carriage across packet-switched networks. 945 Appendix B. ECC-6 Definition 947 ECC-6 is an Error Correction Code to protect the CEM header. This 948 provides single bit correction and the ability to detect up to two 949 bit errors. 951 Error Correction Code: 953 |---------------Header bits 0-25 -------------------| ECC-6 code| 954 0 1 2 3 955 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 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 957 |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| 958 |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| 959 |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| 960 |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| 961 |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| 962 |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| 963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 Figure 7. ECC-6 Check Matrix X 967 The ECC-6 code protects the 32 bit CEM header as follows: 969 The encoder generates the 6 bit ECC using the matrix shown in Figure 970 7. In brief, the encoder builds another 26 column by 6 row matrix 971 and calculates even parity over the rows. The matrix columns 972 represent CEM header bits 0 through 25. 974 Denote each column of the ECC-6 check matrix by X[], and each column 975 of the intermediate encoder matrix as Y[]. CEM[] denotes the CEM 976 header and ECC[] is the error correction code that is inserted into 977 CEM header bits 26 through 31. 979 for i = 0 to 25 { 980 if CEM[i] = 0 { 981 Y[i] = 0; 982 } else { 983 Y[i] = X[i]; 984 } 985 } 987 In other words, for each CEM header bit (i) set to 1, set the 988 resulting matrix column Y[i] according to Figure 7. 990 The final ECC-6 code is calculated as even parity of each row in Y 991 (i.e. ECC[k]=CEM[25+k]=even parity of row k). 993 The receiver also uses matrix X to calculate an intermediate matrix 994 Y� based on all 32 bits of the CEM header. Therefore Y� is 32 995 columns wide and includes the ECC-6 code. 997 for i = 0 to 31 { 998 if CEM[i] = 0 { 999 Y�[i] = 0; 1000 } else { 1001 Y�[i] = X[i]; 1002 } 1003 } 1005 The receiver then appends the incoming ECC-6 code to Y as column 32 1006 (ECC[0] should align with row 0) and calculates even parity for each 1007 row. The result is a single 6 bit column Z. If all 6 bits are 0, 1008 there are no bit errors (or at least no detectable errors). 1009 Otherwise, it uses Z to perform a reverse lookup on X[] from Figure 1010 7. If Z matches column X[i], then there is a single bit error. The 1011 receiver should invert bit CEM[i] to correct the header. If Z fails 1012 to match any column of X, then the CEM header contains more than one 1013 bit error and the CEM packet MUST be discarded. 1015 Note that the ECC-6 code provides single bit correction and 2-bit 1016 detection of errors within the received ECC-6 code itself 1018 Full Copyright Statement 1020 Copyright (C) The Internet Society (2001). All Rights Reserved. This 1021 document and translations of it may be copied and furnished to 1022 others, and derivative works that comment on or otherwise explain it 1023 or assist in its implementation may be prepared, copied, published 1024 and distributed, in whole or in part, without restriction of any 1025 kind, provided that the above copyright notice and this paragraph 1026 are included on all such copies and derivative works. However, this 1027 document itself may not be modified in any way, such as by removing 1028 the copyright notice or references to the Internet Society or other 1029 Internet organizations, except as needed for the purpose of 1030 developing Internet standards in which case the procedures for 1031 copyrights defined in the Internet Standards process must be 1032 followed, or as required to translate it into languages other than 1033 English. 1035 The limited permissions granted above are perpetual and will not be 1036 revoked by the Internet Society or its successors or assigns. 1038 This document and the information contained herein is provided on an 1039 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1040 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1041 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1042 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1043 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1045 Acknowledgement 1047 Funding for the RFC Editor function is currently provided by the 1048 Internet Society.