idnits 2.17.1 draft-martini-l2circuit-trans-mpls-08.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 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 (November 2001) is 8196 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: '32768' is mentioned on line 607, but not defined == Unused Reference: '3' is defined on line 664, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 667, 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: 5 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Luca Martini 3 Internet Draft Nasser El-Aawar 4 Expiration Date: May 2002 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 November 2001 26 Transport of Layer 2 Frames Over MPLS 28 draft-martini-l2circuit-trans-mpls-08.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 ........................................... 13 80 5.3 LDP label Withdrawal procedures ........................ 13 81 5.4 Sequencing Considerations .............................. 14 82 5.4.1 Label Mapping Advertisements ........................... 14 83 5.4.2 Label Mapping Release .................................. 14 84 6 IANA Considerations .................................... 15 85 7 Security Considerations ................................ 15 86 8 References ............................................. 15 87 9 Author Information ..................................... 16 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 [7]. 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 [7]. 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. 433 - Interface MTU 435 A 2 octet value indicating the MTU in octets. This is the Maximum 436 Transmission Unit, excluding encapsulation overhead, of the 437 egress packet interface that will be transmitting the 438 decapsulated PDU that is received from the MPLS network. This 439 parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, 440 and is REQUIRED for these VC types. If this parameter does not 441 match in both directions of a specific VC, that VC MUST NOT be 442 enabled. 444 - Maximum Number of concatenated ATM cells 446 A 2 octet value specifying the maximum number of concatenated ATM 447 cells that can be processed as a single PDU by the egress LSR. An 448 ingress LSR transmitting concatenated cells on this VC can 449 concatenate a number of cells up to the value of this parameter, 450 but MUST NOT exceed it. This parameter is applicable only to VC 451 types 3, 9, and 0x0a, and is REQUIRED for these VC types. This 452 parameter does not need to match in both directions of a specific 453 VC. 455 - Optional Interface Description string 457 This arbitrary, OPTIONAL, interface description string can be 458 used to send an administrative description text string to the 459 remote LSR. This parameter is OPTIONAL, and is applicable to all 460 VC types. The interface description parameter string length is 461 variable, and can be from 0 to 80 octets. 463 - Payload Bytes 465 A 2 octet value indicating the the number of TDM payload octets 466 contained in all packets on the CEM stream, from 48 to 1,023 467 octets. All of the packets in a given CEM stream have the same 468 number of payload bytes. Note that there is a possibility that 469 the packet size may exceed the SPE size in the case of an STS-1 470 SPE, which could cause two pointers to be needed in the CEM 471 header, since the payload may contain two J1 bytes for 472 consecutive SPEs. For this reason, the number of payload bytes 473 must be less than or equal to 783 for STS-1 SPEs. 475 - CEM Options. An optional 16 Bit value of CEM Flags. See [8] for 476 the definition of the bit values. 478 5.2. C Bit handling procedures 480 5.2.1. VC types for which the control word is REQUIRED 482 The Label Mapping messages which are sent in order to set up these 483 VCs MUST have c=1. When a Label Mapping message for a VC of one of 484 these types is received, and c=0, a Label Release MUST be sent, with 485 an "Illegal C-bit" status code. In this case, the VC will not come 486 up. 488 5.2.2. VC types for which the control word is NOT mandatory 490 If a system is capable of sending and receiving the control word on 491 VC types for which the control word is not mandatory, then each such 492 VC endpoint MUST be configurable with a parameter that specifies 493 whether the use of the control word is PREFERRED or NOT PREFERRED. 494 For each VC, there MUST be a default value of this parameter. This 495 specification does NOT state what the default value should. 497 If a system is NOT capable of sending and receiving the control word 498 on VC types for which the control word is not mandatory, then it 499 behaves as exactly as if it were configured for the use of the 500 control word to be NOT PREFERRED. 502 If a Label Mapping message for the VC has already been received, but 503 no Label Mapping message for the VC has yet been sent, then the 504 procedure is the following: 505 -i. If the received Label Mapping message has c=0, send a Label 506 Mapping message with c=0, and the control word is not used. 507 -ii. If the received Label Mapping message has c=1, and the VC is 508 locally configured such that the use of the control word is 509 preferred, then send a Label Mapping message with c=1, and 510 the control word is used. 511 -iii. If the received Label Mapping message has c=1, and the VC is 512 locally configured such that the use of the control word is 513 not preferred or the control word is not supported, then act 514 as if no Label Mapping message for the VC had been received 515 (i.e., proceed to the next paragraph). 517 If a Label Mapping message for the VC has not already been received 518 (or if the received Label Mapping message had c=1 and either local 519 configuration says that the use of the control word is not preferred 520 or the control word is not supported), then send a Label Mapping 521 message in which the c bit is set to correspond to the locally 522 configured preference for use of the control word. (I.e., set c=1 if 523 locally configured to prefer the control word, set c=0 if locally 524 configured to prefer not to use the control word or if the control 525 word is not supported). 527 The next action depends on what control message is next received for 528 that VC. The possibilities are: 529 -i. A Label Mapping message with the same c bit value as 530 specified in the Label Mapping message that was sent. VC 531 setup is now complete, and the control word is used if c=1 532 but not used if c=0. 533 -ii. A Label Mapping message with c=1, but the Label Mapping 534 message that was sent has c=0. In this case, ignore the 535 received Label Mapping message, and continue to wait for the 536 next control message for the VC. 537 -iii. A Label Mapping message with c=0, but the Label Mapping 538 message that was sent has c=1. In this case, send a Label 539 Withdraw message with a "Wrong c-bit" status code, followed 540 by a Label Mapping message that has c=0. VC setup is now 541 complete, and the control word is not used. 543 -iv. A Label Withdraw message with the "Wrong c-bit" status code. 544 Treat as a normal Label Withdraw, but do not respond. 545 Continue to wait for the next control message for the VC. 547 If at any time after a Label Mapping message has been received, a 548 corresponding Label Withdraw or Release is received, the action taken 549 is the same as for any Label Withdraw or Release that might be 550 received at any time. Note that receiving a Label Withdraw should not 551 cause a corresponding Label Release to be sent. 553 If both endpoints prefer the use of the control word, this procedure 554 will cause it to be used. If either endpoint prefers not to use the 555 control word, or does not support the control word, this procedure 556 will cause it not to be used. If one endpoint prefers to use the 557 control word but the other does not, the one that prefers not to use 558 it is has no extra protocol to execute, it just waits for a Label 559 Mapping message that has c=0. 561 5.2.3. Status codes 563 RFC 3036 has a range of Status Code values which are assigned by IANA 564 on a First Come, First Served basis. These are in the range 565 0x20000000-0x3effffff [note 2]. The following new status codes are 566 defined: 568 0x20000001 "Illegal C-Bit" 569 0x20000002 "Wrong C-Bit" 571 5.3. LDP label Withdrawal procedures 573 As mentioned above the Group ID field can be used to withdraw all VC 574 labels associated with a particular group ID. This procedure is 575 OPTIONAL, and if it is implemented the LDP label withdraw message 576 should be as follows: the VC information length field is set to 0, 577 the VC ID field is not present, and the interface paramenters field 578 is not present. For the purpose of this document this is called the 579 "wild card withdraw procedure", and all LSRs implementing this design 580 are REQUIRED to accept such a withdraw message, but are not required 581 to send it. 583 The interface parameters field MUST NOT be present in any LDP VC 584 label withdrawal message or release message. A wildcard release 585 message MUST include only the group ID.A Label Release message 586 initiated from the imposition router must always include the VC ID. 588 5.4. Sequencing Considerations 590 In the case where the router considers the sequence number field in 591 the control word, it is important to note the following when 592 advertising labels 594 5.4.1. Label Mapping Advertisements 596 After a label has been withdrawn by the disposition router and/or 597 released by the imposition router, care must be taken to not re- 598 advertise (re-use) the released label until the disposition router 599 can be reasonably certain that old packets containing the released 600 label no longer persist in the MPLS network. 602 This precaution is required to prevent the imposition router from 603 restarting packet forwarding with sequence number of 1 when it 604 receives the same label mapping if there are still older packets 605 persisting in the network with sequence number between 1 and 32768. 606 For example, if there is a packet with sequence number=n where n is 607 in the interval[1,32768] travelling through the network, it would be 608 possible for the disposition router to receive that packet after it 609 re-advertises the label. Since the label has been released by the 610 imposition router, the disposition router SHOULD be expecting the 611 next packet to arrive with sequence number to be 1. Receipt of a 612 packet with sequence number equal to n will result in n packets 613 potentially being rejected by the disposition router until the 614 imposition router imposes a sequence number of n+1 into a packet. 615 Possible methods to avoid this is for the disposition router to 616 always advertise a different VC label, or for the disposition router 617 to wait for a sufficient time before attempting to re-advertised a 618 recently released label. This is only an issue when sequence number 619 processing at the disposition router is enabled. 621 5.4.2. Label Mapping Release 623 In situations where the imposition router wants to restart forwarding 624 of packets with sequence number 1, the router shall 1) Send to 625 disposition router a label mapping release, and 2) Send to 626 disposition router a label mapping request. When sequencing is 627 supported, advertisement of a vc label in response to a label mapping 628 request MUST also consider the issues discussed in 5.3.1 630 6. IANA Considerations 632 As specified in this document, a Virtual Circuit FEC element contains 633 the VC Type field. VC Type value 0 is reserved. VC Type values 1 634 through 10 are defined in this document. VC Type values 11 through 63 635 are to be assigned by IANA using the "IETF Consensus" policy defined 636 in RFC2434. VC Type values 64 through 127 are to be assigned by IANA, 637 using the "First Come First Served" policy defined in RFC2434. VC 638 Type values 128 through 32767 are vendor-specific, and values in this 639 range are not to be assigned by IANA. 641 As specified in this document, a Virtual Circuit FEC element contains 642 the Interface Parameters field, which is a list of one or more 643 parameters, and each parameter is identified by the Parameter ID 644 field. Parameter ID value 0 is reserved. Parameter ID values 1 645 through 5 are defined in this document. Parameter ID values 6 646 through 63 are to be assigned by IANA using the "IETF Consensus" 647 policy defined in RFC2434. Parameter ID values 64 through 127 are to 648 be assigned by IANA, using the "First Come First Served" policy 649 defined in RFC2434. Parameter ID values 128 through 255 are vendor- 650 specific, and values in this range are not to be assigned by IANA. 652 7. Security Considerations 654 This document does not affect the underlying security issues of MPLS. 656 8. References 658 [1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 659 Fredette, B. Thomas. January 2001. RFC3036 661 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 662 Mode Basic call control, ITU Geneva 1995 664 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 665 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 667 [4] "IEEE 802.3ac-1998" IEEE standard specification. 669 [5] American National Standards Institute, "Synchronous Optical 670 Network Formats," ANSI T1.105-1995. 672 [6] ITU Recommendation G.707, "Network Node Interface For The 673 Synchronous Digital Hierarchy", 1996. 675 [7] "Encapsulation Methods for Transport of Layer 2 Frames Over 676 MPLS", draft-martini-l2circuit-encap-mpls-04.txt ( Work in progress ) 678 [8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM) 679 Encapsulation", draft-malis-sonet-ces-mpls-05.txt ( Work in progress 680 ) 682 [9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 684 [note1] FEC element type 128 is pending IANA approval. [note2] 685 Status codes assigment is pending IANA approval. 687 9. Author Information 689 Luca Martini 690 Level 3 Communications, LLC. 691 1025 Eldorado Blvd. 692 Broomfield, CO, 80021 693 e-mail: luca@level3.net 695 Nasser El-Aawar 696 Level 3 Communications, LLC. 697 1025 Eldorado Blvd. 698 Broomfield, CO, 80021 699 e-mail: nna@level3.net 701 Giles Heron 702 PacketExchange Ltd. 703 The Truman Brewery 704 91 Brick Lane 705 LONDON E1 6QL 706 United Kingdom 707 e-mail: giles@packetexchange.net 709 Dimitri Stratton Vlachos 710 Mazu Networks, Inc. 711 125 Cambridgepark Drive 712 Cambridge, MA 02140 713 e-mail: d@mazunetworks.com 715 Dan Tappan 716 Cisco Systems, Inc. 717 250 Apollo Drive 718 Chelmsford, MA, 01824 719 e-mail: tappan@cisco.com 720 Jayakumar Jayakumar, 721 Cisco Systems Inc. 722 225, E.Tasman, MS-SJ3/3, 723 San Jose, CA, 95134 724 e-mail: jjayakum@cisco.com 726 Alex Hamilton, 727 Cisco Systems Inc. 728 285 W. Tasman, MS-SJCI/3/4, 729 San Jose, CA, 95134 730 e-mail: tahamilt@cisco.com 732 Eric Rosen 733 Cisco Systems, Inc. 734 250 Apollo Drive 735 Chelmsford, MA, 01824 736 e-mail: erosen@cisco.com 738 Steve Vogelsang 739 Laurel Networks, Inc. 740 Omega Corporate Center 741 1300 Omega Drive 742 Pittsburgh, PA 15205 743 e-mail: sjv@laurelnetworks.com 745 John Shirron 746 Omega Corporate Center 747 1300 Omega Drive 748 Pittsburgh, PA 15205 749 Laurel Networks, Inc. 750 e-mail: jshirron@laurelnetworks.com 752 Toby Smith 753 Omega Corporate Center 754 1300 Omega Drive 755 Pittsburgh, PA 15205 756 Laurel Networks, Inc. 757 e-mail: tob@laurelnetworks.com 758 Andrew G. Malis 759 Vivace Networks, Inc. 760 2730 Orchard Parkway 761 San Jose, CA 95134 762 Phone: +1 408 383 7223 763 Email: Andy.Malis@vivacenetworks.com 765 Vinai Sirkay 766 Vivace Networks, Inc. 767 2730 Orchard Parkway 768 San Jose, CA 95134 769 e-mail: sirkay@technologist.com 771 Vasile Radoaca 772 Nortel Networks 773 600 Technology Park 774 Billerica MA 01821 775 e-mail: vasile@nortelnetworks.com 777 Chris Liljenstolpe 778 Cable & Wireless 779 11700 Plaza America Drive 780 Reston, VA 20190 781 e-mail: chris@cw.net 783 Dave Cooper 784 Global Crossing 785 960 Hamlin Court 786 Sunnyvale, CA 94089 787 e-mail: dcooper@gblx.net 789 Kireeti Kompella 790 Juniper Networks 791 1194 N. Mathilda Ave 792 Sunnyvale, CA 94089 793 e-mail: kireeti@juniper.net