idnits 2.17.1 draft-martini-l2circuit-trans-mpls-06.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 351 has weird spacing: '... The highe...' == Line 352 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 (May 2001) is 8381 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 505, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 508, 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: A later version (-12) exists of draft-martini-l2circuit-encap-mpls-02 ** 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-04 ** 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 (~~), 7 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: 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 Transport of Layer 2 Frames Over MPLS 25 draft-martini-l2circuit-trans-mpls-06.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 ........................................... 3 58 3 Tunnel Labels and VC Labels ............................ 3 59 4 Protocol-Specific Details .............................. 5 60 4.1 Frame Relay ............................................ 5 61 4.2 ATM .................................................... 5 62 4.2.1 ATM AAL5 VCC Transport ................................. 5 63 4.2.2 ATM Transparent Cell Transport ......................... 5 64 4.2.3 ATM VCC and VPC Cell Transport ......................... 5 65 4.2.4 OAM Cell Support ....................................... 6 66 4.2.5 ILMI Support ........................................... 7 67 4.3 Ethernet VLAN .......................................... 7 68 4.4 Ethernet ............................................... 7 69 4.5 HDLC ( Cisco ) ......................................... 7 70 4.6 PPP .................................................... 7 71 5 LDP .................................................... 8 72 5.1 Interface Parameters Field ............................. 9 73 5.2 LDP label Withdrawal procedures ........................ 11 74 6 IANA Considerations .................................... 11 75 7 Security Considerations ................................ 12 76 8 References ............................................. 12 77 9 Author Information ..................................... 12 79 1. Specification of Requirements 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119. 85 2. Introduction 87 In an MPLS network, it is possible to carry the Protocol Data Units 88 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 89 these PDUs. This document specifies the necessary label distribution 90 procedures for accomplishing this using the encapsulation methods in 91 [7]. We restrict discussion to the case of point-to-point transport. 92 QoS related issues are not discussed in this draft. 94 An accompanying document [8] also describes a method for transporting 95 time division multiplexed (TDM) digital signals (TDM circuit 96 emulation) over a packet-oriented MPLS network. The transmission 97 system for circuit-oriented TDM signals is the Synchronous Optical 98 Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To 99 support TDM traffic, which includes voice, data, and private leased 100 line service, the MPLS network must emulate the circuit 101 characteristics of SONET/SDH payloads. MPLS labels and a new circuit 102 emulation header are used to encapsulate TDM signals and provide the 103 Circuit Emulation Service over MPLS (CEM). 105 3. Tunnel Labels and VC Labels 107 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 108 to egress LSR R2, across an intervening MPLS network. We assume that 109 there is an LSP from R1 to R2. That is, we assume that R1 can cause a 110 packet to be delivered to R2 by pushing some label onto the packet 111 and sending the result to one of its adjacencies. Call this label the 112 "tunnel label", and the corresponding LSP the "tunnel LSP". 114 The tunnel LSP merely gets packets from R1 to R2, the corresponding 115 label doesn't tell R2 what to do with the payload, and in fact if 116 penultimate hop popping is used, R2 may never even see the 117 corresponding label. (If R1 itself is the penultimate hop, a tunnel 118 label may not even get pushed on.) Thus if the payload is not an IP 119 packet, there must be a label, which becomes visible to R2, that 120 tells R2 how to treat the received packet. Call this label the "VC 121 label". 123 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 124 its label stack, and then (if R1 is not adjacent to R2) pushes on a 125 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 126 the VC label is not visible until the MPLS packet reaches R2. R2's 127 disposition of the packet is based on the VC label. 129 Note that the tunnel could be a GRE encapsulated MPLS tunnel between 130 R1 and R2. In this case R1 would be adjacent to R2, and only the VC 131 label would be used, and the intervening network need only carry IP 132 packets. 134 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 135 the VC label will generally correspond to a particular ATM VC at R2. 136 That is, R2 needs to be able to infer from the VC label the outgoing 137 interface and the VPI/VCI value for the AAL5 PDU. If the payload is a 138 Frame Relay PDU, then R2 needs to be able to infer from the VC label 139 the outgoing interface and the DLCI value. If the payload is an 140 Ethernet frame, then R2 needs to be able to infer from the VC label 141 the outgoing interface, and perhaps the VLAN identifier. This process 142 is unidirectional, and will be repeated independently for 143 bidirectional operation. It is REQUIRED to assign the same VC ID, and 144 VC type for a given circuit in both directions. The group id MUST NOT 145 be required to match in both directions. The transported frame MAY be 146 modified when it reaches the egress router. If the header of the 147 transported layer 2 frame is modified, this MUST be done at the 148 egress LSR only. 150 Note that the VC label must always be at the bottom of the label 151 stack, and the tunnel label, if present, must be immediately above 152 the VC label. Of course, as the packet is transported across the MPLS 153 network, additional labels may be pushed on (and then popped off) as 154 needed. Even R1 itself may push on additional labels above the tunnel 155 label. If R1 and R2 are directly adjacent LSRs, then it may not be 156 necessary to use a tunnel label at all. 158 This document does not specify a method for distributing the tunnel 159 label or any other labels that may appear above the VC label on the 160 stack. Any acceptable method of MPLS label distribution will do. 162 This document does specify a method for assigning and distributing 163 the VC label. Static label assignment MAY be used, and 164 implementations SHOULD provide support for this. If signaling is 165 used, the VC label MUST be distributed from R2 to R1 using LDP in the 166 downstream unsolicited mode; this requires that an LSP session be 167 created between R1 and R2. [1] When using LDP to distribute the VC 168 label, liberal label retention mode SHOULD be used. 170 Note that this technique allows an unbounded number of layer 2 "VCs" 171 to be carried together in a single "tunnel". Thus it scales quite 172 well in the network backbone. 174 While this document currently defines the emulation of Frame Relay 175 and ATM PVC services, it specifically does not preclude future 176 enhancements to support switched service (SVC and SPVC) emulation. 178 4. Protocol-Specific Details 180 4.1. Frame Relay 182 The Frame Relay PDUs are encapsulated according to the procedures 183 defined in [7]. The MPLS edge LSR MUST provide Frame Relay PVC status 184 signaling to the Frame Relay network. If the MPLS edge LSR detects a 185 service affecting condition as defined in [2] Q.933 Annex A.5 sited 186 in IA FRF1.1, it MUST withdraw the label that corresponds to the 187 frame relay DLCI. The Egress LSR SHOULD generate the corresponding 188 errors and alarms as defined in [2] on the Frame relay VC. 190 4.2. ATM 192 4.2.1. ATM AAL5 VCC Transport 194 ATM AAL5 CSPS-PDUs are encapsulated according to [7] ATM AAL5 CPCS- 195 PDU mode. This mode allows the transport of ATM AAL5 CSPS-PDUs 196 traveling on a particular ATM PVC across the MPLS network to another 197 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 CPCS-PDU transport mode if it does not support transport of 228 ATM 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 A pair of LSRs may emulate a bidrectional ATM VC by two uni- 242 directioal LSPs. If an F5 end-to-end OAM cell is received from a ATM 243 VC, by either LSR that is transporting this ATM VC, with a loopback 244 indication value of 1, and the LSR has a label mapping for the ATM 245 VC, then the LSR MUST decrement the loopback indication value and 246 loop back the cell on the ATM VC. Otherwise the loopback cell MUST be 247 discarded by the LSR. 249 The ingress LSR, R1, may also optionally be configured to 250 periodically generate F5 end-to-end loopback OAM cells on a VC. If 251 the LSR fails to receive a response to an F5 end-to-end loopback OAM 252 cell for a pre-defined period of time it MUST withdraw the label 253 mapping for the VC. 255 If an ingress LSR, R1, receives an AIS F5 OAM cell, fails to receive 256 a pre-defined number of the End-to-End loop OAM cells, or a physical 257 interface goes down, it MUST withdraw the label mappings for all VCs 258 associated with the failure. When a VC label mapping is withdrawn, 259 the egress LSR, R2, MUST generate AIS F5 OAM cells on the VC 260 associated with the withdrawn label mapping. In this mode it is very 261 useful to apply a unique group ID to each interface. In the case 262 where a physical interface goes down, a wild card label withdraw can 263 be sent to all LDP neighbors, greatly reducing the signaling response 264 time. 266 4.2.5. ILMI Support 268 An MPLS edge LSR MAY provide an ATM ILMI to the ATM edge switch. If 269 an ingress LSR receives an ILMI message indicating that the ATM edge 270 switch has deleted a VC, or if the physical interface goes down, it 271 MUST withdraw the label mappings for all VCs associated with the 272 failure. When a VC label mapping is withdrawn, the egress LSR SHOULD 273 notify its client of this failure by deleting the VC using ILMI. 275 4.3. Ethernet VLAN 277 The Ethernet frame will be encapsulated according to the procedures 278 in [7]. It should be noted that if the VLAN identifier is modified 279 by the egress LSR, according to the procedures outlined above, the 280 Ethernet spanning tree protocol might fail to work properly. If the 281 LSR detects a failure on the Ethernet physical port, or the port is 282 administratively disabled, it MUST withdraw the label mappings for 283 all VCs associated with the port. 285 4.4. Ethernet 287 The Ethernet frame will be encapsulated according to the procedures 288 in [7]. If the LSR detects a failure on the Ethernet physical port, 289 or the port is administratively disabled, the corresponding VC label 290 mapping MUST be withdrawn. 292 4.5. HDLC ( Cisco ) 294 HDLC frames are encapsulated according to the procedures in [7]. If 295 the MPLS edge LSR detects that the physical link has failed, or the 296 port is adminstratively disabled, it MUST withdraw the label mapping 297 that corresponds to the HDLC link. 299 4.6. PPP 301 PPP frames are encapsulated according to the procedures in [7]. If 302 the MPLS edge LSR detects that the physical link has failed, or the 303 port is adminstratively disabled, it MUST withdraw the label mapping 304 that corresponds to the PPP link. 306 5. LDP 308 The VC label bindings are distributed using the LDP downstream 309 unsolicited mode described in [1]. The LSRs will establish an LDP 310 session using the Extended Discovery mechanism described in [1, 311 section 2.4.2 and 2.5], for this purpose a new type of FEC element is 312 defined. The FEC element type is 128. [note1] Note that if the tunnel 313 label is not available, the VC label MUST NOT be advertized. 315 The Virtual Circuit FEC element, is defined 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 | VC tlv |C| VC Type |VC info Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Group ID | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | VC ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Interface parameters | 327 | " | 328 | " | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 - VC Type 333 A 15 bit quantity containing a value which represents the type of 334 VC. Assigned Values are: 336 VC Type Description 338 0x0001 Frame Relay DLCI 339 0x0002 ATM AAL5 VCC transport 340 0x0003 ATM transparent cell transport 341 0x0004 Ethernet VLAN 342 0x0005 Ethernet 343 0x0006 HDLC ( Cisco ) 344 0x0007 PPP 345 0x8008 CEM [8] 346 0x0009 ATM VCC cell transport 347 0x000A ATM VPC cell transport 349 - Control word bit (C) 351 The highest order bit (C) of the Vc type is used to flag the 352 presence of a control word ( defined in [7] ) as follows: 354 bit 15 = 1 control word present on this VC. 355 bit 15 = 0 no control word present on this VC. 357 - VC information length 359 Length of the VC ID field and the interface parameters field in 360 octets. If this value is 0, then it references all VCs using the 361 specified group ID and there is no VC ID present, nor any 362 interface parameters. 364 - Group ID 366 An arbitrary 32 bit value which represents a group of VCs that is 367 used to augment the VC space. This value MUST be user 368 configurable. The group ID is intended to be used as a port 369 index, or a virtual tunnel index. To simplify configuration a 370 particular VC ID at ingress could be part of the virtual tunnel 371 for transport to the egress router. The Group ID is very useful 372 to send a wild card label withdrawals to remote LSRs upon 373 physical port failure. 375 - VC ID 377 A non zero 32-bit connection ID that together with the VC type, 378 identifies a particular VC. 380 - Interface parameters 382 This variable length field is used to provide interface specific 383 parameters, such as interface MTU. 385 5.1. Interface Parameters Field 387 This field specifies edge facing interface specific parameters and 388 SHOULD be used to validate that the LSRs, and the ingress and egress 389 ports at the edges of the circuit, have the necessary capabilities to 390 interoperate with each other. The field structure is defined as 391 follows: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Parameter ID | Length | Variable Length Value | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Variable Length Value | 399 | " | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 The parameter ID is defined as follows: 402 Parameter ID Length Description 404 0x01 4 Interface MTU in octets. 405 0x02 4 Maximum Number of concatenated ATM cells. 406 0x03 up to 82 Optional Interface Description string. 407 0x04 4 CEM [8] Payload Bytes. 408 0x05 4 CEM options. 410 The Length field is defined as the length of the interface parameter 411 including the parameter id and length field itself. 413 - Interface MTU 415 A 2 octet value indicating the MTU in octets. This is the Maximum 416 Transmission Unit, excluding encapsulation overhead, of the 417 egress packet interface that will be transmitting the 418 decapsulated PDU that is received from the MPLS network. This 419 parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, 420 and is REQUIRED for these VC types. If this parameter does not 421 match in both directions of a specific VC, that VC MUST NOT be 422 enabled. 424 - Maximum Number of concatenated ATM cells 426 A 2 octet value specifying the maximum number of concatenated ATM 427 cells that can be processed as a single PDU by the egress LSR. An 428 ingress LSR transmitting concatenated cells on this VC can 429 concatenate a number of cells up to the value of this parameter, 430 but MUST NOT exceed it. This parameter is applicable only to VC 431 types 3, 9, and 0x0a, and is REQUIRED for these VC types. This 432 parameter does not need to match in both directions of a specific 433 VC. 435 - Optional Interface Description string 437 This arbitrary, OPTIONAL, interface description string can be 438 used to send an administrative description text string to the 439 remote LSR. This parameter is OPTIONAL, and is applicable to all 440 VC types. The interface description parameter length is variable, 441 and can be up to 80 octets. 443 - Payload Bytes 445 A 2 octet value indicating the the number of TDM payload octets 446 contained in all packets on the CEM stream, from 48 to 1,023 447 octets. All of the packets in a given CEM stream have the same 448 number of payload bytes. Note that there is a possibility that 449 the packet size may exceed the SPE size in the case of an STS-1 450 SPE, which could cause two pointers to be needed in the CEM 451 header, since the payload may contain two J1 bytes for 452 consecutive SPEs. For this reason, the number of payload bytes 453 must be less than or equal to 783 for STS-1 SPEs. 455 - CEM Options. An optional 16 Bit value of CEM Flags. Bit 0 is 456 defined being set to indicate CEM-DBA in operation. 458 5.2. LDP label Withdrawal procedures 460 As mentioned above the Group ID field can be used to withdraw all VC 461 labels associated with a particular group ID. This procedure is 462 OPTIONAL, and if it is implemented the LDP label withdraw message 463 should be as follows: the VC information length field is set to 0, 464 the VC ID field is not present, and the interface paramenters field 465 is not present. 467 The interface parameters field MUST NOT be present in any LDP VC 468 label withdrawal message or release message. A wildcard release 469 message MUST include only the group ID. 471 6. IANA Considerations 473 As specified in this document, a Virtual Circuit FEC element contains 474 the VC Type field. VC Type value 0 is reserved. VC Type values 1 475 through 10 are defined in this document. VC Type values 11 through 63 476 are to be assigned by IANA using the "IETF Consensus" policy defined 477 in RFC2434. VC Type values 64 through 127 are to be assigned by IANA, 478 using the "First Come First Served" policy defined in RFC2434. VC 479 Type values 128 through 32767 are vendor-specific, and values in this 480 range are not to be assigned by IANA. 482 As specified in this document, a Virtual Circuit FEC element contains 483 the Interface Parameters field, which is a list of one or more 484 parameters, and each parameter is identified by the Parameter ID 485 field. Parameter ID value 0 is reserved. Parameter ID values 1 486 through 6 are defined in this document. Parameter ID values 7 487 through 63 are to be assigned by IANA using the "IETF Consensus" 488 policy defined in RFC2434. Parameter ID values 64 through 127 are to 489 be assigned by IANA, using the "First Come First Served" policy 490 defined in RFC2434. Parameter ID values 128 through 255 are vendor- 491 specific, and values in this range are not to be assigned by IANA. 493 7. Security Considerations 495 This document does not affect the underlying security issues of MPLS. 497 8. References 499 [1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 500 Fredette, B. Thomas. January 2001. RFC3036 502 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 503 Mode Basic call control, ITU Geneva 1995 505 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 506 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 508 [4] "IEEE 802.3ac-1998" IEEE standard specification. 510 [5] American National Standards Institute, "Synchronous Optical 511 Network Formats," ANSI T1.105-1995. 513 [6] ITU Recommendation G.707, "Network Node Interface For The 514 Synchronous Digital Hierarchy", 1996. 516 [7] "Encapsulation Methods for Transport of Layer 2 Frames Over 517 MPLS", draft-martini-l2circuit-encap-mpls-02.txt ( Work in progress ) 519 [8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM) 520 Encapsulation", draft-malis-sonet-ces-mpls-04.txt ( Work in progress 521 ) 523 [9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 525 [note1] FEC element type 128 is pending IANA approval. 527 9. Author Information 529 Luca Martini 530 Level 3 Communications, LLC. 531 1025 Eldorado Blvd. 532 Broomfield, CO, 80021 533 e-mail: luca@level3.net 534 Nasser El-Aawar 535 Level 3 Communications, LLC. 536 1025 Eldorado Blvd. 537 Broomfield, CO, 80021 538 e-mail: nna@level3.net 540 Giles Heron 541 Gone2 Ltd. 542 c/o MDP 543 One Curzon Street 544 London 545 W1J 5HD 546 United Kingdom 547 e-mail: giles@goneto.net 549 Dimitri Stratton Vlachos 550 Mazu Networks, Inc. 551 125 Cambridgepark Drive 552 Cambridge, MA 02140 553 e-mail: d@mazunetworks.com 555 Dan Tappan 556 Cisco Systems, Inc. 557 250 Apollo Drive 558 Chelmsford, MA, 01824 559 e-mail: tappan@cisco.com 561 Jayakumar Jayakumar, 562 Cisco Systems Inc. 563 225, E.Tasman, MS-SJ3/3, 564 San Jose, CA, 95134 565 e-mail: jjayakum@cisco.com 567 Alex Hamilton, 568 Cisco Systems Inc. 569 285 W. Tasman, MS-SJCI/3/4, 570 San Jose, CA, 95134 571 e-mail: tahamilt@cisco.com 572 Eric Rosen 573 Cisco Systems, Inc. 574 250 Apollo Drive 575 Chelmsford, MA, 01824 576 e-mail: erosen@cisco.com 578 Steve Vogelsang 579 Laurel Networks, Inc. 580 2607 Nicholson Rd. 581 Sewickley, PA 15143 582 e-mail: sjv@laurelnetworks.com 584 John Shirron 585 Laurel Networks, Inc. 586 2607 Nicholson Rd. 587 Sewickley, PA 15143 588 e-mail: jshirron@laurelnetworks.com 590 Andrew G. Malis 591 Vivace Networks, Inc. 592 2730 Orchard Parkway 593 San Jose, CA 95134 594 Phone: +1 408 383 7223 595 Email: Andy.Malis@vivacenetworks.com 597 Vinai Sirkay 598 Vivace Networks, Inc. 599 2730 Orchard Parkway 600 San Jose, CA 95134 601 e-mail: vinai.sirkay@vivacenetworks.com 603 Vasile Radoaca 604 Nortel Networks 605 600 Technology Park 606 Billerica MA 01821 607 e-mail: vasile@nortelnetworks.com 608 Chris Liljenstolpe 609 Cable & Wireless 610 11700 Plaza America Drive 611 Reston, VA 20190 612 chris@cw.net