idnits 2.17.1 draft-martini-l2circuit-trans-mpls-12.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 (November 2003) is 7439 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 667, but not defined == Unused Reference: '3' is defined on line 724, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 727, 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: May 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 November 2003 27 Transport of Layer 2 Frames Over MPLS 29 draft-martini-l2circuit-trans-mpls-12.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. Note that receiving a Label Withdraw should not 555 cause a corresponding Label Release to be sent. 557 If both endpoints prefer the use of the control word, this procedure 558 will cause it to be used. If either endpoint prefers not to use the 559 control word, or does not support the control word, this procedure 560 will cause it not to be used. If one endpoint prefers to use the 561 control word but the other does not, the one that prefers not to use 562 it is has no extra protocol to execute, it just waits for a Label 563 Mapping message that has c=0. 565 The following diagram illustrate the above procedures: 567 ------------------ 568 Y | Received Label | N 569 -------| Mapping Msg? |-------------- 570 | ------------------ | 571 | | 572 -------------- | 573 | | | 574 | | | 575 ------- ------- | 576 | C=0 | | C=1 | | 577 ------- ------- | 578 | | | 579 | | | 580 | ---------------- | 581 | | Control Word | N | 582 | | Capable? |----------- | 583 | ---------------- | | 584 | Y | | | 585 | | | | 586 | ---------------- | | 587 | | Control Word | N | | 588 | | Preferred? |---- | | 589 | ---------------- | | | 590 | Y | | | | 591 | | | | ---------------- 592 | | | | | Control Word | 593 | | | | | Preferred? | 594 | | | | ---------------- 595 | | | | N | Y | 596 | | | | | | 597 Send Send Send Send Send Send 598 C=0 C=1 C=0 C=0 C=0 C=1 599 | | | | 600 | | | | 601 ---------------------------------- 602 | If receive the same as sent, | 603 | VC setup is complete. If not: | 604 ---------------------------------- 605 | | | | 606 | | | | 607 ------------------- ----------- 608 | Receive | | Receive | 609 | C=1 | | C=0 | 610 ------------------- ----------- 611 | | 612 | | 613 Wait for the Send 614 next message Wrong C-Bit 615 | 616 | 617 Send Label 618 Mapping Message 619 with C=0 621 5.2.3. Status codes 623 RFC 3036 has a range of Status Code values which are assigned by IANA 624 on a First Come, First Served basis. These are in the range 625 0x20000000-0x3effffff [note 2]. The following new status codes are 626 defined: 628 0x20000001 "Illegal C-Bit" 629 0x20000002 "Wrong C-Bit" 631 5.3. LDP label Withdrawal procedures 633 As mentioned above the Group ID field can be used to withdraw all VC 634 labels associated with a particular group ID. This procedure is 635 OPTIONAL, and if it is implemented the LDP label withdraw message 636 should be as follows: the VC information length field is set to 0, 637 the VC ID field is not present, and the interface paramenters field 638 is not present. For the purpose of this document this is called the 639 "wild card withdraw procedure", and all LSRs implementing this design 640 are REQUIRED to accept such a withdraw message, but are not required 641 to send it. 643 The interface parameters field MUST NOT be present in any LDP VC 644 label withdrawal message or release message. A wildcard release 645 message MUST include only the group ID.A Label Release message 646 initiated from the imposition router must always include the VC ID. 648 5.4. Sequencing Considerations 650 In the case where the router considers the sequence number field in 651 the control word, it is important to note the following when 652 advertising labels 654 5.4.1. Label Mapping Advertisements 656 After a label has been withdrawn by the disposition router and/or 657 released by the imposition router, care must be taken to not re- 658 advertise (re-use) the released label until the disposition router 659 can be reasonably certain that old packets containing the released 660 label no longer persist in the MPLS network. 662 This precaution is required to prevent the imposition router from 663 restarting packet forwarding with sequence number of 1 when it 664 receives the same label mapping if there are still older packets 665 persisting in the network with sequence number between 1 and 32768. 666 For example, if there is a packet with sequence number=n where n is 667 in the interval[1,32768] travelling through the network, it would be 668 possible for the disposition router to receive that packet after it 669 re-advertises the label. Since the label has been released by the 670 imposition router, the disposition router SHOULD be expecting the 671 next packet to arrive with sequence number to be 1. Receipt of a 672 packet with sequence number equal to n will result in n packets 673 potentially being rejected by the disposition router until the 674 imposition router imposes a sequence number of n+1 into a packet. 675 Possible methods to avoid this is for the disposition router to 676 always advertise a different VC label, or for the disposition router 677 to wait for a sufficient time before attempting to re-advertised a 678 recently released label. This is only an issue when sequence number 679 processing at the disposition router is enabled. 681 5.4.2. Label Mapping Release 683 In situations where the imposition router wants to restart forwarding 684 of packets with sequence number 1, the router shall 1) Send to 685 disposition router a label mapping release, and 2) Send to 686 disposition router a label mapping request. When sequencing is 687 supported, advertisement of a vc label in response to a label mapping 688 request MUST also consider the issues discussed in 5.3.1 690 6. IANA Considerations 692 As specified in this document, a Virtual Circuit FEC element contains 693 the VC Type field. VC Type value 0 is reserved. VC Type values 1 694 through 10 are defined in this document. VC Type values 11 through 63 695 are to be assigned by IANA using the "IETF Consensus" policy defined 696 in RFC2434. VC Type values 64 through 127 are to be assigned by IANA, 697 using the "First Come First Served" policy defined in RFC2434. VC 698 Type values 128 through 32767 are vendor-specific, and values in this 699 range are not to be assigned by IANA. 701 As specified in this document, a Virtual Circuit FEC element contains 702 the Interface Parameters field, which is a list of one or more 703 parameters, and each parameter is identified by the Parameter ID 704 field. Parameter ID value 0 is reserved. Parameter ID values 1 705 through 5 are defined in this document. Parameter ID values 6 706 through 63 are to be assigned by IANA using the "IETF Consensus" 707 policy defined in RFC2434. Parameter ID values 64 through 127 are to 708 be assigned by IANA, using the "First Come First Served" policy 709 defined in RFC2434. Parameter ID values 128 through 255 are vendor- 710 specific, and values in this range are not to be assigned by IANA. 712 7. Security Considerations 714 This document does not affect the underlying security issues of MPLS. 716 8. References 718 [1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 719 Fredette, B. Thomas. January 2001. RFC3036 721 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 722 Mode Basic call control, ITU Geneva 1995 724 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 725 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 727 [4] "IEEE 802.3ac-1998" IEEE standard specification. 729 [5] American National Standards Institute, "Synchronous Optical 730 Network Formats," ANSI T1.105-1995. 732 [6] ITU Recommendation G.707, "Network Node Interface For The 733 Synchronous Digital Hierarchy", 1996. 735 [7] "Encapsulation Methods for Transport of Layer 2 Frames Over 736 MPLS", draft-martini-l2circuit-encap-mpls-06.txt ( Work in progress ) 738 [8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM) 739 Encapsulation", draft-malis-sonet-ces-mpls-05.txt ( Work in progress 740 ) 742 [9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 744 [note1] FEC element type 128 is pending IANA approval. [note2] 745 Status codes assigment is pending IANA approval. 747 9. Author Information 749 Luca Martini 750 Cisco Systems, Inc. 751 9155 East Nichols Avenue, Suite 400 752 Englewood, CO, 80112 753 e-mail: lmartini@cisco.com 755 Nasser El-Aawar 756 Level 3 Communications, LLC. 757 1025 Eldorado Blvd. 758 Broomfield, CO, 80021 759 e-mail: nna@level3.net 761 Giles Heron 762 Tellabs 763 Abbey Place 764 24-28 Easton Street 765 High Wycombe 766 Bucks 767 HP11 1NT 768 UK 769 e-mail: giles.heron@tellabs.com 771 Dimitri Stratton Vlachos 772 Mazu Networks, Inc. 773 125 Cambridgepark Drive 774 Cambridge, MA 02140 775 e-mail: d@mazunetworks.com 777 Dan Tappan 778 Cisco Systems, Inc. 779 250 Apollo Drive 780 Chelmsford, MA, 01824 781 e-mail: tappan@cisco.com 783 Jayakumar Jayakumar, 784 Cisco Systems Inc. 785 225, E.Tasman, MS-SJ3/3, 786 San Jose, CA, 95134 787 e-mail: jjayakum@cisco.com 788 Alex Hamilton, 789 Cisco Systems Inc. 790 285 W. Tasman, MS-SJCI/3/4, 791 San Jose, CA, 95134 792 e-mail: tahamilt@cisco.com 794 Eric Rosen 795 Cisco Systems, Inc. 796 250 Apollo Drive 797 Chelmsford, MA, 01824 798 e-mail: erosen@cisco.com 800 Steve Vogelsang 801 Laurel Networks, Inc. 802 Omega Corporate Center 803 1300 Omega Drive 804 Pittsburgh, PA 15205 805 e-mail: sjv@laurelnetworks.com 807 John Shirron 808 Omega Corporate Center 809 1300 Omega Drive 810 Pittsburgh, PA 15205 811 Laurel Networks, Inc. 812 e-mail: jshirron@laurelnetworks.com 814 Toby Smith 815 Omega Corporate Center 816 1300 Omega Drive 817 Pittsburgh, PA 15205 818 Laurel Networks, Inc. 819 e-mail: tob@laurelnetworks.com 821 Andrew G. Malis 822 Tellabs 823 90 Rio Robles Dr. 824 San Jose, CA 95134 825 e-mail: Andy.Malis@tellabs.com 826 Vinai Sirkay 827 Vivace Networks, Inc. 828 2730 Orchard Parkway 829 San Jose, CA 95134 830 e-mail: sirkay@technologist.com 832 Vasile Radoaca 833 Nortel Networks 834 600 Technology Park 835 Billerica MA 01821 836 e-mail: vasile@nortelnetworks.com 838 Chris Liljenstolpe 839 Cable & Wireless 840 11700 Plaza America Drive 841 Reston, VA 20190 842 e-mail: chris@cw.net 844 Dave Cooper 845 Global Crossing 846 960 Hamlin Court 847 Sunnyvale, CA 94089 848 e-mail: dcooper@gblx.net 850 Kireeti Kompella 851 Juniper Networks 852 1194 N. Mathilda Ave 853 Sunnyvale, CA 94089 854 e-mail: kireeti@juniper.net