idnits 2.17.1 draft-martini-l2circuit-trans-mpls-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 21 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (September 2000) is 8625 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: '7' is mentioned on line 404, but not defined == Unused Reference: '3' is defined on line 575, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-07 -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-07 -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Nasser El-Aawar 4 Expiration Date: March 2001 Level 3 Communications, LLC. 6 Dimitri Stratton Vlachos 7 Daniel Tappan 8 Eric C. Rosen 9 Cisco Systems, Inc. 11 Steve Vogelsang 12 John Shirron 13 Laurel Networks, Inc. 15 Andrew G. Malis 16 Ken Hsu 17 Vivace Networks, Inc. 19 September 2000 21 Transport of Layer 2 Frames Over MPLS 23 draft-martini-l2circuit-trans-mpls-03.txt 25 Status of this Memo 27 This document is an Internet-Draft and is in full conformance with 28 all provisions of Section 10 of RFC2026. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that other 32 groups may also distribute working documents as Internet-Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 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 Abstract 47 This document describes methods for transporting the Protocol Data 48 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, 49 Ethernet, and providing a SONET circuit emulation service across an 50 MPLS network. 52 Table of Contents 54 1 Specification of Requirements .......................... 2 55 2 Introduction ........................................... 3 56 3 Tunnel Labels and VC Labels ............................ 3 57 4 Optional Sequencing and/or Padding ..................... 4 58 5 Protocol-Specific Issues ............................... 5 59 5.1 Frame Relay ............................................ 5 60 5.2 ATM .................................................... 6 61 5.2.1 F5 OAM Cell Support .................................... 6 62 5.2.2 CLP Bit ................................................ 7 63 5.2.3 PTI Field in ATM Cell Mode ............................. 7 64 5.3 Ethernet VLAN .......................................... 7 65 5.4 Ethernet ............................................... 7 66 5.5 Circuit Emulation Service over MPLS (CEM) .............. 8 67 5.5.1 CEM Encapsulation Format ............................... 8 68 5.5.2 Clocking Mode .......................................... 9 69 5.5.3 Synchronous ............................................ 9 70 5.5.4 Asynchronous ........................................... 10 71 6 LDP .................................................... 10 72 7 Security Considerations ................................ 13 73 8 Open Issues ............................................ 13 74 9 Intellectual ........................................... 13 75 10 References ............................................. 13 76 11 Author Information ..................................... 14 77 12 Appendix A: SONET/SDH Rates and Formats ................ 15 79 1. Specification of Requirements 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119. 85 2. Introduction 87 In an MPLS network, it is possible to carry the Protocol Data Units 88 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 89 these PDUs. This document specifies the necessary label distribution 90 and encapsulation procedures for accomplishing this. We restrict 91 discussion to the case of point-to-point transport. QoS related 92 issues are not discussed in this draft. 94 This document also describes a method for transporting time division 95 multiplexed (TDM) digital signals (TDM circuit emulation) over a 96 packet-oriented MPLS network. The transmission system for circuit- 97 oriented TDM signals is the Synchronous Optical Network 98 (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To support TDM 99 traffic, which includes voice, data, and private leased line service, 100 the MPLS network must emulate the circuit characteristics of 101 SONET/SDH payloads. MPLS labels and a new circuit emulation header 102 are used to encapsulate TDM signals and provide the Circuit Emulation 103 Service over MPLS (CEM). 105 3. Tunnel Labels and VC Labels 107 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 108 to egress LSR R2, across an intervening MPLS network. We assume that 109 there is an LSP from R1 to R2. That is, we assume that R1 can cause 110 a packet to be delivered to R2 by pushing some label onto the packet 111 and sending the result to one of its adjacencies. Call this label 112 the "tunnel label", and the corresponding LSP the "tunnel LSP". 114 The tunnel LSP merely gets packets from R1 to R2, the corresponding 115 label doesn't tell R2 what to do with the payload, and in fact if 116 penultimate hop popping is used, R2 may never even see the 117 corresponding label. (If R1 itself is the penultimate hop, a tunnel 118 label may not even get pushed on.) Thus if the payload is not an IP 119 packet, there must be a label, which becomes visible to R2, that 120 tells R2 how to treat the received packet. Call this label the "VC 121 label". 123 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 124 its label stack, and then (if R1 is not adjacent to R2) pushes on a 125 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 126 the VC label is not visible until the MPLS packet reaches R2. R2's 127 disposition of the packet is based on the VC label. 129 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 130 the VC label will generally correspond to a particular ATM VC at R2. 131 That is, R2 needs to be able to infer from the VC label the outgoing 132 interface and the VPI/VCI value for the AAL5 PDU. If the payload is 133 a Frame Relay PDU, then R2 needs to be able to infer from the VC 134 label the outgoing interface and the DLCI value. If the payload is 135 an ethernet frame, then R2 needs to be able to infer from the VC 136 label the outgoing interface, and perhaps the VLAN identifier. This 137 process is unidirectional, and will be repeated independently for 138 bidirectional operation. It is desirable, but not required, to assign 139 the same VC, and Group ID for a given circuit in both directions. 140 Note that the VC label must always be at the bottom of the label 141 stack, and the tunnel label, if present, must be immediately above 142 the VC label. Of course, as the packet is transported across the 143 MPLS network, additional labels may be pushed on (and then popped 144 off) as needed. Even R1 itself may push on additional labels above 145 the tunnel label. If R1 and R2 are directly adjacent LSRs, then it 146 may not be necessary to use a tunnel label at all. 148 This document does not specify a method for distributing the tunnel 149 label or any other labels that may appear above it on the stack. Any 150 acceptable method of MPLS label distribution will do. 152 This document does specify a method for assigning and distributing 153 the VC label. Static label assignment MAY be used, and 154 implementations SHOULD provide support for this. If signaling is 155 used, the VC label MUST be distributed from R2 to R1 using LDP in the 156 downstream unsolicited mode; this requires that an LDP connection be 157 created between R1 and R2. 159 Note that this technique allows an unbounded number of layer 2 "VCs" 160 to be carried together in a single "tunnel". Thus it scales quite 161 well in the network backbone. 163 The MPLS network should be configured with a MTU that is at least 12 164 bytes larger then the largest packet size that will be transported in 165 the LSPs. If a packet, once it has been encapsulated, exceeds the 166 LSP MTU, it MUST be dropped. 168 4. Optional Sequencing and/or Padding 170 Sometimes it is important to guarantee that sequentiality is 171 preserved on a layer 2 virtual circuit. To accommodate this 172 requirement, we provide an optional control word which may appear 173 immediately after the label stack and immediately before the layer 2 174 PDU. This control word contains a sequence number. R1 and R2 both 175 need to be configured with the knowledge of whether a control word 176 will be used for a specific virtual circuit. 178 Sometimes it is necessary to transmit a small packet on a medium 179 where there is a minimum transport unit larger than the actual packet 180 size. In this case, padding is appended to the packet. When the VC 181 label is popped, it may be desirable to remove the padding before 182 forwarding the packet. 184 To facilitate this, the control word has a length field. If the 185 packet's length (without any padding) is less than 256 bytes, the 186 length field MUST be set to the packet's length (without padding). 187 Otherwise the length field MUST be set to zero. The value of the 188 length field, if non-zero, can be used to remove any padding. 190 The generic control word is defined as follows: 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Reserved | Length | Sequence Number | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 The first 8 bits are reserved for future use. They MUST be set to 0 199 when transmitting, and MUST be ignored upon receipt. The length byte 200 is set as specified above. 202 The next 16 bits are the sequence number that is used to guarantee 203 ordered packet delivery. For a given VC label, and a given pair of 204 LSRs, R1 and R2, where R2 has distributed that VC label to R1, the 205 sequence number is initialized to 0, and is incremented by one for 206 each successive packet carrying that VC label which R1 transmits to 207 R2. 209 The sequence number space is a 16 bit unsigned circular space. PDUs 210 carrying the control word MUST NOT be delivered out of order. They 211 may be discarded or reordered. 213 5. Protocol-Specific Issues 215 5.1. Frame Relay 217 A Frame Relay PDU is transported in its entirety, including the Frame 218 Relay Header. The sequencing control word is OPTIONAL. 220 The BECN and FECN signals are carried unchanged across the network in 221 the frame relay header. These signals do not appear in the MPLS 222 header, and are unseen by the MPLS network. 224 If the MPLS edge LSR detects a service affecting condition as defined 225 in [2] Q.933 Annex A.5 sited in IA FRF1.1, it will withdraw the label 226 that corresponds to the frame relay DLCI. The Egress side should 227 generate the corresponding errors and alarms as defined in [2] on the 228 Frame relay VC. 230 The ingress LSR MAY consider the DE bit of the Frame Relay header 231 when determining the value to be placed in the EXP fields of the MPLS 232 label stack. In a similar way, the egress LSR MAY consider the EXP 233 field of the VC label when queuing the packet for egress. 235 5.2. ATM 237 Two modes are supported for ATM transport, ATM Adaptation Layer 5 238 (AAL5) and ATM cell. 240 In ATM AAL5 mode the ingress LSR is required to reassemble AAL5 241 CPCS-PDUs from the incoming VC and transport each CPCS-PDU as a 242 single packet. No AAL5 trailer is transported. The sequencing control 243 word is OPTIONAL. 245 In ATM cell mode the ingress LSR transports each ATM cell payload as 246 a single packet. No ATM cell header is transported. The sequencing 247 control word is OPTIONAL. 249 5.2.1. F5 OAM Cell Support 251 F5 OAM cells are not transported on the VC LSP. 253 If an F5 end-to-end OAM cell is received from a VC by a LSR with a 254 loopback indication value of 1 and the LSR has a label mapping for 255 the VC, the LSR must decrement the loopback indication value and loop 256 back the cell on the VC. Otherwise the loopback cell must be silently 257 discarded by the LSR. 259 A LSR may optionally be configured to periodically generate F5 end- 260 to-end loopback OAM cells on a VC. In this case, the LSR must only 261 generate F5 end-to-end loopback cells while a label mapping exists 262 for the VC. If the VC label mapping is withdrawn the LSR must cease 263 generation of F5 end-to-end loopback OAM cells. If the LSR fails to 264 receive a response to an F5 end-to-end loopback OAM cell for a pre- 265 defined period of time it must withdraw the label mapping for the VC. 267 If an ingress LSR receives an AIS F5 OAM cell, fails to receive a 268 pre-defined number of the End-to-End loop OAM cells, or a physical 269 interface goes down, it must withdraw the label mappings for all VCs 270 associated with the failure. When a VC label mapping is withdrawn, 271 the egress LSR must generate AIS F5 OAM cells on the VC associated 272 with the withdrawn label mapping. 274 5.2.2. CLP Bit 276 The ingress LSR MAY consider the CLP bit when determining the value 277 to be placed in the EXP fields of the MPLS label stack. 279 The egress LSR MAY consider the value of the EXP field of the VC 280 label when determining the value of the ATM CLP bit. 282 5.2.3. PTI Field in ATM Cell Mode 284 ATM cell mode is intended for transporting non-AAL5 traffic only. The 285 ingress LSR must transport cells with a PTI of 0. Cells with a PTI 286 other than 0 are not transported on the LSP. The egress LSR must set 287 the PTI to 0 for cells switched from a VC LSP to an outgoing VC. 289 5.3. Ethernet VLAN 291 For and ethernet 802.1q VLAN the entire ethernet frame without the 292 preamble or FCS is transported as a single packet. The sequencing 293 control word is OPTIONAL. If a packet is received out of sequence it 294 MUST be dropped. The VLAN 4 byte tag is transported as is, and MAY be 295 overwritten by the egress LSR. The ingress LSR MAY consider the user 296 priority field [4] of the VLAN tag header when determining the value 297 to be placed in the EXP fields of the MPLS label stack. In a similar 298 way, the egress LSR MAY consider the EXP field of the VC label when 299 queuing the packet for egress. Ethernet packets containing hardware 300 level CRC, Framing errors, or runt packets MUST be discarded on 301 input. 303 5.4. Ethernet 305 For simple ethernet port to port transport,the entire ethernet frame 306 without the preamble or FCS is transported as a single packet. The 307 sequencing control word is OPTIONAL. If a packet is received out of 308 sequence it MUST be dropped. As in the Ethernet VLAN case, ethernet 309 packets with hardware level CRC, framing, and runt errors are 310 discarded. 312 5.5. Circuit Emulation Service over MPLS (CEM) 314 This section describes how to provide CEM for the following digital 315 signals: 317 1. SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3 319 2. STS-Nc SPE (N = 3, 12, or 48)/SDH VC-4, VC-4-4c, VC-4-16c 321 Other SONET/SDH signals, such as virtual tributary (VT) structured 322 sub-rate mapping, are not explicitly discussed in this document; 323 however, it can be extended in the future to support VT services. 324 OC-192c SPE/VC-4-64c are also not included at this point, since most 325 MPLS networks use OC-192c or slower trunks, and thus would not have 326 sufficient capacity. As trunk capacities increase in the future, the 327 scope of this document can be accordingly extended. 329 5.5.1. CEM Encapsulation Format 331 A TDM data stream is segmented into packets and encapsulated in MPLS 332 packets. Each packet has one or more MPLS labels, followed by a 32- 333 bit TDM header to associate the packet with the TDM stream. Note that 334 the CEM control word is used instead of the generic control word in 335 section 4. 337 The outside label is used to identify the MPLS LSP used to tunnel the 338 TDM packets through the MPLS network (the tunnel LSP). The interior 339 label is used to multiplex multiple TDM connections within the same 340 tunnel. 342 The 32-bit CEM control word has the following format: 344 0 1 2 3 345 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 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Reserved | Sequnce Num | Structure Pointer |N|P| BIP-4 | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 The above fields are defined as follows: 352 - Reserved 354 These eight bits are reserved for future use, such as alarm 355 signaling or OAM. 357 - Structure Pointer 359 The pointer points to the J1 byte in the payload area. The value 360 is from 0 to 1,022, where 0 means the first byte after the CEM 361 control word. The pointer is set to 0x3FF (1,023) if a packet 362 does not carry the J1 byte. See [5] and [6] for more information 363 on the J1 byte and the structure pointer. 365 - The N and P bits 367 See Section 5.4.2 below for their definition. 369 - Seq Num 371 This is a packet sequence number, which continuously cycles from 372 0 to 255. It begins at 0 when a TDM LSP is created. 374 - BIP-4 376 The bit interleaved even parity over the first 28 header bits. 378 5.5.2. Clocking Mode 380 It is necessary to be able to regenerate the input service clock at 381 the output interface. Two clocking modes are supported: synchronous 382 and asynchronous. 384 5.5.3. Synchronous 386 When synchronous SONET timing is available at both ends of the 387 circuit, the N(JE) and P(JE) bits are set for negative or positive 388 justification events. The event is carried in five consecutive 389 packets at the transmitter. The receiver plays out the event when 390 three out of five packets with NJE/PJE bit set are received. If both 391 bits are set, then path AIS event has occurred. If there is a 392 frequency offset between the frame rate of the transport overhead and 393 that of the STS SPE, then the alignment of the SPE shall periodically 394 slip back or advance in time through positive or negative stuffing. 395 The N(JE) and P(JE) bits are used to replay the stuff indicators and 396 eliminate transport jitter. 398 5.5.4. Asynchronous 400 If synchronous timing is not available, the N and P bits are not used 401 for frequency justification and adaptive methods are used to recover 402 the timing. The N and P bits are only checked for the occurrence of 403 a path AIS event. An example adaptive method can be found in Section 404 3.4.2 of [7]. 406 6. LDP 408 The VC label bindings are distributed using the LDP downstream 409 unsolicited mode described in [1]. The LSRs will establish an LDP 410 session using the Extended Discovery mechanism described in [1, 411 section 2.4-2.5], for this purpose a new type of FEC TLV element is 412 defined. The FEC element type in 128. [note1] 414 The Virtual Circuit FEC TLV element, is defined as follows: 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | VC tlv |C| VC Type | VC ID len | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Group ID | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | | 424 | VC ID | 425 | | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 - VC Type 430 A 15 bit quantity containing a value which represents the type of 431 VC. Assigned Values are: 433 VC Type Description 435 0x0001 Frame Relay DLCI 436 0x0002 ATM AAL5 PVC 437 0x0003 ATM Cell 438 0x0004 Ethernet VLAN 439 0x0005 Ethernet 440 0x0006 HDLC ( Cisco ) 441 0x0007 PPP 442 0x8008 CEM 444 The highest order bit is used to flag the presence of a control word as 445 follows: 446 bit 15 = 1 control word present on this VC. 447 bit 15 = 0 no control word present on this VC. 449 - VC ID length 451 Length of the VC ID field in octets. If this value is 0, then it 452 references all VCs using the specified group ID 454 - Group ID 456 An arbitrary 32 bit value which represents a group of VCs that is 457 used to augment the VC space. This value MUST be user 458 configurable. The group ID is intended to be used as either a 459 port index , or a virtual tunnel index. In the latter case a 460 switching function at ingress will map a particular circuit from 461 a port to a circuit in the virtual tunnel for transport to the 462 egress router. 464 - VC ID 466 Identifies a particular VC. The interpretation of the identifier 467 depends on the VC type: 469 * Frame Relay 471 A 32-bit value representing a 16-bit DLCI value as follows: 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 | Reserved | DLCI | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 * ATM AAL5 PVC 481 A 32-bit value representing a 16-bit VPI, and a 16-bit VCI as 482 follows: 484 0 1 2 3 485 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 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | VPI | VCI | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 * ATM Cell 492 A 32-bit value representing a 16-bit VPI, and a 16-bit VCI as 493 follows: 495 0 1 2 3 496 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 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | VPI | VCI | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 * Ethernet VLAN 503 A 32 bit value representing 16bit vlan identifier as follows: 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Reserved | VLAN ID | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 * Ethernet 513 A 32 bit port identifier. 515 * HDLC ( Cisco ) 517 A 32-bit port identifier (details TBD). 519 * PPP 521 A 32-bit port identifier (details TBD). 523 * CEM 525 A 32-bit value used follows: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Reserved | Circuit ID | Payload Bytes | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 Circuit ID: An assigned number for the SONET circuit being 533 transported. 535 Payload Bytes(N): the number of TDM payload bytes contained 536 in all packets on the CES stream, from 48 to 1,023 bytes. All 537 of the packets in a given CES stream have the same number of 538 payload bytes. Note that there is a possibility that the 539 packet size may exceed the SPE size in the case of an STS-1 540 SPE, which could cause two pointers to be needed in the CEM 541 header, since the payload may contain two J1 bytes for 542 consecutive SPEs. For this reason, the number of payload 543 bytes must be less than 783 for STS-1 SPEs. 545 The reserved fields in the above specifications MUST be set 546 to 0 in the FEC TLV, and ignored when received. 548 7. Security Considerations 550 This document does not affect the underlying security issues of MPLS. 552 8. Open Issues 554 Future revisions of this draft will discuss QoS requirements for CEM, 555 methods to provide (or simulate) bi-directional LSPs (perhaps using 556 the Group ID from [5]), signaling for the number of payload bytes, 557 and sending additional end-to-end alarm information in addition to 558 AIS. 560 9. Intellectual 562 This document is being submitted for use in IETF standards 563 discussions. Vivace Networks, Inc. has filed one or more patent 564 applications relating to the CEM technology outlined in this 565 document. 567 10. References 569 [1] "LDP Specification", draft-ietf-mpls-ldp-07.txt ( work in 570 progress ) 572 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 573 Mode Basic call control, ITU Geneva 1995 575 [3] "MPLS Label Stack Encoding", draft-ietf-mpls-label-encaps-07.txt 576 ( work in progress ) 578 [4] "IEEE 802.3ac-1998" IEEE standard specification. 580 [5] American National Standards Institute, "Synchronous Optical 581 Network (SONET) - Basic Description including Multiplex Structure, 582 Rates and Formats," ANSI T1.105-1995. 584 [6] ITU Recommendation G.707, "Network Node Interface For The 585 Synchronous Digital Hierarchy", 1996. 587 [note1] FEC element type 128 is pending IANA approval. 589 11. Author Information 591 Luca Martini 592 Level 3 Communications, LLC. 593 1025 Eldorado Blvd. 594 Broomfield, CO, 80021 595 e-mail: luca@level3.net 597 Nasser El-Aawar 598 Level 3 Communications, LLC. 599 1025 Eldorado Blvd. 600 Broomfield, CO, 80021 601 e-mail: nna@level3.net 603 Dimitri Stratton Vlachos 604 Cisco Systems, Inc. 605 250 Apollo Drive 606 Chelmsford, MA, 01824 607 e-mail: dvlachos@cisco.com 609 Dan Tappan 610 Cisco Systems, Inc. 611 250 Apollo Drive 612 Chelmsford, MA, 01824 613 e-mail: tappan@cisco.com 614 Eric Rosen 615 Cisco Systems, Inc. 616 250 Apollo Drive 617 Chelmsford, MA, 01824 618 e-mail: erosen@cisco.com 620 Steve Vogelsang 621 Laurel Networks, Inc. 622 2607 Nicholson Rd. 623 Sewickley, PA 15143 624 e-mail: sjv@laurelnetworks.com 626 John Shirron 627 Laurel Networks, Inc. 628 2607 Nicholson Rd. 629 Sewickley, PA 15143 630 e-mail: sjv@laurelnetworks.com 632 Andrew G. Malis 633 Vivace Networks, Inc. 634 2730 Orchard Parkway 635 San Jose, CA 95134 636 Phone: +1 408 383 7223 637 Email: Andy.Malis@vivacenetworks.com 639 Ken Hsu 640 Vivace Networks, Inc. 641 2730 Orchard Parkway 642 San Jose, CA 95134 CA 643 Phone: +1 408 432 7772 644 Email: Ken.Hsu@vivacenetworks.com 646 12. Appendix A: SONET/SDH Rates and Formats 648 For simplicity, the discussion in this section uses SONET 649 terminology, but it applies equally to SDH as well. SDH-equivalent 650 terminology is shown in the tables. 652 The basic SONET modular signal is the synchronous transport signal- 653 level 1 (STS-1). A number of STS-1s may be multiplexed into higher- 654 level signals denoted as STS-N, with N synchronous payload envelopes 655 (SPEs). The optical counterpart of the STS-N is the Optical Carrier- 656 level N, or OC-N. Table 1 lists standard SONET line rates discussed 657 in this document. 659 OC Level OC-1 OC-3 OC-12 OC-48 OC-192 660 SDH Term - STM-1 STM-4 STM-16 STM-64 661 Line Rate(Mb/s) 51.840 155.520 622.080 2,488.320 9,953.280 663 Table 1. Standard SONET Line Rates 665 Each SONET frame is 125 us and consists of nine rows. An STS-N frame 666 has nine rows and N*90 columns. Of the N*90 columns, the first N*3 667 columns are transport overhead and the other N*87 columns are SPEs. A 668 number of STS-1s may also be linked together to form a super-rate 669 signal with only one SPE. The optical super-rate signal is denoted 670 as OC-Nc, which has a higher payload capacity than OC-N. 672 The first 9-byte column of each SPE is the path overhead (POH) and 673 the remaining columns form the payload capacity with fixed stuff 674 (STS-Nc only). The fixed stuff, which is purely overhead, is N/3-1 675 columns for STS-Nc. Thus, STS-1 and STS-3c do not have any fixed 676 stuff, STS-12c has three columns of fixed stuff, and so on. 678 The POH of an STS-1 or STS-Nc is always nine bytes in nine rows. The 679 payload capacity of an STS-1 is 86 columns (774 bytes) per frame. The 680 payload capacity of an STS-Nc is (N*87)-(N/3) columns per frame. 681 Thus, the payload capacity of an STS-3c is (3*87 - 1)*9 = 2,340 bytes 682 per frame. As another example, the payload capacity of an STS-192c is 683 149,760 bytes, which is exactly 64 times larger than the STS-3c. 685 There are 8,000 SONET frames per second. Therefore, the SPE size, 686 (POH plus payload capacity) of an STS-1 is 783*8*8,000 = 50.112 Mb/s. 687 The SPE size of a concatenated STS-3c is 2,349 bytes per frame or 688 150.336 Mb/s. The payload capacity of an STS-192c is 149,760 bytes 689 per frame, which is equivalent to 9,584.640 Mb/s. Table 2 lists the 690 SPE and payload rates supported. 692 SONET STS Level STS-1 STS-3c STS-12c STS-48c STS-192c 693 SDH VC Level - VC-4 VC-4-4c VC-4-16c VC-4-64c 694 Payload Size(Bytes) 774 2,340 9,360 37,440 149,760 695 Payload Rate(Mb/s) 49.536 149.760 599.040 2,396.160 9,584.640 696 SPE Size(Bytes) 783 2,349 9,396 37,584 150,336 697 SPE Rate(Mb/s) 50.112 150.336 601.344 2,405.376 9,621.504 699 Table 2. Payload Size and Rate 701 To support circuit emulation, the entire SPE of a SONET STS or SDH VC 702 level is encapsulated into packets, using the encapsulation defined 703 in the next section, for carriage across MPLS networks.