idnits 2.17.1 draft-ietf-trill-prob-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 5, 2009) is 5530 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL WG J. Touch 2 Internet Draft USC/ISI 3 Intended status: Informational R. Perlman 4 Expires: September 2009 Sun 5 March 5, 2009 7 Transparent Interconnection of Lots of Links (TRILL): 8 Problem and Applicability Statement 9 draft-ietf-trill-prob-06.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 This document may contain material from IETF Documents or IETF 17 Contributions published or made publicly available before November 18 10, 2008. The person(s) controlling the copyright in some of this 19 material may not have granted the IETF Trust the right to allow 20 modifications of such material outside the IETF Standards Process. 21 Without obtaining an adequate license from the person(s) controlling 22 the copyright in such materials, this document may not be modified 23 outside the IETF Standards Process, and derivative works of it may 24 not be created outside the IETF Standards Process, except to format 25 it for publication as an RFC or to translate it into languages other 26 than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on September 5, 2009. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 Current IEE 802.1 LANs use spanning tree protocols that have a number 60 of challenges. These protocols need to strictly avoid loops, even 61 temporary ones, during route propagation, because of the lack of 62 header loop detection support. Routing tends not to take full 63 advantage of alternate paths, or even non-overlapping pairwise paths 64 (in the case of spanning trees). This document addresses these 65 concerns and suggests that they can be addressed by applying modern 66 network layer routing protocols at the link layer. This document 67 assumes that solutions would not address issues of scalability beyond 68 that of existing IEEE 802.1 bridged links, but that a solution would 69 be backward compatible with 802.1, including hubs, bridges, and their 70 existing plug-and-play capabilities. 72 Table of Contents 74 1. Introduction...................................................3 75 2. The TRILL Problem..............................................4 76 2.1. Inefficient Paths.........................................4 77 2.2. Multipath Forwarding......................................6 78 2.3. Convergence and Safety....................................7 79 2.4. Stability of IP Multicast Optimization....................7 80 2.5. Other Ethernet Protocol Extensions........................8 81 2.6. Problems Not Addressed....................................9 82 3. Desired Properties of Solutions to TRILL......................10 83 3.1. No Change to Link Capabilities...........................10 84 3.2. Zero Configuration and Zero Assumption...................11 85 3.3. Forwarding Loop Mitigation...............................11 86 3.4. Spanning Tree Management.................................12 87 3.5. Multiple Attachments.....................................12 88 3.6. VLAN Issues..............................................12 89 3.7. Operational Equivalence..................................13 90 3.8. Optimizations............................................13 91 3.9. Internet Architecture Issues.............................14 93 4. Applicability.................................................15 94 5. Security Considerations.......................................15 95 6. IANA Considerations...........................................16 96 7. Acknowledgments...............................................16 97 8. References....................................................16 98 8.1. Normative References.....................................16 99 8.2. Informative References...................................16 101 1. Introduction 103 Conventional Ethernet networks - known in the Internet as Ethernet 104 link subnets - have a number of attractive features, allowing hosts 105 and routers to relocate within the subnet without requiring 106 renumbering and are automatically configuring. The basis of the 107 simplicity of these subnets is the spanning tree, which although 108 simple and elegant, can have substantial limitations. With spanning 109 trees, the bandwidth across the subnet is limited because traffic 110 flows over a subset of links forming a single tree - or, with the 111 latest version of the protocol and significant additional 112 configuration, over a small number of superimposed trees. The oldest 113 version of the spanning tree protocol can converge slowly when there 114 are frequent topology changes. 116 The alternative to an Ethernet link subnet is often a network subnet. 117 Network subnets can use link-state routing protocols that allow 118 traffic to traverse least-cost paths rather than being aggregated on 119 a spanning tree backbone, providing higher aggregate capacity and 120 more resistance to link failures. Unfortunately, IP - the dominant 121 network layer technology - requires that hosts be renumbered when 122 relocated in different network subnets, interrupting network (e.g., 123 tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are 124 in progress during the transition. 126 It is thus useful to consider a new approach that combines the 127 features of these two existing solutions, hopefully retaining the 128 desirable properties of each. Such an approach would develop a new 129 kind of bridge system that was capable of using network-style 130 routing, while still providing Ethernet service. It allows reuse of 131 well-understood network routing protocols to benefit the link layer. 133 This document describes the challenge of such a combined approach. 134 This problem is known as "Transparent Interconnection of Lots of 135 Links" or "TRILL". The remainder of this document makes minimal 136 assumptions about a solution to TRILL. 138 2. The TRILL Problem 140 Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted 141 pair with hubs to twisted pair with switches, becoming increasingly 142 simple to wire and manage. Each level has corresponding topology 143 restrictions; thicknet is inherently linear, whereas thinnet and hub- 144 connected twisted pair have to be wired as a tree. Switches, added in 145 IEEE 802.1D, allow network managers to avoid thinking in trees, where 146 the spanning tree protocol finds a valid tree automatically; 147 unfortunately, this additional simplicity comes with a number of 148 associated penalties [Pe99]. 150 The spanning tree often results in inefficient use of the link 151 topology; traffic is concentrated on the spanning tree path, and all 152 traffic follows that path even when other more direct paths are 153 available. The addition in IEEE 802.1Q of support for multiple 154 spanning trees helps a little, but the use of multiple spanning trees 155 requires additional configuration, the number of trees is limited, 156 and these defects apply within each tree regardless. The spanning 157 tree protocol reacts to certain small topology changes with large 158 effects on the reconfiguration of links in use. Each of these aspects 159 of the spanning tree protocol can cause problems for current link 160 layer deployments. 162 2.1. Inefficient Paths 164 The Spanning Tree Protocol (STP) helps break cycles in a set of 165 interconnected bridges, but it also can limit the bandwidth among 166 that set and cause traffic to take circuitous paths. For example, in 167 a set of N nodes that are interconnected pair-wise along a ring, 168 spanning tree will disable one physical link so that connectivity is 169 loop free. This will cause traffic between the pair of nodes 170 connected by that disabled link to have to go N-1 physical hops 171 around the entire remainder of the ring rather than take the most 172 efficient single hop path. Using modern routing protocols with such a 173 topology, no traffic should have to go more than N/2 hops. 175 For another example, consider the network shown in Figure 1, which 176 shows a number of bridges and their interconnecting links. End hosts 177 and routers are not shown; they would connect to the bridges that are 178 shown, labeled A-H. Note that the network shown has cycles that would 179 cause packet storms if hubs (repeaters) were used instead of 180 spanning-tree-capable bridges. One possible spanning tree is shown by 181 double lines. 183 A 184 // \ C 185 // \ / \\ D 186 // \ / \\ // 187 B=======H===== E 188 \ // || 189 \ // || 190 \ // || 191 G----------F 193 Figure 1 Bridged subnet with spanning tree shown 195 The spanning tree limits the capacity of the resulting subnet. Assume 196 that the links are 100 Mbps. Figure 2 shows how traffic from hosts on 197 A to hosts on C goes via the spanning tree path A-B-H-E-C (links 198 replaced with '1' in the figure); traffic from hosts on G to F go via 199 the spanning three path G-H-E-F (links replaced by '2' in the 200 figure). The link H-E is shared by both paths (alternating '1's and 201 '2's), resulting in an aggregate capacity for both A..C and G..F 202 paths of a total of 100 Mbps. 204 A 205 1 C 206 1 1 207 1 1 208 B1111111H121212E 209 2 2 210 2 2 211 2 2 212 G F 214 Figure 2 Traffic from A..C (1) and G..F (2) share a link 216 If traffic from G to F were to go directly using full routing, e.g., 217 from G-F, both paths could have 100 Mbps each, and the total 218 aggregate capacity could be 200 Mbps (Figure 3). In this case, the H- 219 F link carries only A-C traffic ('1's) and the G-F traffic ('2's) is 220 more direct. 222 A 223 1 C 224 1 1 225 1 1 226 B1111111H111111E 228 G2222222222F 230 Figure 3 Traffic from A..C (1) and G..F (2) with full routing 232 There are a number of features of modern layer 3 routing protocols 233 which would be beneficial if available at layer 2, but which cannot 234 practically be integrated into the spanning tree system such as 235 multipath routing discussed in Section 2.2 below. Layer 3 routing 236 typically optimizes paths between pairs of endpoints based on a cost 237 metric, conventionally based on bandwidth, hop count, latency, and/or 238 policy measures. 240 2.2. Multipath Forwarding 242 The discussion above assumes that all traffic flowing from one point 243 to another follows a single path. Spanning tree reduces aggregate 244 bandwidth by forcing all such paths onto one tree, while modern 245 routing causes such paths to be selected based on a cost metric. 246 However, extensions to modern routing protocols enable even greater 247 aggregate bandwidth by permitting traffic flowing from one end point 248 to another to be sent over multiple, typically equal cost, paths. 249 (Traffic sent over different paths will generally encounter different 250 delays and may be re-ordered with respect to traffic on another path. 251 Thus traffic must be divided into flows, such that re-ordering of 252 traffic between flows is not significant, and those flows allocated 253 to paths.) 255 Multipathing typically spreads the traffic more evenly over the 256 available physical links. The addition of multipathing to a routed 257 network would typically result in only a small improvement in 258 capacity for a network with roughly equal traffic between all pairs 259 of nodes, because in that situation traffic is already fairly well 260 dispersed. Conversely, multipathing can produce a dramatic 261 improvement in a routed network where the traffic between a small 262 numbers of pairs of nodes dominates, because such traffic can - under 263 the right circumstances - be spread over multiple paths that might 264 otherwise be lightly loaded. 266 2.3. Convergence and Safety 268 The spanning tree is dependent on the way a set of bridges are 269 interconnected, i.e., the link layer topology. Small changes in this 270 topology can cause large changes in the spanning tree. Changes in the 271 spanning tree can take time to propagate and converge, especially for 272 older versions of the STP protocol. 274 One possible case occurs when one of the branches connected to the 275 root bridge fails, causing a large number of ports to block and 276 unblock before the network reconverges [Me04]. Consider a ring with a 277 stub as shown in Figure 4. 279 R----A----B----C----D----E 280 | | 281 +-----F-----G-------+ 282 Figure 4 Ring with poor convergence under reconfiguration 284 If A is the root bridge, then the paths A->B->C->D and A->F->G->E are 285 the two open paths, while the D->E link is blocked. If the A->B link 286 fails, then E must unblock its port to D for traffic to flow again, 287 but it may require recomputation of the entire tree through BPDUs 288 (Bridge PDUs). Even worse, if R is root and R or the A-R connection 289 fails, BPDU updates related to the old and new root can lead to a 290 brief count-to-infinity event, and, if RSTP (Rapid Spanning Tree 291 Protocol) is in use, can delay convergence for a few seconds. The 292 original IEEE 802.1 spanning tree protocol can impose 30-second 293 delays in re-establishing data connectivity after a topology change 294 to be sure a new topology has stabilized and been fully propagated. 296 The spanning tree protocol is inherently global to an entire layer 2 297 subnet; there is no current way to contain, partition, or otherwise 298 factor the protocol into a number of smaller, more stable subsets 299 that interact as groups. Contrast this with Internet routing, which 300 includes both intradomain and interdomain variants, split to provide 301 exactly that containment and scalability within a domain while 302 allowing domains to interact freely independent of what happens 303 within a domain. 305 2.4. Stability of IP Multicast Optimization 307 Although it is a layer violation, it is common for high end bridges 308 to snoop on IP multicast control messages for the purpose of 309 optimizing the distribution of IP multicast data and of those control 310 messages [RFC4541]. 312 When such snooping and optimization is performed by spanning tree- 313 based bridges, it done at each bridge based on the traffic observed 314 on that bridge's ports. Changes in topology may reverse or otherwise 315 change the required forwarding ports of messages for a multicast 316 group. Bridges must re-learn the correct multicast forwarding from 317 the receipt of multicast control messages on new ports. Such control 318 messages, after their initial issuance to establish multicast 319 distribution state, are sent only to refresh such state, sometimes at 320 intervals of seconds, during which, if a bridging topology change has 321 occurred, multicast data may be misdirected and lost. 323 However, a solution based on link state routing, for example, can 324 form and maintain a global view of the multicast group membership and 325 multicast router situation in a similar fashion to that in which it 326 maintains a global view of the status of links. Thus such a solution 327 can adjust the forwarding of multicast data and control traffic 328 immediately as it sees the LAN topology change. 330 2.5. Other Ethernet Protocol Extensions 332 There have been a variety of IEEE protocols beyond the initial 333 shared-media Ethernet variant, including: 335 o 802.1D - added bridges (i.e., switches) and a spanning tree 336 protocol (STP) (incorporates 802.1w, below) [IEEE04]. 338 o 802.1w - extension for rapid reconvergence of the spanning tree 339 protocol (RTSP) [IEEE04]. 341 o 802.1Q - added VLAN and priority support, where each link address 342 maps to one VLAN (incorporates 802.1v and 802.1s, below) [IEEE06]. 344 o 802.1v - added VLANs where segments map to VLANs based on link 345 address together with network protocol and transport port 346 [IEEE06]. 348 o 802.1s - added support for multiple spanning trees, up to a 349 maximum of 65, one per non-overlapping group of VLANs (MSTP) 350 [IEEE06]. 352 This document presumes the above variants are supported on the 353 Ethernet subnet, i.e., that a TRILL solution would not interfere with 354 (i.e., would not affect) any of the above. 356 In addition, the following more recent extensions have been 357 standardized to specify provider/carrier Ethernet services that can 358 be effectively transparent to the previously specified customer 359 Ethernet services. The TRILL Problem as described in this document is 360 limited to customer Ethernet services; however, there is no reason 361 that a TRILL solution might not be easily applicable to both customer 362 and provider Ethernet. 364 o 802.1ad (Provider Bridges) - added support for a second level of 365 VLAN tag, called a "service tag", and re-named the original 802.1Q 366 tag a "customer tag". Also known as Q-in-Q because of the stacking 367 of 802.1Q VLAN tags. 369 o 802.1ah (Provider Backbone Bridges) - added support for stacking 370 of MAC addresses by providing a tag to contain the original source 371 and destination MAC addresses. Also know as MAC-in-MAC. 373 It is useful to note that no extension listed above in this section 374 addresses the issue of independent, localized routing in a single LAN 375 - which is the focus of TRILL. 377 The TRILL problem and a sketch of a possible solution [Pe04] were 378 presented to both the IETF (via a BoF) and IEEE 802 (via an IEEE 802 379 Plenary meeting Tutorial). The IEEE, in response, approved a project 380 called Shortest Path Bridging (IEEE Project P802.1aq), taking a 381 different approach than that presented in [Pe04]. The current Draft 382 of P802.1aq appears to describe two different techniques. One, which 383 does not use encapsulation, is, according to the IEEE Draft, limited 384 in applicability to small networks of no more than 100 shortest path 385 bridges. The other, which uses 802.1ah, is, according to the IEEE 386 Draft, limited in applicability to networks of no more than 1,000 387 shortest path bridges. 389 2.6. Problems Not Addressed 391 There are other challenges to deploying Ethernet subnets that are not 392 addressed in this document other than, in some cases, to mention 393 relevant IEEE 802.1 documents, although it is possible for a solution 394 to address one or more of these in addition to the TRILL problem. 395 These include: 397 o increased Ethernet link subnet scale 399 o increased node relocation 401 o Ethernet link subnet management protocol security 403 o flooding attacks on a Ethernet link subnet 404 o support for "provider" services such as Provider Bridges 405 (802.1ad), Provider Backbone Bridges (802.1ah), or Provider 406 Backbone Bridge Traffic Engineering (802.1Qay) 408 Solutions to TRILL need not support deployment of larger scales of 409 Ethernet link subnets than current broadcast domains can support 410 (e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges, 411 or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges). 413 Similarly, solutions to TRILL need not address link layer node 414 migration, which can complicate the caches in learning bridges. 415 Similar challenges exist in the ARP protocol, where link layer 416 forwarding is not updated appropriately when nodes move to ports on 417 other bridges. Again, the compartmentalization available in network 418 routing, like that of network layer Autonomous Systems (ASes), can 419 help hide the effect of migration. That is a side effect, however, 420 and not a primary focus of this work. 422 Current link control plane protocols, including Ethernet link subnet 423 management (spanning tree) and link/network integration (ARP), are 424 vulnerable to a variety of attacks. Solutions to TRILL need not 425 address these insecurities. Similar attacks exist in the data plane, 426 e.g., source address spoofing, single address traffic attacks, 427 traffic snooping, and broadcast flooding. TRILL solutions need not 428 address any of these issues, although it is critical that they do not 429 introduce new vulnerabilities in the process (see Section 5). 431 3. Desired Properties of Solutions to TRILL 433 This section describes some of the desirable or required properties 434 of any system that would solve the TRILL problems, independent of the 435 details of such a solution. Most of these are based on retaining 436 useful properties of bridges, or maintaining those properties while 437 solving the problems listed in Section 2. 439 3.1. No Change to Link Capabilities 441 There must be no change to the service that Ethernet subnets already 442 provide as a result of deploying a TRILL solution. Ethernet supports 443 unicast, broadcast, and multicast natively. Although network 444 protocols, notably IP, can tolerate link layers that do not provide 445 all three, it would be useful to retain the support already in place 446 [RFC3819]. Zeroconf, as well as existing bridge autoconfiguration, 447 are dependent on broadcast as well. 449 Current Ethernet ensures in-order delivery for frames of the same 450 priority and no duplicated frames, under normal operation (excepting 451 transients during reconfiguration). These criteria apply in varying 452 degrees to the different variants of Ethernet, e.g., basic Ethernet 453 up through basic VLAN (802.1Q) ensures that all frames with the same 454 priority between two link addresses have both properties, but 455 protocol/port VLAN (802.1v) ensures this only for packets with the 456 same protocol and port. There are subtle implications to such a 457 requirement. Bridge autolearning already is susceptible to moving 458 nodes between ports, because previously learned associations between 459 port and link address change. A TRILL solution could be similarly 460 susceptible to such changes. 462 3.2. Zero Configuration and Zero Assumption 464 Both bridges and hubs are zero configuration devices; hubs having no 465 configuration at all, and bridges being automatically self- 466 configured. Bridges are further zero-assumption devices, unlike hubs. 467 Bridges can be interconnected in arbitrary topologies, without regard 468 for cycles or even self-attachment. Spanning tree protocols (STPs) 469 remove the impact of cycles automatically, and port autolearning 470 reduces unnecessary broadcast of unicast traffic. 472 A TRILL solution should strive to have similar zero configuration, 473 zero assumption operation. This includes having TRILL solution 474 components automatically discover other TRILL solution components and 475 organize themselves, as well as to configure that organization for 476 proper operation (plug-and-play). It also includes zero configuration 477 backward compatibility with existing bridges and hubs, which may 478 include interacting with some of the bridge protocols, such as 479 spanning tree. 481 VLANs add a caveat to zero configuration; a TRILL solution should 482 support automatic use of a default VLAN (like non-VLAN bridges), but 483 would undoubtedly require explicit configuration for VLANs where 484 bridges require such configuration. 486 Autoconfiguration extends to optional services, such as multicast 487 support via IGMP snooping, broadcast support via serial copy, and 488 supporting multiple VLANs. 490 3.3. Forwarding Loop Mitigation 492 Spanning tree avoids forwarding loops by construction, although 493 transient loops can occur, e.g., via the temporarily undetected 494 appearance of new link connectivity or the loss of a sufficient 495 number of spanning tree control frames. Solutions to TRILL are 496 intended to use adapted network layer routing protocols which may 497 introduce transient loops during routing convergence. A TRILL 498 solution thus needs to provide support for mitigating the effect of 499 such routing loops. 501 In the Internet, loop mitigation is provided by a decrementing hop 502 counts (TTL); in other networks, packets include a trace (sometimes 503 referred to as 'serialized' or 'unioned') of visited nodes [RFC1812]. 504 In addition, there may be localized consistency checks, such as 505 whether traffic in received on an unexpected interface, which 506 indicates that routing is in flux and such traffic should probably be 507 discarded for safety. These types of mechanisms limit the impact of 508 loops or detect them explicitly. Mechanisms with similar effect 509 should be included in TRILL solutions. 511 3.4. Spanning Tree Management 513 In order to address convergence under reconfiguration and robustness 514 to link interruption (Section 2.2), participation in the spanning 515 tree (STP) must be carefully managed. The goal is to provide the 516 desired stability of the TRILL solution and of the entire Ethernet 517 link subnet, which may include bridges using STP. This may involve a 518 TRILL solution participating in the STP, where the protocol used for 519 TRILL might dampen interactions with STP, or it may involve severing 520 the STP into separate STPs on 'stub' external Ethernet link subnet 521 segments. 523 A requirement is that a TRILL solution must not require modifications 524 or exceptions to the existing spanning tree protocols (e.g., STP, 525 RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree 526 Protocol)). 528 3.5. Multiple Attachments 530 In STP, a single node with multiple attachments to a single spanning 531 tree segment will always only get and send traffic over one of the 532 those attachment points. TRILL must manage all traffic, including 533 multicast and broadcast traffic, so as not to create traffic loops 534 involving Ethernet segments with multiple TRILL attachment points. 535 This includes multiple attachments to a single TRILL node and 536 attachments to multiple TRILL nodes. Support for multiple attachments 537 can improve support for forms of mobility that induce topology 538 changes, such as "make before break", although this is not a major 539 goal of TRILL. 541 3.6. VLAN Issues 543 A TRILL solution should support multiple customer VLANs (802.1Q, 544 which includes 802.1v and 802.1s). This may involve ignorance, just 545 as many bridge devices do not participate in the VLAN protocols. It 546 may alternately furnish direct VLAN support, e.g., by providing 547 configurable support for VLAN ignorant end stations equivalent to 548 that provided by 802.1Q non-provider bridges. 550 Provider VLANs (802.1ad) are outside of the scope of this document. A 551 TRILL solution might or might not be easily adaptable to handling 552 provider VLANs. 554 3.7. Operational Equivalence 556 As with any extension to an existing architecture, it would be useful 557 - though not strictly necessary - to be able to describe or consider 558 a TRILL solution as equivalent to an existing link layer component. 559 Such equivalence provides a validation model for the architecture and 560 a way for users to predict the effect of the use of a TRILL solution 561 on a deployed Ethernet. In this case, 'user' refers to users of the 562 Ethernet protocol, whether at the host (data segments), bridge (ST 563 control segments), or VLAN (VLAN control). 565 This provides a sanity check, i.e., "we got it right if we can 566 exchange a TRILL solution component or components with an X" (where 567 "X" might be a single bridge, a hub, or some other link layer 568 abstraction). It does not matter whether "X" can be implemented on 569 the same scale as the corresponding TRILL solution. It also does not 570 matter if it can - there may be utility to deploying the TRILL 571 solution components incrementally, in ways that a single "X" could 572 not be installed. 574 For example, if a TRILL solution's components were equivalent to a 575 single IEEE 802.1D bridge, it would mean that they would - as a whole 576 - participate in the STP. This need not require that TRILL solution 577 components would propagate STP, any more than a bridge need do so in 578 its on-board control. It would mean that the solution would interact 579 with BPDUs at the edge, where the solution would - again, as a whole 580 - participate as if a single node in the spanning tree. Note that 581 this equivalence is not required; a solution may act as if an IEEE 582 802.1 hub, or may not have a corresponding equivalent link layer 583 component at all. 585 3.8. Optimizations 587 There are a number of optimizations that may be applied to TRILL 588 solutions. These must be applied in a way that does not affect 589 functionality as a tradeoff for increased performance. Such 590 optimizations may address broadcast and multicast frame distribution, 591 VLAN support, and snooping of ARP and IPv6 neighbor discovery. 593 In addition, there may be optimizations which make the implementation 594 of a TRILL solution easier than roughly equivalent existing bridge 595 devices. For example, in many bridged LANs, there are topologies such 596 that central ("core") bridges which have both a greater volume of 597 traffic flowing through them as well as traffic to and from a larger 598 variety of end station than do non-core bridges. Thus means that such 599 core bridges need to learn a large number of end station addresses 600 and need to do lookups based on such addresses very rapidly. This 601 might require large high speed content addressable memory making 602 implementation of such core bridges difficult. Although a TRILL 603 solution need not provide such optimizations, it may reduce the need 604 for such large, high speed content addressable memories or provide 605 other similar optimizations. 607 3.9. Internet Architecture Issues 609 TRILL solutions are intended to have no impact on the Internet 610 network layer architecture. In particular, the Internet and higher 611 layer headers should remain intact when traversing a deployed TRILL 612 solution, just as they do when traversing any other link subnet 613 technologies. This means that the IP TTL field cannot be co-opted for 614 forwarding loop mitigation, as it would interfere with the Internet 615 layer assuming that the link subnet was reachable with no changes in 616 TTL (Internet TTLs are changed only at routers, as per RFC 1812, and 617 even if IP TTL were considered, TRILL is expected to support non-IP 618 payloads, and so requires a separate solution anyway) [RFC1812]. 620 TRILL solutions should also have no impact on Internet routing or 621 signaling, which also means that broadcast and multicast, both of 622 which can pervade an entire Ethernet link subnet, must be able to 623 transparently pervade a deployed TRILL solution. Changing how either 624 of these capabilities behaves would have significant effects on a 625 variety of protocols, including RIP (broadcast), RIPv2 (multicast), 626 ARP (broadcast), IPv6 neighbor discovery (multicast), etc. 628 Note that snooping of network layer packets may be useful, especially 629 for certain optimizations. These include snooping multicast control 630 plane packets (IGMP) to tune link multicast to match the network 631 multicast topology, as is already done in existing smart switches 632 [RFC3376][RFC4286]. This also includes snooping IPv6 neighbor 633 discovery messages to assist with governing TRILL solution edge 634 configuration, as is the case in some smart learning bridges 635 [RFC4861]. Other layers may similarly be snooped, notably ARP 636 packets, for similar reasons for IPv4 [RFC826]. 638 4. Applicability 640 As might be expected, TRILL solutions are intended to be used to 641 solve the problems described in Section 2. However, not all such 642 installations are appropriate environments for such solutions. This 643 section outlines the issues in the appropriate use of these 644 solutions. 646 TRILL solutions are intended to address problems of path efficiency 647 and concentration, inability to multipath, and path stability within 648 a single Ethernet link subnet. Like bridges, individual TRILL 649 solution components may find other TRILL solution components within a 650 single Ethernet link subnet and aggregate into a single TRILL 651 solution. 653 TRILL solutions are not intended to span separate Ethernet link 654 subnets interconnected by network layer (e.g., router) devices, 655 except via link layer tunnels, where such tunnels render the distinct 656 subnet undetectably equivalent from a single Ethernet link subnet. 658 A currently open question is whether a single Ethernet link subnet 659 should contain components of only one TRILL solution, either of 660 necessity of architecture or utility. Multiple TRILL solutions, like 661 Internet ASes, may allow TRILL routing protocols to be partitioned in 662 ways that help their stability, but this may come at the price of 663 needing the TRILL solutions to participate more fully as nodes (each 664 modeling a bridge) in the Ethernet link subnet STP. Each architecture 665 solution should decide whether multiple TRILL solutions are supported 666 within a single Ethernet link subnet and mechanisms should be 667 included to enforce whatever decision is made. 669 TRILL solutions need not address scalability limitations in bridged 670 subnets. Although there may be scale benefits of other aspects of 671 solving TRILL problems, e.g., of using network layer routing to 672 provide stability under link changes or intermittent outages, this is 673 not a focus of this work. 675 As also noted earlier, TRILL solutions are not intended to address 676 security vulnerabilities in either the data plane or control plane of 677 the link layer. This means that TRILL solutions should not limit 678 broadcast frames, ARP requests, or spanning tree protocol messages 679 (if such are interpreted by the TRILL solution or solution edge). 681 5. Security Considerations 683 TRILL solutions should not introduce new vulnerabilities compared to 684 traditional bridged subnets. 686 TRILL solutions are not intended to be a solution to Ethernet link 687 subnet vulnerabilities, including spoofing, flooding, snooping, and 688 attacks on the link control plane (STP, flooding the learning cache) 689 and link-network control plane (ARP). Although TRILL solutions are 690 intended to provide more stable routing than STP, this stability is 691 limited to performance, and the subsequent robustness is intended to 692 address non-malicious events. 694 There may be some side-effects to the use of TRILL solutions that can 695 provide more robust operation under certain attacks, such as those 696 interrupting or adding link service, but TRILL solutions should not 697 be relied upon for such capabilities. 699 Finally, TRILL solutions should not interfere with other protocols 700 intended to address these vulnerabilities, such as those to secure 701 IPv6 neighbor discovery [RFC3971]. 703 6. IANA Considerations 705 This document requires no IANA actions. 707 This section should be removed by the RFC Editor prior to final 708 publication. 710 7. Acknowledgments 712 Portions of this document are based on documents that describe a 713 preliminary solution, and on a related network layer solution 714 [Pe04][Pe05][To03]. Donald Eastlake III provided substantial text and 715 comments. Additional comments and feedback were provided by the 716 members of the IETF TRILL WG, in which this document was developed, 717 and by the IESG. 719 This document was prepared using 2-Word-v2.0.template.dot. 721 8. References 723 8.1. Normative References 725 None. 727 8.2. Informative References 729 [IEEE04] IEEE 802.1D bridging standard, "IEEE Standard for Local and 730 metropolitan area networks: Media Access Control (MAC) 731 Bridges", (incorporates 802.1w), Jun. 2004. 733 [IEEE06] IEEE 802.1Q VLAN standard, "IEEE Standards for Local and 734 metropolitan area networks: Virtual Bridged Local Area 735 Networks", (incorporates 802.1v and 802.1s), May 2006. 737 [Me04] Myers, A., T.E. Ng, H. Zhang, "Rethinking the Service 738 Model: Scaling Ethernet to a Million Nodes", Proc. ACM 739 Third Workshop on Hot Topics in Networks (HotNets-III), 740 Mar. 2004. 742 [Pe99] Perlman, R., "Interconnection: Bridges, Routers, Switches, 743 and Internetworking Protocols", Addison Wesley, Chapter 3, 744 1999. 746 [Pe04] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 747 2005, Mar. 2004. 749 [Pe05] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent 750 Routing," (expired work in progress), Apr. 2004 - May 2005. 752 [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or 753 converting network protocol addresses to 48.bit Ethernet 754 address for transmission on Ethernet hardware", RFC-826 / 755 STD-37 (Standard), Nov. 1982. 757 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 758 RFC-1812 (Proposed Standard), Jun. 1995. 760 [RFC3819] Karn, P., (ed.), C. Bormann, G. Fairhurst, D. Grossman, R. 761 Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood, 762 "Advice for Internet Subnetwork Designers", RFC-3819 / BCP 763 89 (Best Current Practice), Jul. 2004. 765 [RFC3376] Cain, B., S. Deering, I. Kouvelas, B. Fenner, A. 766 Thyagarajan, "Internet Group Management Protocol, Version 767 3", RFC-3376 (Proposed Standard), Oct. 2002. 769 [RFC3971] Arkko, J., J. Kempf, B. Sommerfield, B. Zill, P. Nikander, 770 "Secure Neighbor Discovery (SeND)", RFC-3971 (Proposed 771 Standard), Mar. 2005. 773 [RFC4286] Haberman, B., J. Martin, "Multicast Router Discovery", 774 RFC-4286 (Proposed Standard), Dec. 2005. 776 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 777 "Considerations for Internet Group Management Protocol 778 (IGMP) and Multicast Listener Discovery (MLD) Snooping 779 Switches", RFC-4541, May 2006. 781 [RFC4861] Narten, T., E. Nordmark, W. Simpson, H. Soliman, "Neighbor 782 Discovery for IP version 6 (IPv6)", RFC-4861 (Draft 783 Standard), Sep. 2007. 785 [To03] Touch, J., Y. Wang, L. Eggert, G. Finn, "A Virtual Internet 786 Architecture", ISI Technical Report ISI-TR-570, Presented 787 at the Workshop on Future Directions in Network 788 Architecture (FDNA) 2003 at Sigcomm 2003, March 2003. 790 Author's Addresses 792 Joe Touch 793 USC/ISI 794 4676 Admiralty Way 795 Marina del Rey, CA 90292-6695 796 U.S.A. 798 Phone: +1 (310) 448-9151 799 Email: touch@isi.edu 800 URL: http://www.isi.edu/touch 802 Radia Perlman 803 Sun Microsystems 804 16 Network Circle 805 umpk16-161 806 Menlo Park, CA 94025 807 U.S.A. 809 Email: Radia.Perlman@sun.com