idnits 2.17.1 draft-ietf-pwe3-sonet-14.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1948. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1955. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1961. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The control word is REQUIRED for CEP pseudo-wires. Therefore the C-bit in PWid FEC and PW generalized ID FEC elements MUST be set. If the C-bit is not set the pseudo-wire MUST not be established and a Label Release MUST be sent with an Illegal C-bit status code [PWE3-IANA]. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A PE that receives a label-mapping request with request for a CEP/TDM Payload Bytes value that is not locally supported MUST return CEP/TDM miss-configuration status error code [PWE3-IANA] and the pseudo wire MUST not be established. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The CEP/TDM Bit Rate parameter is MANDATORY. Attempts to establish a pseudo-wire between two peers with different bit-rates MUST be rejected with incompatible bit rate status error code [PWE3-IANA] and the pseudo wire MUST not be established. -- 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 (December 21, 2006) is 6336 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'MPLS' is defined on line 1817, but no explicit reference was found in the text == Unused Reference: 'UDP' is defined on line 1841, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4447 (ref. 'PWE3-CONTROL') (Obsoleted by RFC 8077) ** Obsolete normative reference: RFC 3005 (ref. 'RTP') (Obsoleted by RFC 9245) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Pseudo Wire Edge to Edge Emulation A. Malis 3 Internet-Draft Verizon Communications 4 Intended status: Informational P. Pate 5 Expires: June 24, 2007 Overture Networks 6 R. Cohen, Ed. 7 Resolute Networks 8 D. Zelig 9 Corrigent Systems 10 December 21, 2006 12 SONET/SDH Circuit Emulation over Packet (CEP) 13 draft-ietf-pwe3-sonet-14 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 24, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document provides encapsulation formats and semantics for 47 emulating SONET/SDH circuits and services over MPLS. 49 Table of Contents 51 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 53 2. Co-Authors . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 5. CEP Encapsulation Format . . . . . . . . . . . . . . . . . . . 9 60 5.1. SONET/SDH Fragment . . . . . . . . . . . . . . . . . . . . 9 61 5.2. CEP Header . . . . . . . . . . . . . . . . . . . . . . . . 10 62 5.3. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 13 63 5.4. PSN Encapsulation . . . . . . . . . . . . . . . . . . . . 14 65 6. CEP Operation . . . . . . . . . . . . . . . . . . . . . . . . 15 66 6.1. CEP Packetizer and De-Packetizer . . . . . . . . . . . . . 15 67 6.2. Packet Synchronization . . . . . . . . . . . . . . . . . . 16 68 6.2.1. Acquisition of Packet Synchronization . . . . . . . . 16 69 6.2.2. Loss of Packet Synchronization . . . . . . . . . . . . 16 71 7. SONET/SDH Maintenance Signals . . . . . . . . . . . . . . . . 18 72 7.1. SONET/SDH to PSN . . . . . . . . . . . . . . . . . . . . . 18 73 7.1.1. CEP-AIS: AIS-P/V Indication . . . . . . . . . . . . . 18 74 7.1.2. Unequipped Indication . . . . . . . . . . . . . . . . 19 75 7.1.3. CEP-RDI: Remote Defect Indication . . . . . . . . . . 20 76 7.2. PSN to SONET/SDH . . . . . . . . . . . . . . . . . . . . . 20 77 7.2.1. CEP-AIS: AIS-P/V Indication . . . . . . . . . . . . . 20 78 7.2.2. Unequipped Indication . . . . . . . . . . . . . . . . 20 80 8. SONET/SDH Transport Timing . . . . . . . . . . . . . . . . . . 22 82 9. SONET/SDH Pointer Management . . . . . . . . . . . . . . . . . 23 83 9.1. Explicit Pointer Adjustment Relay (EPAR) . . . . . . . . . 23 84 9.2. Adaptive Pointer Management (APM) . . . . . . . . . . . . 25 86 10. CEP Performance Monitors . . . . . . . . . . . . . . . . . . . 26 87 10.1. Near-End Performance Monitors . . . . . . . . . . . . . . 26 88 10.2. Far-End Performance Monitors . . . . . . . . . . . . . . . 27 90 11. Payload Compression Options . . . . . . . . . . . . . . . . . 28 91 11.1. Dynamic Bandwidth Allocation . . . . . . . . . . . . . . . 28 92 11.2. Service-Specific Payload Formats . . . . . . . . . . . . . 28 93 11.2.1. Fractional STS-1 (VC-3) Encapsulation . . . . . . . . 29 94 11.2.1.1. Fractional STS-1 CEP header . . . . . . . . . . . 30 95 11.2.1.2. B3 Compensation . . . . . . . . . . . . . . . . . 31 96 11.2.1.3. Actual Payload Size . . . . . . . . . . . . . . . 32 97 11.2.2. Asynchronous T3/E3 STS-1 (VC-3) Encapsulation . . . . 32 98 11.2.2.1. T3 payload compression . . . . . . . . . . . . . 33 99 11.2.2.2. E3 payload compression . . . . . . . . . . . . . 33 100 11.2.3. Fractional VC-4 Encapsulation . . . . . . . . . . . . 33 101 11.2.3.1. Fractional VC-4 Mapping . . . . . . . . . . . . . 35 102 11.2.3.2. Fractional VC-4 CEP Header . . . . . . . . . . . 35 103 11.2.3.3. B3 Compensation . . . . . . . . . . . . . . . . . 37 104 11.2.3.4. Actual Payload Sizes . . . . . . . . . . . . . . 37 106 12. Signaling of CEP Pseudo Wires . . . . . . . . . . . . . . . . 39 107 12.1. CEP/TDM Payload Bytes . . . . . . . . . . . . . . . . . . 39 108 12.2. CEP/TDM Bit Rate . . . . . . . . . . . . . . . . . . . . . 40 109 12.3. CEP Options . . . . . . . . . . . . . . . . . . . . . . . 40 111 13. Congestion Control . . . . . . . . . . . . . . . . . . . . . . 43 113 14. Security Considerations . . . . . . . . . . . . . . . . . . . 44 115 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 117 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 46 119 Appendix A. SONET/SDH Rates and Formats . . . . . . . . . . . . . 47 121 Appendix B. Example Network Diagrams . . . . . . . . . . . . . . 49 123 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51 124 17.1. Normative References . . . . . . . . . . . . . . . . . . . 51 125 17.2. Informative References . . . . . . . . . . . . . . . . . . 52 127 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54 128 Intellectual Property and Copyright Statements . . . . . . . . . . 55 130 1. Requirements Notation 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Co-Authors 138 The individuals listed below are co-authors of this document. Tom 139 Johnson from Litchfield Communication was the editor of this document 140 from the pre-WG versions of the SONET SPE work through version 01 of 141 this document. 143 Craig White Level3 Communications 145 Ed Hallman Litchfield Communications 147 Jeremy Brayley Laurel Networks 149 Jim Boyle Juniper Networks 151 John Shirron Laurel Networks 153 Luca Martini Cisco Systems 155 Marlene Drost Litchfield Communications 157 Steve Vogelsang Laurel Networks 159 Tom Johnson Litchfield Communications 161 Ken Hsu Tellabs 163 3. Acronyms 165 ADM Add Drop Multiplexer 167 AIS Alarm Indication Signal 169 APM Adaptive Pointer Management 171 AU-n Administrative Unit-n (SDH) 173 AUG Administrative Unit Group (SDH) 175 BIP Bit Interleaved Parity 177 BITS Building Integrated Timing Supply 179 CEP Circuit Emulation over Packet 181 DBA Dynamic Bandwidth Allocation 183 EBM Equipped Bit Mask 185 EPAR Explicit Pointer Adjustment Relay 187 LOF Loss of Frame 189 LOS Loss of Signal 191 LTE Line Terminating Equipment 193 PSN Packet Switched Network 195 POH Path Overhead 197 PTE Path Terminating Equipment 199 PW Pseudo-Wire 201 RDI Remote Defect Indication 203 SDH Synchronous Digital Hierarchy 205 SONET Synchronous Optical Network 207 SPE Synchronous Payload Envelope 209 STM-n Synchronous Transport Module-n (SDH) 210 STS-n Synchronous Transport Signal-n (SONET) 212 TDM Time Division Multiplexing 214 TOH Transport Overhead 216 TU-n Tributary Unit-n (SDH) 218 TUG-n Tributary Unit Group-n (SDH) 220 UNEQ Unequipped 222 VC-n Virtual Container-n (SDH) 224 VT Virtual Tributary (SONET) 226 VTG Virtual Tributary Group (SONET) 228 4. Scope 230 The generic requirements and architecture for Pseudo Wire Emulation 231 Edge-to-Edge (PWE3) are described in [PWE3-REQ] and [PWE3-ARCH]. 232 Additional requirements for emulation of SONET/SDH and lower-rate TDM 233 circuits are described in [PWE3-TDM-REQ]. 235 This document provides encapsulation formats and semantics for 236 emulating SONET/SDH circuits and services over MPLS packet-switched 237 network (PSN). Emulation of the following digital signals are 238 defined: 240 1. Synchronous Payload Envelope (SPE)/Virtual Container (VC-n): STS- 241 1/VC-3, STS-3c/VC-4, STS-12c/VC-4-4c, STS-48c/VC-4-16c, STS-192c/ 242 VC-4-64c, etc. 244 2. Virtual Tributary (VT)/Virtual Container (VC-n): VT1.5/VC-11, 245 VT2/VC-12, VT3, VT6/VC-2 247 For the remainder of this document, these constructs are referred to 248 as SONET/SDH channels. 250 5. CEP Encapsulation Format 252 In order to transport SONET/SDH circuits through a packet-oriented 253 network, the SPE (or VT) is broken into fragments, and a CEP Header 254 and optionally an RTP header are pre-pended to each fragment. 256 The basic CEP packet appears in Figure 1. 258 +-----------------------------------+ 259 | PSN and Multiplexing Layer | 260 | Headers | 261 +-----------------------------------+ 262 | CEP Header | 263 +-----------------------------------+ 264 | RTP Header | 265 | (RFC3550) | 266 +-----------------------------------+ 267 | | 268 | | 269 | SONET/SDH | 270 | Fragment | 271 | | 272 | | 273 +-----------------------------------+ 275 Figure 1: Basic CEP Packet 277 5.1. SONET/SDH Fragment 279 The SONET/SDH Fragments MUST be byte aligned with the SONET/SDH SPE 280 or VT. The first bit received from each byte of the SONET/SDH MUST 281 be the Most Significant Bit of each byte in the SONET/SDH fragment. 283 SONET/SDH bytes are placed into the SONET/SDH fragment in the same 284 order in which they are received. 286 SONET/SDH optical interfaces use binary coding and therefore are 287 scrambled prior to transmission to ensure an adequate number of 288 transitions. For clarity, this scrambling is referred to as physical 289 layer scrambling/descrambling. 291 In addition, many payload formats (such as for ATM and HDLC) include 292 an additional layer of scrambling to provide protection against 293 transition density violations within the SPEs. This function is 294 referred to as payload scrambling/descrambling. 296 CEP assumes that physical layer scrambling/unscrambling occurs as 297 part of the SONET/SDH section/line termination Native Service 298 Processing (NSP) functions. 300 However, CEP makes no assumption about payload scrambling. The 301 SONET/SDH fragments MUST be constructed without knowledge or 302 processing of any incidental payload scrambling. 304 CEP implementations MUST include the H3 (or V3) byte in the SONET/SDH 305 fragment during negative pointer adjustment events, and MUST remove 306 the stuff-byte from the SONET/SDH fragment during positive pointer 307 adjustment events. 309 VT emulation implementations MUST NOT carry the VT pointer bytes V1, 310 V2, V3 and V4 as part of the CEP payload. The only exception being 311 carriage of V3 during negative pointer adjustment as described above. 313 All CEP SPE Implementations MUST support a packet size of 783 Bytes 314 and MAY support other packet sizes. 316 VT emulation implementations MUST support payload size of full VT 317 super-frame, and MAY support 1/2 and 1/4 VT super-frame payload 318 sizes. 320 Table 1 below describes single super-frame payload size per VT type. 322 +-------------+--------------+ 323 | VT type | Size (Bytes) | 324 +-------------+--------------+ 325 | VT1.5/VC-11 | 104 | 326 | | | 327 | VT2/VC-12 | 140 | 328 | | | 329 | VT3 | 212 | 330 | | | 331 | VT6/VC-2 | 428 | 332 +-------------+--------------+ 334 Table 1: VT Super-frame Payload Sizes 336 OPTIONAL SONET/SDH Fragment formats have been defined to reduce the 337 bandwidth requirements of the emulated SONET/SDH circuits under 338 certain conditions. These OPTIONAL formats are included in 339 Section 11. 341 5.2. CEP Header 343 The CEP Header supports both a basic and extended mode. The Basic 344 CEP Header provides the minimum functionality necessary to accurately 345 emulate a SONET/SDH circuit over a PSN. Extended headers are 346 utilized for some of the OPTIONAL SONET/SDH fragment formats 347 described in Section 11. 349 Enhanced functionality and commonality with other real-time Internet 350 applications is provided by RTP encapsulation. 352 The CEP Header has the following format: 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 |0|0|0|0|L|R|N|P|FRG|Length[0:5]| Sequence Number[0:15] | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Reserved |Structure Pointer[0:11]| 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 Figure 2: CEP Header Format 364 L bit: CEP-AIS. This bit MUST be set to one to signal to the 365 downstream PE that a failure condition has been detected on the 366 attachment circuit. Failure conditions leading to generation of 367 CEP-AIS and the mapping of CEP-AIS signal on the downstream 368 attachment circuit are described in Section 7. 370 R bit: CEP-RDI. This bit MUST be set to one to signal to the 371 upstream PE that a loss of packet synchronization has occurred. 372 This bit MUST be set to zero once packet synchronization is 373 acquired. See Section 6.2 for details. 375 N and P bits: These bits are used to explicitly relay negative and 376 positive pointer adjustments events across the PSN. The use of N 377 and P bits is OPTIONAL. If not used, N and P bits MUST be set to 378 zero. See Section 9 for details. 380 Table 2 describes the interpretation of N and P bits settings. 382 +---+---+-----------------------------+ 383 | N | P | Interpretation | 384 +---+---+-----------------------------+ 385 | 0 | 0 | No Pointer Adjustments | 386 | | | | 387 | 0 | 1 | Positive Pointer Adjustment | 388 | | | | 389 | 1 | 0 | Negative Pointer Adjustment | 390 | | | | 391 | 1 | 1 | Loss of Pointer Alarm | 392 +---+---+-----------------------------+ 394 Table 2: Interpretation of N and P bits 396 FRG bits: FRG bits MUST be set to zero by sender and ignored by 397 receiver. 399 SONET data is continuously fragmented into packets. The structure 400 pointer field designates the offset between the SONET SPE or VT 401 structure and the packet boundary. 403 Length [0:5]: The Length field, if other than zero, indicates the 404 length of the CEP Header, plus the length of the RTP header if 405 used, plus the length of the payload. The Length field MUST be 406 set if the length of CEP Header plus RTP header if used, plus 407 payload is less or equal to 64 bytes and MUST be set to zero 408 otherwise. In particular, if the payload is suppressed (e.g. 409 DBA) the Length field MUST be set to the CEP Header length plus 410 the RTP header length if used. 412 Sequence Number [0:15]: The packet sequence number MUST 413 continuously cycle from 0 to 0xFFFF. It is generated and 414 processed in accordance with the rules established in [RTP]. 416 Structure Pointer [0:11]: The Structure Pointer MUST contain the 417 offset of the first byte of the SONET structure within the packet 418 payload. For SPE emulation, the structure pointer locates the J1 419 byte within the CEP packet. For VT emulation the structure 420 pointer locates the V5 byte within the packet. The structure 421 pointer value ranges between 0 to 0xFFE, where 0 represents the 422 first byte after the CEP header. The Structure Pointer MUST be 423 set to 0xFFF if a packet does not carry the J1 (or V5) byte. An 424 arbitrary pointer change (NDF event) in the attachment circuit 425 changes the offset of the SONET structure within the CEP packet 426 and therefore changes the Structure Pointer value. 428 Reserved Field: The reserved field MUST be set to zero by the 429 sender and ignored by receiver. 431 5.3. RTP Header 433 Usage of RTP header is OPTIONAL. Although CEP MAY employ an RTP 434 header when explicit transfer of timing information is required, this 435 is purely formal reuse of the header format. RTP mechanisms, such as 436 header extensions, CSRC list, padding, RTCP, RTP header compression, 437 SRTP, etc. are not applicable to pseudowires. CEP uses the RTP 438 Header as shown below. 440 0 1 2 3 441 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 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 |V=2|P|X| CC |M| PT | Sequence Number | 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 | Timestamp | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Synchronization Source (SSRC) Identifier | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 3: RTP Header 452 V : Version. The Version field MUST be set to 2. 454 P : Padding. No padding is required. The P bit MUST be set to 0 455 by sender and ignored by receiver. 457 X : Header extension. No extensions are defined. The X bit MUST 458 be set to 0 by sender and ignored by receiver. 460 CC: CSRC count. CC field MUST be set to zero by sender and 461 ignored by receiver. 463 M : Marker. The M bit MUST be set to 0 by sender and ignored by 464 receiver. 466 PT [0:6]: Payload type. A PT value SHOULD be allocated from the 467 range of dynamic values for each direction of the PW. The same PT 468 value MAY be reused for both direction as well as between 469 different CEP PWs. 471 Sequence Number [0:15]: The packet sequence number MUST 472 continuously cycle from 0 to 0xFFFF. It is generated and 473 processed in accordance with the rules established in [RTP]. The 474 CEP receiver MUST sequence packets according to the sequence 475 number field of the CEP header and MAY verify correct sequencing 476 using RTP sequence number field. 478 Timestamp [0:31]: Timestamp values are used in accordance with the 479 rules established in [RTP]. Frequency of the clock used for 480 generating timestamps MUST be 19.44 MHz based on a local 481 reference. 483 SSRC [0:31]: Synchronization source. The SSRC field MAY be used 484 for detection of misconnections. 486 5.4. PSN Encapsulation 488 This document defines the transport of CEP over MPLS PSNs. The 489 bottom label in the MPLS label stack MUST be used to de-multiplex 490 individual CEP channels. In keeping with the conventions used in 491 [PWE3-CONTROL], this de-multiplexing label is referred to as the PW 492 Label and the upper labels are referred to as Tunnel Labels. The CEP 493 Header follows the generic PWE3 Control Word format specified in 494 [PWE3-MPLSCW] for use over an MPLS PSN. 496 Transport of CEP over other PSN technologies are out of scope of this 497 document. 499 6. CEP Operation 501 A CEP implementation MUST support a normal mode of operation and MAY 502 support additional bandwidth conserving modes as described in 503 Section 11. During normal operation, SONET/SDH payloads are 504 fragmented, pre-pended with the appropriate headers and then 505 transmitted into the packet network. 507 6.1. CEP Packetizer and De-Packetizer 509 As with all adaptation functions, CEP has two distinct components: 510 adapting TDM SONET/SDH into a CEP packet stream, and converting the 511 CEP packet stream back into a TDM SONET/SDH. The first function is 512 referred to as CEP Packetizer or sender and the second as CEP De- 513 Packetizer or receiver. This terminology is illustrated below. 515 +------------+ +---------------+ 516 | | | | 517 SONET --> | CEP | --> PSN --> | CEP | --> SONET 518 SDH | Packetizer | | De-Packetizer | SDH 519 | | | | 520 +------------+ +---------------+ 521 (sender) (receiver) 523 Figure 4: CEP Terminology 525 The CEP de-packetizer requires a buffering mechanism to account for 526 delay variation in the CEP packet stream. This buffering mechanism 527 is generically referred to as the CEP jitter buffer. 529 During normal operation, the CEP packetizer receives a fixed rate 530 byte stream from a SONET/SDH interface. When a packet worth of data 531 is received from a SONET/SDH channel, the necessary headers are pre- 532 pended to the SPE fragment and the resulting CEP packet is 533 transmitted into the packet network. Because all CEP packets 534 associated with a specific SONET/SDH channel have the same length, 535 the transmission of CEP packets for that channel SHOULD occur at 536 regular intervals. 538 At the far end of the packet network, the CEP de-packetizer receives 539 packets into a jitter buffer and then plays out the received byte 540 stream at a fixed rate onto the corresponding SONET/SDH channel. The 541 jitter buffer SHOULD be adjustable in length to account for varying 542 network delay behavior. On average, the receive packet rate from the 543 packet network should be balanced by the transmission rate onto the 544 SONET/SDH channel. 546 The CEP sequence numbers provide a mechanism to detect lost and/or 547 miss-ordered packets. The sequence number in the CEP header MUST be 548 used when transmission of the RTP header is suppressed. The CEP de- 549 packetizer MUST detect lost or miss-ordered packets. The CEP de- 550 packetizer SHOULD play out an all ones pattern (AIS) in place of any 551 dropped packets. The CEP de-packetizer SHOULD re-order packets 552 received out of order. If the CEP de-packetizer does not support re- 553 ordering, it MUST drop miss-ordered packets. 555 6.2. Packet Synchronization 557 A key component in declaring the state of a CEP service is whether or 558 not the CEP de-packetizer is in or out of packet synchronization. 559 The following paragraphs describe how that determination is made. 561 As packets are received from the PSN, they are placed into a jitter 562 buffer prior to play out on the SONET/SDH interface. If a CEP de- 563 packetizer supports re-ordering, any packet received before its play 564 out time will still be considered valid. 566 The determination of acquisition or loss of packet synchronization is 567 always made at SONET/SDH play-out time. During SONET/SDH play-out, 568 the CEP de-packetizer will play received CEP packets onto the SONET/ 569 SDH interface. However, if the jitter buffer is empty or the packet 570 to be played out has not been received, the CEP de-packetizer will 571 play out an 'empty packet' composed of an all one AIS pattern onto 572 the SONET/SDH interface in place of the unavailable packet. 574 The acquisition of packet synchronization is based on the number of 575 sequential CEP packets that are played onto the SONET/SDH interface. 576 Loss of packet synchronization is based on the number of sequential 577 'empty' packets that are played onto the SONET/SDH interface. 578 Specific details of these two cases are described below. 580 6.2.1. Acquisition of Packet Synchronization 582 At startup, a CEP de-packetizer will be out of packet synchronization 583 by default. To declare packet synchronization at startup or after a 584 loss of packet synchronization, the CEP de-packetizer must play-out a 585 configurable number of CEP packets with sequential sequence numbers 586 towards the SONET/SDH interface. 588 6.2.2. Loss of Packet Synchronization 590 Once a CEP de-packetizer is in packet synchronization state, it may 591 encounter a set of events that will cause it to lose packet 592 synchronization. 594 If the CEP de-packetizer encounters more than a configurable number 595 of sequential empty packets, the CEP de-packetizer MUST declare a 596 loss of packet synchronization (LOPS) defect. 598 Loss of Packet Synchronization (LOPS) failure is declared after 2.5 599 +/- 0.5 seconds of LOPS defect, and cleared after 10 seconds free of 600 LOPS defect state. The circuit is considered down as long as LOPS 601 failure is declared. 603 7. SONET/SDH Maintenance Signals 605 This section describes the mapping of maintenance and alarm signals 606 between the SONET/SDH network and the CEP pseudo-wire. For clarity, 607 the mappings are split into two groups: SONET/SDH to PSN, and PSN to 608 SONET/SDH. 610 For coherent failure detection, isolation, monitoring and trouble 611 shooting, SONET/SDH failure indications MUST be transferred correctly 612 over the CEP pseudo-wire, and CEP connection failures MUST be mapped 613 to SONET/SDH SPE/VT failure indications. Failure detection 614 capabilities and performance monitoring capabilities are dependent on 615 the NSP functionality e.g. LTE, PTE, Tandem Connection Monitoring 616 [G.707], or Non-intrusive Monitoring (intermediate connection 617 monitoring). 619 7.1. SONET/SDH to PSN 621 The following sections describe the mapping of SONET/SDH Maintenance 622 Signals and Alarm conditions into CEP pseudo-wire indications. 624 7.1.1. CEP-AIS: AIS-P/V Indication 626 SONET/SDH Path outages are signaled by using maintenance alarms such 627 as Path AIS (AIS-P). AIS-P, in particular, indicates that the SONET/ 628 SDH Path is not currently transmitting valid end-user data, and the 629 SPE contains all ones. Similarly, AIS-V indicates that the VT is not 630 currently transmitting valid end-user data, and the VT contains all 631 ones. 633 It should be noted that nearly every type of service-affecting 634 section or line defect would result in an AIS-P/V condition. 636 The mapping of SONET/SDH failures into the SPE/VT layer is considered 637 part of the NSP function, and is based on the principles specified in 638 [GR253], [SONET], [G.707], [G.806], and [G.783]. For example, should 639 the SONET Section Layer detect a Loss of Signal (LOS) or Loss of 640 Frame (LOF) or Section Trace Mismatch (TIM) conditions, an AIS-L is 641 sent up to the Line Layer. If the Line Layer detects AIS-L or Loss 642 of Pointer (LOP), an AIS-P is sent to the Path Layer. If the Path is 643 terminated at the PE (i.e. a PTE) and the Path Layer detects AIS-P or 644 UNEQ-P or TIM-P or PLM-P an AIS-V is sent to the VT Layer. 646 The AIS-P/V indication is transferred to the CEP packetizer. During 647 AIS-P/V, CEP packets are generated as usual. The L-bit in the CEP 648 header MUST be set to one to signal AIS-P/V explicitly through the 649 packet network. The N and P bits SHOULD be set to 1 to indicate loss 650 of pointer indication. 652 If DBA has been enabled for AIS-P/V only the necessary headers and 653 optional padding are transmitted into the packet network. The Length 654 field MUST be set to the size of the CEP header plus the size of the 655 RTP header if used. 657 7.1.2. Unequipped Indication 659 Unequipped indication is used for bandwidth conserving modes defined 660 in Section 11 as a trigger for payload removal. 662 The declaration of SPE/VT channel as Unequipped MUST conform to 663 [GR253], [SONET], [G.806] and [G.783]. Unequipped circuits do not 664 carry valid end-user data but MAY be used for transporting valid 665 information in the SPE/VT overhead bytes. Supervisory Unequipped 666 signals and Tandem Connection transport are two such applications: 668 Supervisory Unequipped signal (called TEST-P in [SONET]) is used 669 to provide a test signal for pre-service testing or in-service 670 supervision of a path connection to a remote PTE from a PTE or an 671 intermediate non-terminating path network element. Both 672 Unequipped and Supervisory Unequipped signals carry Unequipped 673 Signal Label defined to be zero. To distinguish between 674 Unequipped and Supervisory Unequipped signals [G.806] recommends 675 that the SPE/VT Trace bytes J1/J2 be set to a non-zero value in 676 Supervisory Unequipped signals. 678 The SPE/VT overhead bytes N1/Z6 (SDH refers to Z6 as N2) 679 optionally transport Tandem Connection signals between 680 intermediate network elements. Unequipped signal transporting 681 Tandem Connection would have non-zero N1 or N2/Z6 bytes. 683 Therefore, the CEP packetizer MUST declare a circuit unequipped only 684 if the Signal Label, Trace (J1/J2) and Tandem Connection (N1/N2/Z6) 685 bytes all have zero value. 687 During SPE/VT Unequipped, the N and P bits MUST be interpreted as 688 usual. The SPE/VT MUST be transmitted into the packet network along 689 with the appropriate headers. 691 If DBA has been enabled for Unequipped SPE/VT only the necessary 692 headers and optional padding are transmitted into the packet network. 693 The Length field MUST be set to the size of the CEP header plus the 694 size of the RTP header if used. The N and P bits MAY be used to 695 signal pointer adjustments as normal. 697 7.1.3. CEP-RDI: Remote Defect Indication 699 The CEP function MUST send CEP-RDI indication towards the packet 700 network during loss of packet synchronization by setting the R bit to 701 one in the CEP header. The CEP function SHOULD clear the R bit once 702 packet synchronization is restored. 704 7.2. PSN to SONET/SDH 706 The following sections describe the mapping of pseudo-wire 707 indications to SONET/SDH Maintenance Signals and Alarm conditions. 709 7.2.1. CEP-AIS: AIS-P/V Indication 711 There are several conditions in the packet network that cause the CEP 712 de-packetization function to play out an AIS-P/V indication towards a 713 SONET/SDH channel. The CEP de-packetizer MUST play out one packet's 714 worth of all ones for each packet received, and MUST set the SONET/ 715 SDH Overhead to signal AIS-P/V as defined in [SONET], [GR253] and 716 [G.707]. 718 The first of these is the receipt of CEP packets with the L-bit set 719 to one indicating the far-end has detected an error leading to 720 declaration of AIS-P/V alarm. In addition to the play-out of 721 AIS-P/V, the CEP de-packetizer SHOULD set the pointer value to all- 722 one value. 724 The second case that will cause a CEP de-packetization function to 725 play out an AIS-P/V indication onto a SONET/SDH channel is during 726 loss of packet synchronization. 728 The third case is the receipt of CEP packets with both the N and P 729 bit set to one. This is an explicit indication of Loss of Pointer 730 LOP-P/V received at the far-end of the packet network. In addition 731 to play-out of AIS-P/V, the CEP de-packetizer SHOULD set the pointer 732 value to all-one value. 734 7.2.2. Unequipped Indication 736 There are several conditions in the packet network that cause the CEP 737 function to transmit Unequipped indications onto the SONET/SDH 738 channel. 740 The first, which is transparent to CEP, is the receipt of regular CEP 741 packets that happen to carry an SPE/VT containing the appropriate 742 Path overhead or VT overhead set to unequipped. This case does not 743 require any special processing on the part of the CEP de-packetizer. 745 The second case is the receipt of CEP packets with Length field 746 indicating payload was removed by DBA, while the L-bit set to zero, 747 indicating that DBA was triggered by Unequipped indication and not by 748 AIS-P/V indication. The CEP de-packetizer MUST use this information 749 to transmit a packet of all zeros onto the SONET/SDH interface. 751 The third case when a CEP de-packetizer MUST play out an SPE/VT 752 Unequipped Indication towards the SONET/SDH interface is when the 753 circuit has been de-provisioned. 755 8. SONET/SDH Transport Timing 757 It is assumed that the distribution of SONET/SDH transport timing 758 information is addressed either through external mechanisms such as 759 Building Integrated Timing System (BITS), Stand Alone Synchronization 760 Equipment (SASE), Global Positioning System (GPS) or other such 761 methods, or is obtained through an adaptive timing recovery 762 mechanism. 764 Details about specific adaptive algorithms for recovery of SONET/SDH 765 transport timing are not considered to be within scope for this 766 document. The wander and jitter limits for networks based on the SDH 767 hierarchy are defined in [G.825] and for the SONET hierarchy in 768 [GR253]. The wander and jitter limits specified in these standards 769 must be maintained when CEP PWs are used. 771 9. SONET/SDH Pointer Management 773 A pointer management system is defined as part of the definition of 774 SONET/SDH. Details on SONET/SDH pointer management can be found in 775 [SONET], [GR253], [G.707] and [G.783]. If there is a frequency 776 offset between the frame rate of the transport overhead and that of 777 the SONET/SDH SPE, the alignment of the SPE will periodically slip 778 back or advance in time through positive or negative stuffing. 779 Similarly, if there is a frequency offset between the SPE rate and 780 the VT rate it carries, the alignment of the VT will periodically 781 slip back or advance in time through positive or negative stuffing 782 within the SPE. 784 The emulation of this aspect of SONET/SDH networks may be 785 accomplished using a variety of techniques including Explicit Pointer 786 Adjustment Relay (EPAR) and Adaptive Pointer Management (APM). 788 In any case, the handling of the SPE or VT data by the CEP packetizer 789 is the same. 791 During a negative pointer adjustment event, the CEP packetizer MUST 792 incorporate the H3 (or V3) byte from the SONET/SDH stream into the 793 CEP packet payload in order with the rest of the SPE (or VT). During 794 a positive pointer adjustment event, the CEP packetizer MUST strip 795 the stuff byte from the CEP packet payload. 797 When playing out a negative pointer adjustment event, the appropriate 798 byte of the CEP payload MUST be placed into the H3 (or V3) byte of 799 the SONET/SDH stream. When playing out a positive pointer 800 adjustment, the CEP de-packetizer MUST insert a stuff-byte into the 801 appropriate position within the SONET/SDH stream. 803 The details regarding the use of the H3 (and V3) byte and stuff byte 804 during positive and negative pointer adjustments can be found in 805 [SONET], [GR253] and [G.707]. 807 9.1. Explicit Pointer Adjustment Relay (EPAR) 809 CEP provides an OPTIONAL mechanism to explicitly relay pointer 810 adjustment events from one side of the PSN to the other. This 811 technique is referred to as Explicit Pointer Adjustment Relay (EPAR). 812 EPAR is only effective when both ends of the PW have access to a 813 common timing reference. 815 The following text only applies to CEP implementations that choose to 816 implement EPAR. Any CEP implementation that does not support EPAR 817 MUST set the N and P bits to zero. 819 The pointer adjustment event MUST be transmitted in three consecutive 820 packets by the packetizer. The de-packetizer MUST play out the 821 pointer adjustment event when any one packet with N/P bit set is 822 received. The CEP de-packetizer MUST utilize the CEP sequence 823 numbers to insure that SONET/SDH pointer adjustment events are not 824 played any more frequently than once per every three CEP packets 825 transmitted by the remote CEP packetizer. 827 The VT EPAR packetizer MUST relay pointer adjustment indications 828 received at the SPE level in addition to relaying VT pointer 829 adjustment indications. Because of the rate differences between VT 830 and SPE, the magnitude of a VT pointer adjustment is much larger than 831 that of an SPE adjustment. Therefore, the VT EPAR packetizer has to 832 convert multiple SPE pointer adjustments to fewer VT pointer 833 adjustment indications signaled over the PSN using the N and P CEP 834 Header bits. A simple algorithm can be used for this purpose using 835 an accumulator (counter): 837 The accumulator value is reset to zero when the circuit is in Loss 838 of Packet Synchronization (LOPS) state. 840 A positive pointer adjustment indication increases the accumulator 841 value by a fixed quota while negative pointer adjustment subtracts 842 the same quota from the accumulator. A VT pointer adjustment 843 changes the accumulator value by 783 units (one STS-1 SPE size). 844 An SPE pointer adjustment changes the accumulator value by quota 845 that depends on the VT emulation type. The quota is 1/4 of the VT 846 size as defined in Table 1, e.g. 26 bytes for VT1.5 emulation and 847 35 bytes for VT2 emulation. 849 When the accumulator value is larger than or equal to 783 units a 850 positive pointer adjustment is signaled towards the PSN using the 851 CEP Header P bit and 783 units are subtracted from the 852 accumulator. 854 When the accumulator value is smaller than or equal to minus 783 855 units a negative pointer adjustment is signaled towards the PSN 856 using the CEP Header N bit and 783 units are added to the 857 accumulator. 859 The same algorithm is applicable for SDH Virtual Container carried in 860 VC-4, i.e. positive VC-4 pointer adjustment adds 35 units to a VC-12 861 accumulator while positive VC-12 pointer adjustment adds 783 units to 862 the accumulator. 864 If both N and P bits are set, then a Loss of Pointer event has been 865 detected at the PW ingress, making the pointer invalid. The de- 866 packetizer MUST play-out an AIS-P/V indication and SHOULD set the 867 pointer value to all-one value. 869 9.2. Adaptive Pointer Management (APM) 871 Another OPTIONAL method that may be used to emulate SONET/SDH pointer 872 management is Adaptive Pointer Management (APM). In basic terms, APM 873 uses information about the depth of the CEP jitter buffers to 874 introduce pointer adjustments in the reassembled SONET/SDH SPE. 876 Details about specific APM algorithms are not considered to be within 877 scope for this document. 879 10. CEP Performance Monitors 881 SONET/SDH as defined in [SONET], [GR253], [G.707] and [G.784] 882 includes a definition of several counters used to monitor the 883 performance of SONET/SDH services. These counters are referred to as 884 Performance Monitors. 886 In order for CEP to be utilized by traditional SONET/SDH network 887 operators, CEP SHOULD provide similar functionality. The following 888 sections describe a number of counters that are collectively referred 889 to as CEP Performance Monitors. 891 10.1. Near-End Performance Monitors 893 These performance monitors are maintained by the CEP de-packetizer 894 during reassembly of the SONET/SDH stream. 896 The performance monitors are based on two types of defects. 898 Type 1 : missing or dropped packet. 900 Type 2 : buffer under run, buffer over-run, LOPS, missing packets 901 above pre-defined configurable threshold. 903 The specific performance monitors defined for CEP are as follows: 905 ES-CEP - CEP Errored Seconds 907 SES-CEP - CEP Severely Errored Seconds 909 UAS-CEP - CEP Unavailable Seconds 911 Each second that contains at least one type 1 defect SHALL be 912 declared as ES-CEP. Each second that contains at least one type 2 913 defect SHALL be declared as SES-CEP. 915 UAS-CEP SHALL be declared after configurable number of consecutive 916 SES-CEP, and cleared after a configurable number of consecutive 917 seconds without SES-CEP. Default value for each is 10 seconds. 919 Once unavailability is declared, ES and SES counts SHALL be inhibited 920 up to the point where the unavailability was started. Once 921 unavailability is removed, ES and SES that occurred along the 922 clearing period SHALL be added to the ES and SES counts. 924 CEP-NE failure is declared after 2.5 +/- 0.5 seconds of CEP-NE Type-2 925 defect, and cleared after 10 seconds free of CEP-NE defect state. 926 Sending notification to the OS for CEP-NE failure is local policy. 928 10.2. Far-End Performance Monitors 930 Far-End performance monitors provide insight into the CEP de- 931 packetizer at the far-end of the PSN. 933 Far end statistics are based on the CEP-RDI indication carried in the 934 CEP Header R bit. CEP-FE defect is declared when CEP-RDI is set in 935 the incoming CEP packets. 937 CEP-FE failure is declared after 2.5 +/- 0.5 seconds of CEP-FE 938 defect, and cleared after 10 seconds free of CEP-FE defect state. 939 Sending notification to the OS for CEP-FE failure is local policy. 941 11. Payload Compression Options 943 In addition to pure emulation, CEP also offers a number of options 944 for reducing the total bandwidth utilized by the emulated circuit. 945 These options fall into two categories: Dynamic Bandwidth Allocation 946 and Service-Specific Payload Formats. 948 Dynamic Bandwidth Allocation (DBA) suppresses transmission of the CEP 949 payload altogether under certain circumstances such as AIS-P/V and 950 SPE/VT Unequipped. The use of DBA is dependent on network 951 architectures e.g. support of Tandem Connection Monitoring, test 952 signals (TEST-P) [SONET] or Supervisory Unequipped [G.806] signals. 954 Service-Specific Payload formats reduce bandwidth by suppressing 955 transmission of portions of the SPE based on specific knowledge of 956 the SPE payload. 958 Details on these payload compression options are described in the 959 following subsections. 961 11.1. Dynamic Bandwidth Allocation 963 Dynamic Bandwidth Allocation (DBA) is an OPTIONAL mechanism for 964 suppressing the transmission of the SPE (or VT) fragment when one of 965 two trigger conditions are met, AIS-P/V or SPE/VT Unequipped. 967 Implementations that support DBA MUST include a mechanism for 968 disabling DBA on a channel-by-channel basis to allow for 969 interoperability with implementations that do not support DBA. 971 When a DBA trigger is recognized at PW ingress, the CEP payload will 972 be suppressed. The CEP Length field MUST be set to the CEP header 973 length plus the RTP header length if used, and padding bytes SHOULD 974 be added if the intervening packet network has a minimum packet size 975 which is larger than the payload-suppressed DBA packet. 977 Other than the suppression of the CEP payload, the CEP behavior 978 during DBA should be equivalent to normal CEP behavior. In 979 particular, the packet transmission rate during DBA should be 980 equivalent to the normal packet transmission rate. 982 11.2. Service-Specific Payload Formats 984 In addition to the standard payload encapsulations for SPE and VT 985 transport, several OPTIONAL payload formats have been defined to 986 provide varying amounts of payload compression depending on the type 987 and amount of user traffic present within the SPE. These are 988 described below. 990 11.2.1. Fractional STS-1 (VC-3) Encapsulation 992 Fractional STS-1 (VC-3) encapsulation carries only a selected set of 993 VTs within an STS-1 container. This mode is applicable for STS-1 994 with POH signal label byte C2=2 (VT-structured SPE) and for C2=3 995 (Locked VT mode). 997 Implementations of fractional STS-1 (VC-3) encapsulation MUST support 998 payload length of one SPE and MAY support payload length of 1/3 SPE. 1000 The mapping of VTs into an STS-1 container is described in section 1001 3.2.4 of [GR253] and the mapping into VC-3 is defined in section 1002 7.2.4 in [G.707]. The CEP packetizer removes all fixed column bytes 1003 (columns 30 and 59) and all bytes belonging to the removed VTs. Only 1004 STS-1 POH bytes and bytes that belong to the selected VTs are carried 1005 within the payload. The CEP de-packetizer adds the fixed stuff bytes 1006 and generates unequipped VT data replacing the removed VT bytes. 1008 The figure below illustrates VT1.5 mapping into an STS-1 SPE. 1010 1 2 3 * * * 29 30 31 32 * * * 58 59 60 61 * * * 87 1011 +--+------------------+-+------------------+-+------------------+ 1012 1 |J1| Byte 1 (V1-V4) |R| | | | |R| | | | | 1013 +--+---+---+------+---+-+------------------+-+------------------+ 1014 2 |B3|VT | | | |R| | | | |R| | | | | 1015 +--+1.5| | | +-+---+---+------+---+-+------------------+ 1016 3 |C2| | | | |R| | | | |R| | | | | 1017 +--+ | | | +-+---+---+------+---+-+------------------+ 1018 4 |G1| | | | |R| | | | |R| | | | | 1019 +--+ | | | +-+---+---+------+---+-+------------------+ 1020 5 |F2| | | | |R| | | | |R| | | | | 1021 +--|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4|-|1-1|2-1| * * *|7-4| 1022 6 |H4| | | | |R| | | | |R| | | | | 1023 +--+ | | | +-+---+---+------+---+-+------------------+ 1024 7 |Z3| | | | |R| | | | |R| | | | | 1025 +--+ | | | +-+---+---+------+---+-+------------------+ 1026 8 |Z4| | | | |R| | | | |R| | | | | 1027 +--+ | | | +-+---+---+------+---+-+------------------+ 1028 9 |Z5| | | | |R| | | | |R| | | | | 1029 +--+---+---+------+---+-+---+---+------+---+-+------------------+ 1030 | | | 1031 +-- Path Overhead +--------------------+-- Fixed Stuffs 1033 Figure 5: SONET SPE Mapping of VT1.5 1035 The SPE always contains seven interleaved VT groups (VTGs). Each VTG 1036 contains a single type of VT, and each VTG occupies 12 columns (108 1037 bytes) within each SPE. A VTG can contain 4 VT1.5s (T1s), 3 VT2s 1038 (E1s), 2 VT3s or a single VT6. Altogether, the SPE can carry 28 T1s 1039 or carry 21 E1s. 1041 The fractional STS-1 encapsulation can optionally carry a bit mask 1042 that specifies which VTs are carried within the STS-1 payload and 1043 which VTs have been removed. This optional bit mask attribute allows 1044 the ingress circuit emulation node to remove an unequipped VT on the 1045 fly, providing the egress circuit emulation node enough information 1046 for reconstructing the VTs in the right order. The use of bit mask 1047 enables on-the-fly compression, whereby only equipped VTs (carrying 1048 actual data) are sent. 1050 11.2.1.1. Fractional STS-1 CEP header 1052 The fractional STS-1 CEP header uses the STS-1 CEP header 1053 encapsulation as defined in this draft. Optionally, an additional 4 1054 byte header extension word is added. 1056 The extended header has the following format: 1058 0 1 2 3 1059 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 1060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1061 |0|0|0|0|L|R|N|P|FRG|Length[0:5]| Sequence Number[0:15] | 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Reserved |Structure Pointer[0:11]| 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 |0|0|0|0| Equipped Bit Mask (EBM) [0:27] | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1068 Figure 6: Extended Fractional STS-1 Header 1070 The L, R, N, P, FRG, Length, Sequence Number and Structured Pointer 1071 fields are used as defined in this draft for STS-1 encapsulation. 1073 Each bit within the Equipped Bit Mask (EBM) field refers to a 1074 different VT within the STS-1 container. A bit set to 1 indicates 1075 that the corresponding VT is equipped, hence carried within the 1076 fractional STS-1 payload. 1078 The STS-1 EBM has the following format: 1080 0 1 2 1081 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 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | VTG7 | VTG6 | VTG5 | VTG4 | VTG3 | VTG2 | VTG1 | 1084 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 Figure 7: Equipped Bit Mask (EBM) for fractional STS-1 1088 The 28 bits of the EBM are divided into groups of 4 bits, each 1089 corresponding to a different VTG within the STS container. All 4 1090 bits are used to indicate whether VT1.5 (T1) tributaries are carried 1091 within a VTG. The first 3 bits read from right to left are used to 1092 indicate whether VT2 (E1) tributaries are carried within a VTG. The 1093 first two bits are used to indicate whether VT3 (DS1C) tributaries 1094 are carried within a VTG. The right most bit is used to indicate 1095 whether a VT6 (DS2) is carried within the VTG. The VTs within the 1096 VTG are numbered from right to left, starting from the first VT as 1097 the first bit on the right. For example, the EBM of a fully occupied 1098 STS-1 with VT1.5 tributaries is all ones, while that of an STS-1 1099 fully occupied with VT2 (E1) tributaries has the binary value 1100 0111011101110111011101110111. 1102 11.2.1.2. B3 Compensation 1104 Fractional STS-1 encapsulation can be implemented in Line Terminating 1105 Equipment (LTE) or in Path Terminating Equipment (PTE). PTE 1106 implementations terminate the path layer at the ingress PE and 1107 generate a new path layer at the egress PE. 1109 LTE implementations do not terminate the path layer, and therefore 1110 need to keep the content and integrity of the POH bytes across the 1111 PSN. In LTE implementations, special care must be taken to maintain 1112 the B3 bit-wise parity POH byte. The B3 compensation algorithm is 1113 defined below. 1115 Since the BIP-8 value in a given frame reflects the parity check over 1116 the previous frame, the changes made to BIP-8 bits in the previous 1117 frame shall also be considered in the compensation of BIP-8 in the 1118 current frame. Therefore the following equation shall be used for 1119 compensation of the individual bits of the BIP-8: 1121 B3[i]'(t) = B3[i](t-1) || B3[i]'(t-1) || B3[i](t) || B*3[i](t-1) 1123 Where: 1125 B3[i] = the existing B3[i] value in the incoming signal 1127 B3[i]' = the new (compensated) B3[i] value. 1129 B3*[i] = the B3[i] value of the unequipped VTs in the incoming 1130 signal. 1132 || = exclusive OR operator. 1134 t = the time of the current frame. 1136 t-1 = the time of the previous frame. 1138 The egress PE MUST reconstruct the unequipped VTs and modify the B3 1139 parity value in the same manner to accommodate for the additional VTs 1140 added. In this way the end-to-end BIP is preserved. 1142 11.2.1.3. Actual Payload Size 1144 The actual CEP payload size depends on the number of virtual 1145 tributaries carried within the fractional SPE. The contributions of 1146 each tributary to the fractional STS-1 payload size as well as the 1147 path overhead contribution are described below. 1149 Each VT1.5 contributes 27 bytes 1151 Each VT2 contributes 36 bytes 1153 Each VT3 contributes 54 bytes 1155 Each VT6 contributes 108 bytes 1157 STS-1 POH contributes 9 bytes 1159 For example, a fractional STS-1 carrying 7 VT2 circuit in full-SPE 1160 encapsulation would have an actual size of 261=36*7+9 bytes. Divide 1161 by 3 to calculate the third-SPE encapsulation actual payload sizes. 1163 11.2.2. Asynchronous T3/E3 STS-1 (VC-3) Encapsulation 1165 Asynchronous T3/E3 STS-1 (VC-3) encapsulation is applicable for 1166 signals with POH signal label byte C2=4, carrying asynchronously 1167 mapped T3 or E3 signals. 1169 Implementations of asynchronous T3/E3 STS-1 (VC-3) encapsulation MUST 1170 support payload length of one SPE and MAY support payload length of 1171 1/3 SPE. 1173 11.2.2.1. T3 payload compression 1175 A T3 is encapsulated asynchronously into an STS-1 SPE using the 1176 format defined in section 3.4.2.1 of [GR253]. The STS-1 SPE is then 1177 encapsulated as defined in this draft. 1179 Optionally, the STS-1 SPE can be compressed by removing the fixed 1180 columns leaving only data columns. STS-1 columns are numbered 1 to 1181 87, starting from the POH column numbered 1. The following columns 1182 have fixed values and are removed: 2, 3, 30, 31, 59 and 60. 1184 Bandwidth saving is approximately 7% (6 columns out of 87). The B3 1185 parity byte need not be modified as the parity of the fixed columns 1186 amounts to zero. The actual payload size for full-SPE encapsulation 1187 would be 729 bytes and 243 bytes for third-SPE encapsulation. 1189 A T3 is encapsulated asynchronously into a VC-3 container as 1190 described in section 10.1.2.1 of [G.707]. VC-3 container has only 85 1191 data columns, which is identical to the STS-1 container with the two 1192 fixed stuff columns 30 and 59 removed. Other than that, the mapping 1193 is identical. 1195 11.2.2.2. E3 payload compression 1197 An E3 is encapsulated asynchronously into a VC-3 SPE using the format 1198 defined in section 10.1.2.2 of [G.707]. The VC-3 SPE is then 1199 encapsulated as defined in this draft. 1201 Optionally, the VC3 SPE can be compressed by removing the fixed 1202 columns leaving only data columns. VC-3 columns are numbered 1 to 85 1203 (and not 87), starting from the POH column numbered 1. The following 1204 columns have fixed values and are removed: 2, 6, 10, 14, 18, 19, 23, 1205 27, 31, 35, 39, 44, 48, 52, 56, 60, 61, 65, 69, 73, 77 and 81. 1207 Bandwidth saving is approximately 28% (24 columns out of 85). The B3 1208 parity byte need not be modified as the parity of the fixed columns 1209 amounts to zero. The actual payload size for full-SPE encapsulation 1210 would be 567 bytes and 189 bytes for third-SPE encapsulation. 1212 11.2.3. Fractional VC-4 Encapsulation 1214 SDH defines a mapping of VC-11, VC-12, VC-2 and VC-3 directly into 1215 VC-4. This mapping does not have an equivalent within the SONET 1216 hierarchy. The VC-4 mapping is common in SDH implementations. 1218 VC-4 <--x3-- TUG-3 <--------x1-------- TU-3 <-- VC-3 <---- E3/T3 1219 | 1220 +--x7-- TUG-2 <--x1-- TU-2 <-- VC-2 <---- DS2 1221 | 1222 +----x3---- TU-12 <-- VC-12<---- E1 1223 | 1224 +----x4---- TU-11 <-- VC-11<---- T1 1226 Figure 8: Mapping of VCs into VC-4 1228 Figure 8 describes the mapping options of VCs into VC-4. A VC-4 1229 contains three TUG-3s. Each TUG-3 is composed of either a single 1230 TU-3, or 7 TUG-2s. A TU-3 contains a single VC-3. A TUG-2 contains 1231 either 4 VC-11s (T1s), 3 VC-12s (E1s) or one VC-2. Therefore a VC-4 1232 may contain 3 VC-3s, 1 VC-3 and 42 VC-12s, 63 VC-12s, etc. 1234 Fractional VC-4 encapsulation carries only a selected set of VCs 1235 within a VC-4 container. This mode is applicable for VC-4 with POH 1236 signal label byte C2=2 (TUG structure) and for C2=3 (Locked TU-n). 1237 The mapping of VCs into a VC-4 container is described in section 7.2 1238 of [G.707]. The CEP packetizer removes all fixed column bytes and 1239 all bytes that belong to the removed VCs. Only VC-4 POH bytes and 1240 bytes that belong to the selected VCs are carried within the payload. 1241 The CEP de-packetizer adds the fixed stuff bytes and generates 1242 unequipped VC data replacing the removed VC bytes. 1244 The fractional VC-4 encapsulation can optionally carry a bit mask 1245 that specifies which VCs are carried within the VC-4 payload and 1246 which VCs have been removed. This optional bit mask attribute allows 1247 the ingress circuit emulation node to remove an unequipped VCs on the 1248 fly, providing the egress circuit emulation node enough information 1249 for reconstructing the VCs in the right order. The use of bit mask 1250 enables on-the-fly compression, whereby only equipped VCs (carrying 1251 actual data) are sent. 1253 VC-3 carrying asynchronous T3/E3 signals within the VC-4 container 1254 can optionally be compressed by removing the fixed column bytes as 1255 described in Section 11.2.2, providing additional bandwidth saving. 1257 Implementations of fractional VC-4 encapsulation MUST support payload 1258 length of 1/3 SPE and MAY support payload lengths of 4/9, 5/9, 6/9, 1259 7/9, 8/9 and full SPE. The actual payload size of fractional VC-4 1260 encapsulation depends on the number of VCs carried within the 1261 payload. 1263 11.2.3.1. Fractional VC-4 Mapping 1265 [G.707] defines the mapping of TUG-3 to a VC-4 in section 7.2.1. 1266 Each TUG-3 includes 86 columns. TUG-3#1, TUG-3#2 and TUG-3#3 are 1267 byte multiplexed, starting from column 4. Column 1 is the VC-4 POH, 1268 while columns 2 and 3 are fixed, and therefore removed within the 1269 fractional VC-4 encapsulation. 1271 The mapping of TU-3 into TUG-3 is defined in section 7.2.2 of 1272 [G.707]. The TU-3 consists of the VC-3 with a 9-byte VC-3 POH and 1273 the TU-3 pointer. The first column of the 9-row by 86-column TUG-3 1274 is allocated to the TU-3 pointer (bytes H1, H2, H3) and fixed stuff. 1275 The phase of the VC-3 with respect to the TUG-3 is indicated by the 1276 TU-3 pointer. 1278 The mapping of TUG-2 into TUG-3 is defined in section 7.2.3 of 1279 [G.707]. The first two columns of the TUG-3 are fixed and therefore 1280 removed in the fractional VC-4 encapsulation. The 7 TUG-2, each 12 1281 columns wide, are byte multiplexed starting from column 3 of the 1282 TUG-3. This is the equivalent of multiplexing 7 VTGs within STS-1 1283 container in SONET terminology, except for the location of the fixed 1284 columns. 1286 The static fractional VC-4 mapping assumes that both the ingress and 1287 egress nodes are pre configured with the set of equipped VCs carried 1288 within the fractional VC-4 encapsulation. The ingress emulation edge 1289 removes the fixed columns as well as columns of the VCs agreed upon 1290 by the two edges, and updates the B3 VC-4 byte. The egress side adds 1291 the fixed columns and the unequipped VCs and updates B3. 1293 11.2.3.2. Fractional VC-4 CEP Header 1295 The fractional VC-4 CEP header uses the VC-4 CEP header defined in 1296 this draft. Optionally, an additional 12 byte header extension word 1297 is added. 1299 The extended header has the following format: 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 |0|0|0|0|L|R|N|P|FRG|Length[0:5]| Sequence Number[0:15] | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Reserved |Structure Pointer[0:11]| 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 |0|0| Equipped Bit Mask #1 (EBM) [0:29] TUG-3#1 | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 |0|0| Equipped Bit Mask #2 (EBM) [0:29] TUG-3#2 | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 |0|0| Equipped Bit Mask #3 (EBM) [0:29] TUG-3#3 | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 Figure 9: Extended Fractional VC-4 Header 1317 The L, R, N, P, FRG, Length, Sequence Number and Structured Pointer 1318 fields are used as defined in this draft for STS-1 encapsulation. 1320 Each bit within the Equipped Bit Mask (EBM) field refers to a 1321 different tributary within the VC-4 container. A bit set to 1 1322 indicates that the corresponding tributary is equipped, hence carried 1323 within the fractional VC-4 payload. 1325 Three EBM fields are used. Each EBM field corresponds to a different 1326 TUG-3 within the VC-4. The EBM includes 7 groups of 4 bits per 1327 TUG-2.A bit set to 1 indicates that the corresponding VC is equipped, 1328 hence carried within the fractional VC-4 payload. Additional 2 bit 1329 within the EBM indicates whether VC-3 carried within the TUG-3 is 1330 equipped and whether it is in AIS mode. 1332 The VC-4 EBM has the following format: 1334 0 1 2 1335 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 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 |A|T|TUG2#7 |TUG2#6 |TUG2#5 |TUG2#4 |TUG2#3 |TUG2#2 |TUG2#1 | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 Figure 10: Equipped Bit Mask (EBM) for fractional VC-4 1342 The 30 bits of the EBM are divided into two bits that control the 1343 VC-3 within the TUG-3 and 7 groups of 4 bits, each corresponding to a 1344 different TUG-2 within the TUG-3 container. 1346 For a TUG-3 containing TUG-2, the first two A and T bits MUST be set 1347 to zero. The TUG-2 bits indicate whether the VCs within the TUG-2 1348 are equipped. All 4 bits are used to indicate whether VC-11 (T1) 1349 tributaries are carried within a TUG-2. The first 3 bits read right 1350 to left are used to indicate whether VC-12 (E1) tributaries are 1351 carried within a TUG-2. The first bit is used to indicate a VC-2 is 1352 carried within a TUG-2. The VCs within the TUG-2 are numbered from 1353 right to left, starting from the first VC as the first bit on the 1354 right. For example, 28 bits of the EBM of a fully occupied TUG-3 1355 with VC11 tributaries are all ones, while that of a TUG-3 fully 1356 occupied with VC-12 tributaries has the binary value 1357 000111011101110111011101110111. 1359 For a TUG-3 containing VC-3, all TUG-2 bits MUST be set to zero. The 1360 A and T bits are defined as follows: 1362 T: TUG-3 carried bit. If set to 1, the VC-3 payload is carried 1363 within the TUG-3 container. If set to 0, all the TUG-3 columns are 1364 not carried within the fractional VC-4 encapsulation. The TUG-3 1365 columns are removed either because the VC-3 is unequipped or in AIS 1366 mode. 1368 A: VC-3 AIS bit. The A bit MUST be set to 0 when the T bit is 1 1369 (i.e. when the TUG-3 columns are carried within the fractional VC-4 1370 encapsulation). The A bit indicate the reason for removal of the 1371 entire TUG-3 columns. If set to 0, the TUG-3 columns were removed 1372 because the VC-3 is unequipped. If set to 1, the TUG-3 columns were 1373 removed because the VC-3 is in AIS mode. 1375 11.2.3.3. B3 Compensation 1377 Fractional VC-4 encapsulation can be implemented in Line Terminating 1378 Equipment (LTE) or in Path Terminating Equipment (PTE). PTE 1379 implementations terminate the path layer at the ingress PE and 1380 generate a new path layer at the egress PE. LTE implementations do 1381 not terminate the path layer, and therefore need to keep the content 1382 and integrity of the POH bytes across the PSN. In LTE 1383 implementations, special care must be taken to maintain the B3 bit- 1384 wise parity POH byte. The same procedures for B3 compensation as 1385 described in Section 11.2.1.2 for fractional STS-1 encapsulation are 1386 used. 1388 11.2.3.4. Actual Payload Sizes 1390 The actual CEP payload size depends on the number of virtual 1391 tributaries carried within the fractional SPE. The contributions of 1392 each tributary to the fractional VC-4 payload length as well as the 1393 path overhead contribution are described below. 1395 Each VC-11 contributes 27 bytes 1397 Each VC-12 contributes 36 bytes 1399 Each VC-2 contributes 108 bytes 1401 Each VC-3(T3) contributes 738 bytes 1403 Each VC-3(E3) contributes 576 bytes 1405 Each VC-3(uncompressed) contributes 774 bytes 1407 VC-4 POH contributes 9 bytes 1409 The VC-3 contribution includes the AU-3 pointer. For example, the 1410 payload size of a fractional VC-4 configured to third-SPE 1411 encapsulation that carries a single compressed T3 VC-3 and 6 VC-12s 1412 would be: 321=(9 + 6*36 + 738) / 3 bytes payload per each packet. 1414 12. Signaling of CEP Pseudo Wires 1416 [PWE3-CONTROL] specifies the use of the MPLS Label Distribution 1417 Protocol, LDP, as a protocol for setting up and maintaining pseudo 1418 wires. In particular it provides a way to bind a de-multiplexer 1419 field value to a pseudo-wire, specifies procedures for reporting 1420 pseudo-wire status changes and for releasing the bindings. 1421 [PWE3-CONTROL] assumes the pseudo-wire de-multiplexer field is an 1422 MPLS label; however the PSN tunnel itself can be either an IP or MPLS 1423 PSN. 1425 The use of LDP for setting up and maintaining CEP pseudo-wires is 1426 OPTIONAL. This section describes the use of the CEP-specific fields 1427 and error codes. 1429 The PW Type field in PWid FEC and PW generalized ID FEC elements MUST 1430 be set to SONET/SDH Circuit Emulation over Packet (CEP) [PWE3-IANA]. 1432 The control word is REQUIRED for CEP pseudo-wires. Therefore the 1433 C-bit in PWid FEC and PW generalized ID FEC elements MUST be set. If 1434 the C-bit is not set the pseudo-wire MUST not be established and a 1435 Label Release MUST be sent with an Illegal C-bit status code 1436 [PWE3-IANA]. 1438 The PWid FEC and PW generalized ID FEC elements can include one or 1439 more Interface Parameters fields. The Interface Parameters fields 1440 are used to validate that the two ends of the pseudo-wire have the 1441 necessary capabilities to inter operate with each other. The CEP 1442 specific Interface Parameters fields are the CEP/TDM Payload Bytes, 1443 the CEP Option and the CEP/TDM Bit Rate parameters. 1445 12.1. CEP/TDM Payload Bytes 1447 This parameter MUST contain the expected CEP payload size in bytes. 1448 The payload size does not include network headers, CEP Header or 1449 padding. If payload compression is used, the CEP/TDM Payload Bytes 1450 parameter MUST be set to the uncompressed payload size as if payload 1451 compression was disabled. In particular, when Fractional SPE (STS-1/ 1452 VC-3 or VC-4) payload compression is used, the payload bytes 1453 parameter MUST be set to the payload size before removal of the 1454 unequipped VT containers and fixed value columns. Therefore, when 1455 fractional SPE mode is used, the actual (i.e. on the wire) packet 1456 length would normally be less than advertised, and in dynamic 1457 fractional SPE, even change while the connection is active. 1458 Similarly when DBA payload compression is used, the CEP/TDM Payload 1459 Bytes parameter MUST be set to the payload size prior to compression. 1461 The CEP/TDM Payload Bytes parameter is OPTIONAL. Default payload 1462 sizes are assumed if this parameter is not included as part of the 1463 Interface Parameters fields. The default payload size for VT is a 1464 single super frame. The default payload size for SPE is 783 bytes. 1466 A PE that receives a label-mapping request with request for a CEP/TDM 1467 Payload Bytes value that is not locally supported MUST return CEP/TDM 1468 miss-configuration status error code [PWE3-IANA] and the pseudo wire 1469 MUST not be established. 1471 12.2. CEP/TDM Bit Rate 1473 The CEP/TDM Bit Rate parameter MUST be set to the data rate in 64Kbps 1474 units of the CEP payload. If payload compression is used, the CEP/ 1475 TDM Bit Rate parameter MUST be set to the uncompressed payload data 1476 rate as if payload compression was disabled. Table 3 specifies the 1477 CEP/TDM Bit Rate parameters that MUST be set for each of the pseudo- 1478 wire circuits. 1480 +-------------+-----------------------+ 1481 | Circuit | Bit Rate Parameter | 1482 +-------------+-----------------------+ 1483 | VT1.5/VC-11 | 26 | 1484 | | | 1485 | VT2/VC-12 | 35 | 1486 | | | 1487 | VT3 | 53 | 1488 | | | 1489 | VT6/VC-2 | 107 | 1490 | | | 1491 | STS-Nc | 783*N N=1,3,12,48,192 | 1492 +-------------+-----------------------+ 1494 Table 3: CEP/TDM Bit Rates 1496 The CEP/TDM Bit Rate parameter is MANDATORY. Attempts to establish a 1497 pseudo-wire between two peers with different bit-rates MUST be 1498 rejected with incompatible bit rate status error code [PWE3-IANA] and 1499 the pseudo wire MUST not be established. 1501 12.3. CEP Options 1503 The CEP Options parameter is MANDATORY. The format of the CEP 1504 Options parameter is described below: 1506 0 1 1507 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1508 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1509 |AIS|UNE|RTP|EBM| Reserved [0:6] | CEP Type | Async | 1510 | | | | | | [0:2] |T3 |E3 | 1511 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1513 Figure 11: CEP Options 1515 AIS - When set, indicates that the PE sending the label-mapping 1516 request is configured to send DBA packets when AIS indication is 1517 detected. 1519 UNE - When set, indicates that the PE sending the label-mapping 1520 request is configured to send DBA packets when unequipped circuit 1521 indication is detected. 1523 RTP - When set, indicates that the PE sending the label-mapping 1524 request is configured to send packets with RTP header. 1526 EBM - When set, indicates that the PE sending the label-mapping 1527 request is configured to send packets with EBM extension header. 1529 CEP Type - indicates the CEP connection type: 1531 0x0 SPE mode (STS-1/STS-Mc) 1533 0x1 VT mode (VT1.5/VT2/VT3/VT6) 1535 0x2 Fractional SPE (STS-1/VC-3/VC-4) 1537 Async Type - indicates the Async E3/T3 bandwidth reduction 1538 configuration. Relevant only when CEP type is set to fractional 1539 SPE, and fractional SPE is expected to carry Asynchronous T3/E3 1540 payload: 1542 T3 - When set, indicates that the PE sending the label-mapping 1543 request is configured to send Fractional SPE packets with T3 1544 bandwidth reduction. 1546 E3 - When set, indicates that the PE sending the label-mapping 1547 request is configured to send Fractional SPE packets with E3 1548 bandwidth reduction. 1550 Reserved field - MUST be set to zero by the PE sending the label- 1551 mapping request and ignored by the receiver. 1553 A PE that does not support one of the CEP options set in the label- 1554 mapping request MUST send a label-release message with status code of 1555 CEP/TDM miss-configuration [PWE3-IANA], report to the operator and 1556 wait for a new consistent label-mapping. A PE MUST send a new label- 1557 mapping request once it is re-configured or when it receives a label- 1558 mapping request from its peer with consistent configuration. 1560 A pseudo-wire can be configured asymmetrically. One PE can be 1561 configured to use bandwidth reduction modes while the other PE can be 1562 configured to send the entire circuit unmodified. A PE can compare 1563 the CEP options settings received in the label mapping request with 1564 its own configuration and detect an asymmetric pseudo-wire 1565 configuration. A PE that identifies an asymmetric configuration MAY 1566 report it to the operator. 1568 13. Congestion Control 1570 The PSN carrying the CEP PW may be subject to congestion. Congestion 1571 considerations for PWs are described in section 6.5 of [PWE3-ARCH]. 1572 CEP PWs represent inelastic constant bit-rate (CBR) flows and cannot 1573 respond to congestion in a TCP-friendly manner prescribed by [CONG]. 1575 CEP PWs SHOULD be carried across traffic-engineered PSNs that provide 1576 either bandwidth reservation and admission control or forwarding 1577 prioritization and boundary traffic conditioning mechanisms. 1578 IntServ-enabled domains [INTSERV] supporting Guaranteed Service [GS] 1579 and DiffServ-enabled domains [DIFFSERV] supporting Expedited 1580 Forwarding [EF] provide examples of such PSNs. It is expected that 1581 PWs emulating high rate SONET STS-Nc or SDH virtual circuits will be 1582 tunneled over traffic-engineered MPLS PSN. 1584 CEP PWs SHOULD monitor packet loss in order to detect "severe 1585 congestion". If such a condition is detected, a CEP PW SHOULD shut 1586 down bi-directionally. This specification does not define the exact 1587 criteria for detecting "severe congestion" using the CEP packet loss 1588 rate and the consequent re-start criteria after a suitable delay. 1589 This is left for further study. 1591 If the CEP PW has been set up using the PWE3 control protocol 1592 [PWE3-CONTROL] the regular PW teardown procedures SHOULD be used upon 1593 detection of "severe congestion". 1595 The SONET/SDH services emulated by CEP PWs have high availability 1596 objectives that MUST be taken into account when deciding on temporary 1597 shutdown of CEP PWs. CEP performance monitoring provides entry and 1598 exit criteria for the CEP PW unavailable state (UAS-CEP). Detection 1599 of "Severe congestion" MAY be based on unavailability criteria of the 1600 CEP PW. 1602 14. Security Considerations 1604 The CEP encapsulation is subject to all of the general security 1605 considerations discussed in [PWE3-ARCH]. In addition, this document 1606 specifies only encapsulations, and not the protocols used to carry 1607 the encapsulated packets across the PSN. Each such protocol may have 1608 its own set of security issues, but those issues are not affected by 1609 the encapsulations specified herein. Note that the security of the 1610 transported CEP service will only be as good as the security of the 1611 PSN. This level of security may be less rigorous than that available 1612 from a native TDM service due to the inherent differences between 1613 circuit-switched and packet-switched public networks. 1615 Although CEP MAY employ an RTP header when explicit transfer of 1616 timing information is required, SRTP [RFC3711] mechanisms are not a 1617 substitute for PW layer security. 1619 15. IANA Considerations 1621 IANA considerations for pseudo-wires are covered in [PWE3-IANA]. CEP 1622 does not introduce additional requirements from IANA. 1624 16. Acknowledgments 1626 The authors would like to thank the members of the PWE3 working group 1627 for their assistance on this draft. We thank Sasha Vainshtein, 1628 Deborah Brungard, Juergen Heiles and Nick Weeds for their review and 1629 valuable feedback. 1631 Appendix A. SONET/SDH Rates and Formats 1633 For simplicity, the discussion in this section uses SONET 1634 terminology, but it applies equally to SDH as well. SDH-equivalent 1635 terminology is shown in the tables. 1637 The basic SONET modular signal is the synchronous transport signal- 1638 level 1 (STS-1). A number of STS-1s may be multiplexed into higher- 1639 level signals denoted as STS-N, with N synchronous payload envelopes 1640 (SPEs). The optical counterpart of the STS-N is the Optical Carrier- 1641 level N, or OC-N. Table 4 lists standard SONET line rates discussed 1642 in this document. 1644 +-------------+--------+---------+----------+-----------+-----------+ 1645 | OC Level | OC-1 | OC-3 | OC-12 | OC-48 | OC-192 | 1646 +-------------+--------+---------+----------+-----------+-----------+ 1647 | SDH Term | - | STM-1 | STM-4 | STM-16 | STM-64 | 1648 | | | | | | | 1649 | Line | 51.840 | 155.520 | 622.080 | 2,488.320 | 9,953.280 | 1650 | Rate(Mb/s) | | | | | | 1651 +-------------+--------+---------+----------+-----------+-----------+ 1653 Table 4: Standard SONET Line Rates 1655 Each SONET frame is 125us and consists of nine rows. An STS-N frame 1656 has nine rows and N*90 columns. Of the N*90 columns, the first N*3 1657 columns are transport overhead and the other N*87 columns are SPEs. 1658 A number of STS-1s may also be linked together to form a super-rate 1659 signal with only one SPE. The optical super-rate signal is denoted 1660 as OC-Nc, which has a higher payload capacity than OC-N. 1662 The first 9-byte column of each SPE is the path overhead (POH) and 1663 the remaining columns form the payload capacity with fixed stuff 1664 (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 1665 columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed 1666 stuff, STS-12c has three columns of fixed stuff, and so on. 1668 The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The 1669 payload capacity of an STS-1 is 86 columns (774 bytes) per frame. 1670 The payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. 1671 Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 bytes 1672 per frame. As another example, the payload capacity of an STS-192c 1673 is 149,760 bytes, which is 64 times the capacity of an STS-3c. 1675 There are 8,000 SONET frames per second. Therefore, the SPE 1676 size,(POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 1677 Mb/s. The SPE size of a concatenated STS-3c is 2,349 bytes per frame 1678 or 150.336 Mb/s. The payload capacity of an STS-192c is 149,760 1679 bytes per frame, which is equivalent to 9,584.640 Mb/s. Table 5 1680 lists the SPE and payload rates supported. 1682 +-------------+--------+---------+----------+-----------+-----------+ 1683 | SONET STS | STS-1 | STS-3c | OC-12c | OC-48c | OC-192c | 1684 | Level | | | | | | 1685 +-------------+--------+---------+----------+-----------+-----------+ 1686 | SDH VC | VC-3 | VC-4 | VC-4-4c | VC-4-16c | VC-4-64c | 1687 | Level | | | | | | 1688 | | | | | | | 1689 | Payload | 774 | 2,340 | 9,360 | 37,440 | 149,760 | 1690 | Size(Bytes) | | | | | | 1691 | | | | | | | 1692 | Payload | 49.536 | 149.760 | 599.040 | 2,396.160 | 9,584.640 | 1693 | Rate(Mb/s) | | | | | | 1694 | | | | | | | 1695 | SPE | 783 | 2,349 | 9,396 | 37,584 | 150,336 | 1696 | Size(Bytes) | | | | | | 1697 | | | | | | | 1698 | SPE | 50.112 | 150.336 | 601.344 | 2,405.376 | 9,621.504 | 1699 | Rate(Mb/s) | | | | | | 1700 +-------------+--------+---------+----------+-----------+-----------+ 1702 Table 5: Payload Size and Rate 1704 To support circuit emulation, the entire SPE of a SONET STS or SDH VC 1705 level is encapsulated into packets, using the encapsulation defined 1706 in Section 5, for carriage across packet-switched networks. 1708 VTs are organized in SONET super-frames, where a SONET super-frame is 1709 a sequence of four SONET SPEs. The SPE path overhead byte H4 1710 indicates the SPE number within the super-frame. The VT data can 1711 float relative to the SPE position. The overhead bytes V1, V2 and V3 1712 are used as pointer and stuffing byte similar to the use of the H1, 1713 H2 and H3 TOH bytes. 1715 Appendix B. Example Network Diagrams 1717 Figure 12 below illustrates a SONET interconnect example. Site A and 1718 Site B are connected back to a Hub Site, Site C by means of a SONET 1719 infrastructure. The OC12 from Site A and the OC12 from Site B are 1720 partially equipped. Each of them is transported through a SONET 1721 network back to a hub site C. Equipped SPEs (or VTs) are then groomed 1722 onto the OC-12 towards site C. 1724 SONET Network 1725 ____ ___ ____ 1726 / \___/ \ _/ \__ 1727 +------+ Physical / \__/ \ 1728 |Site A| OC-12 / +---+ OC-12 \ Hub Site 1729 | |=================|\S/|-------------+-----+ \ +------+ 1730 | | \ |/ \|=============|\ /| \ | | 1731 +------+ /\ +---+-------------| \ / | / OC12 | | 1732 / | S |=========|Site C| 1733 +------+ Physical/ +---+-------------| / \ | \ | | 1734 |Site B| OC-12 \ |\S/|=============|/ \| \ | | 1735 | |=================|/ \|-------------+-----+ / +------+ 1736 | | \ +---+ OC12 __ / 1737 +------+ \ __/ \ / 1738 \ ___ ___ / \_/ 1739 \_/ \____/ \___/ 1741 Figure 12: SONET Interconnect Example Diagram 1743 Figure 13 below illustrates the same pair of OC12s being emulated 1744 over a PSN. This configuration frees up bandwidth in the grooming 1745 network, since only equipped SPEs (or VTs) are sent through the PSN. 1746 Additional bandwidth savings can be realized by taking advantage of 1747 the various payload compression options described in Section 11. 1749 SONET/TDM/Packet Network 1750 ____ ___ ____ 1751 / \___/ \ / \__ 1752 +------+ Physical /+-+ \__/ \_ 1753 |Site A| OC12 / | | +---+ \ Hub Site 1754 | |=============|P|=| R | +---+ +-+ +-----+ \ +------+ 1755 | | \ |E| | |===| | | |=|\ /| \ | | 1756 +------+ /\+-+ +---+ | | | | | \ / | / OC12| | 1757 / | R |=|P| | S |========|Site C| 1758 +------+ Physical/ +-+ +---+ | | |E| | / \ | \ | | 1759 |Site B| OC12 \ |P| | R |===| | | |=|/ \| \ | | 1760 | |=============|E|=| | +---+ +-+ +-----+ / +------+ 1761 | | \ | | +---+ __ / 1762 +------+ \ +-+ __/ \ / 1763 \ ___ ___ / \_/ 1764 \_/ \____/ \___/ 1766 Figure 13: SONET Interconnect Emulation Example Diagram 1768 Figure 14 below shows an example of T1 grooming into OC-12 in access 1769 networks. The VT encapsulation is used to transport the T1s from the 1770 Hub site to customer sites, maintaining SONET/SDH OAM. 1772 SONET/TDM/Packet Network 1773 ____ ___ ____ 1774 / \___/ \ / \__ 1775 +------+ Physical /+-+ \__/ \_ 1776 |Site A| T1 / | | +---+ \ Hub Site 1777 | |=============|P|=| R | +---+ +-+ +-----+ \ +------+ 1778 | | \ |E| | |===| | | |=|\ /| \ | | 1779 +------+ /\+-+ +---+ | | | | | \ / | / OC12| | 1780 / | R |=|P| | S |========|Site C| 1781 +------+ Physical/ +-+ +---+ | | |E| | / \ | \ | | 1782 |Site B| T1 \ |P| | R |===| | | |=|/ \| \ | | 1783 | |=============|E|=| | +---+ +-+ +-----+ / +------+ 1784 | | \ | | +---+ __ / 1785 +------+ \ +-+ __/ \ / 1786 \ ___ ___ / \_/ 1787 \_/ \____/ \___/ 1789 Figure 14: T1 to OC-12 Grooming Emulation Example Diagram 1791 17. References 1793 17.1. Normative References 1795 [G.707] "Network Node Interface For The Synchronous Digital 1796 Hierarchy", ITU-T Recommendation G.707, December 2003. 1798 [G.783] "Characteristics of synchronous digital hierarchy (SDH) 1799 equipment functional blocks", ITU-T Recommendation G.783, 1800 February 2004. 1802 [G.784] "Synchronous Digital Hierarchy (SDH) management", ITU-T 1803 Recommendation G.784, July 1999. 1805 [G.806] "Characteristics of transport equipment-Description 1806 methodology and generic functionality", ITU-T 1807 Recommendation G.806, February 2004. 1809 [G.825] "The control of jitter and wander within digital networks 1810 which are based on the synchronous digital hierarchy 1811 (SDH)", ITU-T Recommendation G.825, March 2000. 1813 [GR253] "Synchronous Optical Network (SONET) Transport Systems: 1814 Common Generic Criteria", Telcordia GR-253-CORE Issue 3, 1815 September 2000. 1817 [MPLS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1818 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1819 Encoding", RFC 3032, January 2001. 1821 [PWE3-CONTROL] 1822 Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1823 Heron, "Pseudo-wire Setup and Maintenance using LDP", 1824 RFC 4447, April 2006. 1826 [PWE3-IANA] 1827 Martini, L., "IANA Allocations for pseudo Wire Edge to 1828 Edge Emulation (PWE3)", RFC 4446, April 2006. 1830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1831 Requirement Levels", BCP 14, RFC 2119, March 1997. 1833 [RTP] Schulzrinne, H., Casner, S., Frederick, R., and V. 1834 Jacobson, "RTP: A Transport Protocol for Real-Time 1835 Applications", STD 64, RFC 3005, July 2003. 1837 [SONET] "Synchronous Optical Network (SONET) - Basic Description 1838 including Multiplex Structure, Rates and Formats", 1839 ANSI T1.105-2001, October 2001. 1841 [UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1842 August 1980. 1844 17.2. Informative References 1846 [CONG] Floyd, S., "Congestion Control Principles", RFC 2914, 1847 September 2000. 1849 [DIFFSERV] 1850 Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1851 and W. Weiss, "An Architecture for Differentiated 1852 Services", RFC 2475, December 1998. 1854 [EF] Davie, B., Charny, A., Bennett, J., Benson, K., Le Boudec, 1855 J., Courtney, W., Davari, S., Firoiu, V., and D. 1856 Stiliadis, "An Expedited Forwarding PHB (Per-Hop 1857 Behavior)", RFC 3246, March 2002. 1859 [GS] Shenker, S., Partridge, C., and R. Guerin, "Specification 1860 of Guaranteed Quality of Service", RFC 2212, 1861 September 1997. 1863 [INTSERV] Braden, R., Clark, D., and S. Shenker, "Integrated 1864 Services in the Internet Architecture: an Overview", 1865 RFC 1633, June 1994. 1867 [PWE3-ARCH] 1868 Bryant, S. and P. Pate, "PWE3 Architecture", RFC 3985, 1869 March 2005. 1871 [PWE3-MPLSCW] 1872 Bryant, S., Swallow, G., and D. McPherson, "Control Word 1873 for Use over an MPLS PSN", RFC 4385, February 2006. 1875 [PWE3-REQ] 1876 Xiao, X., McPherson, D., and P. Pate, "Requirements for 1877 Pseudo Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, 1878 September 2004. 1880 [PWE3-TDM-REQ] 1881 Riegel, M., "Requirements for Edge-to-Edge Emulation of 1882 TDM Circuits over Packet Switching Networks (PSN)", 1883 RFC 4197, October 2005. 1885 [RFC3711] Baugher, M., McGrew, D., Naslund, N., Carrara, E., and K. 1886 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1887 RFC 3711, March 2004. 1889 Authors' Addresses 1891 Andrew G. Malis 1892 Verizon Communications 1893 40 Sylvan Road 1894 Waltham, MA 02451 1895 USA 1897 Email: andrew.g.malis@verizon.com 1899 Prayson Pate 1900 Overture Networks 1901 507 Airport Blvd, Suite 111 1902 Morrisville, NC 27560 1903 USA 1905 Email: prayson.pate@overturenetworks.com 1907 Ron Cohen (editor) 1908 Resolute Networks 1909 15 Central Avenue 1910 Modiin, 71700 1911 Israel 1913 Email: ronc@resolutenetworks.com 1915 David Zelig 1916 Corrigent Systems 1917 126 Yigal Alon st. 1918 Tel Aviv, 1919 Israel 1921 Email: davidz@corrigent.com 1923 Full Copyright Statement 1925 Copyright (C) The Internet Society (2006). 1927 This document is subject to the rights, licenses and restrictions 1928 contained in BCP 78, and except as set forth therein, the authors 1929 retain all their rights. 1931 This document and the information contained herein are provided on an 1932 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1933 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1934 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1935 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1936 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1937 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1939 Intellectual Property 1941 The IETF takes no position regarding the validity or scope of any 1942 Intellectual Property Rights or other rights that might be claimed to 1943 pertain to the implementation or use of the technology described in 1944 this document or the extent to which any license under such rights 1945 might or might not be available; nor does it represent that it has 1946 made any independent effort to identify any such rights. Information 1947 on the procedures with respect to rights in RFC documents can be 1948 found in BCP 78 and BCP 79. 1950 Copies of IPR disclosures made to the IETF Secretariat and any 1951 assurances of licenses to be made available, or the result of an 1952 attempt made to obtain a general license or permission for the use of 1953 such proprietary rights by implementers or users of this 1954 specification can be obtained from the IETF on-line IPR repository at 1955 http://www.ietf.org/ipr. 1957 The IETF invites any interested party to bring to its attention any 1958 copyrights, patents or patent applications, or other proprietary 1959 rights that may cover technology that may be required to implement 1960 this standard. Please address the information to the IETF at 1961 ietf-ipr@ietf.org. 1963 Acknowledgment 1965 Funding for the RFC Editor function is provided by the IETF 1966 Administrative Support Activity (IASA).