idnits 2.17.1 draft-martini-l2circuit-trans-mpls-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 759. -- Found old boilerplate from RFC 3978, Section 5.5 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 741. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 748. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 754. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 373 has weird spacing: '... The highe...' == Line 374 has weird spacing: '...resence of a...' == Line 410 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 (February 2005) is 7008 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 311, but not defined == Missing Reference: '32768' is mentioned on line 669, but not defined == Unused Reference: '3' is defined on line 769, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 772, 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: 11 errors (**), 0 flaws (~~), 11 warnings (==), 12 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: August 2005 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 February 2005 27 Transport of Layer 2 Frames Over MPLS 29 draft-martini-l2circuit-trans-mpls-15.txt 31 Status of this Memo 33 By submitting this Internet-Draft, we certify that any applicable 34 patent or other IPR claims of which we are aware have been disclosed, 35 or will be disclosed, and any of which we become aware will be 36 disclosed, in accordance with RFC 3668. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that other 40 groups may also distribute working documents as Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/1id-abstracts.html 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html. 52 Abstract 54 This document describes methods for transporting the Protocol Data 55 Units (PDUs) of layer 2 protocols such as Frame Relay, ATM AAL5, 56 Ethernet, and providing a SONET circuit emulation service across an 57 MPLS network. 59 Table of Contents 61 1 Specification of Requirements .......................... 3 62 2 Introduction ........................................... 4 63 3 Tunnel Labels and VC Labels ............................ 4 64 4 Protocol-Specific Details .............................. 6 65 4.1 Frame Relay ............................................ 6 66 4.2 ATM .................................................... 6 67 4.2.1 ATM AAL5 VCC Transport ................................. 6 68 4.2.2 ATM Transparent Cell Transport ......................... 6 69 4.2.3 ATM VCC and VPC Cell Transport ......................... 7 70 4.2.4 OAM Cell Support ....................................... 7 71 4.2.5 ILMI Support ........................................... 8 72 4.3 Ethernet VLAN .......................................... 8 73 4.4 Ethernet ............................................... 8 74 4.5 HDLC ................................................... 8 75 4.6 PPP .................................................... 9 76 5 LDP .................................................... 9 77 5.1 Interface Parameters Field ............................. 11 78 5.2 C Bit handling procedures .............................. 12 79 5.2.1 VC types for which the control word is REQUIRED ........ 12 80 5.2.2 VC types for which the control word is NOT mandatory ... 12 81 5.2.3 Status codes ........................................... 16 82 5.3 LDP label Withdrawal procedures ........................ 16 83 5.4 Sequencing Considerations .............................. 16 84 5.4.1 Label Mapping Advertisements ........................... 17 85 5.4.2 Label Mapping Release .................................. 17 86 6 IANA Considerations .................................... 17 87 7 Security Considerations ................................ 18 88 8 Full Copyright Statement ............................... 18 89 9 Intellectual Property Statement ........................ 18 90 10 References ............................................. 19 91 11 Author Information ..................................... 20 93 1. Specification of Requirements 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119. 99 2. Introduction 101 In an MPLS network, it is possible to carry the Protocol Data Units 102 (PDUs) of layer 2 protocols by prepending an MPLS label stack to 103 these PDUs. This document specifies the necessary label distribution 104 procedures for accomplishing this using the encapsulation methods in 105 [7]. We restrict discussion to the case of point-to-point transport. 106 QoS related issues are not discussed in this draft. This document 107 describes methods for transporting a number of protocols; in some 108 cases, transporting a particular protocol may have several modes of 109 operation. Each of these protocols and/or modes may be implemented 110 independently. 112 An accompanying document [8] also describes a method for transporting 113 time division multiplexed (TDM) digital signals (TDM circuit 114 emulation) over a packet-oriented MPLS network. The transmission 115 system for circuit-oriented TDM signals is the Synchronous Optical 116 Network (SONET)[5]/Synchronous Digital Hierarchy (SDH) [6]. To 117 support TDM traffic, which includes voice, data, and private leased 118 line service, the MPLS network must emulate the circuit 119 characteristics of SONET/SDH payloads. MPLS labels and a new circuit 120 emulation header are used to encapsulate TDM signals and provide the 121 Circuit Emulation Service over MPLS (CEM). 123 3. Tunnel Labels and VC Labels 125 Suppose it is desired to transport layer 2 PDUs from ingress LSR R1 126 to egress LSR R2, across an intervening MPLS network. We assume that 127 there is an LSP from R1 to R2. That is, we assume that R1 can cause a 128 packet to be delivered to R2 by pushing some label onto the packet 129 and sending the result to one of its adjacencies. Call this label the 130 "tunnel label", and the corresponding LSP the "tunnel LSP". 132 The tunnel LSP merely gets packets from R1 to R2, the corresponding 133 label doesn't tell R2 what to do with the payload, and in fact if 134 penultimate hop popping is used, R2 may never even see the 135 corresponding label. (If R1 itself is the penultimate hop, a tunnel 136 label may not even get pushed on.) Thus if the payload is not an IP 137 packet, there must be a label, which becomes visible to R2, that 138 tells R2 how to treat the received packet. Call this label the "VC 139 label". 141 So when R1 sends a layer 2 PDU to R2, it first pushes a VC label on 142 its label stack, and then (if R1 is not adjacent to R2) pushes on a 143 tunnel label. The tunnel label gets the MPLS packet from R1 to R2; 144 the VC label is not visible until the MPLS packet reaches R2. R2's 145 disposition of the packet is based on the VC label. 147 Note that the tunnel could be a GRE encapsulated MPLS tunnel between 148 R1 and R2. In this case R1 would be adjacent to R2, and only the VC 149 label would be used, and the intervening network need only carry IP 150 packets. 152 If the payload of the MPLS packet is, for example, an ATM AAL5 PDU, 153 the VC label will generally correspond to a particular ATM VC at R2. 154 That is, R2 needs to be able to infer from the VC label the outgoing 155 interface and the VPI/VCI value for the AAL5 PDU. If the payload is a 156 Frame Relay PDU, then R2 needs to be able to infer from the VC label 157 the outgoing interface and the DLCI value. If the payload is an 158 Ethernet frame, then R2 needs to be able to infer from the VC label 159 the outgoing interface, and perhaps the VLAN identifier. This process 160 is unidirectional, and will be repeated independently for 161 bidirectional operation. It is REQUIRED to assign the same VC ID, and 162 VC type for a given circuit in both directions. The group ID (see 163 below) MUST NOT be required to match in both directions. The 164 transported frame MAY be modified when it reaches the egress router. 165 If the header of the transported layer 2 frame is modified, this MUST 166 be done at the egress LSR only. 168 Note that the VC label must always be at the bottom of the label 169 stack, and the tunnel label, if present, must be immediately above 170 the VC label. Of course, as the packet is transported across the MPLS 171 network, additional labels may be pushed on (and then popped off) as 172 needed. Even R1 itself may push on additional labels above the tunnel 173 label. If R1 and R2 are directly adjacent LSRs, then it may not be 174 necessary to use a tunnel label at all. 176 This document does not specify a method for distributing the tunnel 177 label or any other labels that may appear above the VC label on the 178 stack. Any acceptable method of MPLS label distribution will do. 180 This document does specify a method for assigning and distributing 181 the VC label. Static label assignment MAY be used, and 182 implementations SHOULD provide support for this. When signaling is 183 used, the VC label MUST be distributed from R2 to R1 using LDP in the 184 downstream unsolicited mode; this requires that an LDP session be 185 created between R1 and R2. It should be noted that this LDP session 186 is not necessarily transported along the same path as the Layer 2 187 PDUs. [1] In addition, when using LDP to distribute the VC label, 188 liberal label retention mode SHOULD be used. However, as required in 189 [1], the label request operation (mainly used by conservative label 190 retention mode) MUST be implemented. VC labels MUST be allocated from 191 the per-platform label space. 193 Note that this technique allows an unbounded number of layer 2 "VCs" 194 to be carried together in a single "tunnel". Thus it scales quite 195 well in the network backbone. 197 While this document currently defines the emulation of Frame Relay 198 and ATM PVC services, it specifically does not preclude future 199 enhancements to support switched service (SVC and SPVC) emulation. 201 4. Protocol-Specific Details 203 4.1. Frame Relay 205 The Frame Relay PDUs are encapsulated according to the procedures 206 defined in [7]. The MPLS edge LSR MUST provide Frame Relay PVC status 207 signaling to the Frame Relay network. If the MPLS edge LSR detects a 208 service affecting condition as defined in [2] Q.933 Annex A.5 sited 209 in IA FRF1.1, it MUST withdraw the label that corresponds to the 210 frame relay DLCI. The Egress LSR SHOULD generate the corresponding 211 errors and alarms as defined in [2] on the egress Frame relay VC. 213 4.2. ATM 215 4.2.1. ATM AAL5 VCC Transport 217 ATM AAL5 CSPS-SDUs are encapsulated according to [7] ATM AAL5 CPCS- 218 SDU mode. This mode allows the transport of ATM AAL5 CSPS-SDUs 219 traveling on a particular ATM PVC across the MPLS network to another 220 ATM PVC. 222 4.2.2. ATM Transparent Cell Transport 224 This mode is similar to the Ethernet port mode. Every cell that is 225 received at the ingress ATM port on the ingress LSR, R1, is 226 encapsulated according to [7], ATM cell mode, and sent across the LSP 227 to the egress LSR, R2. This mode allows an ATM port to be connected 228 to only one other ATM port. [7] allows for grouping of multiple cells 229 into a single MPLS frame. Grouping of ATM cells is OPTIONAL for 230 transmission at the ingress LSR, R1. If the Egress LSR R2 supports 231 cell concatenation the ingress LSR, R1, should only concatenate cells 232 up to the "Maximum Number of concatenated ATM cells" parameter 233 received as part of the FEC element. 235 4.2.3. ATM VCC and VPC Cell Transport 237 This mode is similar to the ATM AAL5 VCC transport except that cells 238 are transported. Every cell that is received on a pre-defined ATM 239 PVC, or ATM PVP, at the ingress ATM port on the ingress LSR, R1, is 240 encapsulated according to [7], ATM cell mode, and sent across the LSP 241 to the egress LSR R2. Grouping of ATM cells is OPTIONAL for 242 transmission at the ingress LSR, R1. If the Egress LSR R2 supports 243 cell concatenation the ingress LSR, R1, MUST only concatenate cells 244 up to the "Maximum Number of concatenated ATM cells in a frame" 245 parameter received as part of the FEC element. 247 4.2.4. OAM Cell Support 249 OAM cells MAY be transported on the VC LSP. When the LSR is operating 250 in AAL5 CPCS-SDU transport mode if it does not support transport of 251 ATM cells, the LSR MUST discard incoming MPLS frames on an ATM VC LSP 252 that contain a VC label with the T bit set [7]. When operating in 253 AAL5 SDU transport mode an LSR that supports transport of OAM cells 254 using the T bit defined in [7], or an LSR operating in any of the 255 three cell transport modes MUST follow the procedures outlined in [9] 256 section 8 for mode 0 only, in addition to the applicable procedures 257 specified in [6]. 259 4.2.4.1. OAM Cell Emulation Mode 261 AN LSR that does not support transport of OAM cells across an LSP MAY 262 provide OAM support on ATM PVCs using the following procedures: 264 A pair of LSRs MAY emulate a bidrectional ATM VC by two uni- 265 directional LSPs. If an F5 end-to-end OAM cell is received from a 266 ATM VC, by either LSR that is transporting this ATM VC, with a 267 loopback indication value of 1, and the LSR has a label mapping for 268 the ATM VC, then the LSR MUST decrement the loopback indication value 269 and loop back the cell on the ATM VC. Otherwise the loopback cell 270 MUST be discarded by the LSR. 272 The ingress LSR, R1, may also optionally be configured to 273 periodically generate F5 end-to-end loopback OAM cells on a VC. If 274 the LSR fails to receive a response to an F5 end-to-end loopback OAM 275 cell for a pre-defined period of time it MUST withdraw the label 276 mapping for the VC. 278 If an ingress LSR, R1, receives an AIS F5 OAM cell, fails to receive 279 a pre-defined number of the End-to-End loop OAM cells, or a physical 280 interface goes down, it MUST withdraw the label mappings for all VCs 281 associated with the failure. When a VC label mapping is withdrawn, 282 the egress LSR, R2, MUST generate AIS F5 OAM cells on the VC 283 associated with the withdrawn label mapping. In this mode it is very 284 useful to apply a unique group ID to each interface. In the case 285 where a physical interface goes down, a wild card label withdraw can 286 be sent to all LDP neighbors, greatly reducing the signaling response 287 time. 289 4.2.5. ILMI Support 291 An MPLS edge LSR MAY provide an ATM ILMI to the ATM edge switch. If 292 an ingress LSR receives an ILMI message indicating that the ATM edge 293 switch has deleted a VC, or if the physical interface goes down, it 294 MUST withdraw the label mappings for all VCs associated with the 295 failure. When a VC label mapping is withdrawn, the egress LSR SHOULD 296 notify its client of this failure by deleting the VC using ILMI. 298 4.3. Ethernet VLAN 300 The Ethernet frame will be encapsulated according to the procedures 301 in [12]. It should be noted that if the VLAN identifier is modified 302 by the egress LSR, according to the procedures outlined above, the 303 Ethernet spanning tree protocol might fail to work properly. If the 304 LSR detects a failure on the Ethernet physical port, or the port is 305 administratively disabled, it MUST withdraw the label mappings for 306 all VCs associated with the port. 308 4.4. Ethernet 310 The Ethernet frame will be encapsulated according to the procedures 311 in [12]. If the LSR detects a failure on the Ethernet physical port, 312 or the port is administratively disabled, the corresponding VC label 313 mapping MUST be withdrawn. 315 4.5. HDLC 317 HDLC frames are encapsulated according to the procedures in [7]. If 318 the MPLS edge LSR detects that the physical link has failed, or the 319 port is adminstratively disabled, it MUST withdraw the label mapping 320 that corresponds to the HDLC link. 322 4.6. PPP 324 PPP frames are encapsulated according to the procedures in [7]. If 325 the MPLS edge LSR detects that the physical link has failed, or the 326 port is adminstratively disabled, it MUST withdraw the label mapping 327 that corresponds to the PPP link. 329 5. LDP 331 The VC label bindings are distributed using the LDP downstream 332 unsolicited mode described in [1]. The LSRs will establish an LDP 333 session using the Extended Discovery mechanism described in [1, 334 section 2.4.2 and 2.5], for this purpose a new type of FEC element is 335 defined. The FEC element type is 128. [note1] Only a single VC FEC 336 element MUST be advertised per LDP VC label. The Virtual Circuit FEC 337 element, is defined as follows: 339 0 1 2 3 340 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 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | VC tlv |C| VC Type |VC info Length | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | Group ID | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | VC ID | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Interface parameters | 349 | " | 350 | " | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 - VC Type 355 A 15 bit quantity containing a value which represents the type of 356 VC. Assigned Values are: 358 VC Type Description 360 0x0001 Frame Relay DLCI 361 0x0002 ATM AAL5 VCC transport 362 0x0003 ATM transparent cell transport 363 0x0004 Ethernet VLAN 364 0x0005 Ethernet 365 0x0006 HDLC 366 0x0007 PPP 367 0x8008 CEM [8] 368 0x0009 ATM VCC cell transport 369 0x000A ATM VPC cell transport 371 - Control word bit (C) 373 The highest order bit (C) of the VC type is used to flag the 374 presence of a control word ( defined in [7] ) as follows: 375 bit 15 = 1 control word present on this VC. 376 bit 15 = 0 no control word present on this VC. 378 Please see the section "C Bit handling procedures" for further 379 explenation. 381 - VC information length 383 Length of the VC ID field and the interface parameters field in 384 octets. If this value is 0, then it references all VCs using the 385 specified group ID and there is no VC ID present, nor any 386 interface parameters. 388 - Group ID 390 An arbitrary 32 bit value which represents a group of VCs that is 391 used to create groups in the VC space. The group ID is intended 392 to be used as a port index, or a virtual tunnel index. To 393 simplify configuration a particular VC ID at ingress could be 394 part of the virtual tunnel for transport to the egress router. 395 The Group ID is very useful to send wild card label withdrawals 396 to remote LSRs upon physical port failure. 398 - VC ID 400 A non zero 32-bit connection ID that together with the VC type, 401 identifies a particular VC. 403 - Interface parameters 405 This variable length field is used to provide interface specific 406 parameters, such as interface MTU. 408 5.1. Interface Parameters Field 410 This field specifies interface specific parameters. When aplicable, 411 it MUST be used to validate that the LSRs, and the ingress and egress 412 ports at the edges of the circuit, have the necessary capabilities to 413 interoperate with each other. The field structure is defined as 414 follows: 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Parameter ID | Length | Variable Length Value | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Variable Length Value | 422 | " | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 The parameter ID is defined as follows: 426 Parameter ID Length Description 428 0x01 4 Interface MTU in octets. 429 0x02 4 Maximum Number of concatenated ATM cells. 430 0x03 up to 82 Optional Interface Description string. 431 0x04 4 CEM [8] Payload Bytes. 432 0x05 4 CEM options. 434 The Length field is defined as the length of the interface parameter 435 including the parameter id and length field itself. Processing of the 436 interface parameters should continue when encounting unknown interface 437 parameters and they MUST be silently ignored. 439 - Interface MTU 441 A 2 octet value indicating the MTU in octets. This is the Maximum 442 Transmission Unit, excluding encapsulation overhead, of the 443 egress packet interface that will be transmitting the 444 decapsulated PDU that is received from the MPLS network. This 445 parameter is applicable only to VC types 1, 2, 4, 5, 6, and 7, 446 and is REQUIRED for these VC types. If this parameter does not 447 match in both directions of a specific VC, that VC MUST NOT be 448 enabled. 450 - Maximum Number of concatenated ATM cells 452 A 2 octet value specifying the maximum number of concatenated ATM 453 cells that can be processed as a single PDU by the egress LSR. An 454 ingress LSR transmitting concatenated cells on this VC can 455 concatenate a number of cells up to the value of this parameter, 456 but MUST NOT exceed it. This parameter is applicable only to VC 457 types 3, 9, and 0x0a, and is REQUIRED for these VC types. This 458 parameter does not need to match in both directions of a specific 459 VC. 461 - Optional Interface Description string 463 This arbitrary, OPTIONAL, interface description string can be 464 used to send an administrative description text string to the 465 remote LSR. This parameter is OPTIONAL, and is applicable to all 466 VC types. The interface description parameter string length is 467 variable, and can be from 0 to 80 octets. 469 - Payload Bytes 471 A 2 octet value indicating the the number of TDM payload octets 472 contained in all packets on the CEM stream, from 48 to 1,023 473 octets. All of the packets in a given CEM stream have the same 474 number of payload bytes. Note that there is a possibility that 475 the packet size may exceed the SPE size in the case of an STS-1 476 SPE, which could cause two pointers to be needed in the CEM 477 header, since the payload may contain two J1 bytes for 478 consecutive SPEs. For this reason, the number of payload bytes 479 must be less than or equal to 783 for STS-1 SPEs. 481 - CEM Options. An optional 16 Bit value of CEM Flags. See [8] for 482 the definition of the bit values. 484 5.2. C Bit handling procedures 486 5.2.1. VC types for which the control word is REQUIRED 488 The Label Mapping messages which are sent in order to set up these 489 VCs MUST have c=1. When a Label Mapping message for a VC of one of 490 these types is received, and c=0, a Label Release MUST be sent, with 491 an "Illegal C-bit" status code. In this case, the VC will not come 492 up. 494 5.2.2. VC types for which the control word is NOT mandatory 496 If a system is capable of sending and receiving the control word on 497 VC types for which the control word is not mandatory, then each such 498 VC endpoint MUST be configurable with a parameter that specifies 499 whether the use of the control word is PREFERRED or NOT PREFERRED. 501 For each VC, there MUST be a default value of this parameter. This 502 specification does NOT state what the default value should. 504 If a system is NOT capable of sending and receiving the control word 505 on VC types for which the control word is not mandatory, then it 506 behaves as exactly as if it were configured for the use of the 507 control word to be NOT PREFERRED. 509 If a Label Mapping message for the VC has already been received, but 510 no Label Mapping message for the VC has yet been sent, then the 511 procedure is the following: 512 -i. If the received Label Mapping message has c=0, send a Label 513 Mapping message with c=0, and the control word is not used. 514 -ii. If the received Label Mapping message has c=1, and the VC is 515 locally configured such that the use of the control word is 516 preferred, then send a Label Mapping message with c=1, and 517 the control word is used. 518 -iii. If the received Label Mapping message has c=1, and the VC is 519 locally configured such that the use of the control word is 520 not preferred or the control word is not supported, then act 521 as if no Label Mapping message for the VC had been received 522 (i.e., proceed to the next paragraph). 524 If a Label Mapping message for the VC has not already been received 525 (or if the received Label Mapping message had c=1 and either local 526 configuration says that the use of the control word is not preferred 527 or the control word is not supported), then send a Label Mapping 528 message in which the c bit is set to correspond to the locally 529 configured preference for use of the control word. (I.e., set c=1 if 530 locally configured to prefer the control word, set c=0 if locally 531 configured to prefer not to use the control word or if the control 532 word is not supported). 534 The next action depends on what control message is next received for 535 that VC. The possibilities are: 536 -i. A Label Mapping message with the same c bit value as 537 specified in the Label Mapping message that was sent. VC 538 setup is now complete, and the control word is used if c=1 539 but not used if c=0. 540 -ii. A Label Mapping message with c=1, but the Label Mapping 541 message that was sent has c=0. In this case, ignore the 542 received Label Mapping message, and continue to wait for the 543 next control message for the VC. 544 -iii. A Label Mapping message with c=0, but the Label Mapping 545 message that was sent has c=1. In this case, send a Label 546 Withdraw message with a "Wrong c-bit" status code, followed 547 by a Label Mapping message that has c=0. VC setup is now 548 complete, and the control word is not used. 550 -iv. A Label Withdraw message with the "Wrong c-bit" status code. 551 Treat as a normal Label Withdraw, but do not respond. 552 Continue to wait for the next control message for the VC. 554 If at any time after a Label Mapping message has been received, a 555 corresponding Label Withdraw or Release is received, the action taken 556 is the same as for any Label Withdraw or Release that might be 557 received at any time. 559 If both endpoints prefer the use of the control word, this procedure 560 will cause it to be used. If either endpoint prefers not to use the 561 control word, or does not support the control word, this procedure 562 will cause it not to be used. If one endpoint prefers to use the 563 control word but the other does not, the one that prefers not to use 564 it is has no extra protocol to execute, it just waits for a Label 565 Mapping message that has c=0. 567 The following diagram illustrate the above procedures: 569 ------------------ 570 Y | Received Label | N 571 -------| Mapping Msg? |-------------- 572 | ------------------ | 573 | | 574 -------------- | 575 | | | 576 | | | 577 ------- ------- | 578 | C=0 | | C=1 | | 579 ------- ------- | 580 | | | 581 | | | 582 | ---------------- | 583 | | Control Word | N | 584 | | Capable? |----------- | 585 | ---------------- | | 586 | Y | | | 587 | | | | 588 | ---------------- | | 589 | | Control Word | N | | 590 | | Preferred? |---- | | 591 | ---------------- | | | 592 | Y | | | | 593 | | | | ---------------- 594 | | | | | Control Word | 595 | | | | | Preferred? | 596 | | | | ---------------- 597 | | | | N | Y | 598 | | | | | | 599 Send Send Send Send Send Send 600 C=0 C=1 C=0 C=0 C=0 C=1 601 | | | | 602 | | | | 603 ---------------------------------- 604 | If receive the same as sent, | 605 | VC setup is complete. If not: | 606 ---------------------------------- 607 | | | | 608 | | | | 609 ------------------- ----------- 610 | Receive | | Receive | 611 | C=1 | | C=0 | 612 ------------------- ----------- 613 | | 614 | | 615 Wait for the Send 616 next message Wrong C-Bit 617 | 618 | 619 Send Label 620 Mapping Message 621 with C=0 623 5.2.3. Status codes 625 RFC 3036 has a range of Status Code values which are assigned by IANA 626 on a First Come, First Served basis. These are in the range 627 0x20000000-0x3effffff [note 2]. The following new status codes are 628 defined: 630 0x20000001 "Illegal C-Bit" 631 0x20000002 "Wrong C-Bit" 633 5.3. LDP label Withdrawal procedures 635 As mentioned above the Group ID field can be used to withdraw all VC 636 labels associated with a particular group ID. This procedure is 637 OPTIONAL, and if it is implemented the LDP label withdraw message 638 should be as follows: the VC information length field is set to 0, 639 the VC ID field is not present, and the interface paramenters field 640 is not present. For the purpose of this document this is called the 641 "wild card withdraw procedure", and all LSRs implementing this design 642 are REQUIRED to accept such a withdraw message, but are not required 643 to send it. 645 The interface parameters field MUST NOT be present in any LDP VC 646 label withdrawal message or release message. A wildcard release 647 message MUST include only the group ID.A Label Release message 648 initiated from the imposition router must always include the VC ID. 650 5.4. Sequencing Considerations 652 In the case where the router considers the sequence number field in 653 the control word, it is important to note the following when 654 advertising labels 656 5.4.1. Label Mapping Advertisements 658 After a label has been withdrawn by the disposition router and/or 659 released by the imposition router, care must be taken to not re- 660 advertise (re-use) the released label until the disposition router 661 can be reasonably certain that old packets containing the released 662 label no longer persist in the MPLS network. 664 This precaution is required to prevent the imposition router from 665 restarting packet forwarding with sequence number of 1 when it 666 receives the same label mapping if there are still older packets 667 persisting in the network with sequence number between 1 and 32768. 668 For example, if there is a packet with sequence number=n where n is 669 in the interval[1,32768] travelling through the network, it would be 670 possible for the disposition router to receive that packet after it 671 re-advertises the label. Since the label has been released by the 672 imposition router, the disposition router SHOULD be expecting the 673 next packet to arrive with sequence number to be 1. Receipt of a 674 packet with sequence number equal to n will result in n packets 675 potentially being rejected by the disposition router until the 676 imposition router imposes a sequence number of n+1 into a packet. 677 Possible methods to avoid this is for the disposition router to 678 always advertise a different VC label, or for the disposition router 679 to wait for a sufficient time before attempting to re-advertised a 680 recently released label. This is only an issue when sequence number 681 processing at the disposition router is enabled. 683 5.4.2. Label Mapping Release 685 In situations where the imposition router wants to restart forwarding 686 of packets with sequence number 1, the router shall 1) Send to 687 disposition router a label mapping release, and 2) Send to 688 disposition router a label mapping request. When sequencing is 689 supported, advertisement of a vc label in response to a label mapping 690 request MUST also consider the issues discussed in 5.3.1 692 6. IANA Considerations 694 As specified in this document, a Virtual Circuit FEC element contains 695 the VC Type field. VC Type value 0 is reserved. VC Type values 1 696 through 10 are defined in this document. VC Type values 11 through 63 697 are to be assigned by IANA using the "IETF Consensus" policy defined 698 in RFC2434. VC Type values 64 through 127 are to be assigned by IANA, 699 using the "First Come First Served" policy defined in RFC2434. VC 700 Type values 128 through 32767 are vendor-specific, and values in this 701 range are not to be assigned by IANA. 703 As specified in this document, a Virtual Circuit FEC element contains 704 the Interface Parameters field, which is a list of one or more 705 parameters, and each parameter is identified by the Parameter ID 706 field. Parameter ID value 0 is reserved. Parameter ID values 1 707 through 5 are defined in this document. Parameter ID values 6 708 through 63 are to be assigned by IANA using the "IETF Consensus" 709 policy defined in RFC2434. Parameter ID values 64 through 127 are to 710 be assigned by IANA, using the "First Come First Served" policy 711 defined in RFC2434. Parameter ID values 128 through 255 are vendor- 712 specific, and values in this range are not to be assigned by IANA. 714 7. Security Considerations 716 This document does not affect the underlying security issues of MPLS. 718 8. Full Copyright Statement 720 Copyright (C) The Internet Society (2004). This document is subject 721 to the rights, licenses and restrictions contained in BCP 78 and 722 except as set forth therein, the authors retain all their rights. 724 This document and the information contained herein are provided on an 725 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 726 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 727 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 728 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 729 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 730 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 732 9. Intellectual Property Statement 734 The IETF takes no position regarding the validity or scope of any 735 Intellectual Property Rights or other rights that might be claimed to 736 pertain to the implementation or use of the technology described in 737 this document or the extent to which any license under such rights 738 might or might not be available; nor does it represent that it has 739 made any independent effort to identify any such rights. Information 740 on the procedures with respect to rights in RFC documents can be 741 found in BCP 78 and BCP 79. 743 Copies of IPR disclosures made to the IETF Secretariat and any 744 assurances of licenses to be made available, or the result of an 745 attempt made to obtain a general license or permission for the use of 746 such proprietary rights by implementers or users of this 747 specification can be obtained from the IETF on-line IPR repository at 748 http://www.ietf.org/ipr. 750 The IETF invites any interested party to bring to its attention any 751 copyrights, patents or patent applications, or other proprietary 752 rights that may cover technology that may be required to implement 753 this standard. Please address the information to the IETF at ietf- 754 ipr@ietf.org. 756 By submitting this Internet-Draft, I certify that any applicable 757 patent or other IPR claims of which I am aware have been disclosed, 758 or will be disclosed, and any of which I become aware will be 759 disclosed, in accordance with RFC 3668. 761 10. References 763 [1] "LDP Specification." L. Andersson, P. Doolan, N. Feldman, A. 764 Fredette, B. Thomas. January 2001. RFC3036 766 [2] ITU-T Recommendation Q.933, and Q.922 Specification for Frame 767 Mode Basic call control, ITU Geneva 1995 769 [3] "MPLS Label Stack Encoding", E. Rosen, Y. Rekhter, D. Tappan, G. 770 Fedorkow, D. Farinacci, T. Li, A. Conta. RFC3032 772 [4] "IEEE 802.3ac-1998" IEEE standard specification. 774 [5] American National Standards Institute, "Synchronous Optical 775 Network Formats," ANSI T1.105-1995. 777 [6] ITU Recommendation G.707, "Network Node Interface For The 778 Synchronous Digital Hierarchy", 1996. 780 [7] "Encapsulation Methods for Transport of Layer 2 Frames Over 781 MPLS", draft-martini-l2circuit-encap-mpls-06.txt ( Work in progress ) 783 [8] "SONET/SDH Circuit Emulation Service Over MPLS (CEM) 784 Encapsulation", draft-malis-sonet-ces-mpls-05.txt ( Work in progress 785 ) 787 [9] "Frame Based ATM over SONET/SDH Transport (FAST)," 2000. 789 [note1] FEC element type 128 is pending IANA approval. [note2] 790 Status codes assigment is pending IANA approval. 792 11. Author Information 794 Luca Martini 795 Cisco Systems, Inc. 796 9155 East Nichols Avenue, Suite 400 797 Englewood, CO, 80112 798 e-mail: lmartini@cisco.com 800 Nasser El-Aawar 801 Level 3 Communications, LLC. 802 1025 Eldorado Blvd. 803 Broomfield, CO, 80021 804 e-mail: nna@level3.net 806 Giles Heron 807 Tellabs 808 Abbey Place 809 24-28 Easton Street 810 High Wycombe 811 Bucks 812 HP11 1NT 813 UK 814 e-mail: giles.heron@tellabs.com 816 Dimitri Stratton Vlachos 817 Mazu Networks, Inc. 818 125 Cambridgepark Drive 819 Cambridge, MA 02140 820 e-mail: d@mazunetworks.com 822 Dan Tappan 823 Cisco Systems, Inc. 824 250 Apollo Drive 825 Chelmsford, MA, 01824 826 e-mail: tappan@cisco.com 828 Jayakumar Jayakumar, 829 Cisco Systems Inc. 830 225, E.Tasman, MS-SJ3/3, 831 San Jose, CA, 95134 832 e-mail: jjayakum@cisco.com 833 Alex Hamilton, 834 Cisco Systems Inc. 835 285 W. Tasman, MS-SJCI/3/4, 836 San Jose, CA, 95134 837 e-mail: tahamilt@cisco.com 839 Eric Rosen 840 Cisco Systems, Inc. 841 250 Apollo Drive 842 Chelmsford, MA, 01824 843 e-mail: erosen@cisco.com 845 Steve Vogelsang 846 Laurel Networks, Inc. 847 Omega Corporate Center 848 1300 Omega Drive 849 Pittsburgh, PA 15205 850 e-mail: sjv@laurelnetworks.com 852 John Shirron 853 Omega Corporate Center 854 1300 Omega Drive 855 Pittsburgh, PA 15205 856 Laurel Networks, Inc. 857 e-mail: jshirron@laurelnetworks.com 859 Toby Smith 860 Omega Corporate Center 861 1300 Omega Drive 862 Pittsburgh, PA 15205 863 Laurel Networks, Inc. 864 e-mail: tob@laurelnetworks.com 866 Andrew G. Malis 867 Tellabs 868 90 Rio Robles Dr. 869 San Jose, CA 95134 870 e-mail: Andy.Malis@tellabs.com 871 Vinai Sirkay 872 Vivace Networks, Inc. 873 2730 Orchard Parkway 874 San Jose, CA 95134 875 e-mail: sirkay@technologist.com 877 Vasile Radoaca 878 Nortel Networks 879 600 Technology Park 880 Billerica MA 01821 881 e-mail: vasile@nortelnetworks.com 883 Chris Liljenstolpe 884 Cable & Wireless 885 11700 Plaza America Drive 886 Reston, VA 20190 887 e-mail: chris@cw.net 889 Dave Cooper 890 Global Crossing 891 960 Hamlin Court 892 Sunnyvale, CA 94089 893 e-mail: dcooper@gblx.net 895 Kireeti Kompella 896 Juniper Networks 897 1194 N. Mathilda Ave 898 Sunnyvale, CA 94089 899 e-mail: kireeti@juniper.net