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