idnits 2.17.1 draft-gibanez-trill-abridge-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1247. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1228. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1234. ** 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 20) being 73 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations [To be added]' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations.' ) ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [10], [11], [SPB], [12], [13], [14], [AMSTP], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1215 has weird spacing: '...imed to perta...' == Line 1231 has weird spacing: '...ion any copy...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 (June 6, 2006) is 6527 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 1143 looks like a reference -- Missing reference section? '10' on line 1176 looks like a reference -- Missing reference section? '7' on line 1163 looks like a reference -- Missing reference section? '6' on line 1160 looks like a reference -- Missing reference section? '3' on line 1149 looks like a reference -- Missing reference section? '5' on line 1156 looks like a reference -- Missing reference section? '4' on line 1152 looks like a reference -- Missing reference section? 'AMSTP' on line 419 looks like a reference -- Missing reference section? '12' on line 1184 looks like a reference -- Missing reference section? '13' on line 1188 looks like a reference -- Missing reference section? 'SPB' on line 986 looks like a reference -- Missing reference section? '2' on line 1146 looks like a reference -- Missing reference section? '8' on line 1167 looks like a reference -- Missing reference section? '9' on line 1172 looks like a reference -- Missing reference section? '11' on line 1179 looks like a reference -- Missing reference section? '14' on line 1192 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 23 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TRILL WG Guillermo Ibanez 3 Internet Draft Alberto Garcia 4 Expires: Dec 2006 Arturo Azcorra 6 June 6, 2006 8 ABridges as RBridges: Transparent Routing with Simplified 9 Multiple Spanning Trees. 11 draft-gibanez-trill-abridge-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents 16 that any applicable patent or other IPR claims of which he or 17 she is aware have been or will be disclosed, and any of which 18 he or she becomes aware will be disclosed, in accordance with 19 Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet 22 Engineering Task Force (IETF), its areas, and its working 23 groups. Note that other groups may also distribute working 24 documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of 27 six months and may be updated, replaced, or obsoleted by 28 other documents at any time. It is inappropriate to use 29 Internet-Drafts as reference material or to cite them other 30 than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed 36 at 37 http://www.ietf.org/shadow.html 39 This Internet-Draft will expire on Dec 16, 2006. 41 Abstract 43 RBridges are link layer devices that use routing protocols as 44 a control plane but do not target to scale up to large campus 45 networks. This document contains an alternative proposal to 46 link-state RBridges, named ABridges. ABridges overcome 47 RBridges L2 network size restrictions allowing applicability 48 to very large Ethernet campus networks while maintaining zero 49 configuration and high performance, by assuming a topological 50 restriction that is automatically performed. The proposal 51 includes a two-layered network architecture with two 52 hierarchical independent spanning tree layers. Expected 53 convergence is fast, probably below two seconds. 55 G. ibanez Informational Expires May 2006 1 56 ABridges use multiple simplified spanning trees rooted at 57 core edge bridges to achieve results comparable to RBridges 58 with lower computational complexity. Two implementation 59 variants of simplified multiple spanning trees are proposed: 60 The first one is a fundamental simplification of the standard 61 Multiple Spanning Tree protocol and the second one (still in 62 a very preliminary stage) consists of an N-multiple 63 simultaneous execution of the Rapid Spanning Tree protocol at 64 each RBridge. 65 An optional mechanism of ARP/ABridge servers/registrars (with 66 load splitting) is proposed to limit ARP traffic in large 67 scale Ethernet networks and to enhance scalability and 68 security. This mechanism can also be used for host-Designated 69 RBridge resolution as an alternative to the interchange of 70 Hosts Lists between RBridges. 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 73 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 74 "OPTIONAL" in this document are to be interpreted as 75 described in RFC-2119 [1]. 77 Table of Contents 78 1.Introduction...............................................2 79 2.Terminology................................................4 80 3. Network Architecture......................................4 81 4. Protocols.................................................5 82 4.1 RSTP Protocol............................................5 83 4.2 MSTP Protocol............................................6 84 4.3 Core Layer: AMSTP Protocol ..............................6 85 4.4 AMSTP versus MSTP........................................8 86 4.5 Designated (and Root) ABridge............................9 87 4.6 Forwarding Scenario.....................................10 88 4.7 Learning End Node Location..............................12 89 4.8 Routing versus Learning Bridges Addresses...............12 90 4.9 Header on 802 Links.....................................12 91 4.10 Distributed ARP Query..................................13 92 4.11 ABridge Identities and Addresses.......................13 93 5. ARP/ABridge Server/Registrars............................12 94 6. Issues...................................................13 95 6.1 Per Ingress Spanning Tree...............................14 96 6.2 Symmetrical Path Problem................................14 97 6.3 Traffic Aggregation at Root bridge......................14 98 6.4 VLANs ..................................................14 99 6.5 Optimizing ARP/ND.......................................14 100 7. Security Considerations..................................15 101 8. IANA Considerations......................................15 102 9.NRSTP.....................................................15 103 10.Conclusions..............................................15 104 11.Acknowledgments..........................................15 105 12.References...............................................15 106 Author's Addresses..........................................16 107 Intellectual Property Statement.............................16 108 Disclaimer of Validity......................................17 109 Copyright Statement.........................................17 111 G.Ibanez Informational expires Dec 6, 2006 2 112 1. Introduction 114 Current IP-based campus networks use one prefix address per 115 link to support routing. This implies administration and 116 configuration of IP addresses. IP addresses are link-related, 117 so the IP address of an end node varies when the point of 118 attachment to the network changes. 119 Bridges do not require this kind of configuration because 120 they forward in the switched domain using flat layer 2 121 addresses. However standard bridge protocols do not scale, 122 because the spanning tree protocol only enables some selected 123 links to prevent loops, and network utilization is therefore 124 low. Also the routes along the spanning tree are not pair- 125 wise shortest paths, and temporary loops may produce packet 126 proliferation across the entire switched domain. 128 RBridges have been proposed as a hybrid of routers and 129 bridges, showing the advantages of routers while preserving 130 at the same time the zero configuration capability of 131 bridges. 132 However RBridges currently do not fulfill an important 133 requirement such as scaling to large Ethernet campus 134 networks. The importance of this requirement is growing with 135 the increasing size of campus networks and the foreseeable 136 increase in connected devices (displays, IP phones, cameras, 137 802.11 PDAs, sensors, etc). This lack of scalability derives 138 from the use of flat MAC addresses to perform routing. Being 139 non aggregatable, MAC addresses will produce long tables in 140 RBridges when used in large campus networks. Another 141 potential weakness of RBridges is that, while exhibiting 142 unrestricted topological compatibility with standard bridges, 143 RBridges depend on the bridged links to communicate among 144 themselves and to perform the IS-IS Designated Router 145 election. This dependency increases their complexity and 146 makes the whole system vulnerable to inter RBridge 147 communication problems. The overall convergence time is 148 increased because the spanning tree convergence time adds up 149 to the IS-IS DR election time. 151 This draft proposes an architecture for Ethernet campus 152 networks based on a new type of Ethernet hierarchical 153 switches for campus cores. The architecture is oriented to 154 provide high performance, minimal configuration, and 155 scalability in very large Ethernet campus networks. The 156 proposed network architecture consists of a high capacity 157 core composed of an arbitrary mesh of switches named 158 ABridges, and a number of access networks with standard 159 bridges connected to the core. 161 The document proposes an alternative implementation for 162 RBridges [10] (Routing Bridges), identified as AMSTP Bridges 163 (ABridges) that combine the advantages of bridges and 164 routers. Like bridges and RBridges, ABridges require zero 165 configuration and are transparent to IP nodes. ABridges also 166 forward on pair-wise shortest paths like routers as RBridges 167 do. 169 G.Ibanez Informational expires Dec 6, 2006 3 170 We propose to use multiple L2 spanning trees between ABridges 171 to forward via shortest paths in the core of the campus 172 network. The AMSTP protocol is a simplification of the 173 standard MSTP protocol, oriented to zero configuration. The 174 core edge bridges provide backbone connectivity to lower 175 layer (Access Layer) networks. The active topology of the 176 Access Layer networks consists of standard spanning trees of 177 switches (RSTP/STP). Each Edge Switch acts as the root bridge 178 of two independent spanning trees: the spanning tree of its 179 lower layer Access network, and one spanning tree instance of 180 the core network. The architecture provides shortest paths in 181 most traffic situations for client-server traffic (for 182 servers located in a server farm) and adapts well to traffic 183 aggregation. Additional mechanisms can be designed to achieve 184 high network availability. 186 Due to the access port mode, ABridges are compatible with 187 current bridges as well as current IPv4 and IPv6 routers and 188 end nodes. They are as transparent to current IP routers as 189 bridges and RBridges are. Like routers, they terminate a 190 bridged spanning tree. 192 Packets in the Core of ABridges must be encapsulated such 193 that: 195 - Forwarding is performed in the Core across per egress 196 bridge tree instances, while maintaining the original L2 197 header so that end destination bridges can learn about the 198 location of the source by learning the source address from 199 packets. 201 - ABridges can learn the location of end nodes. They can 202 learn the location and layer 2 addresses of attached nodes 203 from the source address of data packets, as bridges and 204 RBridges. However, very large campus networks with tens of 205 thousands of nodes may require more scalable and safer 206 solutions for locating end nodes. For this case, the use of 207 ARP/Abriges Server/Registrars is proposed. 209 Support of VLANs traditionally requires configuration of the 210 bridges to know which ports and links belong to which VLANs. 211 In order to achieve true zero configuration, we recommend 212 that bridges do not separate per VLAN traffic in the campus 213 core, and do not use a separate spanning tree for each 214 broadcast domain. In a campus without VLANs, this means a 215 single spanning tree would be used for delivery of packets 216 with unknown or layer 2 group address layer 2 destinations. 218 ABridges can suppress the broadcast/multicast for Neighbour 219 discovery by using ARP servers/registrars or, similarly to 220 RBridges, by conventional proxy ARP (IPv4) or proxy ND 221 (IPv6). 223 ABridges are fully compatible with current IPv4 and IPv6 224 routers and end nodes. They are as invisible to current IP 226 G.Ibanez Informational expires Dec 6, 2006 4 227 routers as bridges are, and they participate in two bridged 228 hierarchically linked but separated spanning trees. 230 2. Terminology 232 AMSTP: Alternative Multiple Spanning Tree Protocol 234 ABridge: An RBridge implemented as an AMSTP Bridge 236 Access network: subnetwork of standard bridges connected to 237 an ABridge. 239 ARP/ABridge Server/Registrar: Server that provides ARP 240 resolution and the ID of a destination hosts Designated 241 ABridge (see DR). 243 Campus network: set of network elements (standard bridges and 244 ABridges) connected to one or more routers. 246 Core: set of ABridges directly interconnected through point 247 to point links. 249 Core port: The port of an ABridge connected to another 250 ABridge through a point to point link. 252 Access port: The port of an ABridge connected to a link that 253 has active standard bridges connected. It executes the 254 standard spanning tree protocol and provides connection to 255 the Access Network. 257 DR: Designated RBridge. In the context of an ABridge, it 258 means the Designated ABridge that coincides with the STP/RSTP 259 Root bridge of the Access network. 261 MSTP: Multiple Spanning Tree Algorithm and Protocol. 263 NRSTP: Variant implementation of AMSTP through execution of N 264 independent RSTP instances. 266 RBridge: Routing Bridge as defined by Radia Perlman and TRILL 267 WGs proposal. 269 RSTP: Rapid Spanning Tree Algorithm and Protocol 271 3. Network Architecture 273 Campus network designs are currently based on a layered 274 architecture (core, distribution and access layers) to obtain 275 network scalability and predictability. Segmentation of 276 networks is obtained using routers or devices called 277 multilayer switches that segment the network in IP segments 278 or subnets. 280 A similar approach is proposed here, but with the network 281 segmentation performed at layer 2 instead of layer 3. The 283 G.Ibanez Informational expires Dec 6, 2006 5 284 proposed network architecture is shown in Figure 1. It uses a 285 two-layer hierarchical L2 network to achieve scalability to 286 large scale Ethernet networks. The upper layer acts as a 287 Core-Distribution Layer (Core) and the lower Layer acts as an 288 Access Layer. The core layer uses the AMSTP protocol for 289 interconnection between core ABridges while the Access Layer 290 uses the standard spanning tree protocol (RSTP or STP) to 291 connect hosts of the access network with other hosts via 292 their root bridge at the core (ABridge). 294 The ABridges constitute the core network and are 295 interconnected by dedicated links. The point to point link 296 requirement derives from the need for fast convergence of 297 standard layer 2 spanning tree algorithms, but it is also 298 required for high performance and enhanced security (802.1X). 299 Thus, point to point links are becoming a requirement for 300 Ethernet networks, at least at the core and distribution 301 layers. 302 Other bridges connect to ABridges without requiring a point 303 to point connection, and form the Access Layer. The Access 304 Layer is segmented in multiple access networks. Each Access 305 network is formed by devices connected to a core ABridge; it 306 may have arbitrary topologies but the active topology will 307 use the standard spanning tree as the basic forwarding 308 mechanism. More sophisticated protocols are possible for 309 better infrastructure usage inside each Access network, but 310 they are out of the scope of this proposal. 312 --------- 313 | network| 314 / --------- 315 / 316 A -----A 317 / \ / \ Core layer 318 / \ / \ 319 A------A-----A 320 / \ \ 321 -------- / \ \----------- 322 |network| \ | network | Access Layer 323 -------- \ ----------- 324 \ --------- 325 | network | 326 ---------- 328 A: ABridge 330 Figure 1. Campus network topology 332 ABridges must auto-configure ports to participate in the Core 333 or in the Access network. The port reconfiguring mechanism is 334 as follows: a port that is not connected using a point to 336 G.Ibanez Informational expires Dec 6, 2006 6 337 point link to another ABridge configures itself as an access 338 port (an ingress and egress point for traffic to/from the 339 core). Ports directly connected to another ABridge act as 340 core ports. The auto-configuration of ports works as follows: 341 each port detects, through the STP BPDU type (STP, RSTP or 342 AMSTP) received on their link upon initialization, whether 343 the device connected to the link is a standard bridge or an 344 ABridge. If the BPDUs received are standard 802.1D BPDUs, the 345 link will be assigned to the Access Network and the port will 346 be automatically configured to access port mode. Any standard 347 bridge connected to the ABridge is thus automatically 348 excluded from the core function. 350 Figure 1 shows an example of the proposed network topology. A 351 core of ABridges constitutes the campus backbone and 352 interconnects different area networks formed by standard 353 802.1D bridges. 355 4. Protocols 357 In this section the proposed protocols are described. The 358 Alternative Multiple Spanning Tree Protocol [7] is an 359 evolution of the standard MSTP [6] and RSTP [3] protocols. In 360 the following paragraphs RSTP and MSTP protocols are first 361 summarily introduced to provide the required context to 362 describe the AMSTP protocol. Differences between AMSTP and 363 MSTP are summarized after a description of AMSTP. 365 4.1 RSTP Protocol 367 A standard protocol for bridges is the Rapid Spanning Tree 368 Protocol, included in IEEE 802.1D[5]. It provides much faster 369 convergence than the previous standard protocol STP [4]. To 370 achieve convergence in (typically) fractions of one second, 371 RSTP substitutes the timer based mechanism that STP uses, to 372 ensure that the algorithm has converged with a locally 373 controlled proposal-agreement mechanism between adjacent 374 switches to transition the port states to forwarding in a 375 controlled way. This mechanism requires point to point links 376 to operate without loops. Other mechanisms are also used to 377 ensure rapid convergence. 379 4.2 MSTP protocol 381 The Multiple Spanning Tree Protocol (IEEE 802.1Q) is based on 382 RSTP (IEEE 802.1D) and creates different tree instances that 383 are used by sets of VLANs according to the configuration of 384 the bridge. MSTP implements a set of multiple and independent 385 spanning tree instances (MSTI) in a network region. Each 386 region is interconnected via a common spanning tree (CST) to 387 other MST regions. Inside a region, several VLANs can be 388 mapped to a single tree instance. Multiple tree instances at 389 each region make it possible to improve the usage of the 390 links. At each region, there is a tree instance (IST), 391 identified with the number 0, that acts as the basic spanning 392 tree. The CIST or total spanning tree is comprised of the CST 394 G.Ibanez Informational expires Dec 6, 2006 7 395 that connects all the regions, and the IST that provides 396 connectivity inside each region. It allows separated 397 management of the regions, appearing to the outside as a 398 unique and separate "superbridge", i.e. the whole region 399 connects to the CST via one Regional Root Bridge port and a 400 number of designated ports like a single bridge. Therefore, 401 no change in internal topology inside is influenced by 402 outside tree topology changes. MSTP allows more efficient 403 network infrastructure usage by assigning different spanning 404 trees to different sets of VLANs. 405 But MSTP is complex to configure. Tree instances must be 406 planned and VLANs must be mapped to those tree instances. The 407 configuration table must be checked to be exactly the same 408 for all bridges of the same region. Serious malfunction 409 occurs if VLAN mapping discrepancies between bridges in the 410 same region exist. 412 4.3 Core layer: AMSTP Protocol 414 In the architecture proposed, the AMSTP Protocol works as a 415 Core Layer protocol providing shortest path interconnection 416 between Access Networks and providing network segmentation to 417 prevent the extension of failures to the whole switched 418 domain. The AMSTP Protocol has been proposed previously 419 [AMSTP] for metropolitan Ethernet backbones but it can be 420 extended for campus networks as well, with some 421 modifications. AMSTP is a simplified multiple spanning tree 422 protocol that uses one tree instance rooted at each edge 423 bridge in the core to forward frames. A complete multi-tree 424 is the set of all tree instances, one rooted at every edge 425 bridge that interconnects all bridges in the backbone. Only 426 the ABridge ports connected to other ABridges participate in 427 the multiple spanning tree protocol. The rest of the ports 428 participate in the standard spanning tree protocols such as 429 RSTP or STP (IEEE 802.1D). 430 To describe the AMSTP protocol, we consider its two main 431 functionalities: building and maintaining the spanning trees 432 (control plane), and processing and forwarding frames in the 433 bridges (user plane). 435 4.3.1 Building the Trees 437 The process of tree building consists of two parts: building 438 the basic (standard) RSTP tree and building the rest of the 439 instances, called Alternate Multiple Spanning Tree Instances 440 (AMSTI), till one tree instance per bridge is built as shown 441 in figure 2. The process of building the main tree is the 442 same as in RSTP. 443 Every bridge emits autonomously Bridge Protocol Data Units 444 (BPDU) every Hello Time (configurable from milliseconds) to 445 neighbouring bridges. First the Bridge having the lowest 446 Bridge ID (best configured priority plus lower MAC address 447 appended) is elected as Root Bridge of the main spanning 449 G.Ibanez Informational expires Dec 6, 2006 8 450 tree. Every bridge receiving BPDU from this Bridge will adopt 451 it as Root and propagate it in the BPDUs emitted. 453 These BPDUs contain the minimum path cost from the emitting 454 bridge to the elected Root Bridge. Every Bridge attaches to 455 the spanning tree by selecting the port that is receiving the 456 "best" BPDU as the root port. The best BPDU is the one that 457 announces minimum path cost to root bridge. Each bridge 458 builds its own BPDU with the result of received BPDUs from 459 other bridges, selecting "superior" BPDUs according to the 460 standard STP criteria (lower Bridge ID, lower path cost, 461 lower port priority, lower port ID) and transmits them via 462 the main tree for the continuous maintenance of the optimum 463 main spanning tree. 465 A -----A 466 / \ / \ 467 / \ / \ 468 A------A-----A 470 A ----A A A A A R-----A A---R 471 / \ / \ \ / \ \ / \ 472 / \ / \ \ / \ \ / \ 473 R-----A----A A----R----A A---A----R A A A A---A A 475 Fig.2. A five node network and its five self-rooted AMSTP 476 Spanning Tree Instances (R: root bridge). 478 The process of building all the other tree instances, one per 479 tree, takes place as follows: Each Core Bridge appends to the 480 main tree BPDU the information of all AMSTI tree instances 481 which the bridges participates in. The information appended 482 per tree instance is called the AM-Record and contains similar 483 information for BPDU tree instance building. The key 484 difference with other spanning tree protocols is that there is 485 no bridge election. In AMSTP the ABridge claims itself as Tree 486 Root Bridge of its own instance and accepts equally every 487 other ABridge as the Root of its own instance. The bridge is 488 accepted as the root by other bridges without negotiation 489 (except when a malfunction is detected). This self rooted tree 490 instance is identified by the bridge ID of the edge ABridge 491 (root). The rest of the process is analogous to the building 492 of the MSTI tree instances used by MSTP inside an MST region 493 [4]: the tree is built by selecting tree paths at every bridge 494 according to the same minimum path cost criteria as MSTP, 495 using port priority and port ID for tie breaking. A flag 496 octet, identical to the one for building the basic tree 497 instance, is used by the bridges to communicate and negotiate 498 transitions of port states and roles per tree instance. 500 4.3.2 Frame processing in Core Switches 502 G.Ibanez Informational expires Dec 6, 2006 9 503 When processing a frame, a Core Switch (ABridge) may act as an 504 ingress, transit or egress ABridge. 506 As ingress ABridge, the switch encapsulates the frame with an 507 additional Layer 2 header containing its MAC as source 508 address, and as destination the MAC address of the egress 509 ABridge. The ingress ABridge forwards the encapsulated frame 510 through the branch belonging to the spanning tree instance 511 rooted at the egress ABridge. This path is a pair-wise 512 shortest path because the tree is built by minimizing path 513 cost from each root to the rest of the nodes. 515 Traffic forwarding in the core depends on the traffic type: 516 broadcast, multicast and traffic to unknown destinations is 517 forwarded via the tree instance rooted at the ingress ABridge. 518 Unicast traffic (to a known ABridge) is forwarded through the 519 tree instance of the egress ABridge. Forwarding takes place by 520 sending the frame through the bridge root port. Broadcast and 521 multicast traffic are forwarded via the tree instance rooted 522 at the ingress ABridge. 524 ABridges may learn from the received frames both the MAC 525 addresses of other ABridges and the MACs of the connected end 526 nodes by the inspection of the inner and outer Ethernet MAC 527 addresses of the encapsulated frames. This learning process is 528 called double MAC learning and is applicable only in networks 529 with a moderate number of end nodes, like a backbone with 530 routers connected to it [7]. 532 The MAC learning process is based on frames broadcasted over 533 the switched network. These broadcasts are commonly ARP 534 packets issued by end nodes for layer 2 destination address 535 resolution. In this process the bridges learn the originating 536 MAC at receiving ports and the hosts add the IP-MAC pair to 537 their ARP table. In networks with a high number of end nodes, 538 processing a high number of ARP requests by every endnode may 539 result in significant load for endnodes. A different mechanism 540 is needed to prevent ARP packets from 541 broadcasting/multicasting in large Ethernet campus networks. 543 The ports of switches that are not connected to AMSTP capable 544 Core Switches do not run AMSTP, so they are kept out of the 545 core forwarding mechanism. For Core Switches running AMSTP to 546 interoperate with legacy switches running STP or RSTP, a 547 mechanism is needed, like the standard port migration protocol 548 used by MSTP, RSTP and STP. Basically the mechanism is that if 549 a port of an MSTP switch receives BPDUs of protocol version 0 550 (STP protocol) it will emit STP BPDUs only. Recovery is not 551 automatic; the port will not emit MSTP BPDUs until a 552 configuration command restarts the protocol migration process, 553 forcing renegotiation between neighbouring switches. 555 4.3.3 AMSTP BPDU layout 557 AMSTP BPDUs have a structure that resembles MSTP BPDUs [4] 558 since both are comprised essentially of a basic BPDU and 560 G.Ibanez Informational expires Dec 6, 2006 10 561 several AM-Records appended. The AMSTP BPDU structure is shown 562 in figure 3. The basic BPDU is used for basic tree (0) 563 negotiation between switches. Each of the appended AM-Records 564 is used to negotiate a specific tree instance (AMSTI). 565 As in the MSTP case the BPDUs carrying the rapid spanning tree 566 information distributed via instance 0 also carry the 567 information of all the spanning tree instances appended to the 568 RSTP BPDU as AM records. This reduces broadcasting and 569 simplifies BPDU processing at the switches. 571 -------------------------- 572 ! Basic RSTP BPDU ! 573 ! Tree instance 0 ! 574 -------------------------- ------------------------- 575 ! [AMSTP header] ! /! AMSTI flags ! 576 ! ! / ------------------------- 577 --------------------------/ ! Root bridge ID (edge)! 578 ! Tree Instance 1 ! ------------------------- 579 ! Root 1 ! ! Root path cost ! 580 ! ! ------------------------- 581 -------------------------- ! Dest. Port Address ! 582 ! Tree Instance 2 !\ ! of Root bridge ! 583 ! Root 2 !| ------------------------- 584 ! ! \ ! Port priority ! 585 -------------------------- | ------------------------- 586 ........... \! Remaining hops ! 587 -------------------------- ------------------------- 588 ! Tree Instance 1 ! 589 ! Root N ! 590 -------------------------- 592 Fig. 3. AMSTP BPDU layout 594 Every AM-record includes an octet flag identical to the one 595 described for the RSTP tree. These flags are used to negotiate 596 all transitions of each tree instance between connected ports 597 of neighbouring switches. 598 Minimum configuration is an important requirement for Core 599 Switches. While multiple spanning tree algorithms enable much 600 better usage of the existing infrastructure, they are usually 601 complex to configure because a way to assign frames to tree 602 instances is needed. In the case of MSTP, this means that the 603 mapping of VLANs to tree instances (MSTIs) has to be 604 configured manually at each bridge, resulting in a complex and 605 error-prone process. 606 AMSTP uses Self rooted Spanning Tree instances instead of 607 VLAN mapped trees and all tree instances are automatically 608 created, so no tree configuration is needed. The parameters to 609 configure are those common to RSTP, such as selection of the 610 Root Bridge and configuration of the Backup Bridges for the 611 region and their priorities. 613 Multicast (L2 addresses) traffic. Multicast traffic in the 614 campus core is forwarded via same tree instances as unicast 615 traffic, via pair-wise shortest paths to destination ABridges. 617 G.Ibanez Informational expires Dec 6, 2006 11 618 The difference with unicast traffic is that the spanning tree 619 used is rooted at the ingress ABridge, instead of the tree 620 rooted at the destination ABridge. The multicast trees are 621 therefore always optimized for minimum hops without the 622 construction of additional tree instances. As for RBridges, 623 ABridges may treat multicast traffic as broadcast or may use 624 current techniques like IGMP snooping to limit broadcast. 626 4.4 AMSTP versus MSTP 628 Table I below shows a comparison of the main protocol 629 differences between MSTP and AMSTP. The first difference is 630 the criteria used for assignment of frames to a tree instance 631 for processing, in other words, how the bridge knows which 632 spanning tree instance to use to forward the frame. The second 633 one is the criteria used to create a tree instance. 635 TABLE I 636 MSTP VS AMSTP - MAIN PROTOCOL DIFFERENCES 637 -------------------------------------------------------------- 638 Protocol feature MSTP AMSTP 639 -------------------------------------------------------------- 640 Criteria for 641 frame assignment Destination MAC 642 of frame(root) 643 to a tree instance VLAN tag on frame (802.1Q) 644 -------------------------------------------------------------- 645 Tree instance Configured : Automatic: One 646 formation Sets of VLANs are per core bridge 647 criteria mapped to every tree 648 instance 649 -------------------------------------------------------------- 650 Number of tree instances Configured :1 to 64 One per core 651 bridge (*) 653 -------------------------------------------------------------- 654 Root bridge As RSTP (lower bridge No election. 655 election. ID including bridge priority) Every bridge is 656 the root of its 657 tree instance 658 -------------------------------------------------------------- 659 Bridge ID 4 MSB byte priority, 12 bit VLAN ID 6 byte MAC 661 -------------------------------------------------------------- 662 Single or Multiple Single 663 Multiple MST regions 664 -------------------------------------------------------------- 665 Main application 666 Environment Interconnected VLAN based regions 667 Cores, backbones 668 -------------------------------------------------------------- 669 (*) An ABridge with no access ports (transit ABridge instead 670 of edge ABridge) does not create a self rooted instance. 672 4.5 Designated (and Root) ABridge 674 G.Ibanez Informational expires Dec 6, 2006 12 675 Similarly to RBridges, an ABridge of each link has special 676 duties. This ABridge acts as the Designated RBridge of that 677 link. The DR function combines very well with being the root 678 bridge of the spanning tree of that link. To achieve automatic 679 election of ABridges as roots of the respective access 680 networks of the campus it would suffice that the default 681 bridge ID of ABridges have a lower value than that of standard 682 bridges (midrange). An ABridge may in this way become the root 683 bridge of any link. DR election and root bridge election are 684 one and the same operation, performed according to the 685 standard procedure [5]. In this way DR election does not 686 depend on any external mechanism and convergence time at links 687 does not add up to the convergence time of DR election at IS- 688 IS as in the RBridge case. The complete DR election process is 689 avoided. 691 4.6 Forwarding scenario 693 Now the basic forwarding scenario is described. Figure 4 shows 694 two hosts H1 and H2 connected at different access networks. 695 First the ARP and destination ABridge resolution are 696 described, and then the forwarding process. 698 4.6.1 ARP and ABridge Resolution 700 Using ARP servers is the optional mechanism proposed to limit 701 broadcast/multicast traffic. However, the standard ARP 702 mechanism must be kept to ensure that hosts that silently move 703 from one part of the campus to another can be located. 705 Besides ARP for host resolution, the servers may also be used 706 for resolution of the destination ABridge. Each server stores 707 a table with tuples containing the IP, L2 address of the end 708 node and L2 address of the Designated Bridge (Root ABridge). 709 The set of stored tuples corresponds to IP addresses that 710 produce identical (few bits) hash results of IP destination 711 end node. 713 The sequence for communication between H1 and H2 at figure 4 714 is as follows: 715 Host H1 first sends a broadcast ARP packet to get the 716 resolution of host H2s L2 address. The packet is distributed 717 through the spanning tree of the access network and arrives at 718 the root ABridge. The root ABridge detects the ARP, calculates 719 hash(IP destination address) and with the result obtains the 720 server responsible for that IP address. The server performs a 721 look up using H2s IP destination address and obtains the H2 L2 722 address and the (egress) ABridge ID of that access network, 723 then sends the reply in a packet to the ingress ABridge. The 724 ABridge extracts the information and forwards a standard ARP 725 response packet to host H1. Host H1 can then proceed to send 726 packets with the L2 address of host H2. The ingress ABridge 727 also registers the originating host by sending a registration 728 packet containing the ARP packet to the corresponding 729 ARP/ABridge server, obtained by computing hash(IP origin). 731 G.Ibanez Informational expires Dec 6, 2006 13 732 b---b 733 b: standard bridge / Access Layer 734 A: ABridge b---b 735 Path: H1-b-b-b-A-A-A-b-b-b-H2 / ............. 736 A A 737 \\ \\ Core layer 738 \\ \\ 739 A======A=====A 740 / \ \ .......... 741 / \ \ Access Layer 742 H1---- b---b--b b b---b---b----H2 743 / / / \ \ 744 b-/ b---b b- b b-b b---b---b 746 Figure 4. End to End forwarding scenario 748 Note: If the destination host is connected to the same access 749 network, the host will reply directly by emitting an ARP 750 response packet. 752 Note: The ABridge registers a host at the corresponding ARP 753 Server/Registrar whenever it detects a frame from an unknown 754 host connected at its access network. 756 4.6.2 Forwarding 758 The frame forwarding process is as follows: the standard frame 759 sent by host (IP(H2), L2(H2)) arrives to the Access network 760 root bridge (ABridge). Its DA Ethernet Address contains the 761 end node destination address. The root ABridge (Designated) 762 looks at its cache for the ID of the destination end nodes 763 designated ABridge (that was filled just before with the 764 ARP/ABridge server response). The ABridge still has in its 765 cache the pair (L2 address, L2 egress ABridge) obtained before 766 and encapsulates the frame with a header like this: (DA egress 767 ABridge, SA ingress ABridge, Ethertype: AMSTP). It then 768 determines the applicable tree instance by looking at the 769 destination ABridge and forwards it through the port that was 770 elected root for the ABridge destination instance. The packet 771 arrives at the Designated Port of the next ABridge, which then 772 inspects it and forwards it to the outer destination MAC 773 address using the corresponding tree instance to obtain the 774 root port of that instance. The packet is forwarded again via 775 the root port till the egress ABridge is reached. The egress 776 ABridge detects that it is the destination of the frame, 777 removes the encapsulation header of the frame and forwards the 778 original frame via the access port where the L2 host has been 779 learnt or via all access ports if H2 is unknown. The packet 780 goes from the egress bridge (root) to H2 following a branch of 781 the tree rooted at the egress bridge. Frame forwarding in the 782 access networks is performed in the standard way with the 783 spanning tree set up by STP or RSTP. A packet exiting the 784 ABridge by an access port must look to ordinary bridges like 785 an ordinary layer 2 packet and must not be encapsulated. 787 G.Ibanez Informational expires Dec 6, 2006 14 788 The ABridge may learn the destination ABridge by host list 789 interchange. The forwarding behaviour of RBridges is as 790 follows: "When a DR R1 receives a native packet with layer 2 791 address S and layer 2 destination address D, R1 looks up the 792 location of D. If D is claimed by egress RBridge R2, then R1 793 encapsulates the packet, directing it towards R2". ABridges 794 may use the same behaviour, but in this case network size 795 might not scale to one hundred thousand end nodes--the Campus 796 Transit Tables (CTT) would be too big. 798 In contrast to an RBridge, when an ABridge receives an 799 encapsulated packet, it forwards it based on the DA ABridge 800 and does not change the DA for the "next-hop" address. The 801 next hop is selected by forwarding the frame via the root port 802 of tree instance rooted at the destination ABridge. A packet 803 in the core must look like an Ethernet frame, but must be 804 differentiable from a native layer 2 packet by ABridges. To 805 accomplish this, a new layer 2 protocol type ("Ethertype") is 806 used. 808 4.7 Learning End node Location 810 ABridges learn end node location in access ports as standard 811 bridges do. ABridges learn root bridge IDs of the multiple 812 instances of core from AMSTP BPDUs received. 814 Similarly to RBridges, the Core (Edge) ABridge, acting as root 815 and Designated RBridge, might work in two modes: 816 - As a standard Designated RBridge, that learns the L2 817 addresses of attached end nodes, initiates a distributed 818 ARP when an ARP query is received for an unknown 819 destination, and answers ARP queries when the target node 820 is known. This mechanism is an alternative to the use of 821 ARP Servers/Registrars 822 - From data packets. They learn (layer 3, layer 2) pairs 823 (for the purpose of supporting proxy ARP/ND) from 824 listening to ARP or ND replies. 826 4.8 Routing in ABridges vs Learning Bridges Addresses 828 Some recent proposals like Shortest Path Bridging (SPB), as 829 proposed at the IEEE [12][13], use also multiple tree 830 instances rooted at edge bridges. However it presents the 831 problem of asymmetrical spanning trees. This happens when the 832 tree rooted at bridge A differs in chosen path A-B from the 833 path chosen by the tree rooted at B to A. The problem occurs 834 when there are ties in the path costs of tree instances. In 835 the instance with node A as root the tie may be solved by 836 choosing one path. In the instance with node B as root the tie 837 may be solved choosing a different path. But the spanning 838 trees must be symmetrical for the address learning to work 839 correctly: the address learnt at one port of B sent by A (via 840 spanning tree A to B), if forwarded via same port through the 841 opposite direction spanning tree (B to A) might find the path 842 blocked due to a different root port election at A for the 843 tree instance rooted at B. 845 G.Ibanez Informational expires Dec 6, 2006 15 846 ABridges work differently because they do not learn addresses. 847 ABridges only build spanning trees and assign traffic to them 848 according to the destination ABridge. AMSTP uses always the 849 root port to send frames to the destination bridge (instance 850 rooted at destination), so the routing function for ABridge is 851 as follows: 852 - The bridge ID of the destination corresponding to the 853 destination end node is obtained from the ABridge Server. 854 - The bridge ID of the destination is translated to the 855 port MAC destination address of the destination ABridge 856 at the internal ABridge table. 857 - The frame is encapsulated with an external L2 header with 858 Destination Bridge ID. 859 - ABridges only forward a frame received at a designated 860 port, upstream, via the root port. The L2 external 861 destination address can be the Destination Bridge ID 862 itself. When the encapsulated frame arrives at the 863 destination bridge, it must identify its Bridge ID in the 864 DA and remove the L2 encapsulation of the frame and 865 forward it downstream to the access network via access 866 port(s). 868 4.9 Header on 802 Links 870 ABridges, as RBridges, must coexist with ordinary bridges. 871 The encapsulated L2 format must be compatible with the 872 Ethernet format. No additional fields like TTL are required 873 if the fast convergence mechanism procedure of RSTP is used. 875 An encapsulated packet would look as follows: 877 +--------------+----------------+---- 878 | outer header |original packet |CRC| 879 +--------------+----------------+---- 881 Figure 5 Encapsulated packet 883 The outer header contains: 885 o L2 destination = destination (egress) ABridge 887 o L2 source = origin (ingress) ABridge 889 o protocol type = "to be assigned...ABridge encapsulated 890 packet" (AMSTP) 892 4.10 Distributed ARP Query 894 ABridges may perform distributed ARP Query as RBridges do, 895 but for large campus networks, it is recommended the use of 896 ARP/ABridge servers/ registrars to reduce multicast traffic 897 and processing load at end nodes. 899 4.11 ABridge identities and addresses. 901 G.Ibanez Informational expires Dec 6, 2006 16 902 Each ABridge needs a unique ID within the campus. The 903 simplest such address is a unique 6-byte ID, since such an ID 904 is easily obtainable as any of the EUI-48's owned by that 905 ABridge. 907 A new Ethertype must be assigned to indicate an ABridge- 908 encapsulated packet. 910 A layer 2 multicast address is used as the "all ABridges" 911 destination address in distributed ARP queries and any other 912 intercommunication message. 914 An optional layer 2 multicast address is needed to address to 915 "all ARB/ABridge" servers" (if used), to communicate among 916 them the available servers and the hash value(s) supported. 918 The AMSTP protocol distributes BPDUs addressed to the local 919 multicast protocol addresses used by the spanning tree 920 protocol (Bridge Group Address 01-80-C2-00-00-00). These 921 addresses are neither forwarded by bridges nor by RBridges or 922 ABridges. 924 5. ARP/ABridge Servers/Registrars 926 ABridges, as RBridges, may suppress the broadcast/multicast 927 for neighbour discovery by doing proxy ARP (IPv4) or proxy ND 928 (IPv6). However the mechanism proposed for large campus 929 networks to suppress broadcast/multicast for neighbour 930 discovery consists of ARP servers/registrars, where end nodes 931 are registered upon frame detection by the Designated 932 ABridge. 934 Although all ARP/ABridge servers might work in parallel, it 935 seems more efficient to perform statistical uniform load 936 distribution between servers, distributing the IP addresses 937 to resolve among the available servers by a hashing based 938 mechanism. The process is as follows: When a host issues an 939 ARP packet, the packet is forwarded up across the spanning 940 tree of the access network up to the root bridge (ABridge). 941 The ABridge, acting as Designated ABridge, performs hashing 942 of the destination IP. With this hash result the ABridge 943 obtains the ARP/ABridge server ID in charge of that IP 944 address. This server ID was previously obtained from 945 announcement packets from ARP servers containing its IP 946 address, L2 address, server ID and hash values that it 947 serves. 948 The ABridge encapsulates the ARP packet originated by endnode 949 with an additional L2 header with the destination address of 950 the corresponding server for ARP resolution. 951 The ABridge also prepares a registering packet with the IP 952 origin in order to register (or refresh) the host originating 953 the ARP into the corresponding ARP/ABridge server. 955 To avoid redundant load on ARP/ABridge servers, they must 956 share the load by assigning server IDs according to the 957 result of hash (IP destination). The total number of servers 959 G.Ibanez Informational expires Dec 6, 2006 17 960 may be dimensioned according to the length of the hash 961 results used or by additional grouping. An additional 962 protocol between ARP/ABridge servers can be designed to 963 handle dynamic load splitting among the available 964 servers/registrars as they come into and out of service. A 965 server coming into service takes charge of a hash value 966 handed out by a running server. The new server performs the 967 new registrations, and forwards unsolved requests to the 968 previous server. After the expiration time of the first 969 registration performed at new server is reached, the handover 970 process is complete as no valid registries remain in previous 971 server. 973 6. Issues 975 In this section the identified issues, either for RBridges, 976 ABridges or both, are described or commented. 978 6.1 Per Ingress Spanning Tree. 980 Per Ingress multicast spanning Tree is implemented by default 981 with ABridges. Multicast paths always traverse minimum hops. 982 There is no issue here. 984 6.2 Symmetrical Paths Problem. 986 Shortest Path Bridging [SPB], the current proposal at IEEE 987 for pair-wise shortest path, depends on symmetrical tree 988 instances between bridges pairs for the L2 addresses learning 989 to work properly. In case of a path cost tie during tree 990 instances calculation, different paths might be elected in 991 opposite directions. The proposal at [13] describes a change 992 in MSTP Protocol to prevent this, but convergence times 993 increase. 995 ABridges are not subject to this problem because they forward 996 unicast traffic through one branch of the destination ABridge 997 tree instance. Packets are forwarded in ABridges via its port 998 elected as the root of the destination ABridge tree instance. 999 Unicast forwarding in the core campus always follows the path 1000 from Designated Port to root port at each ABridge traversed 1001 till reaching the destination. No address learning is used 1002 for filtering as the packet is always forwarded via one port 1003 (root port of ABridge). 1005 6.3 Traffic Aggregation at Root. 1007 A usual argument against spanning trees is that the traffic 1008 accumulates near the root bridge, provoking congestion. The 1009 real situation in campus networks is that traffic, 1010 predominantly client-server, distributes in a tree form. 1011 However, bridge design and Ethernet technologies with their 1012 various speeds (100 Mbps, 1 Gbps, 10 Gbps) currently make 1013 efficient switch designs possible (like N*100 Mbps with two 1 1014 Gbps uplinks) that aggregate traffic efficiently. 1016 G.Ibanez Informational expires Dec 6, 2006 18 1017 6.4 VLANs 1019 VLAN usage in campus core requires detailed configuration of 1020 which ABridge port belongs to which VLAN. 1022 ABridges may learn, as VLAN aware bridges, which port belongs 1023 to which VLAN by inspecting the incoming VLAN tagged frames. 1024 This may help simplify VLAN configuration in ABridges but 1025 does not eliminate the need to configure VLANs in campus 1026 networks: Tagged VLAN frames must be generated either by 1027 manually configured bridges or by hosts originating the 1028 frames. In the hosts case, a system to assign a VLAN to each 1029 host must be set up via a dynamic VLAN server that requires 1030 configuration. 1032 VLANs are used to separate broadcast domains. Frames are 1033 broadcast in ABridges when the destination is unknown. The 1034 tree instance used by the ingress ABridge to broadcast is its 1035 own tree instance rooted at that ABridge. To limit broadcast 1036 to the ports belonging to the VLAN, it is necessary to filter 1037 by VLAN, which means that separate tree instances must be 1038 built for VLAN forwarding, increasing the complexity or at 1039 least requiring additional filtering on the tree instance 1040 used for broadcast, performed using the VLAN tag inside the 1041 encapsulated frame. 1043 The recommendation, as default behaviour, is that VLAN tagged 1044 frames are encapsulated in the same way as non VLAN tagged 1045 frames and no VLAN specific forwarding is performed in the 1046 ABridges. 1048 6.5 Optimizing ARP/ND 1049 Mechanisms proposed for RBridges for ARP/ND optimization 1050 [10] are feasible in ABridges as well. However, if proposed 1051 ARP/ABridge servers are used for ARP and destination ABridge 1052 resolution they become redundant. 1054 7. Security Considerations [To be added] 1056 As for RBridges, the objective of ABridges is to keep at 1057 least the same security level of bridged networks, not 1058 introducing additional risks. 1060 However the position of ABridges and their role as Root 1061 Bridges combined with the use of ARP Servers/Registrars 1062 allow efficient means to enhance the network security due to 1063 easier localization of attackers, fast detection of spoofed 1064 MACs by successive and duplicated, inconsistent registries, 1065 etc. 1067 If IEEE 802.1X is used in link ports connecting ABridges, 1068 security is greatly enhanced in the network core, although 1069 it can not prevent malicious behaviour of trusted 1070 authenticated ABridges. 1072 G.Ibanez Informational expires Dec 6, 2006 19 1073 However, authentication requires some additional 1074 configuration, which contradicts in part the zero 1075 configuration objective of RBridges and ABridges. 1077 8. IANA Considerations. 1078 A new Ethertype must be assigned to indicate an ABridge- 1079 encapsulated packet. 1080 A layer 2 multicast address is used as the "all ABridges" 1081 destination address in distributed ARP queries and any other 1082 intercommunication message. 1083 An optional layer 2 multicast address is needed to address to 1084 "all ARB/ABridge servers" (if used), to communicate among 1085 them the available servers and the hash value(s) supported. 1086 A new Ethertype is required for AMSTP protocol. 1087 If ARP/ABridge servers-registrars are used, a L2 group 1088 multicast address is required. 1090 9. NRSTP Protocol. 1091 This concept is in its early stages, and requires detailed 1092 analysis and is described summarily here due to its 1093 simplicity. 1094 An alternative to implementing multiple simplified spanning 1095 trees like AMSTP might consist of a simultaneous and 1096 independent construction of N spanning trees (one per 1097 ABridge) by full independent execution of N RSTP protocols 1098 (single code, multiple data) at each ABridge. Each ABridge 1099 executes RSTP protocol N times simultaneously to participate 1100 in N tree instances. In one of the N protocol executions, the 1101 ABridge claims itself as the nonnegotiable root bridge. At 1102 the same time, with the other N-1 RSTP protocol executions, 1103 the ABridge joins the N-1 RST tree instances proposed by the 1104 other N-1 ABridges of the core. As for AMSTP, the destination 1105 ABridge tree instance is used to forward unicast frames, 1106 while for broadcast and multicast, the originating ABridge 1107 tree instance is used. The number of BPDUs is multiplied, but 1108 processing and implementation may be simplified. 1110 10. Conclusions 1112 An alternative implementation for RBridges has been 1113 described. It provides pair-wise shortest paths using 1114 multiple L2 spanning trees across ABridges instead of link 1115 state L2 routing. The proposal has lower computational 1116 complexity than RBridges and is scalable to large scale 1117 Ethernet campus networks. A topological restriction, 1118 automatically controlled, is introduced: core forwarding only 1119 operates on dedicated links that interconnect ABridges. 1120 Obtainable convergence is likely similar to that obtained by 1121 the standard IEEE Rapid Spanning Tree protocol, less than 2 1122 seconds, typically in the hundreds of milliseconds range. The 1123 design is compatible with current IP nodes and routers and 1124 with standard bridges, but any connected standard bridge 1125 connected to an ABridge always works outside the network 1126 core, in the access layer. 1128 11. Acknowledgments 1130 This draft used the current RBridges draft as a basis for the 1131 structure, and for some of the text, to aid 1132 comprehension and to aid comparison between the two. 1134 Thanks to Matt Hutton who performed the English language 1135 review. 1137 For feedback and contributions, join the RBridge mailing list 1138 at http://www.postel.org/rbridge 1140 G.Ibanez Informational expires Dec 6, 2006 20 1141 12. References 1143 [1] Bradner, S."Key words for use in RFCs to Indicate 1144 Requirement Levels" BCP 14, RFC 2119, March 1997. 1146 [2] The RBridge archives. http://www.postel.org/pipermail/ 1147 rbridge/ 1149 [3] Rapid Reconfiguration of Spanning Tree. http://www. 1150 ieee802.org/1/pages/802.1w.html 1152 [4] IEEE 802.1D.IEEE-1998 IEEE standard for local and 1153 metropolitan area networks--Common specifications--Media 1154 access control (MAC) Bridges. 1156 [5] IEEE 802.1D-2004 IEEE standard for local and metropolitan 1157 area Networks-- Common specifications--Media access control 1158 (MAC) Bridges. 1160 [6] IEEE 802.1Q-2003 IEEE standard for Local and Metropolitan 1161 Area Networks- Virtual Bridged Local Area Networks. 1163 [7] G. Ibanez, A. Garcia, A. Azcorra. Alternative Multiple 1164 Spanning Tree Protocol (AMSTP) for Optical Ethernet 1165 Backbones. IEEE HSLN (LCN 2004). Tampa, Nov. 2004 1167 [8] Plummer, D., "Ethernet Address Resolution Protocol: Or 1168 converting network protocol addresses to 48.bit Ethernet 1169 address for transmission on Ethernet hardware", STD 37, RFC 1170 826, November 1982. 1172 [9] Narten, T., Nordmark, E. and W. Simpson, "Neighbour 1173 Discovery for IP Version 6 (IPv6)", RFC 2461 (Standards 1174 Track), December 1998. 1176 [10] Perlman, R., "RBridges: Transparent Routing", Proc. 1177 Infocom 2004. 1179 [11] R. Perlman, J. Touch, A. Yegin. RBridges: Transparent 1180 Routing draft-perlman-rbridge-03.txt May 2005. 1181 http://www.ietf.org/internet-drafts/draft-perlman-rbridge- 1182 03.txt 1184 [12] M. Seaman. Shortest Path Bridging. http://www.ieee802. 1185 org/1/files/public/docs2005/ new-seaman-shortest-path-par- 1186 0405-02.htm. 1188 [13] N. Finn. "An Update on Networking Technologies". 1189 http://www.ieee802.org/802_tutorials/july05/nfinn-shortest 1190 path-bridging.pdf 1192 [14] A. Iwata, et al., "Global Open Ethernet Architecture for 1193 a Cost-Effective Scalable VPN Solution,"IEICE Trans. On 1194 Communications, E87-B, 1, pp.142-151, Jan. 2004. 1196 G.Ibanez Informational expires Dec 6, 2006 21 1197 Author's Addresses 1199 Guillermo Ibanez 1200 Universidad Carlos III Madrid 1201 Email: gibanez@it.uc3m.es 1203 Alberto Garcia 1204 Universidad Carlos III Madrid 1205 Email: alberto@it.uc3m.es 1207 Arturo Azcorra 1208 Universidad Carlos III Madrid 1209 Email: azcorra@it.uc3m.es 1211 Intellectual Property Statement 1213 The IETF takes no position regarding the validity or scope 1214 of any Intellectual Property Rights or other rights that might 1215 be claimed to pertain to the implementation or use of the 1216 technology described in this document or the extent to which 1217 any license under such rights might or might not be available; 1218 nor does it represent that it has made any independent effort 1219 to identify any such rights. Information on the procedures 1220 with respect to rights in RFC documents can be found in BCP 78 1221 and BCP 79. 1223 Copies of IPR disclosures made to the IETF Secretariat and 1224 any assurances of licenses to be made available, or the result 1225 of an attempt made to obtain a general license or permission 1226 for the use of such proprietary rights by implementers or 1227 users of this specification can be obtained from the IETF on- 1228 line IPR repository at http://www.ietf.org/ipr. 1230 The IETF invites any interested party to bring to its 1231 attention any copyrights, patents or patent applications, or 1232 other proprietary rights that may cover technology that may be 1233 required to implement this standard. Please address the 1234 information to the IETF at ietf-ipr@ietf.org. 1236 Disclaimer of Validity 1238 This document and the information contained herein are 1239 provided on an 1240 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1241 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET 1242 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 1243 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1244 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1245 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1246 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 1247 PURPOSE. 1249 Copyright Statement 1251 Copyright (C) The Internet Society (2006). 1253 G.Ibanez Informational expires Dec 6, 2006 22 1254 INTERNET DR abridge June 6, 2006 1256 This document is subject to the rights, licenses and 1257 restrictions contained in BCP 78, and except as set forth 1258 therein, the authors retain all their rights. 1260 G.Ibanez Informational expires Dec 6, 2006 23