idnits 2.17.1 draft-martini-l2circuit-trans-mpls-04.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 26 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 (November 2000) is 8556 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 381, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 384, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' == Outdated reference: A later version (-12) exists of draft-martini-l2circuit-encap-mpls-00 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. '7') == Outdated reference: A later version (-09) exists of draft-malis-sonet-ces-mpls-01 ** Downref: Normative reference to an Historic draft: draft-malis-sonet-ces-mpls (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 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: May 2001 Giles Heron 5 Level 3 Communications, LLC. 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 Vivace Networks, Inc. 18 Dimitri Stratton Vlachos 19 Mazu Networks, Inc. 21 November 2000 23 Transport of Layer 2 Frames Over MPLS 25 draft-martini-l2circuit-trans-mpls-04.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 transporting the Protocol Data 50 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, 51 Ethernet, and providing a SONET circuit emulation service across an 52 MPLS network. 54 Table of Contents 56 1 Specification of Requirements .......................... 2 57 2 Introduction ........................................... 2 58 3 Tunnel Labels and VC Labels ............................ 3 59 4 Protocol-Specific Issues ............................... 4 60 4.1 Frame Relay ............................................ 4 61 4.2 ATM .................................................... 4 62 4.2.1 OAM Cell Support ....................................... 4 63 4.2.2 ILMI Support ........................................... 5 64 4.3 HDLC ( Cisco ) ......................................... 5 65 4.4 PPP .................................................... 5 66 5 LDP .................................................... 6 67 6 Security Considerations ................................ 9 68 7 References ............................................. 9 69 8 Author Information ..................................... 9 71 1. Specification of Requirements 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119. 77 2. Introduction 79 In an MPLS network, it is possible to carry the Protocol Data Units 80 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 81 these PDUs. This document specifies the necessary label distribution 82 procedures for accomplishing this using the encapsulation methods in 83 [7]. We restrict discussion to the case of point-to-point transport. 84 QoS related issues are not discussed in this draft. 86 An accompanying document [8] also describes a method for transporting 87 time division multiplexed (TDM) digital signals (TDM circuit 88 emulation) over a packet-oriented MPLS network. The transmission 89 system for circuit-oriented TDM signals is the Synchronous Optical 90 Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To 91 support TDM traffic, which includes voice, data, and private leased 92 line service, the MPLS network must emulate the circuit 93 characteristics of SONET/SDH payloads. MPLS labels and a new circuit 94 emulation header are used to encapsulate TDM signals and provide the 95 Circuit Emulation Service over MPLS (CEM). This encapsulation method 96 is described in [8]. 98 3. Tunnel Labels and VC Labels 100 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 101 to egress LSR R2, across an intervening MPLS network. We assume that 102 there is an LSP from R1 to R2. That is, we assume that R1 can cause a 103 packet to be delivered to R2 by pushing some label onto the packet 104 and sending the result to one of its adjacencies. Call this label the 105 "tunnel label", and the corresponding LSP the "tunnel LSP". 107 The tunnel LSP merely gets packets from R1 to R2, the corresponding 108 label doesn't tell R2 what to do with the payload, and in fact if 109 penultimate hop popping is used, R2 may never even see the 110 corresponding label. (If R1 itself is the penultimate hop, a tunnel 111 label may not even get pushed on.) Thus if the payload is not an IP 112 packet, there must be a label, which becomes visible to R2, that 113 tells R2 how to treat the received packet. Call this label the "VC 114 label". 116 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 117 its label stack, and then (if R1 is not adjacent to R2) pushes on a 118 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 119 the VC label is not visible until the MPLS packet reaches R2. R2's 120 disposition of the packet is based on the VC label. 122 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 123 the VC label will generally correspond to a particular ATM VC at R2. 124 That is, R2 needs to be able to infer from the VC label the outgoing 125 interface and the VPI/VCI value for the AAL5 PDU. If the payload is a 126 Frame Relay PDU, then R2 needs to be able to infer from the VC label 127 the outgoing interface and the DLCI value. If the payload is an 128 ethernet frame, then R2 needs to be able to infer from the VC label 129 the outgoing interface, and perhaps the VLAN identifier. This process 130 is unidirectional, and will be repeated independently for 131 bidirectional operation. It is REQUIRED to assign the same VC, and 132 Group ID for a given circuit in both directions. 134 Note that the VC label must always be at the bottom of the label 135 stack, and the tunnel label, if present, must be immediately above 136 the VC label. Of course, as the packet is transported across the MPLS 137 network, additional labels may be pushed on (and then popped off) as 138 needed. Even R1 itself may push on additional labels above the tunnel 139 label. If R1 and R2 are directly adjacent LSRs, then it may not be 140 necessary to use a tunnel label at all. 142 This document does not specify a method for distributing the tunnel 143 label or any other labels that may appear above it on the stack. Any 144 acceptable method of MPLS label distribution will do. 146 This document does specify a method for assigning and distributing 147 the VC label. Static label assignment MAY be used, and 148 implementations SHOULD provide support for this. If signaling is 149 used, the VC label MUST be distributed from R2 to R1 using LDP in the 150 downstream unsolicited mode; this requires that an LDP connection be 151 created between R1 and R2. 153 Note that this technique allows an unbounded number of layer 2 "VCs" 154 to be carried together in a single "tunnel". Thus it scales quite 155 well in the network backbone. 157 4. Protocol-Specific Issues 159 4.1. Frame Relay 161 The MPLS edge LSR MAY provide a Frame Relay LMI to the CE device. 163 If the MPLS edge LSR detects a service affecting condition as defined 164 in [2] Q.933 Annex A.5 sited in IA FRF1.1, it MUST withdraw the label 165 that corresponds to the frame relay DLCI. The Egress LSR SHOULD 166 generate the corresponding errors and alarms as defined in [2] on the 167 Frame relay VC. 169 4.2. ATM 171 4.2.1. OAM Cell Support 173 OAM cells MAY be transported on the VC LSP. A router that does not 174 support transport of ATM cells MUST discard incoming MPLS frames on 175 an ATM VC LSP that contain a control word with the T bit set. [7] A 176 router that supports transport of OAM cells MUST follow the 177 procedures outlined in [9] section 8 for mode 0 only in addition to 178 the applicable procedures specified in [6]. 180 A router that does not support transport of OAM cells across an LSP 181 MAY provide OAM support on ATM PVCs using the following procedures: 183 If an F5 end-to-end OAM cell is received from a VC by a LSR with a 184 loopback indication value of 1 and the LSR has a label mapping for 185 the VC, the LSR MUST decrement the loopback indication value and loop 186 back the cell on the VC. Otherwise the loopback cell MUST be 187 discarded by the LSR. 189 The LSR MAY optionally be configured to periodically generate F5 190 end-to-end loopback OAM cells on a VC. In this case, the LSR must 191 only generate F5 end-to-end loopback cells while a label mapping 192 exists for the VC. If the VC label mapping is withdrawn the LSR MUST 193 cease generation of F5 end-to-end loopback OAM cells. If the LSR 194 fails to receive a response to an F5 end-to-end loopback OAM cell for 195 a pre-defined period of time it MUST withdraw the label mapping for 196 the VC. 198 If an ingress LSR receives an AIS F5 OAM cell, fails to receive a 199 pre-defined number of the End-to-End loop OAM cells, or a physical 200 interface goes down, it MUST withdraw the label mappings for all VCs 201 associated with the failure. When a VC label mapping is withdrawn, 202 the egress LSR SHOULD generate AIS F5 OAM cells on the VC associated 203 with the withdrawn label mapping. 205 4.2.2. ILMI Support 207 An MPLS edge LSR MAY provide an ATM ILMI to the CE device. 209 If an ingress LSR receives an ILMI message indicating that the CE has 210 deleted a VC, or if the physical interface goes down, it MUST 211 withdraw the label mappings for all VCs associated with the failure. 212 When a VC label mapping is withdrawn, the egress LSR SHOULD notify 213 its client of this failure by deleting the VC using ILMI. 215 4.3. HDLC ( Cisco ) 217 If the MPLS edge LSR detects that the physical link has failed it 218 MUST withdraw the label that corresponds to the HDLC link. The Egress 219 LSR SHOULD notify the CE device of this failure by using a physical 220 layer mechanism to take the link out of service. 222 4.4. PPP 224 If the MPLS edge LSR detects that the physical link has failed it 225 MUST withdraw the label that corresponds to the PPP link. The Egress 226 LSR SHOULD notify the CE device of this failure by using a physical 227 layer mechanism to take the link out of service. 229 5. LDP 231 The VC label bindings are distributed using the LDP downstream 232 unsolicited mode described in [1]. The LSRs will establish an LDP 233 session using the Extended Discovery mechanism described in [1, 234 section 2.4-2.5], for this purpose a new type of FEC TLV element is 235 defined. The FEC element type is 128. [note1] 237 The Virtual Circuit FEC TLV element, is defined as follows: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | VC tlv |C| VC Type | VC ID len | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Group ID | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | | 247 | VC ID | 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 - VC Type 253 A 15 bit quantity containing a value which represents the type of 254 VC. Assigned Values are: 256 VC Type Description 258 0x0001 Frame Relay DLCI 259 0x0002 ATM VCC transport 260 0x0003 ATM VPC transport 261 0x0004 Ethernet VLAN 262 0x0005 Ethernet 263 0x0006 HDLC ( Cisco ) 264 0x0007 PPP 265 0x8008 CEM [8] 267 The highest order bit is used to flag the presence of a control word as 268 follows: 269 bit 15 = 1 control word present on this VC. 270 bit 15 = 0 no control word present on this VC. 272 - VC ID length 274 Length of the VC ID field in octets. If this value is 0, then it 275 references all VCs using the specified group ID 277 - Group ID 279 An arbitrary 32 bit value which represents a group of VCs that is 280 used to augment the VC space. This value MUST be user 281 configurable. The group ID is intended to be used as either a 282 port index , or a virtual tunnel index. In the latter case a 283 switching function at ingress will map a particular circuit from 284 a port to a circuit in the virtual tunnel for transport to the 285 egress router. 287 - VC ID 289 Identifies a particular VC. The interpretation of the identifier 290 depends on the VC type: 292 * Frame Relay 294 A 32-bit value representing a 16-bit DLCI value as follows: 296 0 1 2 3 297 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 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Reserved | DLCI | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 * ATM VCC Transport 304 A 32-bit value representing a 16-bit VPI, and a 16-bit VCI as 305 follows: 307 0 1 2 3 308 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 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | VPI | VCI | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 * ATM VPC Transport 315 A 32-bit value containing a 16-bit VPI as follows: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | VPI | Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 * Ethernet VLAN 325 A 32 bit value representing 16bit vlan identifier as follows: 327 0 1 2 3 328 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 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Reserved | VLAN ID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 * Ethernet 335 A 32 bit port identifier. 337 * HDLC ( Cisco ) 339 A 32-bit port identifier 341 * PPP 343 A 32-bit port identifier 345 * CEM[8] 347 A 32-bit value used follows: 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Reserved | Circuit ID | Payload Bytes | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 Circuit ID: An assigned number for the SONET circuit being 355 transported. 357 Payload Bytes(N): the number of TDM payload bytes contained 358 in all packets on the CEM stream, from 48 to 1,023 bytes. All 359 of the packets in a given CEM stream have the same number of 360 payload bytes. Note that there is a possibility that the 361 packet size may exceed the SPE size in the case of an STS-1 362 SPE, which could cause two pointers to be needed in the CEM 363 header, since the payload may contain two J1 bytes for 364 consecutive SPEs. For this reason, the number of payload 365 bytes must be less than or equal to 783 for STS-1 SPEs. The 366 reserved fields in the above specifications MUST be set to 0 367 in the FEC TLV, and ignored when received. 369 6. Security Considerations 371 This document does not affect the underlying security issues of MPLS. 373 7. References 375 [1] "LDP Specification", draft-ietf-mpls-ldp-11.txt ( work in 376 progress ) 378 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 379 Mode Basic call control, ITU Geneva 1995 381 [3] "MPLS Label Stack Encoding", draft-ietf-mpls-label-encaps-08.txt 382 ( work in progress ) 384 [4] "IEEE 802.3ac-1998" IEEE standard specification. 386 [5] American National Standards Institute, "Synchronous Optical 387 Network Formats," ANSI T1.105-1995. 389 [6] ITU Recommendation G.707, "Network Node Interface For The 390 Synchronous Digital Hierarchy", 1996. 392 [7] "Encapsulation Methods for Transport of Layer 2 Frames Over 393 MPLS", draft-martini-l2circuit-encap-mpls-00.txt ( Work in progress ) 395 [8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM) 396 Encapsulation", draft-malis-sonet-ces-mpls-01.txt ( Work in progress 397 ) 399 [9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 401 [note1] FEC element type 128 is pending IANA approval. 403 8. Author Information 405 Luca Martini 406 Level 3 Communications, LLC. 407 1025 Eldorado Blvd. 408 Broomfield, CO, 80021 409 e-mail: luca@level3.net 410 Nasser El-Aawar 411 Level 3 Communications, LLC. 412 1025 Eldorado Blvd. 413 Broomfield, CO, 80021 414 e-mail: nna@level3.net 416 Giles Heron 417 Level 3 Communications 418 66 Prescot Street 419 London 420 E1 8HG 421 United Kingdom 422 e-mail: giles@level3.net 424 Dimitri Stratton Vlachos 425 Mazu Networks, Inc. 426 125 Cambridgepark Drive 427 Cambridge, MA 02140 428 e-mail: d@mazunetworks.com 430 Dan Tappan 431 Cisco Systems, Inc. 432 250 Apollo Drive 433 Chelmsford, MA, 01824 434 e-mail: tappan@cisco.com 436 Eric Rosen 437 Cisco Systems, Inc. 438 250 Apollo Drive 439 Chelmsford, MA, 01824 440 e-mail: erosen@cisco.com 442 Steve Vogelsang 443 Laurel Networks, Inc. 444 2607 Nicholson Rd. 445 Sewickley, PA 15143 446 e-mail: sjv@laurelnetworks.com 447 John Shirron 448 Laurel Networks, Inc. 449 2607 Nicholson Rd. 450 Sewickley, PA 15143 451 e-mail: jshirron@laurelnetworks.com 453 Andrew G. Malis 454 Vivace Networks, Inc. 455 2730 Orchard Parkway 456 San Jose, CA 95134 457 Phone: +1 408 383 7223 458 Email: Andy.Malis@vivacenetworks.com