idnits 2.17.1 draft-rosen-mpls-lan-encaps-compar-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 390: '... routes. B MUST learn from frames w...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 90 has weird spacing: '...ave the same ...' == Line 92 has weird spacing: '...S label stack...' == Line 132 has weird spacing: '... The ethern...' == Line 133 has weird spacing: '...elds in the ...' == Line 134 has weird spacing: '... fields carry...' == (2 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1997) is 9651 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 section? '1' on line 582 looks like a reference -- Missing reference section? '2' on line 585 looks like a reference -- Missing reference section? '3' on line 588 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric C. Rosen, Cisco Systems, Inc. 3 Internet Draft Andre Fredette, Bay Networks, Inc. 4 Expiration Date: May 1998 Tony Li, Juniper Networks, Inc. 5 Keith McCloghrie, Cisco Systems, Inc. 6 Milan Merhar, Lucent Technologies 8 November 1997 10 Comparison of MPLS LAN Encapsulation Proposals 12 draft-rosen-mpls-lan-encaps-compar-00.txt 14 Status of this Memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 To learn the current status of any Internet-Draft, please check the 27 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 [1] describes how to encode an MPLS label stack as a ''shim'' between 35 the data link and network layer headers of a labeled frame, but [1] 36 does not require that this encoding be used to encode the top of the 37 label stack on LAN media. This document examines the alternative 38 encapsulations that have been proposed for LANs. One alternative is 39 to use the shim as the MPLS encapsulation on LAN interfaces [2]. 40 Another alternative is to encode the top label in the MAC header, 41 rather than in the shim [3]. We describe the implications of each 42 approach. 44 Table of Contents 46 1 Introduction ....................................... 2 47 2 Frame Size and Fragmentation ....................... 3 48 3 Time to Live ....................................... 4 49 4 Interactions with Installed Equipment .............. 4 50 4.1 MAC Address Filtering .............................. 4 51 4.2 Effect on 'Source Address Learning' in LAN Bridges . 6 52 4.3 Size of Bridge Forwarding Tables ................... 8 53 4.4 Environments with Mixed Bridging/Routing ........... 8 54 4.5 Uniqueness of Labels ............................... 10 55 4.6 Protocol Layering .................................. 10 56 5 Hardware Implementation ............................ 11 57 6 Leveraging the ATM Encapsulation ................... 11 58 7 Summary ............................................ 12 59 8 Authors' Addresses ................................. 13 60 9 Bibliography ....................................... 14 62 1. Introduction 64 In [1], there is a proposal for encoding an MPLS label stack as a 65 "shim" between the data link layer header and the network layer 66 header. This is sometimes referred to as the "generic" encapsulation 67 of MPLS messages, since it is independent of the underlying data 68 link. 70 It has been proposed to use the generic encapsulation on PPP 71 interfaces [1] and on LAN interfaces [2]. In both cases, the data 72 link layer header would have a protocol codepoint which identifies 73 the frame as containing an MPLS packet. 75 In the proposal of [2], the data link layer and MAC layer would 76 remain unaffected, with MPLS being, from the data link's point of 77 view, just another higher layer. In this draft, we will refer to 78 this proposal as the "MPLS-SHIM proposal", or just "MPLS-SHIM". 80 In the proposal of [3], the top of the label stack is encoded 81 directly into the MAC layer header. It is proposed to carry the top 82 entry of the label stack in the field of the MAC layer header which 83 is conventionally used to hold the MAC Destination Address. That is, 84 the MAC Destination Address field would be redefined as follows: 86 +--------------------+------------+---------+-----------+ 87 | OUI Prefix (24) | Label (20) | CoS (3) | Stack (1) | 88 +--------------------+------------+---------+-----------+ 90 where "Label", "CoS", and "Stack" have the same meaning as defined 91 in [1]. The 24-bit OUI prefix is used to indicate that this 48-bit 92 field contains an MPLS label stack entry, rather than a real MAC 93 address. In this draft,we will refer to this proposal as the "MPLS- 94 MAC proposal", or just "MPLS-MAC". 96 2. Frame Size and Fragmentation 98 An MPLS-MAC frame carrying the same information as an MPLS-SHIM frame 99 is four bytes shorter. If a frame needs to carry one label, and the 100 original, unlabeled frame is already at the maximum size (MTU) for 101 the LAN, MPLS-SHIM will require the frame to be fragmented, while 102 MPLS-MAC will not. If the frame needs to carry two or more labels, 103 however, both schemes require fragmentation. Thus in either case, 104 MPLS must have procedures for fragmenting labeled packets; these 105 procedures can be found in [1]. 107 The use of shorter packets on the LAN may reduce the number of 108 packets which need to get fragmented. However, as is discussed in 109 [1], packets would in fact never need to get fragmented unless they 110 came from one of the relatively small number of end systems which (a) 111 do not support Path MTU discovery, and (b) emit 1500-byte IP 112 datagrams even when the source and destination are not on the same 113 subnet (normally this implies that the source and destination have 114 the same classful network number). Thus the difference between the 115 amount of fragmentation caused by MPLS-SHIM and the amount caused by 116 MPLS-MAC is quite small. 118 3. Time to Live 120 Unlike MPLS-SHIM, MPLS-MAC does not propose to carry an 8-bit TTL 121 value in the top label stack entry. However, doing so is not ruled 122 out by the use of the MAC header to carry the label stack entry. For 123 example, if MPLS were assigned 256 OUI prefixes, the TTL could 124 certainly be encoded therein. Whether this particular technique is 125 practical, given IEEE fees and policies with respect to OUI 126 assignment, is certainly arguable. The point though is that the 127 presence or absence of TTL is not a fundamental difference between 128 MPLS-SHIM and MPLS-MAC. 130 4. Interactions with Installed Equipment 132 The ethernet and IEEE 802.3 data link protocols assume that the 133 "address" fields in the frame headers contain MAC addresses. In 134 MPLS-MAC, these fields carry a completely different kind of 135 information, with completely different semantics. On a LAN in 136 which MPLS-MAC is in use, there is not one data link protocol being 137 used, but two: 139 - The existing data link layer protocol (ethernet or 802.3), which 140 continues to be used for unlabeled packets. 142 - A new data link layer protocol (specified, e.g., in [3]) for 143 carrying labeled packets. 145 Existing LAN networks, existing LAN bridges and switches, existing 146 LAN troubleshooting and administrative tools and procedures, have all 147 been designed around the assumption that all frames on the LAN use 148 certain data link layer protocols. To add a new data link layer 149 protocol which assigns different semantics to the addressing fields 150 is extremely likely to cause problems. We cannot hope to exhibit all 151 such problems here, but we can certainly point out a few of them. 153 4.1. MAC Address Filtering 155 Ordinarily, a LAN device (such as a host or a router) does not 156 receive a frame unless the frame's MAC Destination Address field ("DA 157 field", or just "DA") satisfies one of the following conditions: 159 - contains the 48-bit MAC address of the device itself, or 161 - contains the broadcast address or a multicast address. 163 Bridges and switches, on the other hand, run in "promiscuous mode"; 164 they receive all frames. 166 In MPLS-MAC, if one needs to send a labeled packet to an LSR, one 167 does not put the LSR's MAC address in the DA; rather, one puts in one 168 of the labels assigned and distributed by the LSR. So how does the 169 LSR receive the frame? 171 In general, LAN NICs can be programmed with a small number of unicast 172 MAC addresses (often only one, certainly less than a dozen) which 173 they will receive. That is, the number of unicast addresses which 174 can be programmed into a LAN NIC is MUCH smaller than the number of 175 labels which an LSR can assign and distribute. Therefore, if one is 176 using MPLS-MAC, one must operate every LSR LAN interface in 177 promiscuous mode. 179 Running in promiscuous mode can be quite costly, especially if the 180 LAN is heavily loaded, as every frame must be examined. Generally 181 one does not run a system in promiscuous mode unless it has been 182 explicitly designed to run in that mode (e.g., is a bridge or a 183 switch). 185 It must be possible however to run MPLS in devices which attach to a 186 LAN but which are not bridges or switches, such as routers. Using 187 promiscuous mode for LSRs on LANs may have significant additional 188 development costs on new equipment, and may not be practical on 189 installed systems. 191 What if the labels were encoded not as unicast addresses, but as 192 multicast addresses? The same problem occurs, in that most LAN NICs 193 cannot be programmed to receive ONLY multicasts whose DA fields 194 contain one of a specified set of values. When these NICs are 195 programmed to receive a particular multicast address, they receive 196 all frames with that address in the DA, but they also receive frames 197 with other multicast DAs, and software must be used to filter out the 198 undesired frames. The more multicast addresses one programs into the 199 NIC, the more undesired multicast addresses one will receive. Some 200 NICs could even end up receiving all multicast frames. If the 201 traffic on the LAN large consists largely of labeled frames, this is 202 essentially no different than running in promiscuous mode, and may be 203 prohibitively expensive. 205 4.2. Effect on 'Source Address Learning' in LAN Bridges 207 Suppose it is desired to send a labeled packet from one LSR to 208 another, where both are on the same 802.1D extended LAN (bridged 209 Ethernet), and where traffic from one to the other must traverse one 210 or more bridges. The LSRs do not recognize the presence of the 211 bridges; 802.1D defines transparent bridges. Since the DA contains a 212 label instead of the MAC address of the target LSR, the bridges will 213 flood such frames until such time as their forwarding databases have 214 entries which are keyed by label values, where those label values are 215 used as if they were MAC addresses. The (bridged) LAN would have a 216 serious performance problem if it were necessary to flood all such 217 frames. 219 Bridges populate their forwarding databases by "learning". They 220 learn which MAC addresses are reachable over which ports by looking 221 at the MAC Source Address fields (SA fields, or just "SA") in frames 222 which they see on the ethernets to which they are attached. This 223 mapping between MAC addresses and ports is maintained in a forwarding 224 table entry. These entries are aged out after some period (a 225 configurable parameter with a default of 300 seconds) of non-use. 227 Thus to enable MPLS-MAC to be used in a bridged LAN environment, it 228 is necessary to send frames which carry labels in their SA fields, as 229 well as in their DA fields. In order to keep the bridge forwarding 230 tables properly populated, an LSR must transmit, for each label it is 231 using, (or more accurately, for each label/TTL/Cos combination) at 232 least one frame every aging period which has that label value in its 233 SA field. Failure to do this would result in the flooding of labeled 234 frames along the spanning tree, which would have a significant 235 detrimental impact on LAN performance. 237 There are a number of different ways to do this, but all are 238 problematical: 240 - When one sends the control message (an LDP message) which 241 distributes a particular label, one can put that label in the SA 242 field of the control message. However, this requires that a 243 separate control message be sent for each label, and that each 244 such message be refreshed every aging period. Given a large 245 number of labels, this creates the need for high control 246 overhead. It also requires that all the LSRs and bridges be 247 configured with the same aging period. 249 - It is sometimes suggested that some new protocol, such as GARP, 250 be used for populating the bridge forwarding tables with labels. 251 However, the existing installed base of bridges does not support 252 GARP. Many existing bridges cannot be upgraded to support GARP. 254 This would have a significant negative impact on the ability to 255 deploy MPLS in existing bridged environments. 257 - As an LSR sends ordinary data frames out a particular interface, 258 it could cycle through the list of labels it has distributed out 259 that interface, writing one such label into the SA of each frame. 260 This does not create any extra overhead on the ethernet itself, 261 but does create additional processing overhead for each 262 transmitted frame (i.e., additional processing in the "fast 263 path"). It also impacts certain administrative tools and 264 procedures: 266 * When one is having LAN ethernet problems, one frequently 267 troubleshoots by using a sniffer to find the frames that are 268 causing problems. Then one looks at the SA of the frames to 269 find the system that is at fault, so that the system can be 270 located, examined and repaired. If the SA is overwritten 271 with a label, this sort of troubleshooting technique can no 272 longer be used. 274 * Administrators frequently filter the SA values at hub and 275 switch ports, in order to ensure that only specific systems 276 can access portions of the network. If the SA is overwritten 277 with a label, this sort of filtering can no longer be done, 278 and a valuable security tool is removed from the 279 administrator's portfolio. 281 * A variety of automated topology discovery tools depend on the 282 SA of a frame containing the actual MAC address of the system 283 which originated the frame. If the SA is overwritten with a 284 label, these tools will no longer produce correct results. 286 To summarize this section: 288 - Since MPLS-SHIM does not alter the use of the SA and DA, it has 289 no effect on the source address learning procedures, or upon 290 tools which examine the SA. 292 - MPLS-MAC must include some sort of "source address spoofing" 293 procedure so that existing bridges do not flood all labeled 294 packets down the spanning tree. If the SA is overwritten in data 295 frames, there are issues of compatibility with existing tools. 296 If the SA is overwritten in control frames, additional overhead 297 is required. 299 4.3. Size of Bridge Forwarding Tables 301 In many large bridged LANs, the bridges operate with forwarding 302 tables that are very nearly full to their maximum size, containing 303 just the actual MAC addresses of systems that are on the bridged LAN. 304 There simply may not be enough space in the bridge forwarding tables 305 to accommodate labels as well as MAC addresses, especially if the 306 number of labels in use in the LAN is large. 308 If the table size overflows, packets with DA field values that did 309 not make it into the table will get flooded along the spanning tree. 310 That is, MPLS-MAC could result in many packets, labeled or unlabeled, 311 getting flooded along the spanning tree. 313 One could of course encode the labels as if they were "multicast 314 addresses"; this would keep them out of bridge forwarding tables 315 (unless the bridge has a VLAN implementation which keeps multicast 316 addresses in the same forwarding table as unicast addresses). While 317 this would prevent the table size from increasing, the cost would be 318 that all labeled packets get flooded along the spanning tree. 320 Any time frames need to get flooded along the spanning tree, there is 321 a significant degradation in LAN performance, which affects both 322 labeled and unlabeled frames. 324 4.4. Environments with Mixed Bridging/Routing 326 Consider the following topology (which is part of a larger topology): 328 RI1 RX1 329 | | 330 -----------------------------LAN1 331 | | 332 RI2 B RX2 333 | | | 334 LAN2 ------------------------------- 336 In this topology: 338 - There are two LANs, LAN1 and LAN2. 340 - B is a conventional bridge connecting them. 342 - B is configured to filter (i.e., discard) IP packets, but to pass 343 packets of other protocols. 345 - LAN1 and LAN2 are both in the spanning tree. 347 - All the R systems are LSRs running IP routing: 349 * RI1, RX1, and RI2 are IP routing neighbors. 351 * RI2 and RX2 are IP routing neighbors. 353 - There is an LDP connection between every pair of IP routing 354 neighbors. 356 - RX1 and RX2 are LSRs running IPX routing in addition to IP 357 routing. They are NOT IP routing neighbors, but they ARE IPX 358 routing neighbors. 360 - There is an LDP connection between every pair of IPX routing 361 neighbors. 363 This topology represents a fairly common situation in which IP is 364 being routed between two LANs, but IPX (for example) is being 365 bridged. 367 Since RI1 and RX2, for example, are NOT in the same broadcast domain 368 with respect to IP (and with respect to the Label Distribution 369 Protocol, LDP, which sits on top of IP), there is nothing to stop 370 them from assigning the same label. That is, there is no way they 371 can coordinate their label assignments. Suppose L is a label which 372 they both use. Then each will generate frames with L in the MPLS-MAC 373 Source Address field. This means that bridge B will "learn" that L 374 is located on each of the two LANs. 376 Suppose that RX1 sends a frame with L in the MAC Destination Address 377 field, intending the frame for RI1. There is no way to prevent B 378 from relaying that frame to LAN2, where it will be received by RX2. 379 This causes unintended packet duplication. RX2 will of course 380 misinterpret the frame, but eventually that frame will reach a point 381 where it gets unlabeled, and forwarded according to the IP address. 382 If the packet makes it back to RX1 somehow, we have created a loop. 383 (Though even in the absence of a loop, the packet duplication is bad 384 enough.) 386 One might think that this problem could be avoided by telling B not 387 to learn from frames with labels in the SA. But remember that RX1 388 and RX2 have an LDP connection between them, and each will be 389 distributing labels to the other, where the labels correspond to IPX 390 routes. B MUST learn from frames with labels in the SA, or else the 391 labeled IPX frames will not be passed from one LAN to the other. 393 4.5. Uniqueness of Labels 395 In MPLS-SHIM, there is no need for the LSRs on a LAN to coordinate 396 their use of labels; each label has only local significance. In 397 MPLS-MAC, the set of labels that can be used on a LAN must be 398 partitioned, and each LSR on the LAN must be assigned a distinct set 399 of labels which it can use. The reason is that the labels will 400 appear in the SA field, and bridge learning presupposes that the SA 401 field contains a value which is unique throughout the LAN. 403 The need to partition the set of labels this way imposes scaling 404 limitations, either in the number of LSRs that can exist on the LAN, 405 or the number of labels that each can use. 407 As LSRs are added to or removed from the LAN, it will be necessary to 408 change the way the labels are partitioned, and/or the way the labels 409 are assigned to particular LSRs. This may result in periods of time 410 during which labels are not unique throughout the LAN. This can have 411 a negative effect on bridge learning, causing additional flooding of 412 packets, as well as packet duplication and looping. 414 In the section 4.4, we exhibited a realistic scenario in which MPLS- 415 MAC can cause packet duplication and/or looping to occur, even though 416 everything is properly configured and operating correctly. It is 417 also worth considering the effects if the coordination procedures for 418 partitioning labels were to fail. The result could be uncontrollable 419 packet duplication and/or looping. Distributed coordination 420 procedures like this have certainly been known to fail in practice. 422 4.6. Protocol Layering 424 A fundamental design approach that has aided the specification and 425 deployment of new networking protocols is the maintenance of protocol 426 layer separation. When this design approach is followed, lower 427 layers can be reused as is. This enables one to take advantage of 428 the many years of testing and debugging of the lower layers, and it 429 minimizes the amount of new work that must be done, and new 430 alternatives that must be considered. 432 MPLS-SHIM maintains this layered approach. MPLS-MAC overloads and 433 changes the semantics of the data link layer, by stealing fields from 434 the data link header and assigning them semantics which are different 435 than the semantics which the data link layer assigns them. In 436 section 4, we have given several examples of how this overloading can 437 cause problems that may not have been foreseen. Even if it is 438 possible to consider each such problem one at a time and develop a 439 fix, the risk is high that some problems will go undiscovered until 440 the protocol is deployed in some unforeseen way. 442 5. Hardware Implementation 444 An important consideration is the ability to implement an LSR out of 445 standard hardware. It is clear that MPLS-SHIM, if implemented in 446 hardware, would require hardware that differs significantly from that 447 in standard LAN switches and bridges. MPLS requires that the top 448 label change each time a transit frame is switched. For MPLS-SHIM, 449 the Destination Address must also match the address of the next LSR 450 in the path, so at every hop at least the Destination Address and the 451 top label would change. 453 Similarly, MPLS-MAC, if implemented in hardware, would require 454 hardware that replaced the Destination Address field every time a 455 transit labelled packet were switched. Replacing the Destination 456 Address is not a function of either existing 802.1D bridges or the 457 newer 802.1p and 802.1Q bridges. 459 MPLS-MAC also requires that the MAC Source Address field be 460 overwritten as packets pass through (see section 4). This is another 461 function that does not exist in current bridges/switches, and is not 462 envisioned to exist in future bridges/switches. 464 It does not appear that there is any way to use standard LAN 465 switching/bridging hardware to provide MPLS functionality, regardless 466 of the proposal adopted. 468 6. Leveraging the ATM Encapsulation 470 The MPLS encoding for ATM is rather analogous to the MPLS-MAC 471 procedures. In MPLS over ATM, the top of the stack is encoded in the 472 VPI/VCI field of the AAL5 cell header, and processed by standard ATM 473 switching hardware. Shouldn't it be possible to do the same thing 474 for LANs? 476 The functionality provided by MPLS is very similar to the 477 functionality provided by the ATM "forwarding plane". Both sets of 478 procedures are based on the lookup of a "label", and the replacement 479 of the label by another label before forwarding. Both the MPLS label 480 and the AAL5 VPI/VCI have the the semantics of a "connection" 481 identifier. Thus it is very easy to map MPLS functionality onto ATM 482 forwarding plane functionality, by mapping the MPLS label swap 483 directly to ATM's VPI/VCI replacement. MPLS does not change the 484 semantics of any of the fields used by the ATM forwarding plane. 486 However, the semantics of a MAC address field is that of an "address" 487 which identifies either a unique physical device, or a unique virtual 488 device within one particular physical device. In either case, this 489 is expected to be a globally unique mapping. This is very different 490 than the semantics of an MPLS label, which is an identifier having 491 only local significance. As we have shown, the forwarding 492 functionality of LAN switches is very different than the forwarding 493 functionality of MPLS, as no LAN address replacement operation exists 494 which is equivalent to the VPI/VCI replacement in ATM. So it does 495 not appear to be possible to map MPLS functionality directly into LAN 496 switching functionality. 498 7. Summary 500 - Frame Size 502 MPLS-MAC generates frames which are four bytes shorter than those 503 generated by MPLS-SHIM. 505 - Time to Live 507 Although MPLS-MAC, as proposed in [3], does not have a TTL field, 508 such a field could added; the handling of TTL is not a 509 fundamental difference between the proposals. 511 - Installed Equipment 513 * MPLS-MAC requires ALL LSRS on a LAN to run in promiscuous 514 mode; MPLS-SHIM does not. Running in promiscuous mode may 515 have a significant performance impact. 517 * MPLS-MAC causes a large increase in the size of the 518 forwarding tables in existing bridges/switches. MPLS-SHIM 519 does not. If the maximum forwarding table size is reached, 520 flooding down the spanning tree results, reducing the 521 effective forwarding capacity for both MPLS and non-MPLS 522 traffic. 524 * MPLS-SHIM does not overwrite the SA. MPLS-MAC does. This 525 has an effect on source address learning in existing bridges. 526 The procedures introduced to compensate for this effect may 527 impact the use of existing administrative tools, or may cause 528 extra overhead. It also appears that such procedures will 529 not produce correct results in LANs with mixed 530 bridging/routing. 532 * MPLS-SHIM maintains protocol layering, allowing the LAN data 533 link protocol to be used without changes. MPLS-MAC overloads 534 fields of the LAN data link protocol by assigning them new 535 semantics, thereby introducing significant risk of additional 536 unforeseen problems. 538 - Hardware Implementation 540 Neither MPLS-SHIM nor MPLS-MAC enable one to implement MPLS on 541 standard (or soon-to-be-standard) bridging/switching hardware. 543 8. Authors' Addresses 545 Eric C. Rosen 546 Cisco Systems, Inc. 547 250 Apollo Drive 548 Chelmsford, MA, 01824 549 E-mail: erosen@cisco.com 551 Andre N. Fredette 552 Bay Networks, Inc. 553 3 Federal St. 554 Billerica, MA 01821 555 Phone: (978) 916-8524 556 email: fredette@baynetworks.com 558 Tony Li 559 Juniper Networks, Inc. 560 385 Ravendale Dr. 561 Mountain View, CA 94043 562 Email: tli@juniper.net 563 Voice: +1 650 526 8006 564 Fax: +1 650 526 8001 566 Keith McCloghrie 567 Cisco Systems, Inc. 568 170 Tasman Drive 569 San Jose, CA, 95134 570 E-mail: kzm@cisco.com 572 Milan J. Merhar 573 Lucent Technologies 574 300 Baker Ave. 575 Concord, MA, 01742-2168 576 Voice: (978) 287-2841 577 Fax: (978) 287-2810 578 E-mail: milan@lucent.com 580 9. Bibliography 582 [1] "MPLS Label Stack Encoding," draft-ietf-mpls-label-encaps-00.txt, 583 Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, Conta 585 [2] "MPLS Label Stack Encoding on LAN Media", draft-rosen-mpls-lan- 586 encaps-00.txt, Rosen, Rekhter, Tappan, Farinacci, Fedorkow, Li, Conta 588 [3] "Labels for MPLS over LAN Media", draft-srinivasan-mpls-lans- 589 label-00.txt, Bussiere, Esaki, Ghanwani, Matsuzawa, Pace, Srinivasan.