idnits 2.17.00 (12 Aug 2021) /tmp/idnits49404/draft-martini-l2circuit-encap-mpls-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 127: '...otocols this word is REQUIRED, and for...' RFC 2119 keyword, line 128: '... others OPTIONAL....' RFC 2119 keyword, line 144: '... They MUST be set to 0 when transmit...' RFC 2119 keyword, line 153: '... length field MUST be set to the pac...' RFC 2119 keyword, line 154: '... field MUST be set to zero. The valu...' (71 more instances...) 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 (February 2001) is 7765 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) == Outdated reference: draft-martini-l2circuit-trans-mpls has been published as RFC 4906 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-trans-mpls (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 5 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: August 2001 Giles Heron 5 Level 3 Communications, LLC. 7 Daniel Tappan 8 Eric C. Rosen 9 Alex Hamilton 10 Jayakumar Jayakumar 11 Cisco Systems, Inc. 13 Steve Vogelsang 14 John Shirron 15 Toby Smith 16 Laurel Networks, Inc. 18 Andrew G. Malis 19 Vinai Sirkay 20 Vivace Networks, Inc. 22 Dimitri Stratton Vlachos 23 Mazu Networks, Inc. 25 Kireeti Kompella 26 Juniper Networks 28 February 2001 30 Encapsulation Methods for Transport of Layer 2 Frames Over MPLS 32 draft-martini-l2circuit-encap-mpls-01.txt 34 Status of this Memo 36 This document is an Internet-Draft and is in full conformance with 37 all provisions of Section 10 of RFC2026. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF), its areas, and its working groups. Note that other 41 groups may also distribute working documents as Internet-Drafts. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 47 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 Abstract 55 This document describes methods for encapsulating the Protocol Data 56 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, or 57 Ethernet for transport across an MPLS network. 59 Table of Contents 61 1 Specification of Requirements .......................... 3 62 2 Introduction ........................................... 3 63 3 General encapsulation method ........................... 3 64 3.1 The Control Word ....................................... 3 65 3.1.1 Setting the sequence number ............................ 4 66 3.1.2 Processing the sequence number ......................... 5 67 3.2 MTU Requirements ....................................... 5 68 3.3 MPLS Shim EXP Bit Values ............................... 6 69 3.4 MPLS Shim TTL Values ................................... 6 70 4 Protocol-Specific Details .............................. 6 71 4.1 Frame Relay ............................................ 6 72 4.2 ATM .................................................... 8 73 4.2.1 ATM AAL5 CPCS-PDU Mode ................................. 8 74 4.2.2 ATM Cell Mode .......................................... 10 75 4.2.3 OAM Cell Support ....................................... 12 76 4.2.4 CLP bit to MPLS label stack EXP bit mapping ............ 12 77 4.3 Ethernet VLAN .......................................... 12 78 4.4 Ethernet ............................................... 12 79 4.5 HDLC ( Cisco ) ......................................... 13 80 4.6 PPP .................................................... 13 81 5 Security Considerations ................................ 13 82 6 Intellectual Property Disclaimer ....................... 13 83 7 References ............................................. 13 84 8 Author Information ..................................... 14 86 1. Specification of Requirements 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 90 document are to be interpreted as described in RFC 2119 92 2. Introduction 94 In an MPLS network, it is possible to carry the Protocol Data Units 95 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 96 these PDUs. This document specifies the necessary encapsulation 97 procedures for accomplishing this. One possible control protocol 98 method is described in [1]. QoS related issues are not discussed in 99 this draft. For the purpose of this document R1 will be defined as 100 the ingress LSR, and R2 as the egress LSR. A layer 2 PDU will be 101 received at R1, encapsulated at R1, transported, decapsulated at R2, 102 and transmitted out of R2. In a similar way, the "VC label" is 103 defined as the label at the bottom of the label stack used to 104 transmit the layer 2 PDU. 106 3. General encapsulation method 108 When transporting layer 2 protocols over MPLS it is, in most cases, 109 not necessary to transport the layer 2 encapsulation across the MPLS 110 network. In most cases the layer 2 header can be stripped at R1, and 111 reproduced at R2 with the help of some extra encapsulation 112 information, some of which is a priori signaled, and some of which 113 may be carried in the control word described below. 115 3.1. The Control Word 117 There are three requirements that may need to be satisfied when 118 transporting layer 2 protocols over MPLS: 119 -i. Sequentiality may need to be preserved. 120 -ii. Small packets may need to be padded in order to be 121 transmitted on a medium where the minimum transport unit is 122 larger than the actual packet size. 123 -iii. Control bits carried in the header of the layer 2 frame may 124 need to be transported. 126 The control word defined here addresses all three of these 127 requirements. For some protocols this word is REQUIRED, and for 128 others OPTIONAL. 130 In all cases the the egress LSR must be aware of whether the ingress 131 LSR will send a control word over a specific virtual circuit. This 132 may be achived by configuration of the LSRs, or by signaling, for 133 example as defined in [1]. 135 The control word is defined as follows: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Rsvd | Flags | Length | Sequence Number | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 In the above diagram the first 4 bits are reserved for future use. 144 They MUST be set to 0 when transmitting, and MUST be ignored upon 145 receipt. 147 The next 4 bits provide space for carrying protocol specific flags. 148 These are defined in the protocol-specific details below. 150 The next 8 bits provide a length field, which is used as follows: If 151 the packet's length (defined as the length of the layer 2 payload 152 plus the length of the control word) is less than 256 bytes, the 153 length field MUST be set to the packet's length. Otherwise the length 154 field MUST be set to zero. The value of the length field, if non- 155 zero, can be used to remove any padding. When the packet reaches the 156 service provider's egress LSR, it may be desirable to remove the 157 padding before forwarding the packet. 159 The next 16 bits provide a sequence number that can be used to 160 guarantee ordered packet delivery. The processing of the sequence 161 number field is OPTIONAL. 163 The sequence number space is a 16 bit, unsigned circular space. The 164 sequence number value 0 is used to indicate an unsequenced packet. 166 3.1.1. Setting the sequence number 168 Given a VC label V and a pair of LSRs R1 and R2, where R2 has 169 distributed V to R1. If R1 supports packet sequencing then the 170 following procedures should be used: 172 - the initial packet transmitted to label V MUST use sequence 173 number 1 174 - subsequent packets MUST increment the sequence number by one for 175 each packet 177 - when the transmit sequence number reaches the maximum 16 bit 178 value (65535) the sequence number MUST wrap to 1 180 If the transmitting LSR R1 does not support sequence number 181 processing, then the sequence number field in the control word MUST 182 be set to 0. 184 3.1.2. Processing the sequence number 186 If an LSR R2 supports receive sequence number processing, then the 187 following procedures should be used: 189 When a VC label V is first distributed, the "expected sequence 190 number" associated with V MUST be initialized to 1 192 When a packet is received with label V the sequence number should be 193 processed as follows: 194 - if the sequence number on the packet is 0, then the packet passes 195 the sequence number check 196 - Otherwise if the packet sequence number >= the expected sequence 197 number (using an unsigned comparison, modulo 2**16), then the 198 packet is in order. 199 - otherwise the packet is out of order. 201 If a packet passes the sequence number check, or is in order then, it 202 can be delivered immediately. If the packet is in order, then the 203 expected sequence number should be set using the algorithm: 205 expected_sequence_number := packet_sequence_number + 1 mod 2**16 206 if (expected_sequence_number = 0) then expected_sequence_number := 1; 208 Packets which are received out of order MAY be dropped or reordered 209 at the discretion of the receiver. 211 If an LSR R2 does not support receive sequence number processing, 212 then the sequence number field MAY be ignored. 214 3.2. MTU Requirements 216 The MPLS network MUST be configured with an MTU that is sufficient to 217 transport the largest frame size that will be transported in the 218 LSPs. Note that this is likely to be 12 or more bytes greater than 219 the largest frame size. If a packet length, once it has been 220 encapsulated on the ingress LSR, exceeds the LSP MTU, it MUST be 221 dropped. If an egress LSR receives a packet on a VC LSP with a 222 length, once the label stack and control word have been popped, that 223 exceeds the MTU of the destination layer 2 interface, it MUST be 224 dropped. 226 3.3. MPLS Shim EXP Bit Values 228 The ingress LSR, R1, SHOULD set the EXP field of the VC label to the 229 same value as the EXP field of the previous label in the stack (if in 230 fact a stack of more than one label is imposed at the ingress.) This 231 will ensure that the EXP field will be visible to the egress LSR, R2, 232 in the event of the packet having been penultimate hop popped. 234 3.4. MPLS Shim TTL Values 236 The ingress LSP, R1, MAY set the TTL field of the VC label to a value 237 of 2. 239 4. Protocol-Specific Details 241 4.1. Frame Relay 243 A Frame Relay PDU is transported without the Frame Relay header or 244 the FCS. The sequencing control word is REQUIRED. 246 The BECN, FECN, DE and C/R bits are carried across the network in the 247 control word. The edge LSRs that implement this document MAY, when 248 either adding or removing the encapsulation described herein, change 249 the BECN and/or FECN bits from zero to one in order to reflect 250 congestion in the MPLS network that is known to the edge LSRs, and 251 the D/E bit from zero to one to reflect marking from edge policing of 252 the Frame Relay Committed Information Rate. The BECN, FECN, and D/E 253 bits MUST NOT be changed from one to zero. 255 The following is an example of a Frame Relay packet: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | VC Label | EXP |S| TTL | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Rsvd |B|F|D|C| Length | Sequence Number | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Frame Relay PDU | 265 | " | 266 | " | 267 | " | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 * B ( BECN ) Bit 272 The ingress LSR, R1, MUST copy the BECN field from the incoming 273 Frame Relay header into this field. The egress LSR, R2, MUST 274 generate a new BECN field based on the value of the B bit. 276 * F ( FECN ) Bit 278 The ingress LSR, R1, MUST copy the FECN field from the incoming 279 Frame Relay header into this field. The egress LSR, R2, MUST 280 generate a new FECN field based on the value of the F bit. 282 * D ( DE ) Bit 284 The ingress LSR, R1, MUST copy the DE field from the incoming 285 Frame Relay header into this field. The egress LSR, R2, MUST 286 generate a new DE field based on the value of the D bit. 288 The ingress LSR, R1, MAY consider the DE bit of the Frame Relay 289 header when determining the value to be placed in the EXP field 290 of the MPLS label stack. In a similar way, the egress LSR, R2, 291 MAY consider the EXP field of the VC label when queuing the 292 packet for egress. Note however that frames from the same VC MUST 293 NOT be reordered by the MPLS network. 295 * C ( C/R ) Bit 297 The ingress LSR, R1, MUST copy the C/R bit from the received 298 Frame Relay PDU to the C bit of the control word. The egress 299 LSR, R2, MUST copy the C bit into the output frame. 301 The Label, EXP, S, and TTL fields are described in [2]. 303 4.2. ATM 305 Two encapsulations are supported for ATM transport: one for ATM AAL5 306 and another for ATM cells. 308 The AAL5 CPCS-PDU encapsulation consists of the MPLS label stack, a 309 REQUIRED control word, and the AAL5 CPCS-PDU. 311 The ATM cell encapsulation consists of an MPLS label stack, an 312 OPTIONAL sequencing control word, a 4 byte ATM cell header, and the 313 ATM cell payload. 315 4.2.1. ATM AAL5 CPCS-PDU Mode 317 In ATM AAL5 mode the ingress LSR is required to reassemble AAL5 318 CPCS-PDUs from the incoming VC and transport each CPCS-PDU as a 319 single packet. No AAL5 trailer is transported. The sequencing control 320 word is REQUIRED. 322 The EFCI and CLP bits are carried across the network in the control 323 word. The edge LSRs that implement this document MAY, when either 324 adding or removing the encapsulation described herein, change the 325 EFCI bit from zero to one in order to reflect congestion in the MPLS 326 network that is known to the edge LSRs, and the CLP bit from zero to 327 one to reflect marking from edge policing of the ATM Sustained Cell 328 Rate. The EFCI and CLP bits MUST NOT be changed from one to zero. 330 The AAL5 CPCS-PDU is prepended by the following header: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | VC Label | EXP |S| TTL | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Rsvd |T|E|L|C| Length | Sequence Number | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | ATM AAL5 CPCS-PDU | 340 | " | 341 | " | 342 | " | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 * T (transport type) bit 347 Bit (T) of the control word indicates whether the MPLS packet 348 contains an ATM cell or an AAL5 CPCS-PDU. If set the packet 349 contains an ATM cell, encapsulated according to the ATM cell mode 350 section below, otherwise it contains an AAL5 CPCS-PDU. The 351 ability to transportan ATM cell in the AAL5 mode is intended to 352 provide a means of enabling OAM functionality over the AAL5 VC. 354 * E ( EFCI ) Bit 356 The ingress LSR, R1, SHOULD set this bit to 1 if the EFCI bit of 357 the final cell of those that transported the AAL5 CPCS-PDU is set 358 to 1, or if the EFCI bit of the single ATM cell to be transported 359 in the MPLS packet is set to 1. Otherwise this bit SHOULD be set 360 to 0. The egress LSR, R2, SHOULD set the EFCI bit of all cells 361 that transport the AAL5 CPCS-PDU to the value contained in this 362 field. 364 * L ( CLP ) Bit 366 The ingress LSR, R1, SHOULD set this bit to 1 if the CLP bit of 367 any of the ATM cells that transported the AAL5 CPCS-PDU is set to 368 1, or if the CLP bit of the single ATM cell to be transported in 369 the MPLS packet is set to 1. Otherwise this bit SHOULD be set to 370 0. The egress LSR, R2, SHOULD set the CLP bit of all cells that 371 transport the AAL5 CPCS-PDU to the value contained in this field. 373 The ingress LSR, R1, MAY consider the CLP bit of the ATM cell 374 header when determining the value to be placed in the EXP fields 375 of the MPLS label stack. In a similar way, the egress LSR, R2, 376 MAY consider the EXP field of the VC label when queuing the 377 packet for egress. Note however that frames from the same VC MUST 378 NOT be reordered by the MPLS network. 380 * C ( Command / Response Field ) Bit 382 When FRF.8.1 Frame Relay / ATM PVC Service Interworking [3] 383 traffic is being transported, the CPCS-UU Least Significant Bit 384 (LSB) of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit. 385 The ingress LSR, R1, SHOULD copy this bit to the C bit of the 386 control word. The egress LSR, R2, SHOULD copy the C bit to the 387 CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS PDU. 389 The Label, EXP, S, and TTL fields are described in [2]. 391 4.2.2. ATM Cell Mode 393 In this encapsulation mode ATM cells are transported individually 394 without a SAR process. Each ATM cell payload is prepended by a 4 byte 395 header and concatenated to form the MPLS frame. This ATM cell header 396 is defined as in the FAST encapsulation [4] section 3.1.1, but 397 without the trailer byte. The length of each frame, without the MPLS 398 header and the control word, is a multiple of 52 bytes long. The 399 maximum number of ATM cells that can be fitted in an MPLS frame, in 400 this fashion, is limited only by the MPLS network MTU and by the 401 ability of the egress LSR to process them. The ingress LSR MUST NOT 402 send more cells than the egress LSR is willing to receive. The number 403 of cells that the egress LSR is willing to receive may either be 404 configured in the ingress LSR or may be signaled, for example using 405 the methods described in [1]. The number of cells encapsulated in a 406 particular frame can be inferred by the frame length. The sequencing 407 control word is OPTIONAL. If the control word is used then the flag 408 bits in the control word are not used, and MUST be set to 0 when 409 transmitting, and MUST be ignored upon receipt. 411 The EFCI and CLP bits are carried across the network in the ATM cell 412 header. The edge LSRs that implement this document MAY, when either 413 adding or removing the encapsulation described herein, change the 414 EFCI bit from zero to one in order to reflect congestion in the MPLS 415 network that is known to the edge LSRs, and the CLP bit from zero to 416 one to reflect marking from edge policing of the ATM Sustained Cell 417 Rate. The EFCI and CLP bits MUST NOT be changed from one to zero. 419 This diagram illustrates an encapsulation of two ATM cells: 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | VC Label | EXP |S| TTL | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Control word ( Optional ) | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | VPI | VCI | PTI |C| 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | ATM Payload ( 48 bytes ) | 431 | " | 432 | " | 433 | " | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | VPI | VCI | PTI |C| 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | ATM Payload ( 48 bytes ) | 438 | " | 439 | " | 440 | " | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 * VPI 445 The ingress router MUST copy the VPI field from the incoming cell 446 into this field. The egress router MAY generate a new VPI based 447 on the value of the VC label and ignore the VPI contained in this 448 field. 450 * VCI 452 The ingress router MUST copy the VCI field from the incoming ATM 453 cell header into this field. The egress router MAY generate a 454 new VCI based on the value of the VC label. 456 * PTI & CLP ( C bit ) 458 The PTI and CLP fields are the PTI and CLP fields of the incoming 459 ATM cells. The cell headers of the cells within the packet are 460 the ATM headers (without HEC) of the incoming cell. 462 4.2.3. OAM Cell Support 464 OAM cells MAY be transported on the VC LSP. A router that does not 465 support transport of OAM cells MUST discard incoming MPLS frames on 466 an ATM VC LSP that contain an ATM cell with the high-order bit of the 467 PTI field set to 1. A router that supports transport of OAM cells 468 MUST follow the procedures outlined in [4] section 8 for mode 0 only, 469 in addition to the applicable procedures specified in [1]. 471 4.2.4. CLP bit to MPLS label stack EXP bit mapping 473 The ingress LSR MAY consider the CLP bit when determining the value 474 to be placed in the EXP fields of the MPLS label stack. This will 475 give the MPLS network visibility of the CLP bit. Note however that 476 cells from the same VC MUST NOT be reordered by the MPLS network. 478 4.3. Ethernet VLAN 480 For an Ethernet 802.1q VLAN the entire Ethernet frame without the 481 preamble or FCS is transported as a single packet. The sequencing 482 control word is OPTIONAL. If the control word is used then the flag 483 bits in the control word are not used, and MUST be set to 0 when 484 transmitting, and MUST be ignored upon receipt. The 4 byte VLAN tag 485 is transported as is, and MAY be overwritten by the egress LSR. 487 The ingress LSR MAY consider the user priority field [5] of the VLAN 488 tag header when determining the value to be placed in the EXP fields 489 of the MPLS label stack. In a similar way, the egress LSR MAY 490 consider the EXP field of the VC label when queuing the packet for 491 egress. Ethernet packets containing hardware level CRC errors, 492 framing errors, or runt packets MUST be discarded on input. 494 4.4. Ethernet 496 For simple Ethernet port to port transport, the entire Ethernet frame 497 without the preamble or FCS is transported as a single packet. The 498 sequencing control word is OPTIONAL. If the control word is used then 499 the flag bits in the control word are not used, and MUST be set to 0 500 when transmitting, and MUST be ignored upon receipt. As in the 501 Ethernet VLAN case, Ethernet packets with hardware level CRC errors, 502 framing errors, and runt packets MUST be discarded on input. 504 4.5. HDLC ( Cisco ) 506 HDLC (Cisco) mode provides port to port transport of Cisco HDLC 507 encapsulated traffic. The HDLC PDU is transported in its entirety, 508 including the HDLC address, control and protocol fields, but 509 excluding HDLC flags and the FCS. Bit stuffing is undone. The 510 sequencing control word is OPTIONAL. 512 4.6. PPP 514 PPP mode provides point to point transport of PPP encapsulated 515 traffic, as specified in [6]. The PPP PDU is transported in its 516 entirety, including the protocol field, but excluding any media- 517 specific framing information, such as HDLC address and control fields 518 or FCS. The sequencing control word is OPTIONAL. 520 5. Security Considerations 522 This document does not affect the underlying security issues of MPLS. 524 6. Intellectual Property Disclaimer 526 This document is being submitted for use in IETF standards 527 discussions. 529 7. References 531 [1] "Transport of Layer 2 Frames Over MPLS", draft-martini- 532 l2circuit-trans-mpls-05.txt. ( work in progress ) 534 [2] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 535 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 537 [3] "Frame Relay / ATM PVC Service Interworking Implementation 538 Agreement", Frame Relay Forum 2000. 540 [4] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 542 [5] "IEEE 802.3ac-1998" IEEE standard specification. 544 [6] "The Point-to-Point Protocol (PPP)", RFC 1661. 546 8. Author Information 548 Luca Martini 549 Level 3 Communications, LLC. 550 1025 Eldorado Blvd. 551 Broomfield, CO, 80021 552 e-mail: luca@level3.net 554 Nasser El-Aawar 555 Level 3 Communications, LLC. 556 1025 Eldorado Blvd. 557 Broomfield, CO, 80021 558 e-mail: nna@level3.net 560 Giles Heron 561 Level 3 Communications 562 66 Prescot Street 563 London 564 E1 8HG 565 United Kingdom 566 e-mail: giles@level3.net 568 Dimitri Stratton Vlachos 569 Mazu Networks, Inc. 570 125 Cambridgepark Drive 571 Cambridge, MA 02140 572 e-mail: d@mazunetworks.com 574 Dan Tappan 575 Cisco Systems, Inc. 576 250 Apollo Drive 577 Chelmsford, MA, 01824 578 e-mail: tappan@cisco.com 580 Jayakumar Jayakumar, 581 Cisco Systems Inc. 582 225, E.Tasman, MS-SJ3/3, 583 San Jose , CA, 95134 584 e-mail: jjayakum@cisco.com 585 Alex Hamilton, 586 Cisco Systems Inc. 587 285 W. Tasman , MS-SJCI/3/4, 588 San Jose, CA, 95134 589 e-mail: tahamilt@cisco.com 591 Eric Rosen 592 Cisco Systems, Inc. 593 250 Apollo Drive 594 Chelmsford, MA, 01824 595 e-mail: erosen@cisco.com 597 Steve Vogelsang 598 Laurel Networks, Inc. 599 2607 Nicholson Rd. 600 Sewickley, PA 15143 601 e-mail: sjv@laurelnetworks.com 603 John Shirron 604 Laurel Networks, Inc. 605 2607 Nicholson Rd. 606 Sewickley, PA 15143 607 e-mail: jshirron@laurelnetworks.com 609 Toby Smith 610 Laurel Networks, Inc. 611 2607 Nicholson Rd. 612 Sewickley, PA 15143 613 e-mail: tob@laurelnetworks.com 615 Andrew G. Malis 616 Vivace Networks, Inc. 617 2730 Orchard Parkway 618 San Jose, CA 95134 619 e-mail: Andy.Malis@vivacenetworks.com 621 Vinai Sirkay 622 Vivace Networks, Inc. 623 2730 Orchard Parkway 624 San Jose, CA 95134 625 e-mail: vinai.sirkay@vivacenetworks.com 626 Kireeti Kompella 627 Juniper Networks 628 1194 N. Mathilda Ave 629 Sunnyvale, CA 94089 630 e-mail: kireeti@juniper.net