idnits 2.17.1 draft-martini-l2circuit-trans-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. ** There are 27 instances of too long lines in the document, the longest one being 9 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 (July 2000) is 8686 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) == Unused Reference: '3' is defined on line 421, 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' Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 4 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: January 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 July 2000 17 Transport of Layer 2 Frames Over MPLS 19 draft-martini-l2circuit-trans-mpls-02.txt 21 Status of this Memo 23 This document is an Internet-Draft and is in full conformance with 24 all provisions of Section 10 of RFC2026. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 Abstract 44 This document described a method for transporting the Protocol Data 45 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, and 46 ethernet across an MPLS network. 48 Table of Contents 50 1 Specification of Requirements .......................... 2 51 2 Introduction ........................................... 2 52 3 Tunnel Labels and VC Labels ............................ 3 53 4 Optional Sequencing and/or Padding ..................... 4 54 5 Protocol-Specific Issues ............................... 5 55 5.1 Frame Relay ............................................ 5 56 5.2 ATM .................................................... 5 57 5.2.1 F5 OAM Cell Support .................................... 6 58 5.2.2 CLP Bit ................................................ 6 59 5.2.3 PTI Field in ATM Cell Mode ............................. 6 60 5.3 Ethernet VLAN .......................................... 7 61 5.4 Ethernet ............................................... 7 62 6 LDP .................................................... 7 63 7 Security Considerations ................................ 10 64 8 References ............................................. 10 65 9 Author Information ..................................... 10 67 1. Specification of Requirements 69 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 70 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 71 document are to be interpreted as described in RFC 2119. 73 2. Introduction 75 In an MPLS network, it is possible to carry the Protocol Data Units 76 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 77 these PDUs. This document specifies the necessary label distribution 78 and encapsulation procedures for accomplishing this. We restrict 79 discussion to the case of point-to-point transport. QoS related 80 issues are not discussed in this draft. 82 3. Tunnel Labels and VC Labels 84 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 85 to egress LSR R2, across an intervening MPLS network. We assume that 86 there is an LSP from R1 to R2. That is, we assume that R1 can cause 87 a packet to be delivered to R2 by pushing some label onto the packet 88 and sending the result to one of its adjacencies. Call this label 89 the "tunnel label", and the corresponding LSP the "tunnel LSP". 91 The tunnel LSP merely gets packets from R1 to R2, the corresponding 92 label doesn't tell R2 what to do with the payload, and in fact if 93 penultimate hop popping is used, R2 may never even see the 94 corresponding label. (If R1 itself is the penultimate hop, a tunnel 95 label may not even get pushed on.) Thus if the payload is not an IP 96 packet, there must be a label, which becomes visible to R2, that 97 tells R2 how to treat the received packet. Call this label the "VC 98 label". 100 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 101 its label stack, and then (if R1 is not adjacent to R2) pushes on a 102 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 103 the VC label is not visible until the MPLS packet reaches R2. R2's 104 disposition of the packet is based on the VC label. 106 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 107 the VC label will generally correspond to a particular ATM VC at R2. 108 That is, R2 needs to be able to infer from the VC label the outgoing 109 interface and the VPI/VCI value for the AAL5 PDU. If the payload is 110 a Frame Relay PDU, then R2 needs to be able to infer from the VC 111 label the outgoing interface and the DLCI value. If the payload is 112 an ethernet frame, then R2 needs to be able to infer from the VC 113 label the outgoing interface, and perhaps the VLAN identifier. This 114 process is unidirectional, and will be repeated independently for 115 bidirectional operation. It is desirable, but not required, to assign 116 the same VC, and Group ID for a given circuit in both directions. 117 Note that the VC label must always be at the bottom of the label 118 stack, and the tunnel label, if present, must be immediately above 119 the VC label. Of course, as the packet is transported across the 120 MPLS network, additional labels may be pushed on (and then popped 121 off) as needed. Even R1 itself may push on additional labels above 122 the tunnel label. If R1 and R2 are directly adjacent LSRs, then it 123 may not be necessary to use a tunnel label at all. 125 This document does not specify a method for distributing the tunnel 126 label or any other labels that may appear above it on the stack. Any 127 acceptable method of MPLS label distribution will do. 129 This document does specify a method for assigning and distributing 130 the VC label. Static label assignment MAY be used, and 131 implementations SHOULD provide support for this. If signaling is 132 used, the VC label MUST be distributed from R2 to R1 using LDP in the 133 downstream unsolicited mode; this requires that an LDP connection be 134 created between R1 and R2. 136 Note that this technique allows an unbounded number of layer 2 "VCs" 137 to be carried together in a single "tunnel". Thus it scales quite 138 well in the network backbone. 140 The MPLS network should be configured with a MTU that is at least 12 141 bytes larger then the largest packet size that will be transported in 142 the LSPs. If a packet, once it has been encapsulated, exceeds the 143 LSP MTU , it MUST be dropped. 145 4. Optional Sequencing and/or Padding 147 Sometimes it is important to guarantee that sequentiality is 148 preserved on a layer 2 virtual circuit. To accommodate this 149 requirement, we provide an optional control word which may appear 150 immediately after the label stack and immediately before the layer 2 151 PDU. This control word contains a sequence number. R1 and R2 both 152 need to be configured with the knowledge of whether a control word 153 will be used for a specific virtual circuit. 155 Sometimes it is necessary to transmit a small packet on a medium 156 where there is a minimum transport unit larger than the actual packet 157 size. In this case, padding is appended to the packet. When the VC 158 label is popped, it may be desirable to remove the padding before 159 forwarding the packet. 161 To facilitate this, the control word has a length field. If the 162 packet's length (without any padding) is less than 256 bytes, the 163 length field MUST be set to the packet's length (without padding). 164 Otherwise the length field MUST be set to zero. The value of the 165 length field, if non-zero, can be used to remove any padding. 167 The control word is defined as follows: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Reserved | Length | Sequence Number | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 The first 8 bits are reserved for future use. They MUST be set to 0 176 when transmitting, and MUST be ignored upon receipt. The length byte 177 is set as specified above. 179 The next 16 bits are the sequence number that is used to guarantee 180 ordered packet delivery. For a given VC label, and a given pair of 181 LSRs, R1 and R2, where R2 has distributed that VC label to R1, the 182 sequence number is initialized to 0, and is incremented by one for 183 each successive packet carrying that VC label which R1 transmits to 184 R2. 186 The sequence number space is a 16 bit unsigned circular space. PDUs 187 carrying the control word MUST NOT be delivered out of order. They 188 may be discarded or reordered. 190 5. Protocol-Specific Issues 192 5.1. Frame Relay 194 A Frame Relay PDU is transported in its entirety, including the Frame 195 Relay Header. The sequencing control word is OPTIONAL. 197 The BCN and FCN signals are carried unchanged across the network in 198 the frame relay header. These signals do not appear in the MPLS 199 header, and are unseen by the MPLS network. 201 If the MPLS edge LSR detects a service affecting condition as defined 202 in [2] Q.933 Annex A.5 sited in IA FRF1.1, it will withdraw the label 203 that corresponds to the frame relay DLCI. The Egress side should 204 generate the corresponding errors and alarms as defined in [2] on the 205 Frame relay VC. 207 The ingress LSR MAY consider the DE bit of the Frame Relay header 208 when determining the value to be placed in the EXP fields of the MPLS 209 label stack. In a similar way, the egress LSR MAY consider the EXP 210 field of the VC label when queuing the packet for egress. 212 5.2. ATM 214 Two modes are supported for ATM transport, ATM Adaptation Layer 5 215 (AAL5) and ATM cell. 217 In ATM AAL5 mode the ingress LSR is required to reassemble AAL5 218 CPCS-PDUs from the incoming VC and transport each CPCS-PDU as a 219 single packet. No AAL5 trailer is transported. The sequencing control 220 word is OPTIONAL. 222 In ATM cell mode the ingress LSR transports each ATM cell payload as 223 a single packet. No ATM cell header is transported. The sequencing 224 control word is OPTIONAL. 226 5.2.1. F5 OAM Cell Support 228 F5 OAM cells are not transported on the VC LSP. 230 If an F5 end-to-end OAM cell is received from a VC by a LSR with a 231 loopback indication value of 1 and the LSR has a label mapping for 232 the VC, the LSR must decrement the loopback indication value and loop 233 back the cell on the VC. Otherwise the loopback cell must be silently 234 discarded by the LSR. 236 A LSR may optionally be configured to periodically generate F5 end- 237 to-end loopback OAM cells on a VC. In this case, the LSR must only 238 generate F5 end-to-end loopback cells while a label mapping exists 239 for the VC. If the VC label mapping is withdrawn the LSR must cease 240 generation of F5 end-to-end loopback OAM cells. If the LSR fails to 241 receive a response to an F5 end-to-end loopback OAM cell for a pre- 242 defined period of time it must withdraw the label mapping for the VC. 244 If an ingress LSR receives an AIS F5 OAM cell, fails to receive a 245 pre-defined number of the End-to-End loop OAM cells, or a physical 246 interface goes down, it must withdraw the label mappings for all VCs 247 associated with the failure. When a VC label mapping is withdrawn, 248 the egress LSR must generate AIS F5 OAM cells on the VC associated 249 with the withdrawn label mapping. 251 5.2.2. CLP Bit 253 The ingress LSR MAY consider the CLP bit when determining the value 254 to be placed in the EXP fields of the MPLS label stack. 256 The egress LSR MAY consider the value of the EXP field of the VC 257 label when determining the value of the ATM CLP bit. 259 5.2.3. PTI Field in ATM Cell Mode 261 ATM cell mode is intended for transporting non-AAL5 traffic only. The 262 ingress LSR must transport cells with a PTI of 0. Cells with a PTI 263 other than 0 are not transported on the LSP. The egress LSR must set 264 the PTI to 0 for cells switched from a VC LSP to an outgoing VC. 266 5.3. Ethernet VLAN 268 For and ethernet 802.1q VLAN the entire ethernet frame without the 269 preamble or FCS is transported as a single packet. The sequencing 270 control word is OPTIONAL. If a packet is received out of sequence it 271 MUST be dropped. The VLAN 4 byte tag is transported as is, and MAY be 272 overwritten by the egress LSR. The ingress LSR MAY consider the user 273 priority field [4] of the VLAN tag header when determining the value 274 to be placed in the EXP fields of the MPLS label stack. In a similar 275 way, the egress LSR MAY consider the EXP field of the VC label when 276 queuing the packet for egress. Ethernet packets containing hardware 277 level CRC, Framing errors, or runt packets MUST be discarded on 278 input. 280 5.4. Ethernet 282 For simple ethernet port to port transport,the entire ethernet frame 283 without the preamble or FCS is transported as a single packet. The 284 sequencing control word is OPTIONAL. If a packet is received out of 285 sequence it MUST be dropped. As in the Ethernet VLAN case, ethernet 286 packets with hardware level CRC, framing, and runt errors are 287 discarded. 289 6. LDP 291 The VC label bindings are distributed using the LDP downstream 292 unsolicited mode described in [1]. The LSRs will establish an LDP 293 session using the Extended Discovery mechanism described in [1, 294 section 2.4-2.5], for this purpose a new type of FEC TLV element is 295 defined. The FEC element type in 128. [note1] 297 The Virtual Circuit FEC TLV element, is defined as follows: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | VC tlv | VC Type |C| VC ID len | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Group ID | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 | VC ID | 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 - VC Type 313 A 15 bit quantity containing a value which represents the type of 314 VC. Assigned Values are: 316 VC TypeDescription 318 0x0001 Frame Relay DLCI 319 0x0002 ATM AAL5 PVC 320 0x0003 ATM Cell 321 0x0004 Ethernet VLAN 322 0x0005 Ethernet 323 0x0006 HDLC ( Cisco ) 324 0x0007 PPP 326 The highest order bit is used to flag the presence of a sequencing control 327 word as follows: 328 bit 15 = 1 control word present on this VC. 329 bit 15 = 0 no control word present on this VC. 331 - VC ID length 333 Length of the VC ID field in octets. If this value is 0, then it 334 references all VCs using the specified group ID 336 - Group ID 338 An arbitrary 32 bit value which represents a group of VCs that is 339 used to augment the VC space. This value MUST be user 340 configurable. The group ID is intended to be used as either a 341 port index , or a virtual tunnel index. In the latter case a 342 switching function at ingress will map a particular circuit from 343 a port to a circuit in the virtual tunnel for transport to the 344 egress router. 346 - VC ID 348 Identifies a particular VC. The interpretation of the identifier 349 depends on the VC type: 351 * Frame Relay 353 A 32-bit value representing a 16-bit DLCI value as follows: 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Reserved | DLCI | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 * ATM AAL5 PVC 363 A 32-bit value representing a 16-bit VPI, and a 16-bit VCI as 364 follows: 366 0 1 2 3 367 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 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | VPI | VCI | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 * ATM Cell 374 A 32-bit value representing a 16-bit VPI, and a 16-bit VCI as 375 follows: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | VPI | VCI | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 * Ethernet VLAN 385 A 32 bit value representing 16bit vlan identifier as follows: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Reserved | VLAN ID | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 * Ethernet 395 A 32 bit port identifier. 397 * HDLC ( Cisco ) 399 A 32-bit port identifier (details TBD). 401 * PPP 403 A 32-bit port identifier (details TBD). 405 The reserved fields in the above specifications MUST be set 406 to 0 in the FEC TLV, and ignored when received. In some cases 407 the the 409 7. Security Considerations 411 This document does not affect the underlying security issues of MPLS. 413 8. References 415 [1] "LDP Specification", draft-ietf-mpls-ldp-07.txt ( work in 416 progress ) 418 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 419 Mode Basic call control, ITU Geneva 1995 421 [3] "MPLS Label Stack Encoding", draft-ietf-mpls-label-encaps-07.txt 422 ( work in progress ) 424 [4] "IEEE 802.3ac-1998" IEEE standard specification. 426 [note1] FEC element type 128 is pending IANA approval. 428 9. Author Information 430 Luca Martini 431 Level 3 Communications, LLC. 432 1025 Eldorado Blvd. 433 Broomfield, CO, 80021 434 e-mail: luca@level3.net 435 Nasser El-Aawar 436 Level 3 Communications, LLC. 437 1025 Eldorado Blvd. 438 Broomfield, CO, 80021 439 e-mail: nna@level3.net 441 Dimitri Stratton Vlachos 442 Cisco Systems, Inc. 443 250 Apollo Drive 444 Chelmsford, MA, 01824 445 e-mail: dvlachos@cisco.com 447 Dan Tappan 448 Cisco Systems, Inc. 449 250 Apollo Drive 450 Chelmsford, MA, 01824 451 e-mail: tappan@cisco.com 453 Eric Rosen 454 Cisco Systems, Inc. 455 250 Apollo Drive 456 Chelmsford, MA, 01824 457 e-mail: erosen@cisco.com 459 Steve Vogelsang 460 Laurel Networks, Inc. 461 2607 Nicholson Rd. 462 Sewickley, PA 15143 463 e-mail: sjv@laurelnetworks.com 465 John Shirron 466 Laurel Networks, Inc. 467 2607 Nicholson Rd. 468 Sewickley, PA 15143 469 e-mail: sjv@laurelnetworks.com