idnits 2.17.1 draft-ietf-trill-rbridge-arch-05.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1632. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1608. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1615. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1621. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5895 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-trill-rbridge-protocol-05 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Eric Gray, Editor 3 Internet Draft Ericsson 4 Expires: August, 2008 5 Intended Status: Informational 6 February 25, 2008 8 The Architecture of an RBridge Solution to TRILL 9 draft-ietf-trill-rbridge-arch-05.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that 14 any applicable patent or other IPR claims of which he or she is 15 aware have been or will be disclosed, and any of which he or she 16 becomes aware will be disclosed, in accordance with Section 6 of 17 BCP 79. 19 Internet-Drafts are working documents of the Internet 20 Engineering Task Force (IETF), its areas, and its working 21 groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as "work 28 in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on January 25, 2008. 38 Abstract 40 RBridges are link layer (L2) devices that use a routing protocol 41 as a control plane. This combines several of the benefits of the 42 link layer with those of the network layer. For example RBridges 43 use existing link state routing, without necessarily requiring 44 configuration, to improve aggregate throughput, for RBridge to 45 RBridge traffic. RBridges also may support IP multicast and IP 46 address resolution optimizations. They are intended to be 47 applicable to L2 network sizes similar to those of conventional 48 bridges and are intended to be backward compatible with those 49 bridges as both ingress/egress and transit. They also support 50 VLANs (although this generally requires configuration) while 51 otherwise attempting to retain as much 'plug and play' as is 52 already available in existing bridges. This document proposes an 53 architecture for RBridge systems as a solution to the TRILL 54 problem, defines terminology, and describes basic components and 55 desired behavior. One (or more) separate documents will specify 56 protocols and mechanisms that satisfy the architecture presented 57 herein. 59 Table of Contents 61 1. Introduction................................................4 62 2. Background..................................................7 63 2.1. Existing Terminology...................................7 64 2.2. RBridge Terminology...................................10 65 3. Components.................................................12 66 3.1. RBridge Device........................................13 67 3.2. RBridge Data Model....................................14 68 3.2.1. Unicast TRILL Forwarding Database................14 69 3.2.2. Multi-destination TRILL Forwarding Database......14 70 3.2.3. Ingress TRILL Forwarding Database................16 71 4. Functional Description.....................................17 72 4.1. TRILL Campus Auto-configuration.......................17 73 4.2. RBridge Peer Discovery................................18 74 4.3. Topology Discovery....................................18 75 4.4. Determination of End Station Points of Attachment.....18 76 4.5. Learning..............................................19 77 4.6. Tunneling.............................................19 78 5. RBridge Operation..........................................20 79 5.1. RBridge General Operation.............................20 80 5.2. Ingress/Egress Operations.............................21 81 5.3. Transit Forwarding Operations.........................24 82 5.3.1. Unicast..........................................25 83 5.3.2. Broadcast, Multicast and Flooding................25 84 5.3.2.1. Broadcast...................................25 85 5.3.2.2. Multicast...................................27 86 5.3.2.3. Flooding....................................28 87 5.4. Routing Protocol Operation............................30 88 5.5. Other Bridging and Ethernet Protocol Operations.......30 89 5.5.1. Wiring Closet Problem............................31 90 6. How RBridges Address the TRILL Problem Space...............32 91 7. Conclusions................................................32 92 8. Security Considerations....................................33 93 9. IANA Considerations........................................34 94 10. Acknowledgments...........................................34 95 11. References................................................34 96 11.1. Normative References.................................34 97 11.2. Informative References...............................34 98 12. Author's Addresses........................................35 99 Intellectual Property Statement...............................35 100 Disclaimer of Validity........................................36 101 Copyright Statement...........................................36 102 Acknowledgment................................................36 104 1. Introduction 106 This document describes an architecture that addresses the TRILL 107 problem and applicability statement [2]. This architecture 108 describes a solution that is composed of a set of devices called 109 RBridges. RBridges cooperate together in an Ethernet network to 110 provide a layer two delivery service that makes efficient use of 111 available links using a link state routing protocol. The service 112 provided is analogous to creation of a single, virtual device 113 composed of an overlay of tunnels, constructed between RBridge 114 devices, using paths determined by link state routing. RBridges 115 thus support increased aggregate RBridge to RBridge bandwidth, 116 and fault tolerance, when compared to conventional Ethernet 117 bridges (which forward frames via a spanning tree, in a non-VLAN 118 or single VLAN context, or multiple spanning trees), while still 119 being compatible with bridges and hubs. 121 The principal objectives of this architecture is to provide an 122 overview of the use of these RBridges in meeting the following 123 goals: 125 1) Provide a form of optimized layer two delivery service. 127 2) Use existing technology as much as possible. 129 3) Allow for configuration free (or minimal configuration) 130 deployment. 132 In providing a (optimized) layer two (L2) service, key factors 133 we want to maintain are: transparency to higher layer (layer 3 134 and above) delivery services and mechanisms, and use of location 135 independent addressing. Optimization of the L2 delivery service 136 consists of: use of an optimized subset of all available paths 137 and support for optimization of ARP/ND and pruning of multicast 138 traffic delivery paths. 140 Not all optimizations are necessarily expected to be supported 141 in initial specification and some subset of these optimizations 142 may be specified at a later time. This architecture should 143 allow some level of optimization support to be provided in 144 compliant implementations, in as many case as possible. 146 To accomplish the goal of using existing technologies as much as 147 possible, we intend to specify minimal extensions to an existing 148 link-state routing protocol, as well as defining specific sub- 149 sets of existing bridging technologies that this architecture is 150 intended to makes use of. 152 The extent to which routing protocol extensions may be required 153 depends on the closeness of the "fit" of the chosen routing 154 protocol (in this case, IS-IS) to RBridge protocol requirements. 155 The specific of routing protocol use - along with appropriate 156 extensions and enhancements - will be defined in corresponding 157 RBridge protocol specifications (see [3] for example). 159 Specific protocol specifications will also describe the details 160 of interactions between the RBridge protocol and specific L2 161 technologies - i.e. - Virtual Local Area Networking (VLAN), L2 162 Multicast, etc. This document describes the general nature of 163 the RBridge solution without restricting related specifications. 165 As an overview, however, the intention is to use a link-state 166 routing protocol to accomplish the following: 168 1) Discover RBridge peers. 170 2) Determine RBridge link topology. 172 3) Potentially advertise L2 reachability information; note 173 that - at this time - the default method for acquiring L2 174 reachability information specified in [3] depends on use of 175 data-plane learning (see Bridge Learning in the terminology 176 section below). 178 4) Establish L2 delivery using shortest path (verses STP, RSTP 179 or MSTP). 181 There are additional RBridge protocol requirements - above and 182 beyond those addressed by any existing routing protocol - that 183 are identified in this document and need to be addressed in 184 corresponding RBridge protocol specifications. 186 To allow for configuration free deployment, specific protocol 187 specifications should explicitly define the conditions under 188 which RBridges may - and may not - be deployed as-is (plug and 189 play), and the mechanisms that are required to allow this. For 190 example, the first requirement any RBridge protocol must meet is 191 to derive information required by link-state routing protocol(s) 192 for protocol start-up and communications between peers - such as 193 higher-layer addressing and/or identifiers, encapsulation header 194 information, etc. 196 At the abstract level, RBridges need to maintain the following 197 information: 199 1) Peer information, 201 2) Topology information, 203 3) Forwarding information - 205 a. unicast, 207 b. flooded, and 209 c. multicast. 211 In addition, RBridge specifications may suggest (or require) the 212 maintenance of other information as needed to support ARP/ND and 213 multicast optimizations. 215 Peer information may be acquired via the routing protocol, or 216 may be discovered as a result of RBridge-specific peer discovery 217 mechanisms. Details of specific peer information requirements - 218 as well as how this information will be acquired is specified in 219 protocol specifications (e.g. - [3]). 221 Topology information is expected to be acquired via the link- 222 state routing protocol. 224 In addition to the requirement that the routing protocol should 225 be an existing link-state routing protocol, which may provide a 226 mechanism for (or re-use of an existing) neighbor/peer 227 discovery, the routing protocol should be able to work with 228 minimal (or no) configuration - using algorithmically derived 229 addressing, for example, assuming the use of addresses is 230 required. 232 Given the potential choices, IS-IS routing has been chosen at 233 this time, and is assumed in this architecture. The fact that 234 this is assumed in this architecture is - in no way - intended 235 to preclude use of another link-state routing protocol, or any 236 other routing protocol, in any solution not described in this 237 architecture. 239 Forwarding information is derived from the combination of 240 attached MAC address learning, snooping of multicast-related 241 protocols (e.g. - IGMP), and routing advertisements and path 242 computations using the link-state routing protocol. 244 Other information - such as the mapping of MAC and IP addresses, 245 or multicast pruning information - may be learned using snooping 246 of ARP/ND or IGMP (for example) and it is possible that RBridges 247 may need to participate actively in these protocols. 249 The remainder of this document outlines the TRILL architecture 250 of an RBridge-based solution and describes RBridge components, 251 interactions and functions. Note that this document is not 252 intended to represent the only solution to the TRILL problem 253 statement, nor does it specify the protocols that instantiate 254 this architecture - or that only one such set of protocols is 255 prescribed. The former may be contained in other architecture 256 documents and the latter would be contained in separate 257 specification documents (see - e.g. - [3]). 259 2. Background 261 This architecture is based on the RBridge system described in an 262 Infocom paper [1]. That paper describes the RBridge system as a 263 specific instance; this document abstracts architectural 264 features only. The remainder of this section describes the 265 terminology of this document, which may differ from that of the 266 original paper. 268 2.1. Existing Terminology 270 The following terminology is defined in other documents. A brief 271 definition is included in this section for convenience and - in 272 some cases - to remove any ambiguity in how the term may be used 273 in this document, as well as in derivative documents intended to 274 specify components, protocol, behavior and encapsulation 275 relative to the architecture described in this document. 277 o IEEE 802.1D and IEEE 802.1Q: IEEE documents which include 278 specification for bridged Ethernet, including Media Access 279 Control (MAC) bridges and the BPDUs used in spanning tree 280 protocol (STP) [5], [8]. 282 o ARP: Address Resolution Protocol - a protocol used to find an 283 address of form X, given a corresponding address of form Y. 284 In this document, ARP refers to the well-known protocol used 285 to find L2 (MAC) addresses, using a given L3 (IP) address. 286 See [7] for further information on IP ARP. 288 o Bridge: an Ethernet (L2, 802.1D) device with multiple ports 289 that receives incoming frames on a port and transmits them on 290 zero or more of the other ports; bridges support both bridge 291 learning and STP. Transparent bridges do not modify the L2 292 PDU being forwarded. 294 o Bridge Learning: process by which a bridge determines on 295 which (if any) single outgoing port to transmit (forward or 296 copy) an incoming unicast frame. This process depends on 297 consistent forwarding as "learning" uses the source MAC 298 address of frames received on each interface. Layer 2 (L2) 299 forwarding devices "learn" the location of L2 destinations by 300 peeking at layer 2 source addresses during frame forwarding, 301 and store the association of source address and receiving 302 interface. L2 forwarding devices use this information to 303 create "filtering database" entries and - gradually - 304 eliminate the need for flooding. 306 o Bridge Protocol Data Unit (BPDU): the frame type associated 307 with bridge control functions (for example: STP/RSTP). 309 o Bridged LAN: see IEEE 802.1Q-2005, Section 3.3 [8]. 311 o Broadcast Domain: the set of (layer 2) devices that must be 312 reached (or reachable) by (layer 2) broadcast traffic 313 injected into the domain. 315 o Broadcast Traffic: traffic intended for receipt by all 316 devices in a broadcast domain. 318 o Ethernet: a common layer 2 networking technology that 319 includes, and is often equated with, 802.3. 321 o Filtering Database: database containing association 322 information of (source layer 2 address, arrival interface). 323 The interface that is associated with a specific layer 2 324 source address, is the same interface which is used to 325 forward frames having that address as a destination. When a 326 layer 2 forwarding device has no entry for the destination 327 layer 2 address of any frame it receives, the frame is 328 "flooded". 330 o Flooded Traffic: traffic that is subject to flooding - i.e. - 331 being forwarded on all interfaces, except the one on which it 332 was received, within a LAN or VLAN. 334 o Flooding: the process of forwarding traffic to ensure that 335 frames reach all possible destinations when the destination 336 location is not known. In "flooding", an 802.1D forwarding 337 device forwards a frame for any destination not "known" (i.e. 338 - not in the filtering or forwarding database) on every 339 active interface except that one on which it was received. 340 See also VLAN flooding and flooded traffic. 342 o Frame: in this document, frame refers to an Ethernet (L2) 343 unit of transmission (PDU), including header, data, and 344 trailer (or payload and envelope). 346 o Hub: Ethernet device with multiple ports that transparently 347 transmits frames arriving on any port to all other ports. 348 This is a functional definition, as there are devices that 349 combine this function with certain bridge-like functions that 350 may - under certain conditions - be referred to as "hubs". 352 o IS-IS: Intermediate System to Intermediate System routing 353 protocol. [6] for further information on IS-IS. 355 o LAN: Local Area Network, is a computer network covering a 356 small geographic area, like a home, office, or group of 357 buildings, e.g., as based on IEEE 802.3 technology, see also 358 IEEE 802.1Q-2005, Section 3.11 [8]. 360 o MAC: Media Access Control - mechanisms and addressing for L2 361 frame forwarding. 363 o Multicast Forwarding: forwarding methods that apply to frames 364 with broadcast or multicast destination MAC addresses. 366 o Node: a device with an L2 (MAC) address that sources and/or 367 sinks L2 frames. 369 o Packet: in this document, packet refers to L3 (or above) data 370 transmission units (PDU - e.g. - an IP Packet (RFC791 [4]), 371 including header and data. 373 o PDU: Protocol Data Unit - unit of data to be transmitted by a 374 protocol. To distinguish L2 and L3 PDUs, we refer to L2 PDUs 375 as "frames" and L3 PDUs as "packets" in this (and related) 376 document(s). 378 o Router: a device that performs forwarding of IP (L3) packets, 379 based on L3 addressing and forwarding information. Routers 380 forward packets from one L2 broadcast domain to another (one, 381 or more in the IP multicast case) - distinct - L2 broadcast 382 domain(s). A router terminates an L2 broadcast domain. 384 o Spanning Tree Protocol (STP): an Ethernet (802.1D) protocol 385 for establishing and maintaining a single spanning tree among 386 all the bridges on a local Ethernet segment. Also, Rapid 387 Spanning Tree Protocol (RSTP). In this document, STP and RSTP 388 are considered to be the same. 390 o SPF: Shortest Path First - an algorithm name associated with 391 routing, used to determine a shortest path graph traversal. 393 o TRILL: Transparent Interconnect over Lots of Links - the 394 working group and working name for the problem domain to be 395 addressed in this document. 397 o Unicast Forwarding: forwarding methods that apply to frames 398 with unicast destination MAC addresses. 400 o Unknown Destination - a destination for which a receiving 401 device has no filtering database entry. Destination (layer 402 2) addresses are typically "learned" by (layer 2) forwarding 403 devices via a process commonly referred to as "bridge 404 learning" (see definition above). 406 o VLAN: Virtual Local Area Network, see IEEE 802.1Q-2005 [8]. 408 o VLAN Flooding: flooding as described previously, except that 409 frames are only forwarded on those interfaces configured for 410 participation in the applicable VLAN. 412 2.2. RBridge Terminology 414 The following terms are defined in this document and intended 415 for use in derivative documents intended to specify components, 416 protocol, behavior and encapsulation relative to the 417 architecture specified in this document. 419 o Adjacent RBridges: RBridges that communicate directly with 420 each other without relay through other RBridges. 422 o Cooperating RBridges: a set of communicating RBridges that 423 will share a consistent set of forwarding information. 425 o Designated RBridge (DRB): one approach to resolving several 426 issues associated with having multiple RBridges as candidate 427 ingress and egress points for a single LAN (or VLAN) is to 428 designate an RBridge to act as the ingress and egress in that 429 case. The RBridge designated to handle ingress and egress 430 traffic to a specific Ethernet link (or VLAN associated with 431 that link) having shared access and multiple RBridges is such 432 a link's "Designated RBridge", or DRB. The Designated RBridge 433 may (for example) be determined by an election process among 434 those RBridges having shared access via a single LAN, or may 435 be selected by some other means. 437 o Edge RBridge (edge of a TRILL Campus): describes RBridges 438 that may serve to ingress frames into the TRILL Campus and 439 egress frames from the TRILL Campus. L2 frames transiting an 440 TRILL Campus enter, and leave, it via an edge RBridge. 442 o Egress RBridge: for any specific frame, the RBridge through 443 which that frame leaves the TRILL Campus. For frames 444 transiting a TRILL Campus, the egress RBridge is an edge 445 RBridge where RBridge encapsulation is removed from the 446 transit frames prior to exiting the TRILL Campus. 448 o Encapsulation database: in the TRILL context, the database 449 that the Ingress RBridge uses to map the layer 2 destination 450 address in the received frame to the egress Rbridge. 452 o Forwarding Tunnels: in this document, Campus Forwarding 453 Tunnels (or Forwarding Tunnels) is used to refer to the paths 454 for forwarding transit frames, encapsulated at an RBridge 455 ingress and decapsulated at an RBridge egress. 457 o Ingress RBridge: for any specific frame, the RBridge through 458 which that frame enters the TRILL Campus. For frames 459 transiting a TRILL Campus, the ingress RBridge is the edge 460 RBridge where RBridge encapsulation is added to the transit 461 traffic entering the TRILL Campus. 463 o Multi-Destination Frames: Broadcast or Multicast frames, or 464 Unicast frames destined to a MAC DA that is unknown i.e. - 465 flooded frames (see flooded traffic). Frames that need to be 466 delivered to multiple egress RBridges, via the RBridge 467 Distribution Tree. 469 o Peer RBridge: The term "Peer RBridge", or (where usage is not 470 ambiguous) the term "Peer", are used in the RBridge context 471 to refer to any of the RBridges that make up a TRILL campus. 473 o RBridge: a logical device as described in this document, 474 which incorporate both routing and bridging features, thus 475 allowing for the achievement of TRILL Architecture goals. A 476 single RBridge device which can cooperate with other RBridge 477 devices to create a TRILL Campus. 479 o RBridge Distribution Tree: This term or (where usage is not 480 ambiguous) the term "distribution tree", refers to a tree 481 used by RBridges to deliver multi-destination frames. An RDT, 482 or distribution tree, is computed using a specific RBridge as 483 the root. May also be referred to as an R-tree. 485 o TRILL Campus: this term, or the term "Campus" (where usage is 486 not ambiguous) is used in the RBridge context to refer to the 487 set of cooperating RBridges and TRILL Links that connect them 488 to each other. 490 o TRILL Forwarding Database: this term, or the term "forwarding 491 database" (where not ambiguous) is used in an RBridge context 492 to refer to the database that maps the egress TRILL address 493 to the next hop TRILL link. 495 o TRILL Header: a 'shim' header that encapsulates the ingress 496 L2 frame and persists throughout the transit of a TRILL 497 Campus, which may be further encapsulated within a hop-by-hop 498 L2 header (and trailer). The hop-by-hop L2 encapsulation in 499 this case includes the source MAC address of the immediate 500 upstream RBridge transmitting the frame and destination MAC 501 address of the receiving RBridge - at least in the unicast 502 forwarding case. 504 o TRILL Link: this term, or the term "Link" (where its usage is 505 not ambiguous) is used in the RBridge context to refer to the 506 Layer 2 connection that exists either between RBridges, or 507 between an RBridge and Ethernet end stations. 509 3. Components 511 A TRILL Campus is composed of RBridge devices and the forwarding 512 tunnels that connect them; all other Ethernet devices, such as 513 bridges, hubs, and nodes, operate conventionally in the presence 514 of an RBridge. 516 +----------------------------------------------------------+ 517 | Higher Layer Entities | 518 +--+--------------+----------------------+--------------+--+ 519 | \ TRILL Layer | RBridge Relay Entity | TRILL Layer / | 520 +---+-------------+----------------------+-------------+---+ 521 | Data Link Layer | | Data Link Layer | 522 +-----------------+ +-----------------+ 523 | Physical Layer | | Physical Layer | 524 +--------+--------+ +--------+--------+ 525 | | 526 P 1 P 2 528 Figure 1: Simplified Architecture of an RBridge 530 Figure 1 shows an RBridge that contains: 532 o An RBridge Relay Entity connecting two RBridge ports 534 o At least one physical port (two in this example) 536 o Higher layer Entities, including at least the IS-IS protocol 538 o At the TRILL Layer, an RBridge encapsulates incoming Ethernet 539 frames with a TRILL header to forward them to other RBridges. 541 3.1. RBridge Device 543 An RBridge is a device - having some of the characteristics of 544 both bridges and routers - that forwards frames on an Ethernet 545 link segment. It has one or more Ethernet ports which may be 546 wired or wireless; the particular physical layer is not 547 relevant. An RBridge is defined more by its behavior than its 548 structure, although it logically contains three tables, which 549 may be used to describe the externally visible behavior of an 550 RBridge relative to its peers and may also distinguish RBridges 551 from conventional bridges. 553 Conventional bridges contain a learned filtering (or forwarding) 554 database, and spanning tree port state information. The bridge 555 learns which nodes are accessible from a particular port by 556 assuming bi-directional consistency: the source addresses of 557 incoming frames indicate that the incoming port is to be used as 558 output for frames destined to that address. Incoming frames are 559 checked against the learned filtering (forwarding) database and 560 forwarded to the particular port if a match occurs, otherwise 561 they are flooded out all active ports (except the incoming 562 port). 564 Spanning tree port state information indicates the ports that 565 are active in the spanning tree. Details of STP operation are 566 out of scope for this document, however the result of STP is to 567 disable ports which would otherwise result in more than one path 568 traversal of the spanning tree. 570 RBridges, by comparison, have a TRILL forwarding database, used 571 for forwarding of RBridge encapsulated frames across the TRILL 572 Campus and by the ingress RBridge to determine the encapsulation 573 to use for frames received as un-encapsulated from non-RBridge 574 devices. The TRILL forwarding database is described in the 575 following sections. 577 3.2. RBridge Data Model 579 The following tables represent the logical model of the data 580 required by RBridges in forwarding unicast and multicast data 581 across a TRILL Campus. 583 3.2.1. Unicast TRILL Forwarding Database 585 The Unicast TRILL Forwarding Database is a forwarding table for 586 unicast traffic within the TRILL Campus, allowing tunneled 587 traffic to transit the TRILL Campus from ingress to egress. The 588 size of a fully populated Unicast TRILL Forwarding Database at 589 each RBridge is maximally bounded by the product of the number 590 of Adjacent RBridge peers and VLANs. 592 RBridges may have separate Unicast TRILL Forwarding Databases 593 for each VLAN, if this is supported by configuration. Note that 594 scaling concerns may dictate otherwise, either in specific of 595 RBridge protocol specification, or in deployment. The Unicast 596 TRILL Forwarding Database is continually maintained by RBridge 597 routing protocols and/or MAC learning. (see Section 5.4). 599 The Unicast TRILL Forwarding Database contains data specific to 600 RBridge forwarding for unicast traffic. The specific fields 601 contained in this table are to be defined in RBridge protocol 602 specifications. In the abstract, however, the table should 603 contain forwarding direction and encapsulation associated with 604 an RBridge encapsulated frame received - determined by the TRILL 605 "shim" header destination and VLAN (if applicable). 607 3.2.2. Multi-destination TRILL Forwarding Database 609 The Multi-destination TRILL Forwarding Database consists of a 610 set of forwarding entries used for support of RBridge 611 Distribution Trees (RDT). Multi-destination TRILL Forwarding 612 Database entries are distinct from typical Unicast TRILL 613 Forwarding Database entries because there may be zero or more of 614 them that match for any incoming frame. 616 The Multi-destination TRILL Forwarding Database may overlap the 617 Unicast TRILL Forwarding Database, or be instantiated as a 618 separate table, in specific compliant implementations. 620 In discussing entries to be included in the Multi-destination 621 TRILL Forwarding Database, the following entities are 622 temporarily defined, or further qualified: 624 o Root RBridge - the RBridge that is the head end of an RDT. 625 All RBridges within a TRILL Campus are potential Root 626 RBridges. 628 o Egress RBridge - an RBridge that is the tail end of a path 629 corresponding to a specific Multi-destination TRILL 630 Forwarding Database entry. All RBridges within a TRILL Campus 631 are potential egress RBridges. Not all RBridges within a 632 TRILL Campus will be on the shortest path between any ingress 633 RBridge and any other egress RBridge. 635 o Local RBridge - the RBridge that forms and maintains the 636 Multi-destination TRILL Forwarding Database entry (or 637 entries) under discussion. The local RBridge may be a root 638 RBridge, or an egress RBridge with respect to any set of 639 entries in the Multi-destination TRILL Forwarding Database. 641 o RBridge TRILL Campus Egress Interface - an interface on any 642 RBridge where a transit RBridge encapsulated frame would be 643 decapsulated prior to forwarding. With respect to such an 644 interface, the local RBridge is the egress RBridge. 646 Each local RBridge will maintain - as a logical representation - 647 a set of entries for at least the following, corresponding to a 648 subset of all possible forwarding paths: 650 o Zero or more entries grouped for each root RBridge - keyed by 651 some root RBridge identifier - used to determine forwarding 652 of broadcast, multicast, and flooded frames originally 653 RBridge encapsulated by that ingress within the TRILL Campus. 655 o Corresponding to each of these entry groups, one entry for 656 each of zero or more egress RBridge - where the local RBridge 657 is on the shortest path toward that egress RBridge. 659 o Corresponding to each of these entry groups, one entry for 660 each of zero or more TRILL Campus egress interfaces. 662 Each entry would contain an indication of which single interface 663 a broadcast, multicast or flooded frame would be forwarded for 664 each (root RBridge, egress RBridge) pair. Entries would also 665 contain any required encapsulation information, etc. required 666 for forwarding on a given interface, and toward a corresponding 667 specific egress RBridge. 669 Note that the above information is one logical representation of 670 the information required to perform a reverse path forwarding 671 check (or RPFC) as is discussed in [3]. 673 A local RBridge could maintain a full set of entries from every 674 RBridge to every other RBridge, however - depending on topology 675 - only a subset of these entries would ever be used. In 676 addition, a topology change that changed selection of shortest 677 paths would also very likely change other elements of the 678 entries, negating possible benefits from having pre-computed 679 Multi-destination TRILL Forwarding Database entries. 681 Multi-destination TRILL Forwarding Database entries should also 682 include VLAN identification information relative to each set of 683 Root RBridges, to allow scoping of broadcast, multicast and 684 flooding forwarding by configured VLANs. 686 Multi-destination TRILL Forwarding Database entries may also 687 include Multicast-Group Address specific information relative to 688 each egress RBridge that is a member of a given well-known 689 multicast group, to allow scoping of multicast forwarding by 690 multicast group. 692 Implicit in this data model is the assumption that the TRILL 693 "shim" header encapsulation will contain information that 694 explicitly identifies the TRILL Campus ingress RBridge for any 695 broadcast, multicast or flooded frame. 697 Maintenance of this Multi-destination TRILL Forwarding Database 698 will be defined in appropriate protocol specifications used to 699 instantiate this architecture. Note that doing this does not 700 strictly require those specification to adopt this data model. 701 The protocol specification needs to include mechanisms and 702 procedures required to establish and maintain the Multi- 703 destination TRILL Forwarding Database in consideration of 704 potential SPF recomputations resulting from network topology 705 changes. 707 3.2.3. Ingress TRILL Forwarding Database 709 The Ingress TRILL Forwarding Database determines how arriving 710 traffic will be encapsulated, for forwarding toward the egress 711 RBridge, via the TRILL Campus. It becomes configured in much the 712 same way that bridge learning occurs: by snooping incoming 713 traffic, and assuming bi-directional consistency. 715 This learned information at an egress RBridge may be propagated 716 to all other RBridges in the TRILL Campus via the RBridge 717 routing protocol, as an alternative to direct MAC learning from 718 data frames. However, the information propagated in this fashion 719 may be quite large and filtering to prevent overwhelming edge 720 RBridges would require extensive per-VLAN state information in 721 core RBridges. Hence the current model is that the default mode 722 for learning L2 reachability information is via learning from 723 the data plane directly in a manner very analogous to bridge 724 learning. 726 Using this approach, the ingress TRILL Forwarding Database may 727 be as large as the number of nodes on the Ethernet LAN, for all 728 VLANs in which a specific ingress RBridge is a participant. 730 The Ingress TRILL Forwarding Database essentially determines the 731 tunnel encapsulation used to transport each specific frame 732 across the TRILL Campus, for frames entering at this ingress. 734 4. Functional Description 736 The RBridge Architecture is largely defined by RBridge behavior; 737 the logical components are minimal, as outlined in Section 3. 739 4.1. TRILL Campus Auto-configuration 741 Cooperating RBridges self-organize to compose a single TRILL 742 Campus system. The details for how this occurs are given in 743 protocol specification(s). 745 At an architectural level, it is sufficient to note that every 746 end station attached to a TRILL Campus should have a primary 747 point of attachment to the TRILL Campus, as might be defined 748 (for example) by a Designated RBridge. Furthermore, if it is 749 possible that there are 802.1Q (or 802.1D) bridges in a local 750 LAN, the association of specific RBridges and the end stations 751 for which they act as primary point of attachment must be 752 determined in a way that is consistent with forwarding in an 753 802.1Q (or 802.1D) network. If a DRB election process were 754 used, each TRILL Link (or VLAN set within a TRILL Link) attached 755 to a TRILL Campus would have a single Designated RBridge (either 756 for the link, or for a subset of the VLANs on the link); using 757 DRBs as an example, the DRB would be where all traffic intended 758 to transit a TRILL Campus enters and exits. 760 Other approaches might be used as well. For example, the 761 primary point of attachment for each end station (or set of end 762 stations), might be configured, or determined in some other way, 763 on a per end station (or set of end stations) basis. Any such 764 approach must either allow for the possibility of LAN bridges or 765 not be used when such a possibility exists. 767 This rule applies strictly on a per-VLAN basis. 769 High-level steps that may be included in auto-configuration are: 770 RBridge peer discovery, topology discovery, determination of end 771 station points of attachment (DRB election, for example), 772 learning and forwarding (tunneling) TRILL encapsulated frames. 774 4.2. RBridge Peer Discovery 776 Proper operation of the TRILL solution using RBridges depends on 777 the existence of a mechanism for discovering peer RBridges. 778 Failure to discover all peer RBridges leads inevitably to an 779 incomplete discovery of the RBridge topology. 781 RBridge peer discovery can be accomplished in a relatively easy 782 re-use of well-known techniques based on broadcast - such as the 783 use of IS-IS "hello" messages. 785 4.3. Topology Discovery 787 Proper operation of RBridges also depends on the existence of a 788 mechanism for determining the RBridge topology. An accurate 789 determination of RBridge topology is required in order to 790 determine how traffic frames will flow in the topology and thus 791 avoid the establishment of persistent loops in frame forwarding, 792 or construction of a partitioned local LAN. 794 Fortunately, accurate topology determination is a fundamental 795 requirement of a functioning link-state routing protocol. The 796 complexity that applies in this architecture directly relates to 797 the existence of multiple VLANs on a TRILL Link. 799 For this reason, RBridges (in terms of protocol definition, 800 implementation and deployment) should avoid unnecessary use of 801 multiple VLANs - in particular on links that will be, or may be, 802 used for transit of TRILL encapsulated frames. 804 4.4. Determination of End Station Points of Attachment 806 The mechanisms and details of how end stations are associated 807 with a specific RBridge - when multiple RBridges are available 808 (connected to a local LAN or VLAN) - for the purpose of 809 providing ingress to and egress from the Rbridge Campus, will be 810 provided by protocol specification(s). A potential approach to 811 be considered is the use of a "Designated RBridge (DRB) 812 Election", on either a per link, or per VLAN (set) basis. 814 Architecturally, it is important to note that this determination 815 must be based on an accurate view of the topology, including 816 availability of certain links in a given topology for traffic 817 associated with any given VLAN. Otherwise, it is possible to 818 partition a TRILL Link-local LAN (assuming that RBridges may be 819 deployed and configured to replace existing 802.1Q bridges) as a 820 result of a failure - under circumstances in which such a 821 partition would not have occurred with previously deployed 822 802.1Q bridges. 824 Protocol specification(s) need to define how accurate VLAN 825 topology is to be determined and applied in determination of end 826 station primary points of attachment. Protocol specification(s) 827 also need to state the limitations that any chosen mechanisms 828 may impose on the solution (in terms of scalability and ease of 829 deployment, for example). Finally, protocol specification(s) 830 need to describe how determination is made with respect to which 831 RBridge(s) are responsible for learning new end station 832 information, and for flooded and broadcast frames for reaching 833 known and unknown end stations on any link or VLAN. 835 4.5. Learning 837 The protocol specifications need to define how learning of MAC- 838 layer reachability information is expected to occur - at least 839 in the default case. 841 As described previously, a major consideration is the complexity 842 associated with receiving reachability information for a lot of 843 end-stations for which an ingress RBridge has no interest. This 844 is the case, for example, where a large number of VLANs are in 845 use (see [8]). This issue does not arise if learning is based 846 on the data plane (similar to bridge learning) - as is currently 847 described as a default learning mode in [3]. 849 4.6.Tunneling 851 RBridges pass encapsulated frame traffic to each other 852 effectively using tunnels. These tunnels use an Ethernet link 853 layer header, together with a TRILL header. 855 Specifics of encapsulation are to be defined in appropriate 856 protocol/encapsulation specifications. 858 It is the combination of the local MAC desitnation (which is for 859 a locally attached RBridge) and the TRILL encapsulation that 860 distinguishes RBridge to RBridge traffic from other traffic. 861 The link-layer header includes source and destination addresses, 862 which typically identify the local RBridges (the sending and 863 receiving RBridges relative to the local TRILL Link). 865 The TRILL header is required to support loop mitigation for (at 866 least) unicast traffic within the TRILL Campus; traffic loops in 867 forwarding between RBridges and non-RBridge devices, as well as 868 across non-RBridge devices between RBridges, is beyond the scope 869 of this document. 871 The TRILL header and encapsulation: 873 o must clearly identify the traffic as RBridge traffic - the 874 outer Ethernet header may, for instance, use an Ethertype 875 number unique to RBridges; 877 o should also identify a specific (egress) RBridge - the TRILL 878 header may, for example, include an identifier unique to the 879 egress RBridge, in the unicast case; 881 o should include the RBridge transit route, a hopcount, or a 882 timestamp to prevent indefinite looping of a frame. 884 5. RBridge Operation 886 This section is intended primarily to serve as a tutorial for 887 RBridge operations. As such in any case where this section says 888 anything in diagrement with specific protocol specifications, 889 the protocol specification over-rides. 891 5.1. RBridge General Operation 893 As described in sections above, operations that apply to all 894 RBridges include peer and topology discovery (including hello 895 messaging, negotiation of RBridge identifiers and link-state 896 routing), determination of RBridge primary points of attachment 897 (for local end stations - possibly via DRB election), shortest 898 path (SPF) computation and either learning or advertising reach- 899 ability for specific L2 (MAC Ethernet destination) addresses 900 within a broadcast domain. 902 In addition, all RBridges will compute RBridge Distribution 903 Trees for delivery of (potentially VLAN scoped) broadcast, 904 multicast and flooded frames to each peer RBridge. Setting up 905 these trees early is important as there is otherwise no means 906 for frame delivery across the TRILL Campus during the learning 907 phase. Because it is very likely to be impossible (at an early 908 stage) for RBridges to determine which RBridges are edge 909 RBridges, it is preferable that each RBridge compute these trees 910 for all RBridges as early as possible - even if some entries 911 will not be used. 913 The specifics of each of these operational steps will be defined 914 in protocol specifications (such as [3]). 916 5.2.Ingress/Egress Operations 918 Operation specific to edge RBridges involves RBridge learning, 919 advertisement, encapsulation and decapsulation (at ingress and 920 egress RBridges, respectively). 922 As described previously, RBridge learning is similar to typical 923 bridge learning - i.e. - all RBridges listen promiscuously to L2 924 Frames on each local LAN and acquire end station location 925 information associated with source MAC addresses in L2 frames 926 they observe. 928 If multiple RBridges are available (i.e. - connected to a local 929 LAN or VLAN), a determination must be made as to which RBridge 930 is the primary point of attachment for each end station (or end 931 stations by groups - using, for example, the VLAN associations 932 of VLAN aware end stations) requiring ingress and egress 933 services from an RBridge Campus. This is a minimal requirement, 934 and there is no reason why this same determination might not be 935 made in all cases, even the degenerate case in which only one 936 RBridge may be used. This could be the case, for instance, if a 937 DRB election is done in all cases, including when the DRB can 938 only be the one and only RBridge to which local end stations 939 might be attached. 941 In the degenerate case - where only one RBridge is connected to 942 a specific Ethernet LAN - obviously that RBridge will be (or 943 become) the primary point of attachment for local end stations 944 requiring ingress/egress services from the RBridge Campus. 946 Minimally, only the RBridge determined as the primary point of 947 attachment for a given (set of) end station(s) is required to 948 perform RBridge learning for that (set of) end station(s) while 949 they remain associated with interface(s) connected to the local 950 LAN or VLAN. 952 Note that - in some cases - the determination of primary points 953 of attachment and learning may be tightly bound operations. 954 This might be the case if - for example - the determination is 955 based on literal configuration of end station and RBridge 956 attachments. In other cases, learning would occur in a more 957 conventional - and flexible - way, if (for example) an automated 958 process of selecting a DRB (such as DRB election) is used on a 959 per-link or per-VLAN (set) basis. 961 Assuming learning is required by a specific solution described 962 in any protocol specification(s), as RBridges learn segment- 963 local MAC source addresses, it creates an entry in its learned 964 filtering/forwarding database that associates that MAC source 965 address with the interface on which it was learned. 967 Similarly - to support ARP/ND optimization - IP-to-MAC mappings 968 may also be learned by snooping corresponding protocol messages. 969 Protocol specifications may include either optional or required 970 behaviors to support ARP/ND, or multicast, learning and 971 distribution methods. 973 Periodically, as determined by RBridge protocol specification, 974 each RBridge may advertise this learned information to its 975 RBridge peers. These advertisements would propagate to all edge 976 RBridges (as potentially scoped by associated VLAN information 977 for each advertisement). Each edge RBridge would incorporate 978 this information in the form of a Unicast TRILL Forwarding 979 Database entry. 981 Note that currently, [3] specifies that this is not the default 982 mode, and that learning primarily occurs via the data plane at 983 egress, as well as at ingress. 985 The trade-off is between the complexity associated with flooding 986 data verses the complexity associated with flooding reachability 987 information. 989 For applications in which it is likely that most edge RBridges 990 will not want to receive most of the reachability information, 991 flooding avoidance requires either that the method is not used, 992 or that intermediate (core, in at least some cases) RBridges 993 need to keep VLAN specific state information to limit the scope 994 of advertisement flooding. 996 If it is desired - in any specific solution - to support 997 discovery of new end station attachments, RBridges may also 998 discover that a new end station has become locally attached (for 999 which they may be, or become, an edge RBridge) as a result of 1000 receiving un-encapsulated frames that require forwarding. Any 1001 such solution must specify how a primary point of attachment is 1002 determined when this occurs. Several possible approaches exist. 1004 If an automated DRB selection process (such as DRB election) is 1005 the approach in use for a specific solution (on a per-link, or 1006 per-VLAN, basis), this determination is automatic for any link 1007 (or VLAN on a local link). If an RBridge is the DRB for a local 1008 link or VLAN,, and has not previously learned that the MAC 1009 destination for a frame is local (this could be the case - for 1010 instance - for the very first frame it observes), then the 1011 RBridge could be required to forward (or flood) the frame via 1012 the TRILL Campus to all other RBridges (potentially within a 1013 VLAN scope). 1015 When a frame is received, which must be forwarded across the 1016 RBridge Campus, the responsible RBridge would flood the frame 1017 unless it has already created a Unicast TRILL Forwarding 1018 Database entry for the frame's MAC destination address. If it 1019 has a corresponding Unicast TRILL Forwarding Database entry, 1020 then it would use that. The RBridge in this instance would be 1021 an ingress RBridge for the frame being forwarded across the 1022 RBridge Campus. 1024 The encapsulation used by this ingress RBridge would be 1025 determined by the Unicast TRILL Forwarding Database entry - if 1026 one exists - or the Unicast TRILL Forwarding Database-equivalent 1027 entry for the RBridge Distribution Tree. 1029 When the encapsulated frame arrives at egress RBridge(s), it is 1030 decapsulated and forwarded via the egress interface(s) onto the 1031 local link (or VLAN on the local link). 1033 In using the approach of learning from the data plane, the 1034 egress RBridge stores information related to content of the 1035 frame's TRILL encapsulation for use in subsequent reverse 1036 traffic in a manner directly analogous to bridge learning. 1038 Note that an egress RBridge will - in most case - be the RBridge 1039 determined to be the primary point of attachment for a 1040 destination end station on the local link or VLAN accessed via 1041 its egress interface(s). Exceptions to this might exist under 1042 circumstances in which use of distinct RBridges for ingress and 1043 egress for a common (set of) end station(s) does not produce 1044 local forwarding ambiguity. Any protocol specification that 1045 allows this must also unambiguously describe the precise 1046 circumstances under which it is allowed - as well as the 1047 limitations and issues this introduces in the solution 1048 specified. 1050 Also note that specific solution(s) in protocol specification(s) 1051 will need to describe how determination of an end station's 1052 primary point of attachment (RBridge) occurs for the case where 1053 a specific end station has not yet been discovered at any 1054 ingress or egress interface - except under circumstances where 1055 discovery of new end stations is not supported, or explicitly 1056 disallowed. In the example in which a DRB election is used, 1057 this determination is both trivial and automatic. In an 1058 approach where end station and RBridge attachment/association is 1059 configured, this should be relatively obvious - if inflexible. 1061 In the DRB example, if the destination MAC address of a received 1062 frame does not correspond to a learned MAC destination address 1063 at an egress interface, it will forward the frame on all 1064 interfaces for which it is either the designated RBridge. If a 1065 received frame does correspond to a learned MAC destination 1066 address at an egress interface, the RBridge will forward the 1067 frame via that interface only. 1069 Any specific solution's protocol specification(s) should also 1070 allow for the fact that flooded frames may arrive at a single 1071 local LAN (or VLAN) - where local end stations may be attached - 1072 via multiple RBridges. Protocol specification(s) need to account 1073 for how determination of which RBridge is exclusively 1074 responsible for forwarding such frames is to be made. This is 1075 essential to avoid having the same frame arrive multiple times 1076 and potentially from widely disparate directions (i.e. - on 1077 different interfaces of individual bridges). 1079 5.3. Transit Forwarding Operations 1081 There are two models for transit forwarding within a TRILL 1082 Campus: unicast frame forwarding for known destinations, and 1083 everything else. The difference between the two is in how the 1084 encapsulation is determined. Exactly one of these models will be 1085 selected - in any instantiation of this architecture- for each 1086 of the following forwarding modes: 1088 o Unicast frame forwarding 1089 o Forwarding of non-unicast frames 1090 o Broadcast frame forwarding 1091 o Multicast frame forwarding 1092 o Frame flooding 1094 5.3.1. Unicast 1096 In unicast forwarding, the TRILL header is specific to the 1097 egress RBridge and MAC destination in the outer Ethernet 1098 encapsulation is specific to the next hop RBridge. 1100 As the frame is prepared for transmission at each RBridge, the 1101 next hop MAC destination information is determined at that local 1102 RBridge using a corresponding Unicast TRILL Forwarding Database 1103 entry based on the TRILL "shim" header. 1105 5.3.2. Broadcast, Multicast and Flooding 1107 RBridge Distribution Trees are used for forwarding of broadcast, 1108 multicast and unknown destination frames across the TRILL 1109 Campus. In a simple implementation, it is possible to use the 1110 Multi-destination TRILL Forwarding Database entries for all 1111 frames of these types. 1113 However, this approach results in possibly severe inefficiencies 1114 in at least the multicast case. 1116 As a consequence, instantiations of this architecture should 1117 allow for local optimizations on a hop by hop basis. 1119 Examples of such optimizations are included in the sections 1120 below. 1122 5.3.2-1. Broadcast 1124 The path followed in transit forwarding of broadcast frames will 1125 have been established through actions initiated by each RBridge 1126 (as any RBridge is eligible to subsequently become an ingress 1127 RBridge) in the process of computing Multi-destination TRILL 1128 Forwarding Database entries. 1130 The protocol specification will most likely require each RBridge 1131 to assume that it may be a transit as well as an ingress and 1132 egress RBridge and establish forwarding information relative to 1133 itself and each of its peer RBridges, and stored in the Multi- 1134 destination TRILL Forwarding Database. At least one exception 1135 case exists and that is when RBridges are configured to treat a 1136 given link as a point to point link between two RBridges. 1138 Forwarding information should logically exist in two forms: 1139 transit encapsulation information for interfaces over which the 1140 RBridge will forward a multipoint frame to one or more adjacent 1141 RBridges and a decapsulation indication for each interface over 1142 which the RBridge may egress frames from the TRILL Campus. In 1143 each case, the Multi-destination TRILL Forwarding Database 1144 includes some identification of the interface on which a frame 1145 is forwarded toward any specific egress RBridge for frames 1146 received from any specific ingress RBridge. 1148 Note that an interface over which an RBridge may egress frames 1149 is any interface for which the RBridge is the primary point of 1150 end station attachment for one or more end stations, or the 1151 RBridge determined to be responsible for broadcast delivery. 1153 RBridges must not wait to determine that one (or more) Ethernet 1154 end stations are present on an interface before deciding to 1155 forward decapsulated broadcast frames on that interface. Again, 1156 an exception case would exist if RBridges have been configured 1157 to treat a local link as a point to point connection between two 1158 RBridges, or otherwise configured to ignore possible presence of 1159 end stations in this case. 1161 Forwarding information is selected for each broadcast frame 1162 received by any RBridge (based - for example - on identifying 1163 the ingress RBridge, or distribution tree root, for the frame) 1164 for all corresponding Multi-destination TRILL Forwarding 1165 Database entries. Each RBridge may thus be required to replicate 1166 one RBridge encapsulated broadcast frame for each interface that 1167 is determined from Multi-destination TRILL Forwarding Database 1168 entries corresponding to the frame's ingress RBridge (or 1169 distribution tree root). This includes decapsulated broadcast 1170 frames for each interface for which the RBridge is responsible 1171 for providing egress for broadcast frames (as might have been 1172 determined previously by DRB election, for example). 1174 Note that frame replication and forwarding should be scoped by 1175 VLAN, if VLAN support is provided. Also note that an egress 1176 RBridge may be required to transmit a decapsulated frame on the 1177 same interface on which it previously received the corresponding 1178 RBridge encapsulated frame. 1180 This approach for broadcast forwarding might be considered to 1181 add complexity because replication occurs at all RBridges along 1182 the ingress RBridge tree, potentially for both RBridge 1183 encapsulated and decapsulated broadcast frames. However, the 1184 replication process is similar to replication of broadcast 1185 traffic in 802.1D bridges with the exception that additional 1186 replication may be required at each interface for egress from 1187 the TRILL Campus. 1189 Note that the additional replication associated with TRILL 1190 Campus egress may be made to exactly conform to 802.1D bridge 1191 broadcast replication in implementations that model a TRILL 1192 Campus egress as a separate logical interface. 1194 Using this approach results in one and only one copy of the 1195 broadcast frame being delivered to each egress RBridge. 1197 5.3.2-2. Multicast 1199 Multicast forwarding is reducible to broadcast forwarding in the 1200 simplest (default) case. However, protocol specifications may 1201 require, or recommend and implementations may choose - using 1202 mechanisms that are out of scope for this document - to optimize 1203 multicast forwarding. In order for this to work effectively, 1204 however, support for awareness of multicast "interest" is 1205 required for all RBridges. 1207 Without optimization, multicast frames are injected by the 1208 ingress RBridge onto an RDT by - for instance - encapsulating 1209 the frame with a MAC destination multicast address, and 1210 forwarding it according to its local Multi-destination TRILL 1211 Forwarding Database. Again, without optimization, each RBridge 1212 along the path toward all egress RBridges will similarly forward 1213 the frame according to their local Multi-destination TRILL 1214 Forwarding Database. 1216 Using this approach results in one and only one copy of the 1217 multicast frame being delivered to appropriate egress RBridges. 1218 However, using this approach, multicast delivery is identical to 1219 broadcast delivery - hence very inefficient. 1221 In any optimization approach, RBridge encapsulated multicast 1222 frames will use either a broadcast or a group MAC destination 1223 address. In either case, the recognizably distinct destination 1224 addressing allows a frame forwarding decision to be made at each 1225 RBridge hop. RBridges may thus be able to take advantage of 1226 local knowledge of multicast distribution requirements to 1227 eliminate the forwarding requirement on interfaces for which 1228 there is no recipient interested in receiving frames associated 1229 with any specific group address. 1231 As stated earlier, in order for RBridges to be able to implement 1232 multicast optimization, distribution of learned multicast group 1233 "interest" information must be provided - and propagated - by 1234 all RBridges. Mechanisms for learning and propagating multicast 1235 group participation by RBridges is out of scope in this document 1236 but may be defined in RBridge protocol specification(s). 1238 Note that, because the multicast optimization would - in 1239 principle - further scope and reduce broadcast traffic, two 1240 things may be said: 1242 o It is not necessary that all implementations in a deployment 1243 implement the optimization (though all must support the data 1244 required to implement it in RBridge peers) in order for any 1245 local multicast optimization (consistent with the above 1246 description) to work; 1247 o Introduction of a multicast optimization will not result in 1248 potential forwarding loops where broadcast forwarding would 1249 not do so. 1251 In the simplest case, the ingress RBridge for a given multicast 1252 frame will re-use the MAC destination group address of a 1253 received multicast frame. However this may not be required as 1254 it is possible that the mechanisms specified to support 1255 multicast will require examination of the decapsulated MAC 1256 destination group address at each RBridge that implements the 1257 optimization. 1259 Specifics of multicast forwarding are to be defined in protocol 1260 specifications. 1262 5.3.2-3. Flooding 1264 Flooding is similarly reducible to broadcast forwarding in the 1265 simplest (default) case - with the exception that a frame being 1266 flooded across the TRILL Campus is typically a unicast frame for 1267 which no Unicast TRILL Forwarding Database entry exists at the 1268 ingress RBridge. This is not a minor distinction, however, 1269 because it impacts the way that addressing may be used to 1270 accomplish flooding within the TRILL Campus. 1272 An ingress RBridge that does not have a Unicast TRILL Forwarding 1273 Database entry for a received frame MAC destination address, 1274 will inject the frame onto the ingress RBridge Tree by - for 1275 instance - encapsulating the frame with a MAC destination 1276 broadcast address, and forwarding it according to its local 1277 Multi-destination TRILL Forwarding Database. Without 1278 optimization, each RBridge along the path toward all egress 1279 RBridges will similarly forward the frame according to their 1280 local Multi-destination TRILL Forwarding Database. 1282 Using this approach results in one and only one copy of the 1283 flooded frame being delivered to all egress RBridges. 1285 However implementations may choose to optimize flooding. A 1286 Flooding optimization will only work at any specific RBridge if 1287 that RBridge re-evaluates the original (decapsulated) unicast 1288 frame. 1290 Any flooding optimization would operate similarly to the 1291 multicast optimization described above, except that - instead of 1292 requiring local information about multicast distribution - each 1293 RBridge implementing the optimization will need only to lookup 1294 the MAC destination address of the original (decapsulated) frame 1295 in its local Unicast TRILL Forwarding Database. If an entry is 1296 found, the frame could then be forwarded only if the specific 1297 RBridge is on the shortest path between the originating ingress 1298 RBridge and the appropriate egress RBridge. This could be 1299 implemented - for example - as a specialized Multi-destination 1300 TRILL Forwarding Database entry. 1302 Note that, because a flooding optimization would - in principle 1303 - further scope and reduce flooded traffic, two things may be 1304 said: 1306 o It is not necessary that all implementations in a deployment 1307 support the optimization in order for any local flooding 1308 optimization (consistent with the above description) to work 1309 (hence such an optimization is optional); 1310 o Introduction of the flooding optimization will not result in 1311 potential forwarding loops where flooded forwarding would not 1312 do so. 1314 Because a forwarding decision can be made at each hop, it is 1315 possible to terminate flooding early if a Unicast TRILL 1316 Forwarding Database for the original MAC destination was in the 1317 process of being propagated when flooding for the frame was 1318 started. It is therefore possible to reduce the amount of 1319 flooding to some degree in this case. 1321 Specifics of a flooding optimization - beyond the above proof of 1322 the concept that such a thing could be done safely - is out of 1323 scope for this document and should be out of scope generally in 1324 all protocol specifications for which the above analysis holds. 1326 5.4. Routing Protocol Operation 1328 The details of routing protocol operation are determined by the 1329 choice to use IS-IS routing. These details would be defined in 1330 appropriate protocol specification(s). Protocol specifications 1331 in this case may include both RBridge protocols (such as [3]), 1332 and specifications offering a generalized enhancement to IS-IS. 1334 Protocol specifications should identify the means by which IS-IS 1335 meets the peer and topology discovery, and path computation 1336 needs of the specific protocol - including which IS-IS optional 1337 features and enhancements (if any) are required for support of 1338 specified RBridge operations. 1340 5.5. Other Bridging and Ethernet Protocol Operations 1342 In defining this architecture, several interaction models have 1343 been considered for protocol interaction between RBridges and 1344 other L2 forwarding devices - in particular, 802.1D bridges. 1345 Whatever model we adopt for these interactions must allow for 1346 the possibility of other types of L2 forwarding devices. Hence, 1347 a minimal participation model is most likely to be successful 1348 over the long term, assuming that RBridges are used in a L2 1349 topology that would be functional if RBridges were replaced by 1350 other types of L2 forwarding devices. 1352 Toward this end, RBridges - and the TRILL Campus as a whole - 1353 could (in theory) participate in Ethernet link protocols, 1354 notably the spanning tree protocol (STP) on the ingress/egress 1355 links using exactly one of the following interaction models: 1357 o Transparent Participation (Transparent-STP) 1358 o Active Participation (Participate-STP) 1359 o Blocking Participation (Block-STP) 1361 Only one of these variants would be supported by an instance of 1362 this architecture. All RBridges within a single TRILL Campus 1363 must use the same model for interacting with non-RBridge 1364 protocols. Furthermore, it is the explicit intent that only one 1365 of these models is ultimately supported - at least as a default 1366 mode of compliant implementations. 1368 This architecture assumes RBridges block STP. 1370 5.5.1. Wiring Closet Problem 1372 There is at least one remaining issue with this assumption and 1373 that has been referred to as the "wiring closet problem." The 1374 essential problem is described in this subsection. 1376 Given this configuration of bridges in a wiring closet, and an 1377 RBridge core: 1379 -----> B-1 <----------------> RB-a <-----. 1380 | \ 1381 / > RBridge CORE 1382 | / 1383 -----> B-2 <----------------> RB-b <-----' 1385 The link between (802.1D) bridges B-1 and B-2 is meant to be 1386 disabled by STP. In the RBridge case, however, there is no 1387 indication (from STP) that this link is redundant. Moreover, in 1388 order to avoid breaking bridge learning, either RB-a or RB-b 1389 will be the DR and - as a result, only one of the links (B- 1390 1<=>RB-a, B-2<=>RB-b) will get used. 1392 One solution to this problem is to include - as a configuration 1393 option, for instance - the ability to enable negotiation of (or 1394 use of a pre-defined, or configurable) pseudo-bridge identifier 1395 to be used in any of the variations of STP. 1397 One - (near) zero-configuration - option we've considered would 1398 be to use a well-known bridge identifier that each RBridge would 1399 use as a common pseudo-bridge identifier. Such an ID, used in 1400 combination with other STP configuration parameters, would most 1401 likely have to be guaranteed to win the root bridge election 1402 process in order to be a reasonable and useful default. 1404 However, because this architecture assumes RBridges block STP, 1405 participation in any form of STP is assumed to take place in an 1406 in-line, co-located bridge function. Such a bridge function is 1407 in addition to RBridge architectural functionality described in 1408 this document. Implementations may include such functionality 1409 and will very likely require some minimal configuration to turn 1410 it on, in vendor specific RBridge implementations. An example 1411 of a minimal configuration would be to assign a pseudo-bridge 1412 identifier to (the local in-line co-located bridge associated 1413 with) a specific RBridge port. 1415 For reasons of interoperability, specific protocol proposals to 1416 address the needs of this architecture may specify exactly how a 1417 co-located bridge will operate in this case (if such co-located 1418 bridge functionality is included in an implementation), as well 1419 as whether or not inclusion of such co-location is required. 1421 As a further note, one of the problems that should be addressed 1422 - assuming that this problem is to be resolved - is how to make 1423 certain the solution is robust against configuration error. In 1424 any solution that requires configuration of a pseudo-bridge ID 1425 that is common across a TRILL Campus, for example, it is 1426 possible to guard against configuration errors by using an 1427 election process (based on the root bridge election process) to 1428 determine which configured ID will be used by all RBridges in 1429 common - assuming that multiple pseudo-bridge IDs are 1430 inadvertently configured. 1432 Finally, note that there is a chicken-and-egg problem associated 1433 with RBridge participation in STP where RBridges may themselves 1434 be connected by spanning trees. 1436 6. How RBridges Address the TRILL Problem Space 1438 The RBridge architecture addresses the following aspects of the 1439 requirements identified in reference [2] through the use of a 1440 link-state routing protocol and defined forwarding behaviors: 1442 o Inefficient Paths 1444 o Robustness to Link Interruption 1446 In addition, using a logical model of "separation of functions" 1447 this architecture allows specifications and implementations to 1448 address existing and developing Ethernet extensions and 1449 enhancements, and provides a background against which protocol 1450 specifications may address: concerns about convergence under 1451 dynamic network changes, and optimizations for VLAN, ARP/ND, 1452 Multicast, etc. 1454 7. Conclusions 1456 This document discusses options considered and factors affecting 1457 any protocol specific choices that may be made in instantiating 1458 the TRILL architecture using RBridges. 1460 Specific architectural and protocol instantiations should take 1461 these into consideration. In particular, protocol, encapsulation 1462 and procedure specifications should allow for potential 1463 optimizations described in the architectural document to the 1464 maximum extent possible. 1466 Also, this document addresses considerations relative to 1467 interaction with existing technology and "future-proofing" 1468 solutions. For both simplicity in description, and robust long 1469 term implementation of the technology, this document recommends 1470 the use of clear distinction - at all possible points - of 1471 definitions, protocols, procedures, etc. from related (but not 1472 identical) specifications and interactions. 1474 In particular, this document recommends the use of a 1475 "collocation model" in addressing issues with combining RBridge, 1476 Router and 802.1D bridge behavior. 1478 8. Security Considerations 1480 As one stated requirement of this architecture is the need to be 1481 able to provide an L2 delivery mechanism that is potentially 1482 configuration free, the default operation mode for instances of 1483 this architecture should assume a trust model that does not 1484 require configuration of security information. This is - in fact 1485 - an identical trust model to that used by Ethernet devices in 1486 general. 1488 In consequence, the default mode does not require - but also 1489 does not preclude - the use of established security mechanisms 1490 associated with the existing protocols that may be extended or 1491 enhanced to satisfy this document's architectural definitions. 1493 In general, this architecture suggest the use of a link-state 1494 routing protocol - modified as required to support L2 reach- 1495 ability and link state between RBridges. Any mechanisms defined 1496 to support secure protocol exchanges between link-state routing 1497 peers may be extended to support this architecture as well. 1499 This architecture also suggests use of additional encapsulation 1500 mechanisms and - to the extent that any proposed mechanism may 1501 include (or be extended to include) secure transmission - it may 1502 be desirable to provide such (optional) extensions. 1504 To the extent possible, any extensions of protocol or 1505 encapsulation should allow for at least one mode of operation 1506 that doesn't require configuration - if necessary, for limited 1507 use in a physically secure deployment. 1509 9. IANA Considerations 1511 This document has no direct IANA considerations. It does 1512 suggest, that protocols that instantiate the architecture use a 1513 TRILL header as a wrapper on the payload for RBridge to RBridge 1514 traffic, and this TRILL header may be identified by a new 1515 Ethertype in the tunneled Ethernet link header. This Ethertype, 1516 identified in an Ethernet header, could be allocated by the 1517 IEEE. 1519 10. Acknowledgments 1521 The initial work for this document was largely done by Joe 1522 Touch, based on work he and Radia Perlman completed earlier. 1523 Subsequent changes are not to be blamed on either of them. 1525 In addition, the current text has been helped substantially by 1526 comments and suggestions from the TRILL working group, working 1527 group chairs, and from Ron Bonica, Stewart Bryant, Joel Halpern, 1528 Guillermo Ibanez and Russ White in particular. Also, a great 1529 deal of work was recently done - by Joe Touch, Radia Perlman, 1530 Dinesh Dutt and Silvano Gai - in an effort to align terminology 1531 and concepts used in this document with those also used in the 1532 other TRILL documents. 1534 11. References 1536 11.1. Normative References 1538 None. 1540 11.2. Informative References 1542 [1] Perlman, R., "RBridges: Transparent Routing", Proc. 1543 Infocom 2005, March 2004. 1545 [2] Touch, J., R. Perlman, (ed.) "Transparent Interconnection 1546 of Lots of Links (TRILL): Problem and Applicability 1547 Statement", work in progress, draft-touch-trill-prob- 1548 00.txt, November, 2005. 1550 [3] Perlman, R., S. Gai, D. Dutt, D. Eastlake III, "RBridges: 1551 Base Protocol Specification", work in progress, draft- 1552 ietf-trill-rbridge-protocol-05.txt, July, 2007. 1554 [4] Postel, J., "INTERNET PROTOCOL", RFC 791, September, 1981. 1556 [5] 802.1D-2004 IEEE Standard for Local and Metropolitan Area 1557 Networks: Media Access Control (MAC) Bridges 1559 [6] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1560 Dual Environments", RFC 1195, December, 1990. 1562 [7] Plummer, D., "An Ethernet Address Resolution Protocol -- 1563 or -- Converting Network Protocol Addresses to 48.bit 1564 Ethernet Address for Transmission on Ethernet Hardware", 1565 RFC 826, November, 1982. 1567 [8] 802.1Q-2005 IEEE Standard for Local and Metropolitan Area 1568 Networks: Virtual Bridged Local Area Networks 1569 (Incorporates IEEE Std 802.1Q-1998, IEEE Std 802.1uT-2001, 1570 IEEE Std 802.1vT-2001, and IEEE 802.1sT-2002) 1572 12. Author's Addresses 1574 Editor: 1576 Eric Gray 1577 Ericsson 1578 900 Chelmsford Street 1579 Lowell, MA, 01851 1580 Phone: +1 (978) 275-7470 1581 EMail: Eric.Gray@Ericsson.com 1583 Contributors: 1585 Joe Touch 1586 USC/ISI 1587 4676 Admiralty Way 1588 Marina del Rey, CA 90292-6695, U.S.A. 1589 Phone: +1 (310) 448-9151 1590 EMail: touch@isi.edu 1591 URL: http://www.isi.edu/touch 1593 Radia Perlman 1594 Sun Microsystems 1596 EMail: Radia.Perlman@sun.com 1598 Intellectual Property Statement 1600 The IETF takes no position regarding the validity or scope of 1601 any Intellectual Property Rights or other rights that might be 1602 claimed to pertain to the implementation or use of the 1603 technology described in this document or the extent to which any 1604 license under such rights might or might not be available; nor 1605 does it represent that it has made any independent effort to 1606 identify any such rights. Information on the procedures with 1607 respect to rights in RFC documents can be found in BCP 78 and 1608 BCP 79. 1610 Copies of IPR disclosures made to the IETF Secretariat and any 1611 assurances of licenses to be made available, or the result of an 1612 attempt made to obtain a general license or permission for the 1613 use of such proprietary rights by implementers or users of this 1614 specification can be obtained from the IETF on-line IPR 1615 repository at http://www.ietf.org/ipr. 1617 The IETF invites any interested party to bring to its attention 1618 any copyrights, patents or patent applications, or other 1619 proprietary rights that may cover technology that may be 1620 required to implement this standard. Please address the 1621 information to the IETF at ietf-ipr@ietf.org. 1623 Disclaimer of Validity 1625 This document and the information contained herein are provided 1626 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1627 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, 1628 THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 1629 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1630 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1631 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1632 OR FITNESS FOR A PARTICULAR PURPOSE. 1634 Copyright Statement 1636 Copyright (C) The IETF Trust (2008). 1638 This document is subject to the rights, licenses and 1639 restrictions contained in BCP 78, and except as set forth 1640 therein, the authors retain all their rights. 1642 Acknowledgment 1644 Funding for the RFC Editor function is currently provided by the 1645 Internet Society. 1647 Filename: draft-ietf-trill-rbridge-arch-05.doc 1648 Directory: E:\Ericsson\IETF\drafts 1649 Template: \\Boreas\homes\touch-xp\ietf\word 1650 template\2-Word-v2.0.template.dot 1651 Title: Network Working Group 1652 Subject: 1653 Author: Eric Gray 1654 Keywords: 1655 Comments: 1656 Creation Date: 2/25/2008 10:06:00 AM 1657 Change Number: 4 1658 Last Saved On: 2/25/2008 11:11:00 AM 1659 Last Saved By: Eric W Gray 1660 Total Editing Time: 27 Minutes 1661 Last Printed On: 2/25/2008 11:12:00 AM 1662 As of Last Complete Printing 1663 Number of Pages: 36 1664 Number of Words: 11,424 (approx.) 1665 Number of Characters: 65,120 (approx.)