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