idnits 2.17.1 draft-martini-l2circuit-trans-mpls-10.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. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 369 has weird spacing: '... The highe...' == Line 370 has weird spacing: '...resence of a...' == Line 406 has weird spacing: '...ecifies inter...' -- 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 (August 2002) is 7923 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) == Missing Reference: '12' is mentioned on line 307, but not defined == Missing Reference: '32768' is mentioned on line 666, but not defined == Unused Reference: '3' is defined on line 723, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 726, 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-04 ** 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-05 ** 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 (~~), 10 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: February 2003 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 Dave Cooper PacketExchange Ltd. 20 Global Crossing 21 Kireeti Kompella 22 Juniper Networks 24 August 2002 26 Transport of Layer 2 Frames Over MPLS 28 draft-martini-l2circuit-trans-mpls-10.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 Abstract 52 This document describes methods for transporting the Protocol Data 53 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, 54 Ethernet, and providing a SONET circuit emulation service across an 55 MPLS network. 57 Table of Contents 59 1 Specification of Requirements .......................... 3 60 2 Introduction ........................................... 3 61 3 Tunnel Labels and VC Labels ............................ 3 62 4 Protocol-Specific Details .............................. 5 63 4.1 Frame Relay ............................................ 5 64 4.2 ATM .................................................... 5 65 4.2.1 ATM AAL5 VCC Transport ................................. 5 66 4.2.2 ATM Transparent Cell Transport ......................... 5 67 4.2.3 ATM VCC and VPC Cell Transport ......................... 6 68 4.2.4 OAM Cell Support ....................................... 6 69 4.2.5 ILMI Support ........................................... 7 70 4.3 Ethernet VLAN .......................................... 7 71 4.4 Ethernet ............................................... 7 72 4.5 HDLC ................................................... 7 73 4.6 PPP .................................................... 8 74 5 LDP .................................................... 8 75 5.1 Interface Parameters Field ............................. 10 76 5.2 C Bit handling procedures .............................. 11 77 5.2.1 VC types for which the control word is REQUIRED ........ 11 78 5.2.2 VC types for which the control word is NOT mandatory ... 11 79 5.2.3 Status codes ........................................... 15 80 5.3 LDP label Withdrawal procedures ........................ 15 81 5.4 Sequencing Considerations .............................. 15 82 5.4.1 Label Mapping Advertisements ........................... 16 83 5.4.2 Label Mapping Release .................................. 16 84 6 IANA Considerations .................................... 16 85 7 Security Considerations ................................ 17 86 8 References ............................................. 17 87 9 Author Information ..................................... 18 89 1. Specification of Requirements 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC 2119. 95 2. Introduction 97 In an MPLS network, it is possible to carry the Protocol Data Units 98 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 99 these PDUs. This document specifies the necessary label distribution 100 procedures for accomplishing this using the encapsulation methods in 101 [7]. We restrict discussion to the case of point-to-point transport. 102 QoS related issues are not discussed in this draft. This document 103 describes methods for transporting a number of protocols; in some 104 cases, transporting a particular protocol may have several modes of 105 operation. Each of these protocols and/or modes may be implemented 106 independently. 108 An accompanying document [8] also describes a method for transporting 109 time division multiplexed (TDM) digital signals (TDM circuit 110 emulation) over a packet-oriented MPLS network. The transmission 111 system for circuit-oriented TDM signals is the Synchronous Optical 112 Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To 113 support TDM traffic, which includes voice, data, and private leased 114 line service, the MPLS network must emulate the circuit 115 characteristics of SONET/SDH payloads. MPLS labels and a new circuit 116 emulation header are used to encapsulate TDM signals and provide the 117 Circuit Emulation Service over MPLS (CEM). 119 3. Tunnel Labels and VC Labels 121 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 122 to egress LSR R2, across an intervening MPLS network. We assume that 123 there is an LSP from R1 to R2. That is, we assume that R1 can cause a 124 packet to be delivered to R2 by pushing some label onto the packet 125 and sending the result to one of its adjacencies. Call this label the 126 "tunnel label", and the corresponding LSP the "tunnel LSP". 128 The tunnel LSP merely gets packets from R1 to R2, the corresponding 129 label doesn't tell R2 what to do with the payload, and in fact if 130 penultimate hop popping is used, R2 may never even see the 131 corresponding label. (If R1 itself is the penultimate hop, a tunnel 132 label may not even get pushed on.) Thus if the payload is not an IP 133 packet, there must be a label, which becomes visible to R2, that 134 tells R2 how to treat the received packet. Call this label the "VC 135 label". 137 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 138 its label stack, and then (if R1 is not adjacent to R2) pushes on a 139 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 140 the VC label is not visible until the MPLS packet reaches R2. R2's 141 disposition of the packet is based on the VC label. 143 Note that the tunnel could be a GRE encapsulated MPLS tunnel between 144 R1 and R2. In this case R1 would be adjacent to R2, and only the VC 145 label would be used, and the intervening network need only carry IP 146 packets. 148 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 149 the VC label will generally correspond to a particular ATM VC at R2. 150 That is, R2 needs to be able to infer from the VC label the outgoing 151 interface and the VPI/VCI value for the AAL5 PDU. If the payload is a 152 Frame Relay PDU, then R2 needs to be able to infer from the VC label 153 the outgoing interface and the DLCI value. If the payload is an 154 Ethernet frame, then R2 needs to be able to infer from the VC label 155 the outgoing interface, and perhaps the VLAN identifier. This process 156 is unidirectional, and will be repeated independently for 157 bidirectional operation. It is REQUIRED to assign the same VC ID, and 158 VC type for a given circuit in both directions. The group ID (see 159 below) MUST NOT be required to match in both directions. The 160 transported frame MAY be modified when it reaches the egress router. 161 If the header of the transported layer 2 frame is modified, this MUST 162 be done at the egress LSR only. 164 Note that the VC label must always be at the bottom of the label 165 stack, and the tunnel label, if present, must be immediately above 166 the VC label. Of course, as the packet is transported across the MPLS 167 network, additional labels may be pushed on (and then popped off) as 168 needed. Even R1 itself may push on additional labels above the tunnel 169 label. If R1 and R2 are directly adjacent LSRs, then it may not be 170 necessary to use a tunnel label at all. 172 This document does not specify a method for distributing the tunnel 173 label or any other labels that may appear above the VC label on the 174 stack. Any acceptable method of MPLS label distribution will do. 176 This document does specify a method for assigning and distributing 177 the VC label. Static label assignment MAY be used, and 178 implementations SHOULD provide support for this. When signaling is 179 used, the VC label MUST be distributed from R2 to R1 using LDP in the 180 downstream unsolicited mode; this requires that an LDP session be 181 created between R1 and R2. It should be noted that this LDP session 182 is not necessarily transported along the same path as the Layer 2 183 PDUs. [1] In addition, when using LDP to distribute the VC label, 184 liberal label retention mode SHOULD be used. However, as required in 185 [1], the label request operation (mainly used by conservative label 186 retention mode) MUST be implemented. VC labels MUST be allocated from 187 the per-platform label space. 189 Note that this technique allows an unbounded number of layer 2 "VCs" 190 to be carried together in a single "tunnel". Thus it scales quite 191 well in the network backbone. 193 While this document currently defines the emulation of Frame Relay 194 and ATM PVC services, it specifically does not preclude future 195 enhancements to support switched service (SVC and SPVC) emulation. 197 4. Protocol-Specific Details 199 4.1. Frame Relay 201 The Frame Relay PDUs are encapsulated according to the procedures 202 defined in [7]. The MPLS edge LSR MUST provide Frame Relay PVC status 203 signaling to the Frame Relay network. If the MPLS edge LSR detects a 204 service affecting condition as defined in [2] Q.933 Annex A.5 sited 205 in IA FRF1.1, it MUST withdraw the label that corresponds to the 206 frame relay DLCI. The Egress LSR SHOULD generate the corresponding 207 errors and alarms as defined in [2] on the egress Frame relay VC. 209 4.2. ATM 211 4.2.1. ATM AAL5 VCC Transport 213 ATM AAL5 CSPS-SDUs are encapsulated according to [7] ATM AAL5 CPCS- 214 SDU mode. This mode allows the transport of ATM AAL5 CSPS-SDUs 215 traveling on a particular ATM PVC across the MPLS network to another 216 ATM PVC. 218 4.2.2. ATM Transparent Cell Transport 220 This mode is similar to the Ethernet port mode. Every cell that is 221 received at the ingress ATM port on the ingress LSR, R1, is 222 encapsulated according to [7], ATM cell mode, and sent across the LSP 223 to the egress LSR, R2. This mode allows an ATM port to be connected 224 to only one other ATM port. [7] allows for grouping of multiple cells 225 into a single MPLS frame. Grouping of ATM cells is OPTIONAL for 226 transmission at the ingress LSR, R1. If the Egress LSR R2 supports 227 cell concatenation the ingress LSR, R1, should only concatenate cells 228 up to the "Maximum Number of concatenated ATM cells" parameter 229 received as part of the FEC element. 231 4.2.3. ATM VCC and VPC Cell Transport 233 This mode is similar to the ATM AAL5 VCC transport except that cells 234 are transported. Every cell that is received on a pre-defined ATM 235 PVC, or ATM PVP, at the ingress ATM port on the ingress LSR, R1, is 236 encapsulated according to [7], ATM cell mode, and sent across the LSP 237 to the egress LSR R2. Grouping of ATM cells is OPTIONAL for 238 transmission at the ingress LSR, R1. If the Egress LSR R2 supports 239 cell concatenation the ingress LSR, R1, MUST only concatenate cells 240 up to the "Maximum Number of concatenated ATM cells in a frame" 241 parameter received as part of the FEC element. 243 4.2.4. OAM Cell Support 245 OAM cells MAY be transported on the VC LSP. When the LSR is operating 246 in AAL5 CPCS-SDU transport mode if it does not support transport of 247 ATM cells, the LSR MUST discard incoming MPLS frames on an ATM VC LSP 248 that contain a VC label with the T bit set [7]. When operating in 249 AAL5 SDU transport mode an LSR that supports transport of OAM cells 250 using the T bit defined in [7], or an LSR operating in any of the 251 three cell transport modes MUST follow the procedures outlined in [9] 252 section 8 for mode 0 only, in addition to the applicable procedures 253 specified in [6]. 255 4.2.4.1. OAM Cell Emulation Mode 257 AN LSR that does not support transport of OAM cells across an LSP MAY 258 provide OAM support on ATM PVCs using the following procedures: 260 A pair of LSRs MAY emulate a bidrectional ATM VC by two uni- 261 directional LSPs. If an F5 end-to-end OAM cell is received from a 262 ATM VC, by either LSR that is transporting this ATM VC, with a 263 loopback indication value of 1, and the LSR has a label mapping for 264 the ATM VC, then the LSR MUST decrement the loopback indication value 265 and loop back the cell on the ATM VC. Otherwise the loopback cell 266 MUST be discarded by the LSR. 268 The ingress LSR, R1, may also optionally be configured to 269 periodically generate F5 end-to-end loopback OAM cells on a VC. If 270 the LSR fails to receive a response to an F5 end-to-end loopback OAM 271 cell for a pre-defined period of time it MUST withdraw the label 272 mapping for the VC. 274 If an ingress LSR, R1, receives an AIS F5 OAM cell, fails to receive 275 a pre-defined number of the End-to-End loop OAM cells, or a physical 276 interface goes down, it MUST withdraw the label mappings for all VCs 277 associated with the failure. When a VC label mapping is withdrawn, 278 the egress LSR, R2, MUST generate AIS F5 OAM cells on the VC 279 associated with the withdrawn label mapping. In this mode it is very 280 useful to apply a unique group ID to each interface. In the case 281 where a physical interface goes down, a wild card label withdraw can 282 be sent to all LDP neighbors, greatly reducing the signaling response 283 time. 285 4.2.5. ILMI Support 287 An MPLS edge LSR MAY provide an ATM ILMI to the ATM edge switch. If 288 an ingress LSR receives an ILMI message indicating that the ATM edge 289 switch has deleted a VC, or if the physical interface goes down, it 290 MUST withdraw the label mappings for all VCs associated with the 291 failure. When a VC label mapping is withdrawn, the egress LSR SHOULD 292 notify its client of this failure by deleting the VC using ILMI. 294 4.3. Ethernet VLAN 296 The Ethernet frame will be encapsulated according to the procedures 297 in [12]. It should be noted that if the VLAN identifier is modified 298 by the egress LSR, according to the procedures outlined above, the 299 Ethernet spanning tree protocol might fail to work properly. If the 300 LSR detects a failure on the Ethernet physical port, or the port is 301 administratively disabled, it MUST withdraw the label mappings for 302 all VCs associated with the port. 304 4.4. Ethernet 306 The Ethernet frame will be encapsulated according to the procedures 307 in [12]. If the LSR detects a failure on the Ethernet physical port, 308 or the port is administratively disabled, the corresponding VC label 309 mapping MUST be withdrawn. 311 4.5. HDLC 313 HDLC frames are encapsulated according to the procedures in [7]. If 314 the MPLS edge LSR detects that the physical link has failed, or the 315 port is adminstratively disabled, it MUST withdraw the label mapping 316 that corresponds to the HDLC link. 318 4.6. PPP 320 PPP frames are encapsulated according to the procedures in [7]. If 321 the MPLS edge LSR detects that the physical link has failed, or the 322 port is adminstratively disabled, it MUST withdraw the label mapping 323 that corresponds to the PPP link. 325 5. LDP 327 The VC label bindings are distributed using the LDP downstream 328 unsolicited mode described in [1]. The LSRs will establish an LDP 329 session using the Extended Discovery mechanism described in [1, 330 section 2.4.2 and 2.5], for this purpose a new type of FEC element is 331 defined. The FEC element type is 128. [note1] Only a single VC FEC 332 element MUST be advertised per LDP VC label. The Virtual Circuit FEC 333 element, is defined as follows: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | VC tlv |C| VC Type |VC info Length | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Group ID | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | VC ID | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Interface parameters | 345 | " | 346 | " | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 - VC Type 351 A 15 bit quantity containing a value which represents the type of 352 VC. Assigned Values are: 354 VC Type Description 356 0x0001 Frame Relay DLCI 357 0x0002 ATM AAL5 VCC transport 358 0x0003 ATM transparent cell transport 359 0x0004 Ethernet VLAN 360 0x0005 Ethernet 361 0x0006 HDLC 362 0x0007 PPP 363 0x8008 CEM [8] 364 0x0009 ATM VCC cell transport 365 0x000A ATM VPC cell transport 367 - Control word bit (C) 369 The highest order bit (C) of the VC type is used to flag the 370 presence of a control word ( defined in [7] ) as follows: 371 bit 15 = 1 control word present on this VC. 372 bit 15 = 0 no control word present on this VC. 374 Please see the section "C Bit handling procedures" for further 375 explenation. 377 - VC information length 379 Length of the VC ID field and the interface parameters field in 380 octets. If this value is 0, then it references all VCs using the 381 specified group ID and there is no VC ID present, nor any 382 interface parameters. 384 - Group ID 386 An arbitrary 32 bit value which represents a group of VCs that is 387 used to create groups in the VC space. The group ID is intended 388 to be used as a port index, or a virtual tunnel index. To 389 simplify configuration a particular VC ID at ingress could be 390 part of the virtual tunnel for transport to the egress router. 391 The Group ID is very useful to send wild card label withdrawals 392 to remote LSRs upon physical port failure. 394 - VC ID 396 A non zero 32-bit connection ID that together with the VC type, 397 identifies a particular VC. 399 - Interface parameters 401 This variable length field is used to provide interface specific 402 parameters, such as interface MTU. 404 5.1. Interface Parameters Field 406 This field specifies interface specific parameters. When aplicable, 407 it MUST be used to validate that the LSRs, and the ingress and egress 408 ports at the edges of the circuit, have the necessary capabilities to 409 interoperate with each other. The field structure is defined as 410 follows: 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Parameter ID | Length | Variable Length Value | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Variable Length Value | 418 | " | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 The parameter ID is defined as follows: 422 Parameter ID Length Description 424 0x01 4 Interface MTU in octets. 425 0x02 4 Maximum Number of concatenated ATM cells. 426 0x03 up to 82 Optional Interface Description string. 427 0x04 4 CEM [8] Payload Bytes. 428 0x05 4 CEM options. 430 The Length field is defined as the length of the interface parameter 431 including the parameter id and length field itself. Processing of the 432 interface parameters should continue when encounting unknown interface 433 parameters and they MUST be silently ignored. 435 - Interface MTU 437 A 2 octet value indicating the MTU in octets. This is the Maximum 438 Transmission Unit, excluding encapsulation overhead, of the 439 egress packet interface that will be transmitting the 440 decapsulated PDU that is received from the MPLS network. This 441 parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, 442 and is REQUIRED for these VC types. If this parameter does not 443 match in both directions of a specific VC, that VC MUST NOT be 444 enabled. 446 - Maximum Number of concatenated ATM cells 448 A 2 octet value specifying the maximum number of concatenated ATM 449 cells that can be processed as a single PDU by the egress LSR. An 450 ingress LSR transmitting concatenated cells on this VC can 451 concatenate a number of cells up to the value of this parameter, 452 but MUST NOT exceed it. This parameter is applicable only to VC 453 types 3, 9, and 0x0a, and is REQUIRED for these VC types. This 454 parameter does not need to match in both directions of a specific 455 VC. 457 - Optional Interface Description string 459 This arbitrary, OPTIONAL, interface description string can be 460 used to send an administrative description text string to the 461 remote LSR. This parameter is OPTIONAL, and is applicable to all 462 VC types. The interface description parameter string length is 463 variable, and can be from 0 to 80 octets. 465 - Payload Bytes 467 A 2 octet value indicating the the number of TDM payload octets 468 contained in all packets on the CEM stream, from 48 to 1,023 469 octets. All of the packets in a given CEM stream have the same 470 number of payload bytes. Note that there is a possibility that 471 the packet size may exceed the SPE size in the case of an STS-1 472 SPE, which could cause two pointers to be needed in the CEM 473 header, since the payload may contain two J1 bytes for 474 consecutive SPEs. For this reason, the number of payload bytes 475 must be less than or equal to 783 for STS-1 SPEs. 477 - CEM Options. An optional 16 Bit value of CEM Flags. See [8] for 478 the definition of the bit values. 480 5.2. C Bit handling procedures 482 5.2.1. VC types for which the control word is REQUIRED 484 The Label Mapping messages which are sent in order to set up these 485 VCs MUST have c=1. When a Label Mapping message for a VC of one of 486 these types is received, and c=0, a Label Release MUST be sent, with 487 an "Illegal C-bit" status code. In this case, the VC will not come 488 up. 490 5.2.2. VC types for which the control word is NOT mandatory 492 If a system is capable of sending and receiving the control word on 493 VC types for which the control word is not mandatory, then each such 494 VC endpoint MUST be configurable with a parameter that specifies 495 whether the use of the control word is PREFERRED or NOT PREFERRED. 497 For each VC, there MUST be a default value of this parameter. This 498 specification does NOT state what the default value should. 500 If a system is NOT capable of sending and receiving the control word 501 on VC types for which the control word is not mandatory, then it 502 behaves as exactly as if it were configured for the use of the 503 control word to be NOT PREFERRED. 505 If a Label Mapping message for the VC has already been received, but 506 no Label Mapping message for the VC has yet been sent, then the 507 procedure is the following: 508 -i. If the received Label Mapping message has c=0, send a Label 509 Mapping message with c=0, and the control word is not used. 510 -ii. If the received Label Mapping message has c=1, and the VC is 511 locally configured such that the use of the control word is 512 preferred, then send a Label Mapping message with c=1, and 513 the control word is used. 514 -iii. If the received Label Mapping message has c=1, and the VC is 515 locally configured such that the use of the control word is 516 not preferred or the control word is not supported, then act 517 as if no Label Mapping message for the VC had been received 518 (i.e., proceed to the next paragraph). 520 If a Label Mapping message for the VC has not already been received 521 (or if the received Label Mapping message had c=1 and either local 522 configuration says that the use of the control word is not preferred 523 or the control word is not supported), then send a Label Mapping 524 message in which the c bit is set to correspond to the locally 525 configured preference for use of the control word. (I.e., set c=1 if 526 locally configured to prefer the control word, set c=0 if locally 527 configured to prefer not to use the control word or if the control 528 word is not supported). 530 The next action depends on what control message is next received for 531 that VC. The possibilities are: 532 -i. A Label Mapping message with the same c bit value as 533 specified in the Label Mapping message that was sent. VC 534 setup is now complete, and the control word is used if c=1 535 but not used if c=0. 536 -ii. A Label Mapping message with c=1, but the Label Mapping 537 message that was sent has c=0. In this case, ignore the 538 received Label Mapping message, and continue to wait for the 539 next control message for the VC. 540 -iii. A Label Mapping message with c=0, but the Label Mapping 541 message that was sent has c=1. In this case, send a Label 542 Withdraw message with a "Wrong c-bit" status code, followed 543 by a Label Mapping message that has c=0. VC setup is now 544 complete, and the control word is not used. 546 -iv. A Label Withdraw message with the "Wrong c-bit" status code. 547 Treat as a normal Label Withdraw, but do not respond. 548 Continue to wait for the next control message for the VC. 550 If at any time after a Label Mapping message has been received, a 551 corresponding Label Withdraw or Release is received, the action taken 552 is the same as for any Label Withdraw or Release that might be 553 received at any time. Note that receiving a Label Withdraw should not 554 cause a corresponding Label Release to be sent. 556 If both endpoints prefer the use of the control word, this procedure 557 will cause it to be used. If either endpoint prefers not to use the 558 control word, or does not support the control word, this procedure 559 will cause it not to be used. If one endpoint prefers to use the 560 control word but the other does not, the one that prefers not to use 561 it is has no extra protocol to execute, it just waits for a Label 562 Mapping message that has c=0. 564 The following diagram illustrate the above procedures: 566 ------------------ 567 Y | Received Label | N 568 -------| Mapping Msg? |-------------- 569 | ------------------ | 570 | | 571 -------------- | 572 | | | 573 | | | 574 ------- ------- | 575 | C=0 | | C=1 | | 576 ------- ------- | 577 | | | 578 | | | 579 | ---------------- | 580 | | Control Word | N | 581 | | Capable? |----------- | 582 | ---------------- | | 583 | Y | | | 584 | | | | 585 | ---------------- | | 586 | | Control Word | N | | 587 | | Preferred? |---- | | 588 | ---------------- | | | 589 | Y | | | | 590 | | | | ---------------- 591 | | | | | Control Word | 592 | | | | | Preferred? | 593 | | | | ---------------- 594 | | | | N | Y | 595 | | | | | | 596 Send Send Send Send Send Send 597 C=0 C=1 C=0 C=0 C=0 C=1 598 | | | | 599 | | | | 600 ---------------------------------- 601 | If receive the same as sent, | 602 | VC setup is complete. If not: | 603 ---------------------------------- 604 | | | | 605 | | | | 606 ------------------- ----------- 607 | Receive | | Receive | 608 | C=1 | | C=0 | 609 ------------------- ----------- 610 | | 611 | | 612 Wait for the Send 613 next message Wrong C-Bit 614 | 615 | 616 Send Label 617 Mapping Message 618 with C=0 620 5.2.3. Status codes 622 RFC 3036 has a range of Status Code values which are assigned by IANA 623 on a First Come, First Served basis. These are in the range 624 0x20000000-0x3effffff [note 2]. The following new status codes are 625 defined: 627 0x20000001 "Illegal C-Bit" 628 0x20000002 "Wrong C-Bit" 630 5.3. LDP label Withdrawal procedures 632 As mentioned above the Group ID field can be used to withdraw all VC 633 labels associated with a particular group ID. This procedure is 634 OPTIONAL, and if it is implemented the LDP label withdraw message 635 should be as follows: the VC information length field is set to 0, 636 the VC ID field is not present, and the interface paramenters field 637 is not present. For the purpose of this document this is called the 638 "wild card withdraw procedure", and all LSRs implementing this design 639 are REQUIRED to accept such a withdraw message, but are not required 640 to send it. 642 The interface parameters field MUST NOT be present in any LDP VC 643 label withdrawal message or release message. A wildcard release 644 message MUST include only the group ID.A Label Release message 645 initiated from the imposition router must always include the VC ID. 647 5.4. Sequencing Considerations 649 In the case where the router considers the sequence number field in 650 the control word, it is important to note the following when 651 advertising labels 653 5.4.1. Label Mapping Advertisements 655 After a label has been withdrawn by the disposition router and/or 656 released by the imposition router, care must be taken to not re- 657 advertise (re-use) the released label until the disposition router 658 can be reasonably certain that old packets containing the released 659 label no longer persist in the MPLS network. 661 This precaution is required to prevent the imposition router from 662 restarting packet forwarding with sequence number of 1 when it 663 receives the same label mapping if there are still older packets 664 persisting in the network with sequence number between 1 and 32768. 665 For example, if there is a packet with sequence number=n where n is 666 in the interval[1,32768] travelling through the network, it would be 667 possible for the disposition router to receive that packet after it 668 re-advertises the label. Since the label has been released by the 669 imposition router, the disposition router SHOULD be expecting the 670 next packet to arrive with sequence number to be 1. Receipt of a 671 packet with sequence number equal to n will result in n packets 672 potentially being rejected by the disposition router until the 673 imposition router imposes a sequence number of n+1 into a packet. 674 Possible methods to avoid this is for the disposition router to 675 always advertise a different VC label, or for the disposition router 676 to wait for a sufficient time before attempting to re-advertised a 677 recently released label. This is only an issue when sequence number 678 processing at the disposition router is enabled. 680 5.4.2. Label Mapping Release 682 In situations where the imposition router wants to restart forwarding 683 of packets with sequence number 1, the router shall 1) Send to 684 disposition router a label mapping release, and 2) Send to 685 disposition router a label mapping request. When sequencing is 686 supported, advertisement of a vc label in response to a label mapping 687 request MUST also consider the issues discussed in 5.3.1 689 6. IANA Considerations 691 As specified in this document, a Virtual Circuit FEC element contains 692 the VC Type field. VC Type value 0 is reserved. VC Type values 1 693 through 10 are defined in this document. VC Type values 11 through 63 694 are to be assigned by IANA using the "IETF Consensus" policy defined 695 in RFC2434. VC Type values 64 through 127 are to be assigned by IANA, 696 using the "First Come First Served" policy defined in RFC2434. VC 697 Type values 128 through 32767 are vendor-specific, and values in this 698 range are not to be assigned by IANA. 700 As specified in this document, a Virtual Circuit FEC element contains 701 the Interface Parameters field, which is a list of one or more 702 parameters, and each parameter is identified by the Parameter ID 703 field. Parameter ID value 0 is reserved. Parameter ID values 1 704 through 5 are defined in this document. Parameter ID values 6 705 through 63 are to be assigned by IANA using the "IETF Consensus" 706 policy defined in RFC2434. Parameter ID values 64 through 127 are to 707 be assigned by IANA, using the "First Come First Served" policy 708 defined in RFC2434. Parameter ID values 128 through 255 are vendor- 709 specific, and values in this range are not to be assigned by IANA. 711 7. Security Considerations 713 This document does not affect the underlying security issues of MPLS. 715 8. References 717 [1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 718 Fredette, B. Thomas. January 2001. RFC3036 720 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 721 Mode Basic call control, ITU Geneva 1995 723 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 724 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 726 [4] "IEEE 802.3ac-1998" IEEE standard specification. 728 [5] American National Standards Institute, "Synchronous Optical 729 Network Formats," ANSI T1.105-1995. 731 [6] ITU Recommendation G.707, "Network Node Interface For The 732 Synchronous Digital Hierarchy", 1996. 734 [7] "Encapsulation Methods for Transport of Layer 2 Frames Over 735 MPLS", draft-martini-l2circuit-encap-mpls-04.txt ( Work in progress ) 737 [8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM) 738 Encapsulation", draft-malis-sonet-ces-mpls-05.txt ( Work in progress 739 ) 741 [9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 743 [note1] FEC element type 128 is pending IANA approval. [note2] 744 Status codes assigment is pending IANA approval. 746 9. Author Information 748 Luca Martini 749 Level 3 Communications, LLC. 750 1025 Eldorado Blvd. 751 Broomfield, CO, 80021 752 e-mail: luca@level3.net 754 Nasser El-Aawar 755 Level 3 Communications, LLC. 756 1025 Eldorado Blvd. 757 Broomfield, CO, 80021 758 e-mail: nna@level3.net 760 Giles Heron 761 PacketExchange Ltd. 762 The Truman Brewery 763 91 Brick Lane 764 LONDON E1 6QL 765 United Kingdom 766 e-mail: giles@packetexchange.net 768 Dimitri Stratton Vlachos 769 Mazu Networks, Inc. 770 125 Cambridgepark Drive 771 Cambridge, MA 02140 772 e-mail: d@mazunetworks.com 774 Dan Tappan 775 Cisco Systems, Inc. 776 250 Apollo Drive 777 Chelmsford, MA, 01824 778 e-mail: tappan@cisco.com 780 Jayakumar Jayakumar, 781 Cisco Systems Inc. 782 225, E.Tasman, MS-SJ3/3, 783 San Jose, CA, 95134 784 e-mail: jjayakum@cisco.com 785 Alex Hamilton, 786 Cisco Systems Inc. 787 285 W. Tasman, MS-SJCI/3/4, 788 San Jose, CA, 95134 789 e-mail: tahamilt@cisco.com 791 Eric Rosen 792 Cisco Systems, Inc. 793 250 Apollo Drive 794 Chelmsford, MA, 01824 795 e-mail: erosen@cisco.com 797 Steve Vogelsang 798 Laurel Networks, Inc. 799 Omega Corporate Center 800 1300 Omega Drive 801 Pittsburgh, PA 15205 802 e-mail: sjv@laurelnetworks.com 804 John Shirron 805 Omega Corporate Center 806 1300 Omega Drive 807 Pittsburgh, PA 15205 808 Laurel Networks, Inc. 809 e-mail: jshirron@laurelnetworks.com 811 Toby Smith 812 Omega Corporate Center 813 1300 Omega Drive 814 Pittsburgh, PA 15205 815 Laurel Networks, Inc. 816 e-mail: tob@laurelnetworks.com 818 Andrew G. Malis 819 Vivace Networks, Inc. 820 2730 Orchard Parkway 821 San Jose, CA 95134 822 Phone: +1 408 383 7223 823 Email: Andy.Malis@vivacenetworks.com 824 Vinai Sirkay 825 Vivace Networks, Inc. 826 2730 Orchard Parkway 827 San Jose, CA 95134 828 e-mail: sirkay@technologist.com 830 Vasile Radoaca 831 Nortel Networks 832 600 Technology Park 833 Billerica MA 01821 834 e-mail: vasile@nortelnetworks.com 836 Chris Liljenstolpe 837 Cable & Wireless 838 11700 Plaza America Drive 839 Reston, VA 20190 840 e-mail: chris@cw.net 842 Dave Cooper 843 Global Crossing 844 960 Hamlin Court 845 Sunnyvale, CA 94089 846 e-mail: dcooper@gblx.net 848 Kireeti Kompella 849 Juniper Networks 850 1194 N. Mathilda Ave 851 Sunnyvale, CA 94089 852 e-mail: kireeti@juniper.net