idnits 2.17.1 draft-martini-l2circuit-trans-mpls-14.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 370 has weird spacing: '... The highe...' == Line 371 has weird spacing: '...resence of a...' == Line 407 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 (June 2004) is 7255 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 308, 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-06 ** 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 Cisco Systems, Inc. 4 Expiration Date: December 2004 Nasser El-Aawar 5 Level 3 Communications, LLC. 7 Steve Vogelsang Daniel Tappan 8 John Shirron Eric C. Rosen 9 Toby Smith Alex Hamilton 10 Laurel Networks, Inc. Jayakumar Jayakumar 11 Cisco Systems, Inc. 13 Vasile Radoaca Dimitri Stratton Vlachos 14 Nortel Networks Mazu Networks, Inc. 16 Andrew G. Malis Chris Liljenstolpe 17 Vinai Sirkay Cable & Wireless 18 Vivace Networks, Inc. 19 Giles Heron 20 Dave Cooper PacketExchange Ltd. 21 Global Crossing 22 Kireeti Kompella 23 Juniper Networks 25 June 2004 27 Transport of Layer 2 Frames Over MPLS 29 draft-martini-l2circuit-trans-mpls-14.txt 31 Status of this Memo 33 This document is an Internet-Draft and is in full conformance with 34 all provisions of Section 10 of RFC2026. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that other 38 groups may also distribute working documents as Internet-Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 Abstract 53 This document describes methods for transporting the Protocol Data 54 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, 55 Ethernet, and providing a SONET circuit emulation service across an 56 MPLS network. 58 Table of Contents 60 1 Specification of Requirements .......................... 3 61 2 Introduction ........................................... 3 62 3 Tunnel Labels and VC Labels ............................ 3 63 4 Protocol-Specific Details .............................. 5 64 4.1 Frame Relay ............................................ 5 65 4.2 ATM .................................................... 5 66 4.2.1 ATM AAL5 VCC Transport ................................. 5 67 4.2.2 ATM Transparent Cell Transport ......................... 5 68 4.2.3 ATM VCC and VPC Cell Transport ......................... 6 69 4.2.4 OAM Cell Support ....................................... 6 70 4.2.5 ILMI Support ........................................... 7 71 4.3 Ethernet VLAN .......................................... 7 72 4.4 Ethernet ............................................... 7 73 4.5 HDLC ................................................... 7 74 4.6 PPP .................................................... 8 75 5 LDP .................................................... 8 76 5.1 Interface Parameters Field ............................. 10 77 5.2 C Bit handling procedures .............................. 11 78 5.2.1 VC types for which the control word is REQUIRED ........ 11 79 5.2.2 VC types for which the control word is NOT mandatory ... 11 80 5.2.3 Status codes ........................................... 15 81 5.3 LDP label Withdrawal procedures ........................ 15 82 5.4 Sequencing Considerations .............................. 15 83 5.4.1 Label Mapping Advertisements ........................... 16 84 5.4.2 Label Mapping Release .................................. 16 85 6 IANA Considerations .................................... 16 86 7 Security Considerations ................................ 17 87 8 References ............................................. 17 88 9 Author Information ..................................... 18 90 1. Specification of Requirements 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in RFC 2119. 96 2. Introduction 98 In an MPLS network, it is possible to carry the Protocol Data Units 99 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 100 these PDUs. This document specifies the necessary label distribution 101 procedures for accomplishing this using the encapsulation methods in 102 [7]. We restrict discussion to the case of point-to-point transport. 103 QoS related issues are not discussed in this draft. This document 104 describes methods for transporting a number of protocols; in some 105 cases, transporting a particular protocol may have several modes of 106 operation. Each of these protocols and/or modes may be implemented 107 independently. 109 An accompanying document [8] also describes a method for transporting 110 time division multiplexed (TDM) digital signals (TDM circuit 111 emulation) over a packet-oriented MPLS network. The transmission 112 system for circuit-oriented TDM signals is the Synchronous Optical 113 Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To 114 support TDM traffic, which includes voice, data, and private leased 115 line service, the MPLS network must emulate the circuit 116 characteristics of SONET/SDH payloads. MPLS labels and a new circuit 117 emulation header are used to encapsulate TDM signals and provide the 118 Circuit Emulation Service over MPLS (CEM). 120 3. Tunnel Labels and VC Labels 122 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 123 to egress LSR R2, across an intervening MPLS network. We assume that 124 there is an LSP from R1 to R2. That is, we assume that R1 can cause a 125 packet to be delivered to R2 by pushing some label onto the packet 126 and sending the result to one of its adjacencies. Call this label the 127 "tunnel label", and the corresponding LSP the "tunnel LSP". 129 The tunnel LSP merely gets packets from R1 to R2, the corresponding 130 label doesn't tell R2 what to do with the payload, and in fact if 131 penultimate hop popping is used, R2 may never even see the 132 corresponding label. (If R1 itself is the penultimate hop, a tunnel 133 label may not even get pushed on.) Thus if the payload is not an IP 134 packet, there must be a label, which becomes visible to R2, that 135 tells R2 how to treat the received packet. Call this label the "VC 136 label". 138 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 139 its label stack, and then (if R1 is not adjacent to R2) pushes on a 140 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 141 the VC label is not visible until the MPLS packet reaches R2. R2's 142 disposition of the packet is based on the VC label. 144 Note that the tunnel could be a GRE encapsulated MPLS tunnel between 145 R1 and R2. In this case R1 would be adjacent to R2, and only the VC 146 label would be used, and the intervening network need only carry IP 147 packets. 149 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 150 the VC label will generally correspond to a particular ATM VC at R2. 151 That is, R2 needs to be able to infer from the VC label the outgoing 152 interface and the VPI/VCI value for the AAL5 PDU. If the payload is a 153 Frame Relay PDU, then R2 needs to be able to infer from the VC label 154 the outgoing interface and the DLCI value. If the payload is an 155 Ethernet frame, then R2 needs to be able to infer from the VC label 156 the outgoing interface, and perhaps the VLAN identifier. This process 157 is unidirectional, and will be repeated independently for 158 bidirectional operation. It is REQUIRED to assign the same VC ID, and 159 VC type for a given circuit in both directions. The group ID (see 160 below) MUST NOT be required to match in both directions. The 161 transported frame MAY be modified when it reaches the egress router. 162 If the header of the transported layer 2 frame is modified, this MUST 163 be done at the egress LSR only. 165 Note that the VC label must always be at the bottom of the label 166 stack, and the tunnel label, if present, must be immediately above 167 the VC label. Of course, as the packet is transported across the MPLS 168 network, additional labels may be pushed on (and then popped off) as 169 needed. Even R1 itself may push on additional labels above the tunnel 170 label. If R1 and R2 are directly adjacent LSRs, then it may not be 171 necessary to use a tunnel label at all. 173 This document does not specify a method for distributing the tunnel 174 label or any other labels that may appear above the VC label on the 175 stack. Any acceptable method of MPLS label distribution will do. 177 This document does specify a method for assigning and distributing 178 the VC label. Static label assignment MAY be used, and 179 implementations SHOULD provide support for this. When signaling is 180 used, the VC label MUST be distributed from R2 to R1 using LDP in the 181 downstream unsolicited mode; this requires that an LDP session be 182 created between R1 and R2. It should be noted that this LDP session 183 is not necessarily transported along the same path as the Layer 2 184 PDUs. [1] In addition, when using LDP to distribute the VC label, 185 liberal label retention mode SHOULD be used. However, as required in 186 [1], the label request operation (mainly used by conservative label 187 retention mode) MUST be implemented. VC labels MUST be allocated from 188 the per-platform label space. 190 Note that this technique allows an unbounded number of layer 2 "VCs" 191 to be carried together in a single "tunnel". Thus it scales quite 192 well in the network backbone. 194 While this document currently defines the emulation of Frame Relay 195 and ATM PVC services, it specifically does not preclude future 196 enhancements to support switched service (SVC and SPVC) emulation. 198 4. Protocol-Specific Details 200 4.1. Frame Relay 202 The Frame Relay PDUs are encapsulated according to the procedures 203 defined in [7]. The MPLS edge LSR MUST provide Frame Relay PVC status 204 signaling to the Frame Relay network. If the MPLS edge LSR detects a 205 service affecting condition as defined in [2] Q.933 Annex A.5 sited 206 in IA FRF1.1, it MUST withdraw the label that corresponds to the 207 frame relay DLCI. The Egress LSR SHOULD generate the corresponding 208 errors and alarms as defined in [2] on the egress Frame relay VC. 210 4.2. ATM 212 4.2.1. ATM AAL5 VCC Transport 214 ATM AAL5 CSPS-SDUs are encapsulated according to [7] ATM AAL5 CPCS- 215 SDU mode. This mode allows the transport of ATM AAL5 CSPS-SDUs 216 traveling on a particular ATM PVC across the MPLS network to another 217 ATM PVC. 219 4.2.2. ATM Transparent Cell Transport 221 This mode is similar to the Ethernet port mode. Every cell that is 222 received at the ingress ATM port on the ingress LSR, R1, is 223 encapsulated according to [7], ATM cell mode, and sent across the LSP 224 to the egress LSR, R2. This mode allows an ATM port to be connected 225 to only one other ATM port. [7] allows for grouping of multiple cells 226 into a single MPLS frame. Grouping of ATM cells is OPTIONAL for 227 transmission at the ingress LSR, R1. If the Egress LSR R2 supports 228 cell concatenation the ingress LSR, R1, should only concatenate cells 229 up to the "Maximum Number of concatenated ATM cells" parameter 230 received as part of the FEC element. 232 4.2.3. ATM VCC and VPC Cell Transport 234 This mode is similar to the ATM AAL5 VCC transport except that cells 235 are transported. Every cell that is received on a pre-defined ATM 236 PVC, or ATM PVP, at the ingress ATM port on the ingress LSR, R1, is 237 encapsulated according to [7], ATM cell mode, and sent across the LSP 238 to the egress LSR R2. Grouping of ATM cells is OPTIONAL for 239 transmission at the ingress LSR, R1. If the Egress LSR R2 supports 240 cell concatenation the ingress LSR, R1, MUST only concatenate cells 241 up to the "Maximum Number of concatenated ATM cells in a frame" 242 parameter received as part of the FEC element. 244 4.2.4. OAM Cell Support 246 OAM cells MAY be transported on the VC LSP. When the LSR is operating 247 in AAL5 CPCS-SDU transport mode if it does not support transport of 248 ATM cells, the LSR MUST discard incoming MPLS frames on an ATM VC LSP 249 that contain a VC label with the T bit set [7]. When operating in 250 AAL5 SDU transport mode an LSR that supports transport of OAM cells 251 using the T bit defined in [7], or an LSR operating in any of the 252 three cell transport modes MUST follow the procedures outlined in [9] 253 section 8 for mode 0 only, in addition to the applicable procedures 254 specified in [6]. 256 4.2.4.1. OAM Cell Emulation Mode 258 AN LSR that does not support transport of OAM cells across an LSP MAY 259 provide OAM support on ATM PVCs using the following procedures: 261 A pair of LSRs MAY emulate a bidrectional ATM VC by two uni- 262 directional LSPs. If an F5 end-to-end OAM cell is received from a 263 ATM VC, by either LSR that is transporting this ATM VC, with a 264 loopback indication value of 1, and the LSR has a label mapping for 265 the ATM VC, then the LSR MUST decrement the loopback indication value 266 and loop back the cell on the ATM VC. Otherwise the loopback cell 267 MUST be discarded by the LSR. 269 The ingress LSR, R1, may also optionally be configured to 270 periodically generate F5 end-to-end loopback OAM cells on a VC. If 271 the LSR fails to receive a response to an F5 end-to-end loopback OAM 272 cell for a pre-defined period of time it MUST withdraw the label 273 mapping for the VC. 275 If an ingress LSR, R1, receives an AIS F5 OAM cell, fails to receive 276 a pre-defined number of the End-to-End loop OAM cells, or a physical 277 interface goes down, it MUST withdraw the label mappings for all VCs 278 associated with the failure. When a VC label mapping is withdrawn, 279 the egress LSR, R2, MUST generate AIS F5 OAM cells on the VC 280 associated with the withdrawn label mapping. In this mode it is very 281 useful to apply a unique group ID to each interface. In the case 282 where a physical interface goes down, a wild card label withdraw can 283 be sent to all LDP neighbors, greatly reducing the signaling response 284 time. 286 4.2.5. ILMI Support 288 An MPLS edge LSR MAY provide an ATM ILMI to the ATM edge switch. If 289 an ingress LSR receives an ILMI message indicating that the ATM edge 290 switch has deleted a VC, or if the physical interface goes down, it 291 MUST withdraw the label mappings for all VCs associated with the 292 failure. When a VC label mapping is withdrawn, the egress LSR SHOULD 293 notify its client of this failure by deleting the VC using ILMI. 295 4.3. Ethernet VLAN 297 The Ethernet frame will be encapsulated according to the procedures 298 in [12]. It should be noted that if the VLAN identifier is modified 299 by the egress LSR, according to the procedures outlined above, the 300 Ethernet spanning tree protocol might fail to work properly. If the 301 LSR detects a failure on the Ethernet physical port, or the port is 302 administratively disabled, it MUST withdraw the label mappings for 303 all VCs associated with the port. 305 4.4. Ethernet 307 The Ethernet frame will be encapsulated according to the procedures 308 in [12]. If the LSR detects a failure on the Ethernet physical port, 309 or the port is administratively disabled, the corresponding VC label 310 mapping MUST be withdrawn. 312 4.5. HDLC 314 HDLC frames are encapsulated according to the procedures in [7]. If 315 the MPLS edge LSR detects that the physical link has failed, or the 316 port is adminstratively disabled, it MUST withdraw the label mapping 317 that corresponds to the HDLC link. 319 4.6. PPP 321 PPP frames are encapsulated according to the procedures in [7]. If 322 the MPLS edge LSR detects that the physical link has failed, or the 323 port is adminstratively disabled, it MUST withdraw the label mapping 324 that corresponds to the PPP link. 326 5. LDP 328 The VC label bindings are distributed using the LDP downstream 329 unsolicited mode described in [1]. The LSRs will establish an LDP 330 session using the Extended Discovery mechanism described in [1, 331 section 2.4.2 and 2.5], for this purpose a new type of FEC element is 332 defined. The FEC element type is 128. [note1] Only a single VC FEC 333 element MUST be advertised per LDP VC label. The Virtual Circuit FEC 334 element, is defined as follows: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | VC tlv |C| VC Type |VC info Length | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Group ID | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | VC ID | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Interface parameters | 346 | " | 347 | " | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 - VC Type 352 A 15 bit quantity containing a value which represents the type of 353 VC. Assigned Values are: 355 VC Type Description 357 0x0001 Frame Relay DLCI 358 0x0002 ATM AAL5 VCC transport 359 0x0003 ATM transparent cell transport 360 0x0004 Ethernet VLAN 361 0x0005 Ethernet 362 0x0006 HDLC 363 0x0007 PPP 364 0x8008 CEM [8] 365 0x0009 ATM VCC cell transport 366 0x000A ATM VPC cell transport 368 - Control word bit (C) 370 The highest order bit (C) of the VC type is used to flag the 371 presence of a control word ( defined in [7] ) as follows: 372 bit 15 = 1 control word present on this VC. 373 bit 15 = 0 no control word present on this VC. 375 Please see the section "C Bit handling procedures" for further 376 explenation. 378 - VC information length 380 Length of the VC ID field and the interface parameters field in 381 octets. If this value is 0, then it references all VCs using the 382 specified group ID and there is no VC ID present, nor any 383 interface parameters. 385 - Group ID 387 An arbitrary 32 bit value which represents a group of VCs that is 388 used to create groups in the VC space. The group ID is intended 389 to be used as a port index, or a virtual tunnel index. To 390 simplify configuration a particular VC ID at ingress could be 391 part of the virtual tunnel for transport to the egress router. 392 The Group ID is very useful to send wild card label withdrawals 393 to remote LSRs upon physical port failure. 395 - VC ID 397 A non zero 32-bit connection ID that together with the VC type, 398 identifies a particular VC. 400 - Interface parameters 402 This variable length field is used to provide interface specific 403 parameters, such as interface MTU. 405 5.1. Interface Parameters Field 407 This field specifies interface specific parameters. When aplicable, 408 it MUST be used to validate that the LSRs, and the ingress and egress 409 ports at the edges of the circuit, have the necessary capabilities to 410 interoperate with each other. The field structure is defined as 411 follows: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Parameter ID | Length | Variable Length Value | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Variable Length Value | 419 | " | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 The parameter ID is defined as follows: 423 Parameter ID Length Description 425 0x01 4 Interface MTU in octets. 426 0x02 4 Maximum Number of concatenated ATM cells. 427 0x03 up to 82 Optional Interface Description string. 428 0x04 4 CEM [8] Payload Bytes. 429 0x05 4 CEM options. 431 The Length field is defined as the length of the interface parameter 432 including the parameter id and length field itself. Processing of the 433 interface parameters should continue when encounting unknown interface 434 parameters and they MUST be silently ignored. 436 - Interface MTU 438 A 2 octet value indicating the MTU in octets. This is the Maximum 439 Transmission Unit, excluding encapsulation overhead, of the 440 egress packet interface that will be transmitting the 441 decapsulated PDU that is received from the MPLS network. This 442 parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, 443 and is REQUIRED for these VC types. If this parameter does not 444 match in both directions of a specific VC, that VC MUST NOT be 445 enabled. 447 - Maximum Number of concatenated ATM cells 449 A 2 octet value specifying the maximum number of concatenated ATM 450 cells that can be processed as a single PDU by the egress LSR. An 451 ingress LSR transmitting concatenated cells on this VC can 452 concatenate a number of cells up to the value of this parameter, 453 but MUST NOT exceed it. This parameter is applicable only to VC 454 types 3, 9, and 0x0a, and is REQUIRED for these VC types. This 455 parameter does not need to match in both directions of a specific 456 VC. 458 - Optional Interface Description string 460 This arbitrary, OPTIONAL, interface description string can be 461 used to send an administrative description text string to the 462 remote LSR. This parameter is OPTIONAL, and is applicable to all 463 VC types. The interface description parameter string length is 464 variable, and can be from 0 to 80 octets. 466 - Payload Bytes 468 A 2 octet value indicating the the number of TDM payload octets 469 contained in all packets on the CEM stream, from 48 to 1,023 470 octets. All of the packets in a given CEM stream have the same 471 number of payload bytes. Note that there is a possibility that 472 the packet size may exceed the SPE size in the case of an STS-1 473 SPE, which could cause two pointers to be needed in the CEM 474 header, since the payload may contain two J1 bytes for 475 consecutive SPEs. For this reason, the number of payload bytes 476 must be less than or equal to 783 for STS-1 SPEs. 478 - CEM Options. An optional 16 Bit value of CEM Flags. See [8] for 479 the definition of the bit values. 481 5.2. C Bit handling procedures 483 5.2.1. VC types for which the control word is REQUIRED 485 The Label Mapping messages which are sent in order to set up these 486 VCs MUST have c=1. When a Label Mapping message for a VC of one of 487 these types is received, and c=0, a Label Release MUST be sent, with 488 an "Illegal C-bit" status code. In this case, the VC will not come 489 up. 491 5.2.2. VC types for which the control word is NOT mandatory 493 If a system is capable of sending and receiving the control word on 494 VC types for which the control word is not mandatory, then each such 495 VC endpoint MUST be configurable with a parameter that specifies 496 whether the use of the control word is PREFERRED or NOT PREFERRED. 498 For each VC, there MUST be a default value of this parameter. This 499 specification does NOT state what the default value should. 501 If a system is NOT capable of sending and receiving the control word 502 on VC types for which the control word is not mandatory, then it 503 behaves as exactly as if it were configured for the use of the 504 control word to be NOT PREFERRED. 506 If a Label Mapping message for the VC has already been received, but 507 no Label Mapping message for the VC has yet been sent, then the 508 procedure is the following: 509 -i. If the received Label Mapping message has c=0, send a Label 510 Mapping message with c=0, and the control word is not used. 511 -ii. 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 preferred, then send a Label Mapping message with c=1, and 514 the control word is used. 515 -iii. If the received Label Mapping message has c=1, and the VC is 516 locally configured such that the use of the control word is 517 not preferred or the control word is not supported, then act 518 as if no Label Mapping message for the VC had been received 519 (i.e., proceed to the next paragraph). 521 If a Label Mapping message for the VC has not already been received 522 (or if the received Label Mapping message had c=1 and either local 523 configuration says that the use of the control word is not preferred 524 or the control word is not supported), then send a Label Mapping 525 message in which the c bit is set to correspond to the locally 526 configured preference for use of the control word. (I.e., set c=1 if 527 locally configured to prefer the control word, set c=0 if locally 528 configured to prefer not to use the control word or if the control 529 word is not supported). 531 The next action depends on what control message is next received for 532 that VC. The possibilities are: 533 -i. A Label Mapping message with the same c bit value as 534 specified in the Label Mapping message that was sent. VC 535 setup is now complete, and the control word is used if c=1 536 but not used if c=0. 537 -ii. A Label Mapping message with c=1, but the Label Mapping 538 message that was sent has c=0. In this case, ignore the 539 received Label Mapping message, and continue to wait for the 540 next control message for the VC. 541 -iii. A Label Mapping message with c=0, but the Label Mapping 542 message that was sent has c=1. In this case, send a Label 543 Withdraw message with a "Wrong c-bit" status code, followed 544 by a Label Mapping message that has c=0. VC setup is now 545 complete, and the control word is not used. 547 -iv. A Label Withdraw message with the "Wrong c-bit" status code. 548 Treat as a normal Label Withdraw, but do not respond. 549 Continue to wait for the next control message for the VC. 551 If at any time after a Label Mapping message has been received, a 552 corresponding Label Withdraw or Release is received, the action taken 553 is the same as for any Label Withdraw or Release that might be 554 received at any time. 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-06.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 Cisco Systems, Inc. 750 9155 East Nichols Avenue, Suite 400 751 Englewood, CO, 80112 752 e-mail: lmartini@cisco.com 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 Tellabs 762 Abbey Place 763 24-28 Easton Street 764 High Wycombe 765 Bucks 766 HP11 1NT 767 UK 768 e-mail: giles.heron@tellabs.com 770 Dimitri Stratton Vlachos 771 Mazu Networks, Inc. 772 125 Cambridgepark Drive 773 Cambridge, MA 02140 774 e-mail: d@mazunetworks.com 776 Dan Tappan 777 Cisco Systems, Inc. 778 250 Apollo Drive 779 Chelmsford, MA, 01824 780 e-mail: tappan@cisco.com 782 Jayakumar Jayakumar, 783 Cisco Systems Inc. 784 225, E.Tasman, MS-SJ3/3, 785 San Jose, CA, 95134 786 e-mail: jjayakum@cisco.com 787 Alex Hamilton, 788 Cisco Systems Inc. 789 285 W. Tasman, MS-SJCI/3/4, 790 San Jose, CA, 95134 791 e-mail: tahamilt@cisco.com 793 Eric Rosen 794 Cisco Systems, Inc. 795 250 Apollo Drive 796 Chelmsford, MA, 01824 797 e-mail: erosen@cisco.com 799 Steve Vogelsang 800 Laurel Networks, Inc. 801 Omega Corporate Center 802 1300 Omega Drive 803 Pittsburgh, PA 15205 804 e-mail: sjv@laurelnetworks.com 806 John Shirron 807 Omega Corporate Center 808 1300 Omega Drive 809 Pittsburgh, PA 15205 810 Laurel Networks, Inc. 811 e-mail: jshirron@laurelnetworks.com 813 Toby Smith 814 Omega Corporate Center 815 1300 Omega Drive 816 Pittsburgh, PA 15205 817 Laurel Networks, Inc. 818 e-mail: tob@laurelnetworks.com 820 Andrew G. Malis 821 Tellabs 822 90 Rio Robles Dr. 823 San Jose, CA 95134 824 e-mail: Andy.Malis@tellabs.com 825 Vinai Sirkay 826 Vivace Networks, Inc. 827 2730 Orchard Parkway 828 San Jose, CA 95134 829 e-mail: sirkay@technologist.com 831 Vasile Radoaca 832 Nortel Networks 833 600 Technology Park 834 Billerica MA 01821 835 e-mail: vasile@nortelnetworks.com 837 Chris Liljenstolpe 838 Cable & Wireless 839 11700 Plaza America Drive 840 Reston, VA 20190 841 e-mail: chris@cw.net 843 Dave Cooper 844 Global Crossing 845 960 Hamlin Court 846 Sunnyvale, CA 94089 847 e-mail: dcooper@gblx.net 849 Kireeti Kompella 850 Juniper Networks 851 1194 N. Mathilda Ave 852 Sunnyvale, CA 94089 853 e-mail: kireeti@juniper.net