idnits 2.17.00 (12 Aug 2021) /tmp/idnits33004/draft-martini-l2circuit-encap-mpls-02.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 122: '...otocols this word is REQUIRED, and for...' RFC 2119 keyword, line 123: '... others OPTIONAL....' RFC 2119 keyword, line 139: '... They MUST be set to 0 when transmit...' RFC 2119 keyword, line 148: '... length field MUST be set to the pac...' RFC 2119 keyword, line 149: '... field MUST be set to zero. The valu...' (74 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 (May 2001) is 7676 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: November 2001 Level 3 Communications, LLC. 6 Steve Vogelsang Daniel Tappan 7 John Shirron Eric C. Rosen 8 Toby Smith Alex Hamilton 9 Laurel Networks, Inc. Jayakumar Jayakumar 10 Cisco Systems, Inc. 12 Vasile Radoaca Dimitri Stratton Vlachos 13 Nortel Networks Mazu Networks, Inc. 15 Andrew G. Malis Chris Liljenstolpe 16 Vinai Sirkay Cable & Wireless 17 Vivace Networks, Inc. 18 Giles Heron 19 Gone2 Ltd. 21 May 2001 23 Encapsulation Methods for Transport of Layer 2 Frames Over MPLS 25 draft-martini-l2circuit-encap-mpls-02.txt 27 Status of this Memo 29 This document is an Internet-Draft and is in full conformance with 30 all provisions of Section 10 of RFC2026. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that other 34 groups may also distribute working documents as Internet-Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Abstract 49 This document describes methods for encapsulating the Protocol Data 50 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, or 51 Ethernet for transport across an MPLS network. 53 Table of Contents 55 1 Specification of Requirements .......................... 2 56 2 Introduction ........................................... 3 57 3 General encapsulation method ........................... 3 58 3.1 The Control Word ....................................... 3 59 3.1.1 Setting the sequence number ............................ 4 60 3.1.2 Processing the sequence number ......................... 5 61 3.2 MTU Requirements ....................................... 5 62 3.3 MPLS Shim EXP Bit Values ............................... 6 63 3.4 MPLS Shim S Bit Value .................................. 6 64 3.5 MPLS Shim TTL Values ................................... 6 65 4 Protocol-Specific Details .............................. 6 66 4.1 Frame Relay ............................................ 6 67 4.2 ATM .................................................... 8 68 4.2.1 ATM AAL5 CPCS-PDU Mode ................................. 8 69 4.2.2 ATM Cell Mode .......................................... 9 70 4.2.3 OAM Cell Support ....................................... 11 71 4.2.4 CLP bit to MPLS label stack EXP bit mapping ............ 11 72 4.3 Ethernet VLAN .......................................... 11 73 4.4 Ethernet ............................................... 12 74 4.5 HDLC ( Cisco ) ......................................... 12 75 4.6 PPP .................................................... 12 76 5 Security Considerations ................................ 13 77 6 Intellectual Property Disclaimer ....................... 13 78 7 References ............................................. 13 79 8 Author Information ..................................... 13 81 1. Specification of Requirements 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC 2119 87 2. Introduction 89 In an MPLS network, it is possible to carry the Protocol Data Units 90 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 91 these PDUs. This document specifies the necessary encapsulation 92 procedures for accomplishing this. One possible control protocol 93 method is described in [1]. QoS related issues are not discussed in 94 this draft. For the purpose of this document R1 will be defined as 95 the ingress LSR, and R2 as the egress LSR. A layer 2 PDU will be 96 received at R1, encapsulated at R1, transported, decapsulated at R2, 97 and transmitted out of R2. In a similar way, the "VC label" is 98 defined as the label at the bottom of the label stack used to 99 transmit the layer 2 PDU. 101 3. General encapsulation method 103 When transporting layer 2 protocols over MPLS it is, in most cases, 104 not necessary to transport the layer 2 encapsulation across the MPLS 105 network. In most cases the layer 2 header can be stripped at R1, and 106 reproduced at R2 with the help of some extra encapsulation 107 information, some of which is a priori signaled, and some of which 108 may be carried in the control word described below. 110 3.1. The Control Word 112 There are three requirements that may need to be satisfied when 113 transporting layer 2 protocols over MPLS: 114 -i. Sequentiality may need to be preserved. 115 -ii. Small packets may need to be padded in order to be 116 transmitted on a medium where the minimum transport unit is 117 larger than the actual packet size. 118 -iii. Control bits carried in the header of the layer 2 frame may 119 need to be transported. 121 The control word defined here addresses all three of these 122 requirements. For some protocols this word is REQUIRED, and for 123 others OPTIONAL. 125 In all cases the the egress LSR must be aware of whether the ingress 126 LSR will send a control word over a specific virtual circuit. This 127 may be achived by configuration of the LSRs, or by signaling, for 128 example as defined in [1]. 130 The control word is defined as follows: 132 0 1 2 3 133 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 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Rsvd | Flags | Length | Sequence Number | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 In the above diagram the first 4 bits are reserved for future use. 139 They MUST be set to 0 when transmitting, and MUST be ignored upon 140 receipt. 142 The next 4 bits provide space for carrying protocol specific flags. 143 These are defined in the protocol-specific details below. 145 The next 8 bits provide a length field, which is used as follows: If 146 the packet's length (defined as the length of the layer 2 payload 147 plus the length of the control word) is less than 256 bytes, the 148 length field MUST be set to the packet's length. Otherwise the length 149 field MUST be set to zero. The value of the length field, if non- 150 zero, can be used to remove any padding. When the packet reaches the 151 service provider's egress LSR, it may be desirable to remove the 152 padding before forwarding the packet. 154 The next 16 bits provide a sequence number that can be used to 155 guarantee ordered packet delivery. The processing of the sequence 156 number field is OPTIONAL. 158 The sequence number space is a 16 bit, unsigned circular space. The 159 sequence number value 0 is used to indicate an unsequenced packet. 161 3.1.1. Setting the sequence number 163 Given a VC label V and a pair of LSRs R1 and R2, where R2 has 164 distributed V to R1. If R1 supports packet sequencing then the 165 following procedures should be used: 167 - the initial packet transmitted to label V MUST use sequence 168 number 1 169 - subsequent packets MUST increment the sequence number by one for 170 each packet 171 - when the transmit sequence number reaches the maximum 16 bit 172 value (65535) the sequence number MUST wrap to 1 174 If the transmitting LSR R1 does not support sequence number 175 processing, then the sequence number field in the control word MUST 176 be set to 0. 178 3.1.2. Processing the sequence number 180 If an LSR R2 supports receive sequence number processing, then the 181 following procedures should be used: 183 When a VC label V is first distributed, the "expected sequence 184 number" associated with V MUST be initialized to 1 186 When a packet is received with label V the sequence number should be 187 processed as follows: 188 - if the sequence number on the packet is 0, then the packet passes 189 the sequence number check 190 - otherwise if the packet sequence number >= the expected sequence 191 number and the packet sequence number - the expected sequence 192 number < 32768, then the packet is in order. 193 - otherwise if the packet sequence number < the expected sequence 194 number and the expected sequence number - the packet sequence 195 number >= 32768, then the packet is in order. 196 - otherwise the packet is out of order. 198 If a packet passes the sequence number check, or is in order then, it 199 can be delivered immediately. If the packet is in order, then the 200 expected sequence number should be set using the algorithm: 202 expected_sequence_number := packet_sequence_number + 1 mod 2**16 203 if (expected_sequence_number = 0) then expected_sequence_number := 1; 205 Packets which are received out of order MAY be dropped or reordered 206 at the discretion of the receiver. 208 If an LSR R2 does not support receive sequence number processing, 209 then the sequence number field MAY be ignored. 211 3.2. MTU Requirements 213 The MPLS network MUST be configured with an MTU that is sufficient to 214 transport the largest frame size that will be transported in the 215 LSPs. Note that this is likely to be 12 or more bytes greater than 216 the largest frame size. If a packet length, once it has been 217 encapsulated on the ingress LSR, exceeds the LSP MTU, it MUST be 218 dropped. If an egress LSR receives a packet on a VC LSP with a 219 length, once the label stack and control word have been popped, that 220 exceeds the MTU of the destination layer 2 interface, it MUST be 221 dropped. 223 3.3. MPLS Shim EXP Bit Values 225 The ingress LSR, R1, SHOULD set the EXP field of the VC label to the 226 same value as the EXP field of the previous label in the stack (if in 227 fact a stack of more than one label is imposed at the ingress.) This 228 will ensure that the EXP field will be visible to the egress LSR, R2, 229 in the event of the packet having been penultimate hop popped. 231 3.4. MPLS Shim S Bit Value 233 The ingress LSR, R1, MUST set the S bit of the VC label to a value of 234 1 to denote that the VC label is at the bottom of the stack. 236 3.5. MPLS Shim TTL Values 238 The ingress LSR, R1, MAY set the TTL field of the VC label to a value 239 of 2. 241 4. Protocol-Specific Details 243 4.1. Frame Relay 245 A Frame Relay PDU is transported without the Frame Relay header or 246 the FCS. The control word is REQUIRED. 248 The BECN, FECN, DE and C/R bits are carried across the network in the 249 control word. The edge LSRs that implement this document MAY, when 250 either adding or removing the encapsulation described herein, change 251 the BECN and/or FECN bits from zero to one in order to reflect 252 congestion in the MPLS network that is known to the edge LSRs, and 253 the D/E bit from zero to one to reflect marking from edge policing of 254 the Frame Relay Committed Information Rate. The BECN, FECN, and D/E 255 bits MUST NOT be changed from one to zero. 257 The following is an example of a Frame Relay packet: 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | VC Label | EXP |S| TTL | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Rsvd |B|F|D|C| Length | Sequence Number | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Frame Relay PDU | 267 | " | 268 | " | 269 | " | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 * B ( BECN ) Bit 274 The ingress LSR, R1, MUST copy the BECN field from the incoming 275 Frame Relay header into this field. The egress LSR, R2, MUST 276 generate a new BECN field based on the value of the B bit. 278 * F ( FECN ) Bit 280 The ingress LSR, R1, MUST copy the FECN field from the incoming 281 Frame Relay header into this field. The egress LSR, R2, MUST 282 generate a new FECN field based on the value of the F bit. 284 * D ( DE ) Bit 286 The ingress LSR, R1, MUST copy the DE field from the incoming 287 Frame Relay header into this field. The egress LSR, R2, MUST 288 generate a new DE field based on the value of the D bit. 290 The ingress LSR, R1, MAY consider the DE bit of the Frame Relay 291 header when determining the value to be placed in the EXP field 292 of the MPLS label stack. In a similar way, the egress LSR, R2, 293 MAY consider the EXP field of the VC label when queuing the 294 packet for egress. Note however that frames from the same VC MUST 295 NOT be reordered by the MPLS network. 297 * C ( C/R ) Bit 299 The ingress LSR, R1, MUST copy the C/R bit from the received 300 Frame Relay PDU to the C bit of the control word. The egress 301 LSR, R2, MUST copy the C bit into the output frame. 303 The Label, EXP, S, and TTL fields are described in [2]. 305 4.2. ATM 307 Two encapsulations are supported for ATM transport: one for ATM AAL5 308 and another for ATM cells. 310 The AAL5 CPCS-PDU encapsulation consists of the MPLS label stack, a 311 REQUIRED control word, and the AAL5 CPCS-PDU. 313 The ATM cell encapsulation consists of an MPLS label stack, an 314 OPTIONAL control word, a 4 byte ATM cell header, and the ATM cell 315 payload. 317 4.2.1. ATM AAL5 CPCS-PDU Mode 319 In ATM AAL5 mode the ingress LSR is required to reassemble AAL5 320 CPCS-PDUs from the incoming VC and transport each CPCS-PDU as a 321 single packet. No AAL5 trailer is transported. The control word is 322 REQUIRED. 324 The EFCI and CLP bits are carried across the network in the control 325 word. The edge LSRs that implement this document MAY, when either 326 adding or removing the encapsulation described herein, change the 327 EFCI bit from zero to one in order to reflect congestion in the MPLS 328 network that is known to the edge LSRs, and the CLP bit from zero to 329 one to reflect marking from edge policing of the ATM Sustained Cell 330 Rate. The EFCI and CLP bits MUST NOT be changed from one to zero. 332 The AAL5 CPCS-PDU is prepended by the following header: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | VC Label | EXP |S| TTL | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Rsvd |T|E|L|C| Length | Sequence Number | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | ATM AAL5 CPCS-PDU | 342 | " | 343 | " | 344 | " | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 * T (transport type) bit 349 Bit (T) of the control word indicates whether the MPLS packet 350 contains an ATM cell or an AAL5 CPCS-PDU. If set the packet 351 contains an ATM cell, encapsulated according to the ATM cell mode 352 section below, otherwise it contains an AAL5 CPCS-PDU. The 353 ability to transport an ATM cell in the AAL5 mode is intended to 354 provide a means of enabling OAM functionality over the AAL5 VC. 356 * E ( EFCI ) Bit 358 The ingress LSR, R1, SHOULD set this bit to 1 if the EFCI bit of 359 the final cell of those that transported the AAL5 CPCS-PDU is set 360 to 1, or if the EFCI bit of the single ATM cell to be transported 361 in the MPLS packet is set to 1. Otherwise this bit SHOULD be set 362 to 0. The egress LSR, R2, SHOULD set the EFCI bit of all cells 363 that transport the AAL5 CPCS-PDU to the value contained in this 364 field. 366 * L ( CLP ) Bit 368 The ingress LSR, R1, SHOULD set this bit to 1 if the CLP bit of 369 any of the ATM cells that transported the AAL5 CPCS-PDU is set to 370 1, or if the CLP bit of the single ATM cell to be transported in 371 the MPLS packet is set to 1. Otherwise this bit SHOULD be set to 372 0. The egress LSR, R2, SHOULD set the CLP bit of all cells that 373 transport the AAL5 CPCS-PDU to the value contained in this field. 375 * C ( Command / Response Field ) Bit 377 When FRF.8.1 Frame Relay / ATM PVC Service Interworking [3] 378 traffic is being transported, the CPCS-UU Least Significant Bit 379 (LSB) of the AAL5 CPCS-PDU may contain the Frame Relay C/R bit. 380 The ingress LSR, R1, SHOULD copy this bit to the C bit of the 381 control word. The egress LSR, R2, SHOULD copy the C bit to the 382 CPCS-UU Least Significant Bit (LSB) of the AAL5 CPCS PDU. 384 The Label, EXP, S, and TTL fields are described in [2]. 386 4.2.2. ATM Cell Mode 388 In this encapsulation mode ATM cells are transported individually 389 without a SAR process. The ATM cell encapsulation consists of an MPLS 390 label stack, an OPTIONAL control word, and one or more ATM cells - 391 each consisting of a 4 byte ATM cell header and the 48 byte ATM cell 392 payload. This ATM cell header is defined as in the FAST encapsulation 393 [4] section 3.1.1, but without the trailer byte. The length of each 394 frame, without the MPLS header and the control word, is a multiple of 395 52 bytes long. The maximum number of ATM cells that can be fitted in 396 an MPLS frame, in this fashion, is limited only by the MPLS network 397 MTU and by the ability of the egress LSR to process them. The ingress 398 LSR MUST NOT send more cells than the egress LSR is willing to 399 receive. The number of cells that the egress LSR is willing to 400 receive may either be configured in the ingress LSR or may be 401 signaled, for example using the methods described in [1]. The number 402 of cells encapsulated in a particular frame can be inferred by the 403 frame length. The control word is OPTIONAL. If the control word is 404 used then the flag bits in the control word are not used, and MUST be 405 set to 0 when transmitting, and MUST be ignored upon receipt. 407 The EFCI and CLP bits are carried across the network in the ATM cell 408 header. The edge LSRs that implement this document MAY, when either 409 adding or removing the encapsulation described herein, change the 410 EFCI bit from zero to one in order to reflect congestion in the MPLS 411 network that is known to the edge LSRs, and the CLP bit from zero to 412 one to reflect marking from edge policing of the ATM Sustained Cell 413 Rate. The EFCI and CLP bits MUST NOT be changed from one to zero. 415 This diagram illustrates an encapsulation of two ATM cells: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | VC Label | EXP |S| TTL | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Control word ( Optional ) | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | VPI | VCI | PTI |C| 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | ATM Payload ( 48 bytes ) | 427 | " | 428 | " | 429 | " | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | VPI | VCI | PTI |C| 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | ATM Payload ( 48 bytes ) | 434 | " | 435 | " | 436 | " | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 * VPI 441 The ingress router MUST copy the VPI field from the incoming cell 442 into this field. The egress router MAY generate a new VPI based 443 on the value of the VC label and ignore the VPI contained in this 444 field. 446 * VCI 448 The ingress router MUST copy the VCI field from the incoming ATM 449 cell header into this field. The egress router MAY generate a 450 new VCI based on the value of the VC label. 452 * PTI & CLP ( C bit ) 454 The PTI and CLP fields are the PTI and CLP fields of the incoming 455 ATM cells. The cell headers of the cells within the packet are 456 the ATM headers (without HEC) of the incoming cell. 458 4.2.3. OAM Cell Support 460 OAM cells MAY be transported on the VC LSP. A router that does not 461 support transport of OAM cells MUST discard incoming MPLS frames on 462 an ATM VC LSP that contain an ATM cell with the high-order bit of the 463 PTI field set to 1. A router that supports transport of OAM cells 464 MUST follow the procedures outlined in [4] section 8 for mode 0 only, 465 in addition to the applicable procedures specified in [1]. 467 4.2.4. CLP bit to MPLS label stack EXP bit mapping 469 The ingress LSR MAY consider the CLP bit when determining the value 470 to be placed in the EXP fields of the MPLS label stack. This will 471 give the MPLS network visibility of the CLP bit. Note however that 472 cells from the same VC MUST NOT be reordered by the MPLS network. 474 4.3. Ethernet VLAN 476 For an Ethernet 802.1q VLAN the entire Ethernet frame without the 477 preamble or FCS is transported as a single packet. The control word 478 is OPTIONAL. If the control word is used then the flag bits in the 479 control word are not used, and MUST be set to 0 when transmitting, 480 and MUST be ignored upon receipt. The 4 byte VLAN tag is transported 481 as is, and MAY be overwritten by the egress LSR. 483 The ingress LSR MAY consider the user priority field [5] of the VLAN 484 tag header when determining the value to be placed in the EXP fields 485 of the MPLS label stack. In a similar way, the egress LSR MAY 486 consider the EXP field of the VC label when queuing the packet for 487 egress. Ethernet packets containing hardware level CRC errors, 488 framing errors, or runt packets MUST be discarded on input. 490 4.4. Ethernet 492 For simple Ethernet port to port transport, the entire Ethernet frame 493 without the preamble or FCS is transported as a single packet. The 494 control word is OPTIONAL. If the control word is used then the flag 495 bits in the control word are not used, and MUST be set to 0 when 496 transmitting, and MUST be ignored upon receipt. As in the Ethernet 497 VLAN case, Ethernet packets with hardware level CRC errors, framing 498 errors, and runt packets MUST be discarded on input. 500 4.5. HDLC ( Cisco ) 502 HDLC (Cisco) mode provides port to port transport of Cisco HDLC 503 encapsulated traffic. The HDLC PDU is transported in its entirety, 504 including the HDLC address, control and protocol fields, but 505 excluding HDLC flags and the FCS. Bit stuffing is undone. The 506 control word is OPTIONAL. If the control word is used then the flag 507 bits in the control word are not used, and MUST be set to 0 when 508 transmitting, and MUST be ignored upon receipt. 510 4.6. PPP 512 PPP mode provides point to point transport of PPP encapsulated 513 traffic, as specified in [6]. The PPP PDU is transported in its 514 entirety, including the protocol field (whether compressed using PFC 515 or not), but excluding any media-specific framing information, such 516 as HDLC address and control fields or FCS. Since media-specific 517 framing is not carried the following options will not operate 518 correctly if the PPP peers attempt to negotiate them: 520 Frame Check Sequence (FCS) Alternatives Address-and-Control-Field- 521 Compression (ACFC) Asynchronous-Control-Character-Map (ACCM) 523 Note also that VC LSP Interface MTU negotiation as specified in [1] 524 is not affected by PPP MRU advertisement. Thus if a PPP peer sends a 525 PDU with a length in excess of that negotiated for the VC LSP that 526 PDU will be discarded by the ingress LSR. 528 The control word is OPTIONAL. If the control word is used then the 529 flag bits in the control word are not used, and MUST be set to 0 when 530 transmitting, and MUST be ignored upon receipt. 532 5. Security Considerations 534 This document does not affect the underlying security issues of MPLS. 536 6. Intellectual Property Disclaimer 538 This document is being submitted for use in IETF standards 539 discussions. 541 7. References 543 [1] "Transport of Layer 2 Frames Over MPLS", draft-martini- 544 l2circuit-trans-mpls-06.txt. ( work in progress ) 546 [2] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 547 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 549 [3] "Frame Relay / ATM PVC Service Interworking Implementation 550 Agreement", Frame Relay Forum 2000. 552 [4] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 554 [5] "IEEE 802.3ac-1998" IEEE standard specification. 556 [6] "The Point-to-Point Protocol (PPP)", RFC 1661. 558 8. Author Information 560 Luca Martini 561 Level 3 Communications, LLC. 562 1025 Eldorado Blvd. 563 Broomfield, CO, 80021 564 e-mail: luca@level3.net 566 Nasser El-Aawar 567 Level 3 Communications, LLC. 568 1025 Eldorado Blvd. 569 Broomfield, CO, 80021 570 e-mail: nna@level3.net 571 Giles Heron 572 Gone2 Ltd. 573 c/o MDP 574 One Curzon Street 575 London 576 W1J 5HD 577 United Kingdom 578 e-mail: giles@goneto.net 580 Dimitri Stratton Vlachos 581 Mazu Networks, Inc. 582 125 Cambridgepark Drive 583 Cambridge, MA 02140 584 e-mail: d@mazunetworks.com 586 Dan Tappan 587 Cisco Systems, Inc. 588 250 Apollo Drive 589 Chelmsford, MA, 01824 590 e-mail: tappan@cisco.com 592 Jayakumar Jayakumar, 593 Cisco Systems Inc. 594 225, E.Tasman, MS-SJ3/3, 595 San Jose , CA, 95134 596 e-mail: jjayakum@cisco.com 598 Alex Hamilton, 599 Cisco Systems Inc. 600 285 W. Tasman , MS-SJCI/3/4, 601 San Jose, CA, 95134 602 e-mail: tahamilt@cisco.com 604 Eric Rosen 605 Cisco Systems, Inc. 606 250 Apollo Drive 607 Chelmsford, MA, 01824 608 e-mail: erosen@cisco.com 609 Steve Vogelsang 610 Laurel Networks, Inc. 611 2607 Nicholson Rd. 612 Sewickley, PA 15143 613 e-mail: sjv@laurelnetworks.com 615 John Shirron 616 Laurel Networks, Inc. 617 2607 Nicholson Rd. 618 Sewickley, PA 15143 619 e-mail: jshirron@laurelnetworks.com 621 Toby Smith 622 Laurel Networks, Inc. 623 2607 Nicholson Rd. 624 Sewickley, PA 15143 625 e-mail: tob@laurelnetworks.com 627 Andrew G. Malis 628 Vivace Networks, Inc. 629 2730 Orchard Parkway 630 San Jose, CA 95134 631 e-mail: Andy.Malis@vivacenetworks.com 633 Vinai Sirkay 634 Vivace Networks, Inc. 635 2730 Orchard Parkway 636 San Jose, CA 95134 637 e-mail: vinai.sirkay@vivacenetworks.com 639 Vasile Radoaca 640 Nortel Networks 641 600 Technology Park 642 Billerica MA 01821 643 e-mail: vasile@nortelnetworks.com 645 Chris Liljenstolpe 646 Cable & Wireless 647 11700 Plaza America Drive 648 Reston, VA 20190 649 chris@cw.net