idnits 2.17.00 (12 Aug 2021) /tmp/idnits46311/draft-martini-l2circuit-trans-mpls-05.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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 362 has weird spacing: '... The highe...' == Line 363 has weird spacing: '...resence of a...' -- 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) == Unused Reference: '4' is defined on line 505, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (ref. '1') (Obsoleted by RFC 5036) -- 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: draft-martini-l2circuit-encap-mpls has been published as RFC 4905 ** Downref: Normative reference to an Historic draft: draft-martini-l2circuit-encap-mpls (ref. '7') == Outdated reference: draft-malis-sonet-ces-mpls has been published as RFC 5143 ** Downref: Normative reference to an Historic draft: draft-malis-sonet-ces-mpls (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Luca Martini 2 Internet Draft Nasser El-Aawar 3 Expiration Date: August 2001 Giles Heron 4 Level 3 Communications, LLC. 6 Daniel Tappan 7 Eric C. Rosen 8 Alex Hamilton 9 Jayakumar Jayakumar 10 Cisco Systems, Inc. 12 Steve Vogelsang 13 John Shirron 14 Toby Smith 15 Laurel Networks, Inc. 17 Andrew G. Malis 18 Vinai Sirkay 19 Vivace Networks, Inc. 21 Dimitri Stratton Vlachos 22 Mazu Networks, Inc. 24 February 2001 26 Transport of Layer 2 Frames Over MPLS 28 draft-martini-l2circuit-trans-mpls-05.txt 30 Status of this Memo 32 This document is an Internet-Draft and is in full conformance with 33 all provisions of Section 10 of RFC2026. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that other 37 groups may also distribute working documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 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 transporting the Protocol Data 56 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, 57 Ethernet, and providing a SONET circuit emulation service across an 58 MPLS network. 60 Table of Contents 62 1 Specification of Requirements .......................... 2 63 2 Introduction ........................................... 3 64 3 Tunnel Labels and VC Labels ............................ 3 65 4 Protocol-Specific Details .............................. 4 66 4.1 Frame Relay ............................................ 5 67 4.2 ATM .................................................... 5 68 4.2.1 ATM AAL5 VCC Transport ................................. 5 69 4.2.2 ATM Transparent Cell Transport ......................... 5 70 4.2.3 ATM VCC and VPC Cell Transport ......................... 5 71 4.2.4 OAM Cell Support ....................................... 6 72 4.2.5 ILMI Support ........................................... 6 73 4.3 Ethernet VLAN .......................................... 7 74 4.4 Ethernet ............................................... 7 75 4.5 HDLC ( Cisco ) ......................................... 7 76 4.6 PPP .................................................... 7 77 4.7 Static MPLS ............................................ 7 78 5 LDP .................................................... 8 79 5.1 Interface Parameters Field ............................. 9 80 6 IANA Considerations .................................... 11 81 7 Security Considerations ................................ 11 82 8 References ............................................. 11 83 9 Author Information ..................................... 12 85 1. Specification of Requirements 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in RFC 2119. 91 2. Introduction 93 In an MPLS network, it is possible to carry the Protocol Data Units 94 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 95 these PDUs. This document specifies the necessary label distribution 96 procedures for accomplishing this using the encapsulation methods in 97 [7]. We restrict discussion to the case of point-to-point transport. 98 QoS related issues are not discussed in this draft. 100 An accompanying document [8] also describes a method for transporting 101 time division multiplexed (TDM) digital signals (TDM circuit 102 emulation) over a packet-oriented MPLS network. The transmission 103 system for circuit-oriented TDM signals is the Synchronous Optical 104 Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To 105 support TDM traffic, which includes voice, data, and private leased 106 line service, the MPLS network must emulate the circuit 107 characteristics of SONET/SDH payloads. MPLS labels and a new circuit 108 emulation header are used to encapsulate TDM signals and provide the 109 Circuit Emulation Service over MPLS (CEM). This encapsulation method 110 is described in [8]. 112 3. Tunnel Labels and VC Labels 114 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 115 to egress LSR R2, across an intervening MPLS network. We assume that 116 there is an LSP from R1 to R2. That is, we assume that R1 can cause a 117 packet to be delivered to R2 by pushing some label onto the packet 118 and sending the result to one of its adjacencies. Call this label the 119 "tunnel label", and the corresponding LSP the "tunnel LSP". 121 The tunnel LSP merely gets packets from R1 to R2, the corresponding 122 label doesn't tell R2 what to do with the payload, and in fact if 123 penultimate hop popping is used, R2 may never even see the 124 corresponding label. (If R1 itself is the penultimate hop, a tunnel 125 label may not even get pushed on.) Thus if the payload is not an IP 126 packet, there must be a label, which becomes visible to R2, that 127 tells R2 how to treat the received packet. Call this label the "VC 128 label". 130 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 131 its label stack, and then (if R1 is not adjacent to R2) pushes on a 132 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 133 the VC label is not visible until the MPLS packet reaches R2. R2's 134 disposition of the packet is based on the VC label. 136 Note that the tunnel could be a GRE encapsulated MPLS tunnel between 137 R1 and R2. In this case R1 would be adjacent to R2 , and only the VC 138 label would be used, and the intervening network need only carry IP 139 packets. 141 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 142 the VC label will generally correspond to a particular ATM VC at R2. 143 That is, R2 needs to be able to infer from the VC label the outgoing 144 interface and the VPI/VCI value for the AAL5 PDU. If the payload is a 145 Frame Relay PDU, then R2 needs to be able to infer from the VC label 146 the outgoing interface and the DLCI value. If the payload is an 147 Ethernet frame, then R2 needs to be able to infer from the VC label 148 the outgoing interface, and perhaps the VLAN identifier. This process 149 is unidirectional, and will be repeated independently for 150 bidirectional operation. It is REQUIRED to assign the same VC ID for 151 a given circuit in both directions. The transported frame MAY be 152 modified when it reaches the egress router. If the header of the 153 transported layer 2 frame is modified, this MUST be done at the 154 egress LSR only. Note that the VC label must always be at the bottom 155 of the label stack, and the tunnel label, if present, must be 156 immediately above the VC label. Of course, as the packet is 157 transported across the MPLS network, additional labels may be pushed 158 on (and then popped off) as needed. Even R1 itself may push on 159 additional labels above the tunnel label. If R1 and R2 are directly 160 adjacent LSRs, then it may not be necessary to use a tunnel label at 161 all. 163 This document does not specify a method for distributing the tunnel 164 label or any other labels that may appear above the VC label on the 165 stack. Any acceptable method of MPLS label distribution will do. 167 This document does specify a method for assigning and distributing 168 the VC label. Static label assignment MAY be used, and 169 implementations SHOULD provide support for this. If signaling is 170 used, the VC label MUST be distributed from R2 to R1 using LDP in the 171 downstream unsolicited mode; this requires that an LDP connection be 172 created between R1 and R2. [1] 174 Note that this technique allows an unbounded number of layer 2 "VCs" 175 to be carried together in a single "tunnel". Thus it scales quite 176 well in the network backbone. 178 4. Protocol-Specific Details 179 4.1. Frame Relay 181 The Frame Relay PDUs are encapsulated according to the procedures 182 defined in [7]. The MPLS edge LSR MUST provide Frame Relay PVC status 183 signaling to the Frame Relay network. If the MPLS edge LSR detects a 184 service affecting condition as defined in [2] Q.933 Annex A.5 sited 185 in IA FRF1.1, it MUST withdraw the label that corresponds to the 186 frame relay DLCI. The Egress LSR SHOULD generate the corresponding 187 errors and alarms as defined in [2] on the Frame relay VC. 189 4.2. ATM 191 4.2.1. ATM AAL5 VCC Transport 193 ATM AAL5 CSPS-PDUs are encapsulated according to [7] ATM AAL5 CPCS- 194 PDU mode. At the edge LSRs, R1 and R2, if ATM ILMI signaling is 195 supported it SHOULD be connected to VC signaling. This mode allows 196 the transport of ATM AAL5 CSPS-PDUs traveling on a particular ATM PVC 197 across the mpls network to another ATM PVC. 199 4.2.2. ATM Transparent Cell Transport 201 This mode is similar to the Ethernet port mode. Every cell that is 202 received at the ingress ATM port on the ingress LSR, R1, is 203 encapsulated according to [7], ATM cell mode, and sent across the LSP 204 to the egress LSR, R2. This mode allows an ATM port to be connected 205 to only one other ATM port. [7] allows for grouping of multiple cells 206 into a single MPLS frame. Grouping of ATM cells is OPTIONAL for 207 transmission at the ingress LSR, R1. If the Egress LSR R2 supports 208 cell concatenation the ingress LSR, R1, should only concatenate cells 209 up to the "Maximum Number of concatenated ATM cells" parameter 210 received as part of the FEC element. 212 4.2.3. ATM VCC and VPC Cell Transport 214 This mode is similar to the ATM AAL5 VCC transport except that only 215 cells are transported. Every cell that is received on a pre-defined 216 ATM PVC, or ATM PVP, at the ingress ATM port on the ingress LSR, R1, 217 is encapsulated according to [7], ATM cell mode, and sent across the 218 LSP to the egress LSR R2. Grouping of ATM cells is OPTIONAL for 219 transmission at the ingress LSR, R1. If the Egress LSR R2 supports 220 cell concatenation the ingress LSR, R1, MUST only concatenate cells 221 up to the "Maximum Number of concatenated ATM cells in a frame" 222 parameter received as part of the FEC element. 224 4.2.4. OAM Cell Support 226 OAM cells MAY be transported on the VC LSP. When the LSR is operating 227 in AAL5 PDU transport mode if it does not support transport of ATM 228 cells, the LSR MUST discard incoming MPLS frames on an ATM VC LSP 229 that contain a VC label with the T bit set [7]. When operating in 230 AAL5 PDU transport mode an LSR that supports transport of OAM cells 231 using the T bit defined in [7], or an LSR operating in any of the 232 three cell transport modes MUST follow the procedures outlined in [9] 233 section 8 for mode 0 only, in addition to the applicable procedures 234 specified in [6]. 236 4.2.4.1. OAM Cell Emulation Mode 238 AN LSR that does not support transport of OAM cells across an LSP MAY 239 provide OAM support on ATM PVCs using the following procedures: 241 If an F5 end-to-end OAM cell is received from a ATM VC by an ingress 242 LSR or egress LSR, with a loopback indication value of 1 and the LSR 243 has a label mapping for the ATM VC, the LSR MUST decrement the 244 loopback indication value and loop back the cell on the ATM VC. 245 Otherwise the loopback cell MUST be discarded by the LSR. 247 The ingress LSR, R1, may also optionally be configured to 248 periodically generate F5 end-to-end loopback OAM cells on a VC. If 249 the LSR fails to receive a response to an F5 end-to-end loopback OAM 250 cell for a pre-defined period of time it MUST withdraw the label 251 mapping for the VC. 253 If an ingress LSR, R1, receives an AIS F5 OAM cell, fails to receive 254 a pre-defined number of the End-to-End loop OAM cells, or a physical 255 interface goes down, it MUST withdraw the label mappings for all VCs 256 associated with the failure. When a VC label mapping is withdrawn, 257 the egress LSR, R2, MUST generate AIS F5 OAM cells on the VC 258 associated with the withdrawn label mapping. In this mode it is very 259 useful to apply a unique group ID to each interface. In the case 260 where a physical interface goes down, a wild card label withdraw can 261 be sent to all LDP neighbors, greatly reducing the signaling response 262 time. 264 4.2.5. ILMI Support 266 An MPLS edge LSR MAY provide an ATM ILMI to the ATM edge switch. If 267 an ingress LSR receives an ILMI message indicating that the ATM edge 268 switch has deleted a VC, or if the physical interface goes down, it 269 MUST withdraw the label mappings for all VCs associated with the 270 failure. When a VC label mapping is withdrawn, the egress LSR SHOULD 271 notify its client of this failure by deleting the VC using ILMI. 273 4.3. Ethernet VLAN 275 The Ethernet frame will be encapsulated according to the procedures 276 in [7]. It should be noted that if the VLAN identifier is modified 277 by the egress LSR, according to the procedures outlined above, the 278 Ethernet spanning tree protocol might fail to work properly. 280 4.4. Ethernet 282 The Ethernet frame will be encapsulated according to the procedures 283 in [7]. If the LSR detects a failure on the Ethernet physical port, 284 or the port is administratively disabled, the corresponding VC label 285 mapping MAY be withdrawn. If the egress LSR, R2, does not have a VC 286 label mapping for the corresponding Ethernet port, the Ethernet port 287 physical layer MAY be disabled. 289 4.5. HDLC ( Cisco ) 291 If the MPLS edge LSR detects that the physical link has failed it 292 MUST withdraw the label that corresponds to the HDLC link. The Egress 293 LSR SHOULD notify the CE device of this failure by using a physical 294 layer mechanism to take the link out of service. 296 4.6. PPP 298 If the MPLS edge LSR detects that the physical link has failed it 299 MUST withdraw the label that corresponds to the PPP link. The Egress 300 LSR SHOULD notify the CE device of this failure by using a physical 301 layer mechanism to take the link out of service. 303 4.7. Static MPLS 305 The MPLS frames encapsulated according to [3] using any layer 2 306 technology that is commonly used to transport MPLS can be transported 307 across the service provider MPLS network using the methods described 308 in this document. The VC label in this case is the statically 309 configured label that is accepted at the ingress LSR R1, and 310 advertised with an associated VC ID in LDP. The VC ID has to match in 311 both directions on a particular VC. At the egress LSR, R2 a common 312 MPLS label swap operation will swap the VC label with the label that 313 is statically configured for this particular VC. This transport mode 314 can be used to offer packet transport using different kinds of layer 315 2 access infrastructures. 317 5. LDP 319 The VC label bindings are distributed using the LDP downstream 320 unsolicited mode described in [1]. The LSRs will establish an LDP 321 session using the Extended Discovery mechanism described in [1, 322 section 2.4-2.5], for this purpose a new type of FEC element is 323 defined. The FEC element type is 128. [note1] 325 The Virtual Circuit FEC element, is defined 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 | VC tlv |C| VC Type |VC info Length | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Group ID | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | VC ID | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Interface parameters | 337 | " | 338 | " | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 - VC Type 343 A 15 bit quantity containing a value which represents the type of 344 VC. Assigned Values are: 346 VC Type Description 348 0x0001 Frame Relay DLCI 349 0x0002 ATM AAL5 VCC transport 350 0x0003 ATM transparent cell transport 351 0x0004 Ethernet VLAN 352 0x0005 Ethernet 353 0x0006 HDLC ( Cisco ) 354 0x0007 PPP 355 0x8008 CEM [8] 356 0x0009 ATM VCC cell transport 357 0x000A ATM VPC cell transport 358 0x000B MPLS 360 - Control word bit (C) 362 The highest order bit (C) of the Vc type is used to flag the 363 presence of a control word ( defined in [7] ) as follows: 365 bit 15 = 1 control word present on this VC. 366 bit 15 = 0 no control word present on this VC. 368 - VC information length 370 Length of the VC ID field and the interface parameters field in 371 octets. If this value is 0, then it references all VCs using the 372 specified group ID and there is no VC ID present, nor any 373 interface parameters. 375 - Group ID 377 An arbitrary 32 bit value which represents a group of VCs that is 378 used to augment the VC space. This value MUST be user 379 configurable. The group ID is intended to be used as a port 380 index, or a virtual tunnel index. To simplify configuration a 381 particular VC ID at ingress could be part of the virtual tunnel 382 for transport to the egress router. The Group ID is very useful 383 to send a wild card label withdrawals to remote LSRs upon 384 physical port failure. 386 - VC ID 388 A non zero 32-bit connection ID that together with the VC type, 389 identifies a particular VC. 391 - Interface parameters 393 This variable length field is used to provide interface specific 394 parameters, such as interface MTU. 396 5.1. Interface Parameters Field 398 This field specifies edge facing interface specific parameters and 399 SHOULD be used to validate that the LSRs, and the ingress and egress 400 ports at the edges of the circuit have the necessary capabilities to 401 interoperate with each other. The field structure is defines as 402 follows: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Parameter ID | Length | Variable Length Value | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Variable Length Value | 410 | " | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 The parameter ID is defined as follows: 413 Parameter ID Length Description 415 0x01 4 Interface MTU in octets. 416 0x02 4 Maximum Number of concatenated ATM cells. 417 0x03 up to 82 Optional Interface Description string. 418 0x04 4 CEM [8] Payload Bytes. 419 0x05 4 CEM options. 421 The Length field is defined as the length of the interface parameter 422 including the parameter id and length field itself. 424 - Interface MTU 426 A 2 octet value indicating the MTU in bytes. This is the Maximum 427 Transmit Unit of the egress packet interface that will be 428 transmitting the decapsulated PDU that is received from the MPLS 429 network. This parameter is REQUIRED, and SHOULD match in both 430 direction of a specific circuit. The MTU is specified in bytes, 431 and if it does not match on a specific circuit, that circuit 432 should not be enabled. This parameter is applicable only to VC 433 types 1, 2, 4, 5, 6, 7, and 0x0b. 435 - Maximum Number of concatenated ATM cells 437 This 2 octet parameter specifies the maximum number of 438 concatenated ATM cells that can be processed as a single PDU by 439 the egress LSR. This parameter does not need to match in both 440 directions of a specific LSR. This parameter is REQUIRED for the 441 following VC types: 3, 9, and 0x0a. An LSR transmitting 442 concatenated cells on this VC can concatenate a number of cells 443 up to the value of this parameter, but MUST NOT exceed it. 445 - Optional Interface Description string 447 This arbitrary, OPTIONAL, interface description string can be 448 used to send an administrative description text string to the 449 remote LSR. This parameter is OPTIONAL, and is applicable to all 450 VC types. The interface description parameter length is variable, 451 and can be up to 80 octets. 453 - Payload Bytes 455 A 2 octet value indicating the the number of TDM payload octets 456 contained in all packets on the CEM stream, from 48 to 1,023 457 octets. All of the packets in a given CEM stream have the same 458 number of payload bytes. Note that there is a possibility that 459 the packet size may exceed the SPE size in the case of an STS-1 460 SPE, which could cause two pointers to be needed in the CEM 461 header, since the payload may contain two J1 bytes for 462 consecutive SPEs. For this reason, the number of payload bytes 463 must be less than or equal to 783 for STS-1 SPEs. 465 - CEM Options. An optional 16 Bit value of CEM Flags. Bit 0 is 466 defined being set to indicate CEM-DBA in operation. 468 6. IANA Considerations 470 As specified in this document, a Virtual Circuit FEC element contains 471 the VC Type field. VC Type value 0 is reserved. VC Type values 1 472 through 11 are defined in this document. VC Type values 12 through 63 473 are to be assigned by IANA using the "IETF Consensus" policy defined 474 in RFC2434. VC Type values 64 through 127 are to be assigned by IANA, 475 using the "First Come First Served" policy defined in RFC2434. VC 476 Type values 128 through 32767 are vendor-specific, and values in this 477 range are not to be assigned by IANA. 479 As specified in this document, a Virtual Circuit FEC element contains 480 the Interface Parameters field, which is a list of one or more 481 parameters, and each parameter is identified by the Parameter ID 482 field. Parameter ID value 0 is reserved. Parameter ID values 1 483 through 5 are defined in this document. Parameter ID values 6 484 through 63 are to be assigned by IANA using the "IETF Consensus" 485 policy defined in RFC2434. Parameter ID values 64 through 127 are to 486 be assigned by IANA, using the "First Come First Served" policy 487 defined in RFC2434. Parameter ID values 128 through 255 are vendor- 488 specific, and values in this range are not to be assigned by IANA. 490 7. Security Considerations 492 This document does not affect the underlying security issues of MPLS. 494 8. References 496 [1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 497 Fredette, B. Thomas. January 2001. RFC3036 499 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 500 Mode Basic call control, ITU Geneva 1995 502 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 503 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 505 [4] "IEEE 802.3ac-1998" IEEE standard specification. 507 [5] American National Standards Institute, "Synchronous Optical 508 Network Formats," ANSI T1.105-1995. 510 [6] ITU Recommendation G.707, "Network Node Interface For The 511 Synchronous Digital Hierarchy", 1996. 513 [7] "Encapsulation Methods for Transport of Layer 2 Frames Over 514 MPLS", draft-martini-l2circuit-encap-mpls-01.txt ( Work in progress ) 516 [8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM) 517 Encapsulation", draft-malis-sonet-ces-mpls-01.txt ( Work in progress 518 ) 520 [9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 522 [note1] FEC element type 128 is pending IANA approval. 524 9. Author Information 526 Luca Martini 527 Level 3 Communications, LLC. 528 1025 Eldorado Blvd. 529 Broomfield, CO, 80021 530 e-mail: luca@level3.net 532 Nasser El-Aawar 533 Level 3 Communications, LLC. 534 1025 Eldorado Blvd. 535 Broomfield, CO, 80021 536 e-mail: nna@level3.net 538 Giles Heron 539 Level 3 Communications 540 66 Prescot Street 541 London 542 E1 8HG 543 United Kingdom 544 e-mail: giles@level3.net 546 Dimitri Stratton Vlachos 547 Mazu Networks, Inc. 548 125 Cambridgepark Drive 549 Cambridge, MA 02140 550 e-mail: d@mazunetworks.com 551 Dan Tappan 552 Cisco Systems, Inc. 553 250 Apollo Drive 554 Chelmsford, MA, 01824 555 e-mail: tappan@cisco.com 557 Jayakumar Jayakumar, 558 Cisco Systems Inc. 559 225, E.Tasman, MS-SJ3/3, 560 San Jose, CA, 95134 561 e-mail: jjayakum@cisco.com 563 Alex Hamilton, 564 Cisco Systems Inc. 565 285 W. Tasman, MS-SJCI/3/4, 566 San Jose, CA, 95134 567 e-mail: tahamilt@cisco.com 569 Eric Rosen 570 Cisco Systems, Inc. 571 250 Apollo Drive 572 Chelmsford, MA, 01824 573 e-mail: erosen@cisco.com 575 Steve Vogelsang 576 Laurel Networks, Inc. 577 2607 Nicholson Rd. 578 Sewickley, PA 15143 579 e-mail: sjv@laurelnetworks.com 581 John Shirron 582 Laurel Networks, Inc. 583 2607 Nicholson Rd. 584 Sewickley, PA 15143 585 e-mail: jshirron@laurelnetworks.com 586 Andrew G. Malis 587 Vivace Networks, Inc. 588 2730 Orchard Parkway 589 San Jose, CA 95134 590 Phone: +1 408 383 7223 591 Email: Andy.Malis@vivacenetworks.com 593 Vinai Sirkay 594 Vivace Networks, Inc. 595 2730 Orchard Parkway 596 San Jose, CA 95134 597 e-mail: vinai.sirkay@vivacenetworks.com