idnits 2.17.1 draft-gray-trill-rbridge-arch-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1442. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1431. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 33 longer pages, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (June 26, 2006) is 6514 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' == Outdated reference: A later version (-16) exists of draft-ietf-trill-rbridge-protocol-00 -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Normative reference to a draft: ref. '6' ** Obsolete normative reference: RFC 2740 (ref. '9') (Obsoleted by RFC 5340) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 11 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: December, 2006 6 June 26, 2006 8 The Architecture of an RBridge Solution to TRILL 9 draft-gray-trill-rbridge-arch-01.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 December 26, 2006. 38 Abstract 40 RBridges are link layer (L2) devices that use routing protocols 41 as a control plane. They combine several of the benefits of the 42 link layer with network layer routing benefits. RBridges use 43 existing link state routing to provide higher RBridge to RBridge 44 cross-section bandwidth, fast convergence on reconfiguration, 45 and more robustness under link interruption than an equivalent 46 set of conventional bridges using existing spanning tree 47 forwarding. They are intended to apply to similar L2 network 48 sizes as conventional bridges and are intended to be backward 49 compatible with those bridges as both ingress/egress and 50 transit. They also attempt to retain as much 'plug and play' as 51 is already available in existing bridges. This document proposes 52 an RBridge system as a solution to the TRILL problem. It also 53 defines the RBridge architecture, defines its terminology, and 54 describes basic components and desired behavior. One or more 55 separate documents specify the protocols and mechanisms that 56 satisfy the architecture presented herein. 58 Table of Contents 60 1. Introduction................................................4 61 2. Background..................................................6 62 2.1. Existing Terminology...................................6 63 2.2. RBridge Terminology...................................10 64 3. Components.................................................13 65 3.1. RBridge Device........................................13 66 3.2. RBrdige Data Model....................................14 67 3.2.1. CFT..............................................14 68 3.2.2. CFT-IRT..........................................14 69 3.2.3. CTT..............................................16 70 4. Functional Description.....................................16 71 4.1. CRED Auto-configuration...............................16 72 4.2. RBridge Peer Discovery................................19 73 4.3. Tunneling.............................................20 74 4.4. RBridge General Operation.............................21 75 4.5. Ingress/Egress Operations.............................22 76 4.6. Transit Forwarding Operations.........................24 77 4.6.1. Unicast..........................................24 78 4.6.2. Broadcast, Multicast and Flooding................24 79 4.6.2.1. Broadcast...................................25 80 4.6.2.2. Multicast...................................26 81 4.6.2.3. Flooding....................................27 82 4.7. Routing Protocol Operation............................28 83 4.8. Other Bridging and Ethernet Protocol Operations.......29 84 5. How RBridges Address TRILL.................................29 85 6. Conclusions................................................29 86 7. Security Considerations....................................30 87 8. IANA Considerations........................................30 88 9. Acknowledgments............................................31 89 10. References................................................31 90 10.1. Normative References.................................31 91 10.2. Informative References...............................31 92 Author's Addresses............................................32 93 Intellectual Property Statement...............................32 94 Disclaimer of Validity........................................33 95 Copyright Statement...........................................33 96 Acknowledgment................................................33 98 1. Introduction 100 This document describes an architecture that addresses the TRILL 101 problem and applicability statement [2]. This architecture is 102 composed of a set of devices called RBridges that cooperate 103 together within an Ethernet network to provide a layer two 104 delivery service that makes efficient use of available links 105 using a link state routing protocol. The service provided is 106 analogous to creation of a single, virtual device composed of an 107 overlay of tunnels, constructed between RBridge devices, using 108 link state routing. RBridges thus support increased RBridge to 109 RBridge bandwidth and fault tolerance, when compared to 110 conventional Ethernet bridges (which forward frames via a 111 spanning tree), while still being compatible with bridges and 112 hubs. 114 The principal objectives of this architecture is to provide an 115 overview of the use of these RBridges in meeting the following 116 goals: 118 1) Provide a form of optimized layer two delivery service. 120 2) Use existing technology as much as possible. 122 3) Allow for configuration free deployment. 124 In providing a (optimized) layer two (L2) service, key factors 125 we want to maintain are: transparency to higher layer (layer 3 126 and above) delivery services and mechanisms, and use of location 127 independent addressing. Optimization of the L2 delivery service 128 consists of: use of all available paths and support for pruning 129 of multicast traffic delivery paths. 131 To accomplish the goal of using existing technologies as much as 132 possible, we intend to specify minimal extensions (if required) 133 to one or more existing link-state routing protocols, as well as 134 defining the specific sub-set of existing bridging technologies 135 this architecture makes use of. 137 The extent to which routing protocol extensions may be required 138 depends on the closeness of the "fit" of any chosen routing 139 protocol to RBridge protocol requirements. See [6] for further 140 information on these requirements. The use of a specific routing 141 protocol - along with appropriate extensions and enhancements - 142 will be defined in corresponding RBridge protocol specifications 143 (see [3] for example). 145 Specific protocol specifications will also describe the details 146 of interactions between the RBridge protocol and specific L2 147 technologies - i.e. - Virtual Local Area Networking (VLAN), L2 148 Multicast, etc. 150 As an overview, however, the intention is to use a link-state 151 routing protocol to accomplish the following: 153 1) Discover RBridge peers. 155 2) Determine RBridge link topology. 157 3) Advertise L2 reachability information. 159 4) Establish L2 delivery using shortest path (verses STP). 161 There are additional RBridge protocol requirements - above and 162 beyond those addressed by any existing routing protocol - that 163 are identified in this document and need to be addressed in 164 corresponding RBridge protocol specifications. 166 To allow for configuration free deployment, specific protocol 167 specifications need to explicitly define the conditions under 168 which RBridges may - and may not - be deployed as-is (plug and 169 play), and the mechanisms that are required to allow this. For 170 example, the first requirement any RBridge protocol must meet is 171 to derive information required by link-state routing protocol(s) 172 for protocol start-up and communications between peers - such as 173 higher-layer addressing and/or identifiers, encapsulation header 174 information, etc. 176 At the abstract level, RBridges need to maintain the following 177 information: 179 1) Peer information, 181 2) Topology information, 183 3) Forwarding information - 185 a. unicast, 187 b. flooded, and 189 c. multicast. 191 Peer information may be acquired via the routing protocol, or 192 may be discovered as a result of RBridge-specific peer discovery 193 mechanisms. Topology information is expected to be acquired 194 exclusively via the link-state routing protocol. 196 Forwarding information is derived from the combination of bridge 197 learning, snooping of multicast-related protocols (e.g. - IGMP), 198 and routing advertisements and path computations using the link- 199 state routing protocol. 201 The remainder of this document outlines the TRILL architecture 202 of an RBridge-based solution and describes RBridge components, 203 interactions and functions. Note that this document is not 204 intended to represent the only solution to the TRILL problem 205 statement, nor does it specify the protocols that instantiate 206 this architecture - or that only one such set of protocols is 207 prescribed. The former may be contained in other architecture 208 documents and the latter would be contained in separate 209 specification documents (see - e.g. - [3]). 211 2. Background 213 This architecture is based on the RBridge system described in an 214 Infocom paper [1]. That paper describes the RBridge system as a 215 specific instance; this document abstracts architectural 216 features only. The remainder of this section describes the 217 terminology of this document, which may differ from that of the 218 original paper. 220 2.1. Existing Terminology 222 The following terminology is defined in other documents. A brief 223 definition is included in this section for convenience and - in 224 some cases - to remove any ambiguity in how the term may be used 225 in this document, as well as derivative documents intended to 226 specify components, protocol, behavior and encapsulation 227 relative to the architecture specified in this document. 229 o 802: IEEE Specification for Ethernet, i.e., including hubs 230 and switches. 232 o 802.1D: IEEE Specification for bridged Ethernet, including 233 the BPDUs used in spanning tree protocol (STP) [5]. 235 o ARP: Address Resolution Protocol - a protocol used to find an 236 address of form X, given a corresponding address of form Y. 237 In this document, ARP refers to the well-known protocol used 238 to resolve L2 (MAC) addresses, using a given L3 (IP) address. 240 o Bridge: an Ethernet (L2, 802.1D) device with multiple ports 241 that receives incoming frames on a port and transmits them on 242 some or all of the other ports; bridges support both bridge 243 learning and STP. Transparent bridges do not modify the L2 244 PDU being forwarded. 246 o Bridge Learning: process by which a switch or bridge 247 determines on which single outgoing port to transmit (forward 248 or copy) an incoming frame. This process depends on 249 consistent forwarding as "learning" uses the source MAC 250 address of frames received on each interface. Layer 2 (L2) 251 forwarding devices "learn" the location of L2 destinations by 252 peeking at layer 2 source addresses during frame forwarding, 253 and store the association of source address and receiving 254 interface. L2 forwarding devices use this information to 255 create "filtering database" entries and - gradually - 256 eliminate the need for flooding. 258 o Bridge Protocol Data Unit (BPDU): the frame type associated 259 with bridge control functions (for example: STP/RSTP). 261 o Bridge Spanning Tree (BST): an Ethernet (L2, 802.1D) 262 forwarding protocol based on the topology of a spanning tree. 264 o Broadcast Domain: the set of (layer 2) devices that must be 265 reached (or reachable) by any (layer 2) broadcast traffic 266 injected into the domain. 268 o Broadcast Traffic: traffic intended for receipt by all 269 devices in a broadcast domain. 271 o Ethernet: See "802" above. 273 o Filtering Database - database containing association 274 information of (source layer 2 address, arrival interface). 275 The interface that is associated with a specific layer 2 276 source address, is the same interface which is used to 277 forward frames having that address as a destination. When a 278 layer 2 forwarding device has no entry for the destination 279 layer 2 address of any frame it receives, the frame is 280 "flooded". 282 o Flooded Traffic - traffic forwarded on all interfaces, except 283 those on which it was received, within the same broadcast 284 domain. Flooding is the mechanism by which traffic is 285 delivered to a destination that is currently "unknown" (i.e. 286 - either not yet "learned", or aged out of the "filtering 287 database"). 289 o Flooding - the process of forwarding traffic to ensure that 290 frames reach all possible destinations when the destination 291 location is not known. In "flooding", a layer 2 forwarding 292 device forwards a frame for any destination not "known" 293 (i.e. - not in the filtering database) on every active 294 interface except that one on which it was received. See also 295 VLAN flooding. 297 o Frame: in this document, frame refers to an Ethernet (L2) 298 unit of transmission (PDU), including header, data, and 299 trailer (or payload and envelope). 301 o Hub: an Ethernet (L2, 802) device with multiple ports which 302 transparently transmits frames arriving on any port to all 303 other ports. This is a functional definition, as there are 304 devices that combine this function with certain bridge-like 305 functions that may - under certain conditions - be referred 306 to as "hubs". 308 o IGP: Interior Gateway Protocol - any of the potential (link- 309 state) routing protocols candidates considered as potentially 310 useful RBridge routing protocols. 312 o IS-IS: Intermediate System to Intermediate System routing 313 protocol. See [8] for further information on IS-IS. 315 o LAN: Local Area Network. A LAN is an L2 forwarding domain. 316 This term is synonymous with Ethernet Subnet in the context 317 of this document. 319 o MAC: Media Access Control - mechanisms and addressing for L2 320 frame forwarding. 322 o Multicast Forwarding: forwarding methods that apply to frames 323 with broadcast or multicast destination MAC addresses. 325 o Node: a device with an L2 (MAC) address that sources and/or 326 sinks L2 frames. 328 o OSPF: Open Shortest Path First routing protocol. See [7] and 329 [9] for further information on OSPF. 331 o Packet: in this document, packet refers to L3 (or above) data 332 transmission units (PDU - e.g. - an IP Packet (RFC791 [4]), 333 including header and data. 335 o PDU: Protocol Data Unit - unit of data to be transmitted by a 336 protocol. To distinguish L2 and L3 PDUs, we refer to L2 PDUs 337 as "frames" and L3 PDUs as "packets" in this (and related) 338 document(s). 340 o Router: a device that performs IP (L3) forwarding (the 341 "routing function"); RBridges typically do not span routers 342 (i.e. - provide a connection from one router interface to 343 another router interface on the same router). 345 o Routing Function: in this document, the "routing function" 346 consists of forwarding IP packets between L2 broadcast 347 domains, based on L3 addressing and forwarding information. 348 In the process of performing the "routing function", devices 349 (typically routers) usually forward packets from one L2 350 broadcast domain to another (one, or more in the IP multicast 351 case) - distinct - L2 broadcast domain(s). RBridges cannot 352 span the routing function. 354 o Segment: an Ethernet link, either a single physical link or 355 emulation thereof (e.g., via hubs) or a logical link or 356 emulation thereof (e.g., via bridges). 358 o Spanning Tree Protocol (STP): an Ethernet (802.1D) protocol 359 for establishing and maintaining a single spanning tree among 360 all the bridges on a local Ethernet segment. Also, Rapid 361 Spanning Tree Protocol (RSTP). In this document, STP and RSTP 362 are considered to be the same. 364 o Spanning Tree Table (STT): a table containing port activation 365 status information as determined during STP. 367 o SPF: Shortest Path First - the algorithm name associated with 368 routing, used to determine a shortest path graph traversal. 370 o Subnet, Ethernet: a single segment, or a set of segments 371 interconnected by a CRED; in the latter case, the subnet may 372 or may not be equivalent to a single segment. Also a subnet 373 may be referred to as a broadcast domain or LAN. By 374 definition, all nodes within an Ethernet Subnet (broadcast 375 domain or LAN) must have L2 connectivity with all other nodes 376 in the same Ethernet subnet. 378 o Switch: an Ethernet (L2, 802) device with multiple point-to- 379 point ports which transmits (forwards or copies) frames that 380 arrive on one port to one or more other ports. Switches may 381 include bridge learning. Switches may also exclude STP/RSTP. 383 o TRILL: Transparent Interconnect over Lots of Links - the 384 working group and working name for the problem domain to be 385 addressed in this document. 387 o Unicast Forwarding: forwarding methods that apply to frames 388 with unicast destination MAC addresses. 390 o Unknown Destination - a destination for which a receiving 391 device has no filtering database entry. Destination (layer 392 2) addresses are typically "learned" by (layer 2) forwarding 393 devices via a process commonly referred to as "bridge 394 learning". 396 o VLAN: Virtual Local Area Network. VLANs in general fall into 397 two categories: link (or port) specific VLANs and tagged 398 VLANs. In the former case, all frames forwarded and all 399 directly connected nodes are assumed to be part of a single 400 VLAN. In the latter case, VLAN tagged frames are used to 401 distinguish which VLAN each frame is intended for. 403 o VLAN Flooding: flooding as described previously, except that 404 frames are only forwarded on those interfaces configured for 405 participation in the applicable VLAN. 407 2.2. RBridge Terminology 409 The following terms are defined in this document and intended 410 for use in derivative documents intended to specify components, 411 protocol, behavior and encapsulation relative to the 412 architecture specified in this document. 414 o CRED: Cooperating RBridges and Encapsulation Tunnels - a 415 topological construct consisting of a set of cooperating 416 RBridges, and the forwarding tunnels connecting them. 418 o CRED Forwarding Table (CFT): the per-hop forwarding table 419 populated by the RBridge Routing Protocol; forwarding within 420 the CRED is based on a lookup of the CRED Transit Header 421 (CTH) encapsulated within the outermost received L2 header, 422 rather than that encapsulating L2 header. The outermost L2 423 encapsulation in this case includes the source MAC address of 424 the immediate upstream RBridge transmitting the frame and 425 destination MAC address of the receiving RBridge for use in 426 the unicast forwarding case. 428 o CFT-IRT: a forwarding table used for propagation of 429 broadcast, multicast or flooded frames along the Ingress 430 RBridge Tree (IRT). 432 o CRED Transit Header (CTH): a 'shim' header that encapsulates 433 the ingress L2 frame and persists throughout the transit of a 434 CRED, which is further encapsulated within a hop-by-hop L2 435 header (and trailer). The hop-by-hop L2 encapsulation in this 436 case includes the source MAC address of the immediate 437 upstream RBridge transmitting the frame and destination MAC 438 address of the receiving RBridge - at least in the unicast 439 forwarding case. 441 o CRED Transit Table (CTT): a table that maps ingress frame L2 442 destinations to egress RBridge addresses, used to determine 443 encapsulation of ingress frames for transit of the CRED. 445 o Cooperating RBridges - those RBridges within a single 446 Ethernet Subnet (broadcast domain or LAN) not having been 447 configured to ignore each other. By default, all RBridges 448 within a single Ethernet subnet will cooperate with each 449 other. It is possible for implementations to allow for 450 configuration that will restrict "cooperation" between an 451 RBridge and an apparent neighboring RBridge. One reason why 452 this might occur is if the trust model that applies in a 453 particular deployment imposes a need for configuration of 454 security information. By default no such configuration is 455 required however - should it be used in any specific scenario 456 - it is possible (either deliberately or inadvertently) to 457 configure neighboring RBridges so that they do not cooperate. 458 In the remainder of this document, all RBridges are assumed 459 to be in a cooperating (default) configuration. 461 o Designated RBridge (DR): the RBridge associated with ingress 462 and egress traffic to a particular Ethernet link having 463 shared access among multiple RBridges; that RBridge is such a 464 link's "Designated RBridge". The Designated RBridge is 465 determined by an election process among those RBridges having 466 shared access via a single Segment. 468 o Edge RBridge (edge of a CRED): describes RBridges that serve 469 to ingress frames into the CRED and egress frames from the 470 CRED. L2 frames transiting an RBridge CRED enter, and leave, 471 it via an edge RBridge. 473 o Egress RBridge: for any specific frame, the RBridge through 474 which that frame leaves the CRED. For frames transiting a 475 CRED, the egress RBridge is an edge RBridge where RBridge 476 encapsulation is removed from the transit frames prior to 477 exiting the CRED. 479 o Forwarding Tunnels: in this document, CRED Forwarding Tunnels 480 (or Forwarding Tunnels) is used to refer to the paths for 481 forwarding transit frames, encapsulated at an RBridge ingress 482 and decapsulated at an RBridge egress. 484 o Ingress RBridge: for any specific frame, the RBridge through 485 which that frame enters the CRED. For frames transiting a 486 CRED, the ingress RBridge is the edge RBridge where RBridge 487 encapsulation is added to the transit traffic entering the 488 CRED. 490 o Ingress RBridge Tree: a tree computed for each edge RBridge - 491 and potentially for each VLAN in which that RBridge 492 participates - for delivery of broadcast, multicast and 493 flooded frames from that RBridge to all relevant egress 494 RBridges. This is the point-to-multipoint delivery tree used 495 by an ingress RBridge to deliver multicast, broadcast or 496 flooded traffic. The tree consists of a set of one or more 497 next-hops to be used when the ingress RBridge receives a 498 multicast or broadcast frame (frame with a multicast or 499 broadcast destination address), or frame with unknown 500 destination addresses. If forwarding frames hop-by-hop, next 501 hop RBridges will, in turn, have a similar set of one or more 502 next-hops to be used for forwarding these frames - when 503 received from an upstream, or ingress, RBridge. This 504 progression continues until frames arrive at egress RBridges. 506 o LPT: Learned Port Table. See Filtering Database. 508 o RBridge: a logical device as specified in this document, 509 which incorporate both routing and bridging features, thus 510 allowing for the achievement of TRILL Architecture goals. A 511 single RBridge device which can aggregate with other RBridge 512 devices to create a CRED. 514 3. Components 516 A CRED is composed of RBridge devices and the forwarding tunnels 517 that connect them; all other Ethernet link subnet devices, such 518 as bridges, hubs, and nodes, operate conventionally in the 519 presence of an RBridge. 521 3.1. RBridge Device 523 An RBridge is a bridge-like device that forwards frames on an 524 Ethernet link segment. It has one or more Ethernet ports which 525 may be wired or wireless; the particular physical layer is not 526 relevant. An RBridge is defined more by its behavior than its 527 structure, although it contains three tables which distinguish 528 it from conventional bridges. 530 Conventional bridges contain a learned port table (LPT), or 531 filtering database, and a spanning tree table (STT). The LPT 532 allows a bridge to avoid flooding all received frames, as is 533 typical for a hub or repeater. The bridge learns which nodes are 534 accessible from a particular port by assuming bi-directional 535 consistency: the source addresses of incoming frames indicate 536 that the incoming port is to be used as output for frames 537 destined to that address. Incoming frames are checked against 538 the LPT and forwarded to the particular port if a match occurs, 539 otherwise they are flooded out all ports except the incoming 540 port. 542 The STT indicates the ports used in the spanning tree. Details 543 of STP operation are out of scope for this document, however the 544 result of STP is to disable ports which would otherwise result 545 in more than one path traversal of the spanning tree. 547 RBridges, by comparison, have a CRED Forwarding Table (CFT - 548 used for unicast forwarding of RBridge encapsulated frames 549 across the CRED), CFT-IRT (used for flooding, broadcast or 550 multicast forwarding of RBridge encapsulated frames across the 551 CRED) and a CRED Transit Table (CTT - used by the ingress 552 RBridge to determine what encapsulation to use for frames 553 received as un-encapsulated from non-RBridge devices), described 554 in the following sections. 556 3.2. RBrdige Data Model 558 The following tables represent the logical model of the data 559 required by RBridges in forwarding unicast and multicast data 560 across a CRED. 562 3.2.1. CFT 564 The CFT is a forwarding table for unicast traffic within the 565 CRED, allowing tunneled traffic to transit the CRED from ingress 566 to egress. The size of a fully populated CFT at each RBridge is 567 maximally bounded by the product of the number of directly 568 connected RBridge peers (where "directly connected" in this 569 context refers to RBridges connected to each other without 570 transiting one or more additional RBridges) and VLANs. RBridges 571 may have separate CFTs for each VLAN, if this is supported by 572 configuration. The CFT is continually maintained by RBridge 573 routing protocol (see Section 4.7). 575 The CFT contains data specific to RBridge forwarding for unicast 576 traffic. The specific fields contained in this table are to be 577 defined in RBridge protocol specifications. In the abstract, 578 however, the table should contain forwarding direction and 579 encapsulation associated with an RBridge encapsulated frame 580 received - determined by the "shim" header destination and VLAN 581 (if applicable). 583 3.2.2. CFT-IRT 585 The CFT-IRT consists of a special-case set of forwarding entries 586 used for support of Ingress RBridge Trees (IRT). The CFT-IRT may 587 be part of the CFT, or instantiated as a separate table. 589 In discussing entries to be included in the CFT-IRT, the 590 following entities are temporarily defined, or further 591 qualified: 593 o Ingress RBridge - the RBridge that is the head end of an IRT. 594 All RBridges within a CRED are potential ingress RBridges. 596 o Egress RBridge - an RBridge that is the tail end of a path 597 corresponding to a specific CFT-IRT entry. All RBridges 598 within a CRED are potential egress RBridges. Not all RBridges 599 within a CRED will be on the shortest path between any 600 ingress RBridge and any other egress RBridge. 602 o Local RBridge - the RBridge that forms and maintains the CFT- 603 IRT entry (or entries) under discussion. The local RBridge 604 may be an Ingress RBridge, or an egress RBridge with respect 605 to any set of entries in the CFT-IRT. 607 o RBridge CRED Egress Interface - an interface on any RBridge 608 where a transit RBridge encapsulated frame would be 609 decapsulated prior to forwarding. With respect to such an 610 interface, the local RBridge is the egress RBridge. 612 Each local RBridge will maintain a set of entries for at least 613 the following - corresponding to a subset of all possible 614 forwarding paths: 616 o Zero or more entries grouped for each ingress RBridge - keyed 617 by the ingress RBridge identifier - used to determine 618 downstream forwarding of broadcast, multicast, and flooded 619 frames originally RBridge encapsulated by that ingress within 620 the CRED. 622 o Corresponding to each of these entry groups, one entry for 623 each of zero or more egress RBridge - where the local RBridge 624 is on the shortest path toward that egress RBridge. 626 o Corresponding to each of these entry groups, one entry for 627 each of zero or more CRED egress interfaces. 629 Each entry would contain an indication of which single interface 630 a broadcast, multicast or flooded frame would be forwarded for 631 each (ingress RBridge, egress RBridge) pair - as well as any 632 required encapsulation information, etc. required for forwarding 633 on that interface, toward the corresponding specific egress 634 RBridge. 636 A local RBridge could maintain a full set of entries from every 637 RBridge to every other RBridge, however - depending on topology 638 - only a subset of these entries would ever be used. In 639 addition, a topology change that changed selection of shortest 640 paths would also very likely change other elements of the 641 entries, negating possible benefits from having pre-computed 642 CFT-IRT entries. 644 CFT-IRT entries should also include VLAN identification 645 information relative to each set of ingress RBridge, to allow 646 scoping of broadcast, multicast and flooding forwarding by 647 configured VLANs. 649 CFT-IRT entries should also include Multicast-Group Address 650 specific information relative to each egress RBridge that is a 651 member of a given well-known multicast group, to allow scoping 652 of multicast forwarding by multicast group. 654 Implicit in this data model is the assumption that the "shim" 655 header encapsulation will contain information that explicitly 656 identifies the CRED ingress RBridge for any broadcast, multicast 657 or flooded frame. 659 How the CFT-IRT is maintained will be defined in appropriate 660 protocol specifications used to instantiate this architecture. 661 The protocol specification needs to include mechanisms and 662 procedures required to establish and maintain the CFT-IRT in 663 consideration of potential SPF recomputations resulting from 664 network topology changes. 666 3.2.3. CTT 668 The CTT determines how arriving traffic will be encapsulated, 669 for forwarding to the egress RBridge, via the CRED. The CTT can 670 be considered a version of the LPT that treats the CRED, as a 671 whole, as another port. It becomes configured in much the same 672 way as the LPT: by snooping incoming traffic, and assuming bi- 673 directional consistency (see Section 0). The information is 674 learned at the egress RBridge and propagated to all other 675 RBridges in the CRED via the RBridge routing protocol (also 676 Section 0). The CTT may be as large as the number of nodes on 677 the Ethernet subnet, across all VLANs. RBridges may have 678 separate CTTs for each VLAN, if separate VLANs are supported by 679 configuration. 681 The CTT essentially determines the tunnel encapsulation used to 682 transport each specific frame across the CRED. 684 4. Functional Description 686 The RBridge Architecture is largely defined by RBridge behavior; 687 the logical components are minimal, as outlined in Section 3. 689 4.1. CRED Auto-configuration 691 Cooperating RBridges self-organize to compose a single CRED 692 system. Consider first a set of bridges on a single Ethernet 693 link subnet (Figure 1). Here bridges are shown as 'b', hubs as 694 'h', and nodes as 'N'; bridges and hubs are numbered. Note that 695 the figure does not distinguish between types of nodes, i.e., 696 hosts and routers; both are end nodes at the link layer, and are 697 otherwise indistinguishable to L2 forwarding devices. Bridges in 698 this topology organize into a single spanning tree, as shown by 699 double lines ('=', '||', and '//') in the figure. 701 N N---b3---N 702 | || 703 | || 704 N---h1--b4===b5==h2==b6 705 | // | || 706 | // N || 707 | // || 708 N---b7====b8-----b9-----N 709 | |\ 710 | | \ 711 N N N 713 Figure 1 Conventionally bridged Ethernet link subnet 715 It is useful to note that hubs are relatively transparent to 716 bridges, both for traffic from nodes to bridges (h1) and for 717 traffic between bridges (h2). Also note that the same hub can 718 support traffic between bridges and from a host to a bridge 719 (h2), but that the spanning tree is exclusively between bridges. 720 Bridges are thus compatible with hubs, both as transits and 721 ingress/egress. 723 A CRED operates similarly, and can be viewed as a variant of the 724 way bridges self-organize. Figure 2 shows the same topology 725 where some of the bridges are replaced by RBridges. In this 726 figure, stars ('*') represent the paths the RBridge is capable 727 of utilizing, due to the use of link state routing. RBridges can 728 tunnel directly to each other (r4-r5), or through hubs (h2) or 729 bridges (b8). 731 N N---b3---N 732 | || 733 | || 734 N---h1--r4***r5**h2**r6 735 * * | * 736 * * N * 737 * * * 738 N---r7****b8*****r9-----N 739 | |\ 740 | | \ 741 N N N 743 Figure 2 RBridged Ethernet link subnet 745 Every node in a CRED is considered to have a primary point of 746 attachment to the CRED, as defined by the Designated RBridge. 747 Each Ethernet link segment attached to a CRED has a single 748 Designated RBridge; that RBridge is where all traffic that 749 transits the CRED enters and exits. In Figure 2, it is easy to 750 see that the nodes off of h1 must attach at r4; the nodes off of 751 b3, however, attach at either r5 or r6, depending on which is 752 the Designated RBridge. 754 Without loss of generality, an RBridge topology can be 755 reorganized (ignoring link length) such that all nodes, hubs, 756 and bridges are arranged around the periphery, and all RBridges 757 are considered directly connected by their tunnels (Figure 3). 758 Note that this view ignores the ways in which hubs and bridges 759 may serve both on the ingress/egress and for transit, hence this 760 view is not useful for traffic analysis. Using this view, it is 761 easy to distinguish between RBridge to RBridge traffic and other 762 traffic on shared devices, such as h2 and b8, because RBridge to 763 RBridge traffic content is hidden from non RBridge devices by 764 the RBridge encapsulation. 766 N N---b3---N 767 | || 768 | || 769 | h2 770 | /| \ 771 | / N \ 772 | / \ 773 N---h1--r4***r5******r6 774 * * * 775 * * * 776 * * * 777 N---r7***********r9-----N 778 \ /|\ 779 \ / | \ 780 \ / N N 781 \ / 782 \ / 783 b8 784 | 785 N 787 Figure 3 Reorganized RBridge Ethernet link subnet 789 4.2. RBridge Peer Discovery 791 Proper operation of the TRILL solution using RBridges depends on 792 the existence of a mechanism for discovering peer RBridges and 793 the RBridge topology. An accurate determination of RBridge 794 topology is required in order to determine how traffic frames 795 will flow in the topology and thus avoid the establishment of 796 persistent loops in frame forwarding. 798 The discovery mechanisms must use protocol messages which will 799 be propagated throughout the LAN, or broadcast domain, in order 800 to ensure that all RBridges in the same broadcast domain are 801 discovered and to allow for accurate determination of RBridge 802 topology. 804 These protocol messages should be distinguished in a manner that 805 is consistent with the chosen RBridge routing protocol, or any 806 other discovery mechanism used. It is very likely that peer 807 discovery will actually be done as part of the RBridge routing 808 protocol's peer discovery; however this is to be determined by 809 specific RBridge protocol specification(s). 811 An RBridge intercepts protocol messages that it recognizes as 812 being of this type (peer discovery), performs any processing 813 required and forwards these messages as required by the 814 discovery protocol. For example, a receiving RBridge may first 815 determine if it has seen this message before and insert itself 816 in a list of RBridges traversed by this message prior to 817 forwarding the message on at least all interfaces other than the 818 one on which it was received. 820 Note that forwarding the modified message on all interfaces in 821 the example above is safe, if somewhat wasteful. 823 RBridges must forward all other protocol messages in a manner 824 consistent with L2 addressing and forwarding - as would be done 825 by a typical 802.1D bridge. This includes any frames of the same 826 type that are - for one reason or another - not recognized by 827 the receiving RBridge. 829 Note that forwarding unrecognized messages - even when of the 830 same type - has the effect of providing some degree of 831 robustness in the solution against configuration errors and 832 against future variations of the discovery protocol. 834 Handling of 802.1D BPDUs is as determined in section 0. 836 4.3. Tunneling 838 RBridges pass encapsulated frame traffic to each other 839 effectively using tunnels. These tunnels use an Ethernet link 840 layer header, together with a shim header. 842 Specifics of encapsulation are to be defined in appropriate 843 protocol/encapsulation specifications. 845 It is the combination of the encapsulation that distinguishes 846 RBridge to RBridge traffic from other traffic. The link header 847 includes source and destination addresses, which typically 848 identify the ingress and egress RBridges. For incoming multicast 849 and broadcast traffic, one of these addresses may represent the 850 multicast group or broadcast address. Additionally, these 851 addresses may be VLAN-specific, i.e., such that each ingress and 852 egress address have per-VLAN addresses. 854 The additional shim header is required to support loop 855 prevention for traffic within the CRED; traffic loops in 856 forwarding between RBridges and non-RBridge nodes, as well as 857 across non-RBridge devices between RBridges, is prevented by 858 loop prevention mechanisms that are beyond the scope of this 859 document (but may include a TTL-like mechanism, mechanisms to 860 establish a loop free topology - such as STP/RSP - or both) on 861 the applicable LAN segments. 863 The shim header and encapsulation: 865 o must clearly identify the traffic as RBridge traffic - the 866 outer Ethernet header may, for instance, use a protocol 867 number unique to RBridges; 869 o should also identify a specific (egress) RBridge - the shim 870 header may, for example, include an identifier unique to the 871 egress RBridge; 873 o should include the RBridge transit route, a hopcount, or a 874 timestamp to prevent indefinite looping of a frame. 876 4.4. RBridge General Operation 878 Operations that apply to all RBridges include peer and topology 879 discovery (which may include negotiation of RBridge 880 identifiers), Designated RBridge election, link-state routing, 881 SPF computation and advertising reach-ability for specific L2 882 (MAC Ethernet destination) addresses within a broadcast domain. 884 In addition, all RBridges will compute Ingress RBridge Trees for 885 delivery of (potentially VLAN scoped) broadcast, multicast and 886 flooded frames to each peer RBridge. Setting up these trees 887 early is important as there is otherwise no means for frame 888 delivery across the CRED during the learning phase. Because it 889 is very likely to be impossible (at an early stage) for RBridges 890 to determine which RBridges are edge RBridges, it is preferable 891 that each RBridge compute these trees for all RBridges as early 892 as possible - even if some entries will not be used. 894 The initial phase is the peer and topology discovery phase. This 895 should continue for a sufficient amount of time to reduce the 896 amount of re-negotiation (Designated RBridge and - possibly - 897 identifiers) and re-computation that will be triggered by 898 discovery of new peers. The timer values selected for delaying 899 the next phase should take into account the time required for 900 local STP and availability of segment connectivity between 901 RBridge peers. 903 The next phase is election of Designated RBridges for all shared 904 access segments. This phase cannot complete before completion of 905 peer and topology discovery. In parallel, RBridge routing 906 protocol should begin the process of building the link-state 907 information - assuming this was not done during the peer and 908 topology discovery phase. 910 At about this time, RBridges should establish ingress RBridge 911 trees. 913 Once RBridges have established Ingress RBridge Trees, the 914 learning and forwarding phase may begin. In this phase, RBridges 915 initially forward frames by flooding them via Ingress RBridge 916 Tree(s). Also during this phase, RBridges begin "learning" MAC 917 address locations from local segments and propagating L2 reach- 918 ability information via the RBridge routing protocol to all 919 other RBridges. Gradually, the CFT will be built up for all 920 RBridges, and fewer frames will require flooding via the Ingress 921 RBridge Tree(s). 923 The learning phase typically does not complete. Consequently, 924 the learning phase is also the operational phase. During the 925 combined learning and operational phase, all RBridges maintain 926 both an Ingress RBridge Tree and a CFT. RBridges not elected as 927 Designated RBridge may be required to become one in the event 928 that the DR goes off-line. 930 4.5. Ingress/Egress Operations 932 Operation specific to edge RBridges involves RBridge learning, 933 advertisement, encapsulation (at ingress RBridges) and 934 decapsulation (at egress RBridges). 936 As described elsewhere, RBridge learning is similar to typical 937 bridge learning - i.e. - all RBridges listen promiscuously to L2 938 Frames on a local LAN segment and acquire location information 939 associated with source MAC addresses in L2 frames they observe. 941 By convention, a Designated RBridge election always occurs. In 942 the degenerate case - where only one RBridge is connected to a 943 specific Ethernet segment - obviously that RBridge will "win" 944 the election and become the designated RBridge. 946 With this convention, only the Designated RBridge performs 947 RBridge learning for interface(s) connected to that segment. 949 As each RBridge learns segment-local MAC source addresses, it 950 creates an entry in its LPT that associates that MAC source 951 address with the interface on which it was learned. 953 Periodically, as determined by the RBridge routing protocol, 954 each RBridge advertises this learned information to its RBridge 955 peers. 957 These advertisements propagate to all edge RBridges (as 958 potentially scoped by associated VLAN information for each 959 advertisement). Each edge RBridge incorporates this information 960 in the form of a CFT entry. 962 RBridges also discover that they are an edge RBridge as a result 963 of receiving un-encapsulated frames that require forwarding. If 964 an RBridge is the Designated RBridge for a segment, and it has 965 not previously learned that the MAC destination for a frame is 966 local (this will be the case - for instance - for the very first 967 frame it observes), then the RBridge would be required to 968 forward (or flood) the frame via the CRED to all other RBridges 969 (potentially within a VLAN scope). 971 The RBridge in this case would flood the frame unless it has 972 already created a unicast CFT entry for the frame's MAC 973 destination address. If it has a corresponding CFT, then it 974 would use that. This RBridge would be an ingress RBridge with 975 respect to the frame being forwarded. 977 The encapsulation used by this ingress RBridge would be 978 determined by the CFT - if one exists - or the CFT-equivalent 979 entry for the Ingress RBridge Tree. The encapsulation - as 980 discussed elsewhere - should include (in the shim header) 981 information to identify the egress RBridge (for example, the 982 RBridge identifier negotiated previously during the peer and 983 topology discovery phase). 985 When the encapsulated frame arrives at egress RBridge(s), it is 986 decapsulated and forwarded via the egress interface(s) onto the 987 local segment. 989 Note that an egress RBridge will be the Designated RBridge on 990 the local segment accessed via its egress interface(s). If the 991 received frame does not correspond to a learned MAC destination 992 address at an egress interface, it will forward the frame on all 993 interfaces for which it is either the designated - or only - 994 RBridge. If the received frame does correspond to a learned MAC 995 destination address at an egress interface, the RBridge will 996 forward the frame via that interface only. 998 4.6. Transit Forwarding Operations 1000 There two models for transit forwarding within a CRED: unicast 1001 frame forwarding for known destinations, and everything else. 1002 The difference between the two is in how the encapsulation is 1003 determined. Exactly one of these models will be selected - in 1004 any instantiation of this architecture- for each of the 1005 following forwarding modes: 1007 o Unicast frame forwarding 1008 o Forwarding of non-unicast frames 1009 o Broadcast frame forwarding 1010 o Multicast frame forwarding 1011 o Frame flooding 1013 4.6.1. Unicast 1015 In unicast forwarding, the shim header is specific to the egress 1016 RBridge and MAC destination in the outer Ethernet encapsulation 1017 is specific to the next hop RBridge. 1019 Prior to preparing the frame for forwarding to the next hop 1020 RBridge, the MAC source address is examined and - if the MAC 1021 source address is an address of the local RBridge, the frame is 1022 discarded. 1024 As the frame is prepared for transmission at each RBridge, the 1025 next hop MAC destination information is determined at that local 1026 RBridge using a corresponding CFT based on the "shim" header. 1027 In addition, prior to re-writing the outer MAC destination 1028 address, the next hop MAC destination address is compared to the 1029 MAC source address of the outer Ethernet header and the frame is 1030 discarded if the two are equivalent. 1032 4.6.2. Broadcast, Multicast and Flooding 1034 Ingress RBridge Trees are used for forwarding of broadcast, 1035 multicast and unknown destination frames across the CRED. In a 1036 simple implementation, it is possible to use the CFT-IRT entries 1037 for all frames of these types. 1039 However, this approach results in potentially extreme 1040 inefficiencies in the multicast and unknown destination flooding 1041 cases. 1043 As a consequence, instantiations of this architecture should 1044 allow for local optimizations on a hop by hop basis. 1046 Examples of such optimizations are included in the sections 1047 below. 1049 4.6.2.1. Broadcast 1051 The path followed in transit forwarding of broadcast frames will 1052 have been established through actions initiated by each RBridge 1053 (as any RBridge is eligible to subsequently become an ingress 1054 RBridge) in the process of computing CFT-IRT entries. Each 1055 RBridge assumes that it may be a transit as well as an ingress 1056 and egress RBridge and will establish forwarding information 1057 relative to itself and each of its peer RBridges, and stored in 1058 the CFT-IRT. CFT-IRT entries are computed at each RBridge for 1059 paths going toward all other RBridges - at least in cases where 1060 the RBridge performing CFT-IRT computations is on the shortest 1061 path. 1063 Forwarding information is in two forms: transit encapsulation 1064 information for interfaces over which the RBridge will forward a 1065 broadcast frame to one or more peer RBridges and a decapsulation 1066 indication for each interface over which the RBridge may egress 1067 frames from the CRED. In each case, the CFT-IRT includes some 1068 identification of the interface on which a frame is forwarded 1069 toward any specific egress RBridge for frames received from any 1070 specific ingress RBridge. 1072 Note that an interface over which an RBridge may egress frames 1073 is any interface for which the RBridge is a Designated RBridge. 1074 RBridges must not wait to determine that one (or more) non- 1075 RBridge Ethernet nodes is present in an interface before 1076 deciding to forward decapsulated broadcast frames on that 1077 interface. 1079 Forwarding information is selected for each broadcast frame 1080 received by any RBridge (based on identifying the ingress 1081 RBridge for the frame) for all corresponding CFT-IRT entries. 1082 Each RBridge is thus required to replicate one RBridge 1083 encapsulated broadcast frame for each interface that is 1084 determined from CFT-IRT entries corresponding to the frame's 1085 ingress RBridge. This includes decapsulated broadcast frames for 1086 each interface for which it is the designated RBridge. 1088 Note that frame replication and forwarding should be scoped by 1089 VLAN if VLAN support is provided. Also note that a Designated 1090 RBridge (DR) may be required to transmit a decapsulated frame on 1091 the interface on which it received the RBridge encapsulated 1092 frame. 1094 This approach for broadcast forwarding might be considered to 1095 add complexity because replication occurs at all RBridges along 1096 the ingress RBridge tree, potentially for both RBridge 1097 encapsulated and decapsulated broadcast frames. However, the 1098 replication process is similar to replication of broadcast 1099 traffic in 802.1D bridges with the exception that additional 1100 replication may be required at each interface for egress from 1101 the CRED. 1103 Note that the additional replication associated with CRED egress 1104 may be made to exactly conform to 802.1D bridge broadcast 1105 replication in implementations that model a CRED egress as a 1106 separate logical interface. 1108 Using this approach results in one and only one copy of the 1109 broadcast frame being delivered to each egress RBridge. 1111 4.6.2.2. Multicast 1113 Multicast forwarding is reducible to broadcast forwarding in the 1114 simplest (default) case. However implementations may choose - 1115 using mechanisms that are out of scope for this document - to 1116 optimize multicast forwarding. In order for this to work 1117 effectively, however, support for awareness of multicast 1118 "interest" is required for all RBridges. 1120 Without optimization, multicast frames are injected by the 1121 ingress RBridge onto an IRT by - for instance - encapsulating 1122 the frame with a MAC destination multicast address, and 1123 forwarding it according to its local CFT-IRT. Again, without 1124 optimization, each RBridge along the path toward all egress 1125 RBridges will similarly forward the frame according to their 1126 local CFT-IRT. 1128 Using this approach results in one and only one copy of the 1129 multicast frame being delivered to appropriate egress RBridges. 1130 However, using this approach, multicast delivery is identical to 1131 broadcast delivery - hence very inefficient. 1133 In any optimization approach, RBridge encapsulated multicast 1134 frames will use either a broadcast or a group MAC destination 1135 address. In either case, the recognizably distinct destination 1136 addressing allows a frame forwarding decision to be made at each 1137 RBridge hop. RBridges may thus be able to take advantage of 1138 local knowledge of multicast distribution requirements to 1139 eliminate the forwarding requirement on interfaces for which 1140 there is no recipient interested in receiving frames associated 1141 with any specific group address. 1143 As stated earlier, in order for RBridges to be able to implement 1144 multicast optimization, distribution of learned multicast group 1145 "interest" information must be provided - and propagated - by 1146 all RBridges. Mechanisms for learning and propagating multicast 1147 group participation by RBridges is out of scope in this document 1148 but may be defined in RBridge protocol specification(s). 1150 Note that, because the multicast optimization would - in 1151 principle - further scope and reduce broadcast traffic, two 1152 things may be said: 1154 o It is not necessary that all implementations in a deployment 1155 implement the optimization (though all must support the data 1156 required to implement it in RBridge peers) in order for any 1157 local multicast optimization (consistent with the above 1158 description) to work; 1159 o Introduction of a multicast optimization will not result in 1160 potential forwarding loops where broadcast forwarding would 1161 not do so. 1163 In the simplest case, the ingress RBridge for a given multicast 1164 frame will re-use the MAC destination group address of a 1165 received multicast frame. However this may not be required as 1166 it is possible that the mechanisms specified to support 1167 multicast will require examination of the decapsulated MAC 1168 destination group address at each RBridge that implements the 1169 optimization. 1171 4.6.2.3. Flooding 1173 Flooding is similarly reducible to broadcast forwarding in the 1174 simplest (default) case - with the exception that a frame being 1175 flooded across the CRED is typically a unicast frame for which 1176 no CFT exists at the ingress RBridge. This is not a minor 1177 distinction, however, because it impacts the way that addressing 1178 may be used to accomplish flooding within the CRED. 1180 An ingress RBridge that does not have a CFT entry for a received 1181 frame MAC destination address, will inject the frame onto the 1182 ingress RBridge Tree by - for instance - encapsulating the frame 1183 with a MAC destination broadcast address, and forwarding it 1184 according to its local CFT-IRT. Without optimization, each 1185 RBridge along the path toward all egress RBridges will similarly 1186 forward the frame according to their local CFT-IRT. 1188 Using this approach results in one and only one copy of the 1189 flooded frame being delivered to all egress RBridges. 1191 However implementations may choose to optimize flooding. A 1192 Flooding optimization will only work at any specific RBridge if 1193 that RBridge re-evaluates the original (decapsulated) unicast 1194 frame. 1196 Any flooding optimization would operate similarly to the 1197 multicast optimization described above, except that - instead of 1198 requiring local information about multicast distribution - each 1199 RBridge implementing the optimization will need only to lookup 1200 the MAC destination address of the original (decapsulated) frame 1201 in its local CFT. If an entry is found, the frame could then be 1202 forwarded only if the specific RBridge is on the shortest path 1203 between the originating ingress RBridge and the appropriate 1204 egress RBridge. This could be implemented - for example - as a 1205 specialized CFT-IRT entry. 1207 Note that, because the flooding optimization would - in 1208 principle - further scope and reduce flooded traffic, two things 1209 may be said: 1211 o It is not necessary that all implementations in a deployment 1212 support the optimization in order for any local flooding 1213 optimization (consistent with the above description) to work 1214 (hence such an optimization is optional); 1215 o Introduction of the flooding optimization will not result in 1216 potential forwarding loops where flooded forwarding would not 1217 do so. 1219 Because a forwarding decision can be made at each hop, it is 1220 possible to terminate flooding early if a CFT for the original 1221 MAC destination was in the process of being propagated when 1222 flooding for the frame was started. It is therefore possible to 1223 reduce the amount of flooding to some degree in this case. 1225 4.7. Routing Protocol Operation 1227 The details of routing protocol operation can be determined once 1228 a specific routing protocol has been selected. These details 1229 would be defined in appropriate protocol specification(s). 1231 Protocol specifications should identify means for determining 1232 the content of the CFT, CFT-IRT and CTT. 1234 4.8. Other Bridging and Ethernet Protocol Operations 1236 In defining this architecture, several interaction models have 1237 been considered for protocol interaction between RBridges and 1238 other L2 forwarding devices - in particular, 802.1D bridges. 1239 Whatever model we adopt for these interactions must allow for 1240 the possibility of other types of L2 forwarding devices. Hence, 1241 a minimal participation model is most likely to be successful 1242 over the long term, assuming that RBridges are used in a L2 1243 topology that would be functional if RBridges were replaced by 1244 other types of L2 forwarding devices. 1246 Toward this end, RBridges - and the CRED as a whole - could (in 1247 theory) participate in Ethernet link protocols, notably the 1248 spanning tree protocol (STP) on the ingress/egress links using 1249 exactly one of the following interaction models: 1251 o Transparent Participation (Transparent-STP) 1252 o Active Participation (Participate-STP) 1253 o Blocking Participation (Block-STP) 1255 Only one of these variants would be supported by an instance of 1256 this architecture. All RBridges within a single CRED must use 1257 the same model for interacting with non-RBridge protocols. 1258 Furthermore, it is the explicit intent that only one of these 1259 models is ultimately supported - at least as a default mode of 1260 compliant implementations. 1262 This architecture assumes RBridges block STP. 1264 5. How RBridges Address TRILL 1266 This section is for further study, after determining the set of 1267 TRILL requirements that this architecture document is expected 1268 to address. 1270 6. Conclusions 1272 This document discusses options considered and factors affecting 1273 any protocol specific choices that may be made in instantiating 1274 the TRILL architecture using RBridges. 1276 Specific architectural and protocol instantiations should take 1277 these into consideration. In particular, protocol, encapsulation 1278 and procedure specifications should allow for potential 1279 optimizations described in the architectural document to the 1280 maximum extent possible. 1282 Also, this document addresses considerations relative to 1283 interaction with existing technology and "future-proofing" 1284 solutions. For both simplicity in description, and robust long 1285 term implementation of the technology, this document recommends 1286 the use of clear distinction - at all possible points - of 1287 definitions, protocols, procedures, etc. from related (but not 1288 identical) specifications and interactions. 1290 In particular, this document recommends the use of a 1291 "collocation model" in addressing issues with combining RBridge, 1292 Router and 802.1D bridge behavior. 1294 7. Security Considerations 1296 As one stated requirement of this architecture is the need to be 1297 able to provide an L2 delivery mechanism that is potentially 1298 configuration free, the default operation mode for instances of 1299 this architecture should assume a trust model that does not 1300 require configuration of security information. This is - in fact 1301 - an identical trust model to that used by Ethernet devices in 1302 general. 1304 In consequence, the default mode does not require - but also 1305 does not preclude - the use of established security mechanisms 1306 associated with the existing protocols that may be extended or 1307 enhanced to satisfy this document's architectural definitions. 1309 In general, this architecture suggest the use of a link-state 1310 routing protocol - modified as required to support L2 reach- 1311 ability and link state between RBridges. Any mechanisms defined 1312 to support secure protocol exchanges between link-state routing 1313 peers may be extended to support this architecture as well. 1315 This architecture also suggests use of additional encapsulation 1316 mechanisms and - to the extent that any proposed mechanism may 1317 include (or be extended to include) secure transmission - it may 1318 be desirable to provide such (optional) extensions. 1320 To the extent possible, any extensions of protocol or 1321 encapsulation should allow for at least one mode of operation 1322 that doesn't require configuration - if necessary, for limited 1323 use in a physically secure deployment. 1325 8. IANA Considerations 1327 This document has no direct IANA considerations. It does 1328 suggest, that protocols that instantiate the architecture use a 1329 shim header as a wrapper on the payload for RBridge to RBridge 1330 traffic, And this shim header may be identified by a new 1331 protocol type in the tunneled Ethernet link header. This 1332 protocol type, identified in an 802 header, would be allocated 1333 by the IEEE in cooperation with IANA. 1335 9.Acknowledgments 1337 The initial work for this document was largely done by Joe 1338 Touch, based on work he and Radia Perlman completed earlier. 1339 Subsequent changes are not to be blamed on them. 1341 In addition, the current text has been helped substantially by 1342 comments and suggestions from the TRILL working group and from 1343 Joel Halpern, Russ White and Ron Bonica in particular. 1345 10. References 1347 10.1.Normative References 1349 None. 1351 10.2.Informative References 1353 [1] Perlman, R., "RBridges: Transparent Routing", Proc. 1354 Infocom 2005, March 2004. 1356 [2] Touch, J., (ed.) "Transparent Interconnection of Lots of 1357 Links (TRILL): Problem and Applicability Statement", work 1358 in progress, draft-touch-trill-prob-00.txt, November, 1359 2005. 1361 [3] Perlman, R., "RBridges: Base Protocol Specification", work 1362 in progress, draft-ietf-trill-rbridge-protocol-00.txt, 1363 January, 2006. 1365 [4] Postel, J., "INTERNET PROTOCOL", RFC 791, September, 1981. 1367 [5] 802.1D-2004 IEEE Standard for Local and Metropolitan Area 1368 Networks: Media Access Control (MAC) Bridges 1370 [6] Gray, E., (ed.)"TRILL Routing Requirements in Support of 1371 RBridges", work in progress, draft-gray-trill-routing- 1372 reqs-01.txt, June, 2006 1374 [7] Moy, J., "OSPF Version 2", RFC 2328, April, 1998. 1376 [8] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and 1377 Dual Environments", RFC 1195, December, 1990. 1379 [9] Coltun, R., D. Ferguson & J. Moy, "OSPF for IPv6", RFC 1380 2740, December, 1999. 1382 Author's Addresses 1384 Editor: 1386 Eric Gray 1387 Ericsson 1388 900 Chelmsford Street 1389 Lowell, MA, 01851 1390 Phone: +1 (978) 275-7470 1391 EMail: Eric.Gray@Ericsson.com 1393 Contributors: 1395 Joe Touch 1396 USC/ISI 1397 4676 Admiralty Way 1398 Marina del Rey, CA 90292-6695, U.S.A. 1399 Phone: +1 (310) 448-9151 1400 EMail: touch@isi.edu 1401 URL: http://www.isi.edu/touch 1403 Radia Perlman 1404 Sun Microsystems 1406 EMail: Radia.Perlman@sun.com 1408 Intellectual Property Statement 1410 The IETF takes no position regarding the validity or scope of 1411 any Intellectual Property Rights or other rights that might be 1412 claimed to pertain to the implementation or use of the 1413 technology described in this document or the extent to which any 1414 license under such rights might or might not be available; nor 1415 does it represent that it has made any independent effort to 1416 identify any such rights. Information on the procedures with 1417 respect to rights in RFC documents can be found in BCP 78 and 1418 BCP 79. 1420 Copies of IPR disclosures made to the IETF Secretariat and any 1421 assurances of licenses to be made available, or the result of an 1422 attempt made to obtain a general license or permission for the 1423 use of such proprietary rights by implementers or users of this 1424 specification can be obtained from the IETF on-line IPR 1425 repository at http://www.ietf.org/ipr. 1427 The IETF invites any interested party to bring to its attention 1428 any copyrights, patents or patent applications, or other 1429 proprietary rights that may cover technology that may be 1430 required to implement this standard. Please address the 1431 information to the IETF at ietf-ipr@ietf.org. 1433 Disclaimer of Validity 1435 This document and the information contained herein are provided 1436 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1437 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 1438 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 1439 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 1440 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 1441 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1442 FOR A PARTICULAR PURPOSE. 1444 Copyright Statement 1446 Copyright (C) The Internet Society (2006). 1448 This document is subject to the rights, licenses and 1449 restrictions contained in BCP 78, and except as set forth 1450 therein, the authors retain all their rights. 1452 Acknowledgment 1454 Funding for the RFC Editor function is currently provided by the 1455 Internet Society.