idnits 2.17.1 draft-ietf-trill-rbridge-protocol-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2010) is 5130 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. 'ISO10589' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5342 (Obsoleted by RFC 7042) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Radia Perlman 2 INTERNET-DRAFT Intel Labs 3 Intended status: Proposed Standard Donald Eastlake 3rd 4 Expires: September 2, 2010 Stellar Switches 5 Dinesh G. Dutt 6 Silvano Gai 7 Cisco Systems 8 Anoop Ghanwani 9 Brocade 10 March 3, 2010 12 RBridges: Base Protocol Specification 13 15 Abstract 17 RBridges provide optimal pair-wise forwarding without configuration, 18 safe forwarding even during periods of temporary loops, and support 19 for multipathing of both unicast and multicast traffic. They achieve 20 these goals using IS-IS routing and encapsulation of traffic with a 21 header that includes a hop count. 23 RBridges are compatible with previous IEEE 802.1 customer bridges as 24 well as IPv4 and IPv6 routers and end nodes. They are as invisible to 25 current IP routers as bridges are and, like routers, they terminate 26 the bridge spanning tree protocol. 28 The design supports VLANs and optimization of the distribution of 29 multi-destination frames based on VLAN and IP derived multicast 30 groups. It also allows unicast forwarding tables at transit RBridges 31 to be sized according to the number of RBridges (rather than the 32 number of end nodes), which allows their forwarding tables to be 33 substantially smaller than in conventional customer bridges. 35 Status of This Document 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. This document may contain material 39 from IETF Documents or IETF Contributions published or made publicly 40 available before November 10, 2008. The person(s) controlling the 41 copyright in some of this material may not have granted the IETF 42 Trust the right to allow modifications of such material outside the 43 IETF Standards Process. Without obtaining an adequate license from 44 the person(s) controlling the copyright in such materials, this 45 document may not be modified outside the IETF Standards Process, and 46 derivative works of it may not be created outside the IETF Standards 47 Process, except to format it for publication as an RFC or to 48 translate it into languages other than English. 50 Distribution of this document is unlimited. Comments should be sent 51 to the TRILL working group mailing list . 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF), its areas, and its working groups. Note that 55 other groups may also distribute working documents as Internet- 56 Drafts. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 The list of current Internet-Drafts can be accessed at 64 http://www.ietf.org/1id-abstracts.html 66 The list of Internet-Draft Shadow Directories can be accessed at 67 http://www.ietf.org/shadow.html 69 Acknowledgements 71 Many people have contributed to this design, including the following, 72 in alphabetic order: 74 Bernard Aboba, Alia Atlas, Ayan Banerjee, Caitlin Bestler, Suresh 75 Boddapati, David Michael Bond, Stewart Bryant, Ross Callon, James 76 Carlson, Pasi Eronen, Dino Farinacci, Adrian Farrell, Don Fedyk, 77 Bill Fenner, Eric Gray, Joel Halpern, Andrew Lange, Acee Lindem, 78 Peter McCann, Israel Meilik, David Melman, Nandakumar Natarajan, 79 Erik Nordmark, Jeff Pickering, Tim Polk, Dan Romascanu, Sanjay 80 Sane, Pekka Savola, Matthew R. Thomas, Joe Touch, Mark Townsley, 81 Kate Zebrose. 83 We invite you to join the mailing list at 84 http://www.postel.org/rbridge. 86 Table of Contents 88 Abstract...................................................1 89 Status of This Document....................................1 90 Acknowledgements...........................................2 92 1. Introduction............................................7 93 1.1 Algorhyme V2, by Ray Perlner...........................8 94 1.2 Normative Content and Precedence.......................8 95 1.3 Terminology and Notation in this document..............8 96 1.4 Categories of Layer 2 Frames...........................9 97 1.5 Acronyms..............................................10 99 2. RBridges...............................................12 100 2.1 General Overview......................................12 101 2.2 End Station Addresses.................................13 102 2.3 RBridge Encapsulation Architecture....................14 103 2.4 Forwarding Overview...................................16 104 2.4.1 Known-Unicast.......................................16 105 2.4.2 Multi-destination...................................17 106 2.5 RBridges and VLANs....................................18 107 2.5.1 Link VLAN Assumptions...............................18 108 2.6 RBridges and IEEE 802.1 Bridges.......................19 109 2.6.1 RBridge Ports and 802.1 Layering....................19 110 2.6.2 Incremental Deployment..............................21 112 3. Details of the TRILL Header............................22 113 3.1 TRILL Header Format...................................22 114 3.2 Version (V)...........................................22 115 3.3 Reserved (R)..........................................23 116 3.4 Multi-destination (M).................................23 117 3.5 Op-Length.............................................23 118 3.6 Hop Count.............................................24 119 3.7 RBridge Nicknames.....................................24 120 3.7.1 Egress RBridge Nickname.............................25 121 3.7.2 Ingress RBridge Nickname............................25 122 3.7.3 RBridge Nickname Selection..........................25 123 3.8 TRILL Header Options..................................27 125 4. Other RBridge Design Details...........................29 126 4.1 Ethernet Data Encapsulation...........................29 127 4.1.1 VLAN Tag Information................................31 128 4.1.2 Inner VLAN Tag......................................32 129 4.1.3 Outer VLAN Tag......................................32 130 4.1.4 Frame Check Sequence (FCS)..........................33 131 4.2 Link State Protocol (IS-IS)...........................33 132 4.2.1 IS-IS RBridge Identity..............................33 133 4.2.2 IS-IS Instances.....................................34 134 4.2.3 TRILL IS-IS Frames..................................34 135 4.2.4 TRILL Link Hellos, DRBs, and Appointed Forwarders...35 136 4.2.4.1 P2P Hello Links...................................36 138 Table of Contents Continued 140 4.2.4.2 Designated RBridge................................36 141 4.2.4.3 Appointed VLAN-x Forwarder........................37 142 4.2.4.4 TRILL LSP Information.............................38 143 4.2.5 The TRILL ESADI Protocol............................41 144 4.2.5.1 TRILL ESADI Participation.........................43 145 4.2.5.2 TRILL ESADI Information...........................43 146 4.2.6 SPF, Forwarding, and Ambiguous Destinations.........44 147 4.3 Inter-RBridge Link MTU Size...........................44 148 4.3.1 Determining Campus-Wide TRILL IS-IS MTU Size........45 149 4.3.2 Testing Link MTU Size...............................45 150 4.4 TRILL-Hello Protocol..................................46 151 4.4.1 TRILL-Hello Rationale...............................46 152 4.4.2 TRILL-Hello Contents and Timing.....................47 153 4.4.2.1 TRILL Neighbor List...............................49 154 4.4.3 TRILL MTU probe and TRILL Hello VLAN Tagging........49 155 4.4.4 Multiple Ports on the Same Link.....................51 156 4.4.5 VLAN Mapping Within a Link..........................52 157 4.5 Distribution Trees....................................53 158 4.5.1 Distribution Tree Calculation.......................55 159 4.5.2 Multi-destination Frame Checks......................56 160 4.5.3 Pruning the Distribution Tree.......................58 161 4.5.4 Tree Distribution Optimization......................58 162 4.5.5 Forwarding Using a Distribution Tree................59 163 4.6 Frame Processing Behavior.............................60 164 4.6.1 Receipt of a Native Frame...........................61 165 4.6.1.1 Native Unicast Case...............................61 166 4.6.1.2 Native Multicast and Broadcast Frames.............62 167 4.6.2 Receipt of a TRILL Frame............................63 168 4.6.2.1 TRILL Control Frames..............................63 169 4.6.2.2 TRILL ESADI Frames................................64 170 4.6.2.3 TRILL Data Frames.................................64 171 4.6.2.4 Known Unicast TRILL Data Frames...................64 172 4.6.2.5 Multi-Destination TRILL Data Frames...............65 173 4.6.3 Receipt of a Layer 2 Control Frame..................66 174 4.7 IGMP, MLD, and MRD Learning...........................66 175 4.8 End Station Address Details...........................67 176 4.8.1 Learning End Station Addresses......................68 177 4.8.2 Learning Confidence Level Rationale.................69 178 4.8.3 Forgetting End Station Addresses....................70 179 4.8.4 Shared VLAN Learning................................71 180 4.9 RBridge Ports.........................................72 181 4.9.1 RBridge Port Configuration..........................72 182 4.9.2 RBridge Port Structure..............................73 183 4.9.3 BPDU Handling.......................................75 184 4.9.3.1 Receipt of BPDUs..................................76 185 4.9.3.2 Root Bridge Changes...............................76 186 4.9.3.3 Transmission of BPDUs.............................77 187 4.9.4 Dynamic VLAN Registration...........................77 189 Table of Contents Continued 191 5. RBridge Parameters.....................................78 192 5.1 Per RBridge...........................................78 193 5.2 Per Nickname Per RBridge..............................79 194 5.3 Per Port Per RBridge..................................79 195 5.4 Per VLAN Per RBridge..................................80 197 6. Security Considerations................................82 198 6.1 VLAN Security Considerations..........................82 199 6.2 BPDU/Hello Denial of Service Considerations...........83 201 7. Assignment Considerations..............................85 202 7.1 IANA Considerations...................................85 203 7.2 IEEE Registration Authority Considerations............85 205 8. Normative References...................................86 206 9. Informative References.................................88 208 Appendix A: Incremental Deployment Considerations.........90 209 A.1 Link Cost Determination...............................90 210 A.2 Appointed Forwarders and Bridged LANs.................90 211 A.3 Wiring Closet Topology................................92 212 A.3.1 The RBridge Solution................................93 213 A.3.2 The VLAN Solution...................................93 214 A.3.3 The Spanning Tree Solution..........................93 215 A.3.4 Comparison of Solutions.............................94 217 Appendix B: Trunk and Access Port Configuration...........95 218 Appendix C: Multipathing..................................96 219 Appendix D: Determination of VLAN and Priority............99 221 Appendix E: Support of IEEE 802.1Q-2005 Amendments.......100 222 E.1 Completed Amendments.................................100 223 E.2 In-process Amendments................................101 225 Appendix Z: Revision History.............................102 226 Changes from -03 to -04..................................102 227 Changes from -04 to -05..................................103 228 Changes from -05 to -06..................................104 229 Changes from -06 to -07..................................104 230 Changes from -07 to -08..................................106 231 Changes from -08 to -09..................................107 232 Changes from -09 to -10..................................108 233 Changes from -10 to -11..................................109 234 Changes from -11 to -12..................................109 235 Changes from -12 to -13..................................110 236 Changes from -13 to -14..................................111 237 Changes from -14 to -15..................................113 238 Changes from -15 to -16..................................114 240 Table of Figures 242 Figure 2.1: Interconnected RBridges.......................15 243 Figure 2.2: An Ethernet Encapsulated TRILL Frame..........15 244 Figure 2.3: A PPP Encapsulated TRILL Frame................15 245 Figure 2.4: RBridge Port Model............................20 246 Figure 3.1: TRILL Header..................................22 247 Figure 3.2: Options Area Initial Flags Octet..............28 248 Figure 4.1: TRILL Data Encapsulation over Ethernet........30 249 Figure 4.2: VLAN Tag Information..........................31 250 Figure 4.3: TRILL IS-IS Frame Format......................35 251 Figure 4.4: TRILL ESADI Frame Format......................42 252 Figure 4.5: Detailed RBridge Port Model...................74 253 Figure A.1: Link Cost of a Bridged Link...................90 254 Figure A.2: Wiring Closet Topology........................92 255 Figure C.1: Multi-Destination Multipath...................96 256 Figure C.2: Known Unicast Multipath.......................97 258 1. Introduction 260 In traditional IPv4 and IPv6 networks, each subnet has a unique 261 prefix. Therefore, a node in multiple subnets has multiple IP 262 addresses, typically one per interface. This also means that when an 263 interface moves from one subnet to another, it changes its IP 264 address. Administration of IP networks is complicated because IP 265 routers require per port subnet address configuration. Careful IP 266 address management is required to avoid creating subnets that are 267 sparsely populated, wasting addresses. 269 IEEE 802.1 bridges avoid these problems by transparently gluing many 270 physical links into what appears to IP to be a single LAN [802.1D]. 271 However, 802.1 bridge forwarding using the spanning tree protocol has 272 some disadvantages: 274 o The spanning tree protocol works by blocking ports, limiting the 275 number of forwarding links, and therefore creates bottlenecks by 276 concentrating traffic onto selected links. 278 o Forwarding is not pair-wise shortest path, but is instead whatever 279 path remains after the spanning tree eliminates redundant paths. 281 o The Ethernet header does not contain a hop count (or TTL) field. 282 This is dangerous when there are temporary loops such as when 283 spanning tree messages are lost or components such as repeaters 284 are added. 286 o VLANs can partition when spanning tree reconfigures. 288 This document presents the design for RBridges (Routing Bridges 289 [RBridges]) that implement the TRILL protocol and are poetically 290 summarized below. Rbridges combine the advantages of bridges and 291 routers and, as specified in this document, are the application of 292 link state routing to the VLAN aware customer bridging problem. With 293 the exceptions discussed in this document, RBridges can incrementally 294 replace IEEE [802.1Q-2005] or [802.1D] customer bridges. 296 While RBridges can be applied to a variety of link protocols, this 297 specification focuses on IEEE [802.3] links. Use with other link 298 types is expected to be covered in other documents. 300 The TRILL protocol, as specified herein, is designed to be a Local 301 Area Network protocol and not designed with the goal of scaling 302 beyond the size of existing bridged LANs. For further discussion of 303 the problem domain addressed by RBridges see [RFC5556]. 305 1.1 Algorhyme V2, by Ray Perlner 307 I hope that we shall one day see 308 A graph more lovely than a tree. 310 A graph to boost efficiency 311 While still configuration-free. 313 A network where RBridges can 314 Route packets to their target LAN. 316 The paths they find, to our elation, 317 Are least cost paths to destination! 319 With packet hop counts we now see, 320 The network need not be loop-free! 322 RBridges work transparently, 323 Without a common spanning tree. 325 1.2 Normative Content and Precedence 327 The bulk of the normative material in this specification appears in 328 Sections 1 through 4. In case of conflict between provisions in 329 these four sections, the provision in the higher numbered section 330 prevails. 332 1.3 Terminology and Notation in this document 334 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 335 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 336 document are to be interpreted as described in [RFC2119]. 338 "TRILL" is the protocol specified herein while an "RBridge" is a 339 device that implements that protocol. The second letter in Rbridge 340 is case insensitive. Both Rbridge and RBridge are correct. 342 In this document, the term "link", unless otherwise qualified, means 343 "bridged LAN", that is to say, the combination of one or more [802.3] 344 links with zero or more bridges, hubs, repeaters, or the like. The 345 term "simple link" or the like is used indicate a point-to-point or 346 multi-access link with no included bridges or RBridges. 348 In this document, the term "port", unless otherwise qualified, 349 includes physical, virtual [802.1AE], and pseudo [802.1X] ports. The 350 term "physical port" or the like is used to indicate the physical 351 point of connection between an RBridge and a link. 353 A "campus" is to RBridges as a "bridged LAN" is to bridges. An 354 RBridge campus consists of a network of RBridges, bridges, hubs, 355 repeaters, simple links, and the like and it is bounded by end 356 stations and routers. 358 The term "spanning tree" in this document includes both classic 359 spanning tree and rapid spanning tree (RSTP). 361 This document uses Hexadecimal Notation for MAC addresses. Two 362 hexadecimal digits represent each octet (that is, 8-bit byte), giving 363 the value of the octet as an unsigned integer. A hyphen separates 364 successive octets. This document consistently uses IETF bit ordering 365 although the physical order of bit transmission within an octet on an 366 IEEE [802.3] link is from the lowest order bit to the highest order 367 bit, the reverse of IETF ordering. 369 1.4 Categories of Layer 2 Frames 371 In this document, Layer 2 frames are divided into five categories: 373 o layer 2 control frames (such as BPDUs) 374 o native frames (non-TRILL-encapsulated data frames) 375 o TRILL data frames (TRILL-encapsulated data frames) 376 o TRILL control frames 377 o TRILL other frames 379 The way these five types of frames are distinguished is as follows: 381 o Layer 2 control frames are those with a multicast destination 382 address in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F or 383 equal to 01-80-C2-00-00-21. RBridges MUST NOT encapsulate and 384 forward such frames, though they MAY, unless otherwise 385 specified in this document, perform the layer 2 function (such 386 as MAC level security) of the control frame. Frames with a 387 destination address of 01-80-C2-00-00-00 (BPDU) or 388 01-80-C2-00-00-21 (VRP) are called "high level control frames" 389 in this document. All other layer 2 control frames are called 390 "low level control frames". 392 o Native frames are those that are not control frames and have an 393 Ethertype other than "TRILL" or "L2-IS-IS" and have a 394 destination MAC address that is not one of the 16 multicast 395 addresses reserved for TRILL. 397 o TRILL data frames have the Ethertype "TRILL". In addition, 398 TRILL data frames, if multicast, have the multicast destination 399 MAC address "All-RBridges". 401 o TRILL control frames have the Ethertype "L2-IS-IS". In 402 addition, TRILL control frames, if multicast, have the 403 multicast destination MAC addresses of "All-IS-IS-RBridges". 404 (Note that ESADI frames look on the outside like TRILL data and 405 are so handled but, when decapsulated, have the L2-IS-IS 406 Ethertype.) 408 o TRILL other frames are those with any of the 16 multicast 409 destination addresses reserved for TRILL other than All- 410 RBridges and All-IS-IS-RBridges. RBridges conformant to this 411 specification MUST discard TRILL other frames. 413 1.5 Acronyms 415 AllL1ISs - All Level 1 Intermediate Systems 417 AllL2ISs - All Level 2 Intermediate Systems 419 BPDU - Bridge PDU 421 CHbH - Critical Hop-by-Hop 423 CItE - Critical Ingress-to-Egress 425 CSNP - Complete Sequence Number PDU 427 DA - Destination Address 429 DR - Designated Router 431 DRB - Designated RBridge 433 EAP - Extensible Authentication Protocol 435 ECMP - Equal Cost Multi-Path 437 EISS - Extended Internal Sublayer Service 439 ESADI - End Station Address Distribution Information 441 FCS - Frame Check Sequence 443 GARP - Generic Attribute Registration Protocol 445 GVRP - GARP VLAN Registration Protocol 446 IEEE - Institute of Electrical and Electronics Engineers 448 IGMP - Internet Group Management Protocol 450 IP - Internet Protocol 452 IS-IS - Intermediate System to Intermediate System 454 ISS - Internal Sublayer Service 456 LAN - Local Area Network 458 LSP - Link State PDU 460 MAC - Media Access Control 462 MLD - Multicast Listener Discovery 464 MRD - Multicast Router Discovery 466 MTU - Maximum Transmission Unit 468 MVRP - Multiple VLAN Registration Protocol 470 NSAP - Network Service Access Point 472 P2P - Point-to-point 474 PDU - Protocol Data Unit 476 PPP - Point-to-Point Protocol 478 RBridge - Routing Bridge 480 RPF - Reverse Path Forwarding 482 SA - Source Address 484 SNMP - Simple Network Management Protocol 486 SPF - Shortest Path First 488 TLV - Type, Length, Value 490 TRILL - TRansparent Interconnection of Lots of Links 492 VLAN - Virtual Local Area Network 494 VRP - VLAN Registration Protocol 496 2. RBridges 498 This section provides a high-level overview of RBridges, which 499 implement the TRILL protocol, omitting some details. Sections 3 and 4 500 below provide more detailed specifications. 502 TRILL, as described in this document and with the exceptions 503 discussed herein, provides [802.1Q-2005] VLAN aware customer bridging 504 service. As described below, TRILL is layered above the ports of an 505 RBridge. 507 The RBridges specified by this document do not supply provider 508 [802.1ad] or provider backbone [802.1ah] bridging or the like. The 509 extension of TRILL to provide such provider services is left for 510 future work that will be separately documented. However, provider or 511 provider backbone bridges may be used to interconnect parts of an 512 RBridge campus. 514 2.1 General Overview 516 RBridges run a link state protocol amongst themselves. This gives 517 them enough information to compute pair-wise optimal paths for 518 unicast, and calculate distribution trees for delivery of frames 519 either to destinations whose location is unknown or to multicast / 520 broadcast groups. [RBridges] [RP1999] 522 To mitigate temporary loop issues, RBridges forward based on a header 523 with a hop count. RBridges also specify the next hop RBridge as the 524 frame destination when forwarding unicast frames across a shared- 525 media link, which avoids spawning additional copies of frames during 526 a temporary loop. A Reverse Path Forwarding Check and other checks 527 are performed on multi-destination frames to further control 528 potentially looping traffic (see Section 4.5.2). 530 The first RBridge that a unicast frame encounters in a campus, RB1, 531 encapsulates the received frame with a TRILL header that specifies 532 the last RBridge, RB2, where the frame is decapsulated. RB1 is known 533 as the "ingress RBridge" and RB2 is known as the "egress RBridge". 534 To save room in the TRILL header and simplify forwarding lookups, a 535 dynamic nickname acquisition protocol is run among the RBridges to 536 select 2-octet nicknames for RBridges, unique within the campus, 537 which are an abbreviation for the IS-IS ID of the RBridge. The 538 2-octet nicknames are used to specify the ingress and egress RBridges 539 in the TRILL header. 541 Multipathing of multi-destination frames through alternative 542 distribution trees and ECMP (Equal Cost MultiPath) of unicast frames 543 are supported (see Appendix C). 545 Networks with a more mesh-like structure will benefit to a greater 546 extent from the multipathing and optimal paths provided by TRILL than 547 will more tree-like networks. 549 RBridges run a protocol on a link to elect a "Designated RBridge" 550 (DRB). The TRILL-IS-IS election protocol on a link is a little 551 different from the Layer 3 IS-IS [ISO10589] election protocol, 552 because in TRILL it is essential that only one RBridge be elected 553 DRB, whereas in Layer 3 IS-IS it is possible for multiple routers to 554 be elected Designated Router (also known as Designated Intermediate 555 System). As with an IS-IS router, the DRB may give a pseudonode name 556 to the link, issue an LSP (Link State PDU) on behalf of the 557 pseudonode, and issues CSNPs (Complete Sequence Number PDUs) on the 558 link. Additionally, the DRB has some TRILL-specific duties, including 559 specifying which VLAN will be the Designated VLAN used for 560 communication between RBridges on that link (see Section 4.2.4.2). 562 The DRB either encapsulates / decapsulates all data traffic to/from 563 the link, or, for load splitting, delegates this responsibility, for 564 one or more VLANs, to other RBridges on the link. There must at all 565 times be at most one RBridge on the link that encapsulates / 566 decapsulates traffic for a particular VLAN. We will refer to the 567 RBridge appointed to forward VLAN-x traffic on behalf of the link as 568 the "appointed VLAN-x forwarder" (see Section 4.2.4.3). (Section 2.5 569 discusses VLANs further.) 571 Rbridges SHOULD support SNMPv3 [RFC3411]. The Rbridge MIB will be 572 specified in a separate document. If IP service is available to an 573 RBridge, it SHOULD support SNMPv3 over UDP over IPv4 [RFC3417] and 574 IPv6 [RFC3419]; however, management can be used, within a campus, 575 even for an RBridge that lacks an IP or other Layer 3 transport stack 576 or which does not have a Layer 3 address, by transporting SNMP with 577 Ethernet [RFC4789]. 579 2.2 End Station Addresses 581 An RBridge, RB1, which is the VLAN-x forwarder on any of its links 582 MUST learn the location of VLAN-x end nodes, both on the links for 583 which it is VLAN-x forwarder, and on other links in the campus. RB1 584 learns the port, VLAN, and Layer 2 (MAC) addresses of end nodes on 585 links for which it is VLAN-x forwarder from the source address of 586 frames received, as bridges do (for example, see section 8.7 of 587 [802.1Q-2005]), or through configuration or a Layer 2 explicit 588 registration protocol such as IEEE 802.11 association and 589 authentication. RB1 learns the VLAN and Layer 2 address of distant 590 VLAN-x end nodes, and the corresponding RBridge to which they are 591 attached, by looking at the ingress RBridge nickname in the TRILL 592 header and the VLAN and source MAC address of the inner frame of 593 TRILL data frames that it decapsulates. 595 Additionally, an RBridge that is the appointed VLAN-x forwarder on 596 one or more links MAY use the End Station Address Distribution 597 Information (ESADI) protocol to announce some or all of the attached 598 VLAN-x end nodes on those links. 600 The ESADI protocol could be used to announce end nodes that have been 601 explicitly enrolled. Such information might be more authoritative 602 than that learned from data frames being decapsulated onto the link. 603 Also, the addresses enrolled and distributed in this way can be more 604 secure for two reasons: (1) the enrollment might be authenticated 605 (for example by cryptographically based EAP methods via [802.1X]), 606 and (2) the ESADI protocol also supports cryptographic authentication 607 of its messages [RFC5304] for more secure transmission. 609 If an end station is unplugged from one RBridge and plugged into 610 another then, depending on circumstances, frames addressed to that 611 end station can be black holed. This is, they can be sent just to the 612 older RBridge that the end station used to be connected to until 613 cached address information at some remote RBridge(s) times out, 614 possibly for a number of minutes or longer. With the ESADI protocol, 615 the link interruption from the unplugging can cause an immediate 616 update to be sent. 618 Even if the ESADI protocol is used to announce or learn attached end 619 nodes, RBridges MUST still learn from received native frames and 620 decapsulated TRILL data frames unless configured not to do so. 621 Advertising end nodes using ESADI is optional, as is learning from 622 these announcements. 624 (See Section 4.8 for further end station address details.) 626 2.3 RBridge Encapsulation Architecture 628 The Layer 2 technology used to connect Rbridges may be either IEEE 629 [802.3] or some other link technology such as PPP [RFC1661]. This is 630 possible since the RBridge relay function is layered on top of the 631 Layer 2 technologies. However, this document specifies only an IEEE 632 802.3 encapsulation. 634 Figure 2.1 shows two RBridges, RB1 and RB2, interconnected through an 635 Ethernet cloud. The Ethernet cloud may include hubs, point-to-point 636 or shared media, IEEE 802.1D bridges, or 802.1Q bridges. 638 ------------ 639 / \ 640 +-----+ / Ethernet \ +-----+ 641 | RB1 |----< >---| RB2 | 642 +-----+ \ Cloud / +-----+ 643 \ / 644 ------------ 646 Figure 2.1: Interconnected RBridges 648 Figure 2.2 shows the format of a TRILL data or ESADI frame traveling 649 through the Ethernet cloud between RB1 and RB2. 651 +--------------------------------+ 652 | Outer Ethernet Header | 653 +--------------------------------+ 654 | TRILL Header | 655 +--------------------------------+ 656 | Inner Ethernet Header | 657 +--------------------------------+ 658 | Ethernet Payload | 659 +--------------------------------+ 660 | Ethernet FCS | 661 +--------------------------------+ 663 Figure 2.2: An Ethernet Encapsulated TRILL Frame 665 In the case of media different from Ethernet, the header specific to 666 that media replaces the outer Ethernet header. For example, Figure 667 2.3 shows a TRILL encapsulation over PPP. 669 +--------------------------------+ 670 | PPP Header | 671 +--------------------------------+ 672 | TRILL Header | 673 +--------------------------------+ 674 | Inner Ethernet Header | 675 +--------------------------------+ 676 | Ethernet Payload | 677 +--------------------------------+ 678 | Ethernet FCS | 679 +--------------------------------+ 681 Figure 2.3: A PPP Encapsulated TRILL Frame 683 The outer header is link-specific and, although this document 684 specifies only [802.3] links, other links are allowed. 686 In both cases the Inner Ethernet Header and the Ethernet Payload come 687 from the original frame and are encapsulated with a TRILL Header as 688 they travel between RBridges. Use of a TRILL header offers the 689 following benefits: 691 1. loop mitigation through use of a hop count field; 693 2. elimination of the need for end station VLAN and MAC address 694 learning in transit RBridges; 696 3. direction of unicast frames towards the egress RBridge (this 697 enables unicast forwarding tables of transit RBridges to be sized 698 with the number of RBridges rather than the total number of end 699 nodes); and, 701 4. provision of a separate VLAN tag for forwarding traffic between 702 RBridges, independent of the VLAN of the native frame. 704 When forwarding unicast frames between RBridges, the outer header has 705 the MAC destination address of the next hop Rbridge, to avoid frame 706 duplication if the inter-RBridge link is multi-access. This also 707 enables multipathing of unicast, since the transmitting RBridge can 708 specify the next hop. Having the outer header specify the 709 transmitting RBridge as source address ensures that any bridges 710 inside the Ethernet cloud will not get confused, as they might be if 711 multipathing is in use and they were to see the original source or 712 ingress RBridge in the outer header. 714 2.4 Forwarding Overview 716 RBridges are true routers in the sense that, in the forwarding of a 717 frame by a transit RBridge, the outer layer 2 header is replaced at 718 each hop with an appropriate layer 2 header for the next hop, and a 719 hop count is decreased. Despite these modifications of the outer 720 layer 2 header and the hop count in the TRILL Header, the original 721 encapsulated frame is preserved, including the original frame's VLAN 722 tag. See Section 4.6 for more details. 724 From a forwarding standpoint, transit frames may be classified into 725 two categories: known-unicast and multi-destination. Layer 2 control 726 frames and TRILL control and TRILL other frames are not transit 727 frames, are not forwarded by RBridges, and are not included in these 728 categories. 730 2.4.1 Known-Unicast 732 These frames have a unicast inner MAC destination address 733 (Inner.MacDA) and are those for which the ingress RBridge knows the 734 egress RBridge for the destination MAC address in the frame's VLAN. 736 Such frames are forwarded Rbridge hop by Rbridge hop to their egress 737 Rbridge. 739 2.4.2 Multi-destination 741 These are frames that must be delivered to multiple destinations. 743 Multi-destination frames include the following: 745 1. unicast frames for which the location of the destination is 746 unknown: the Inner.MacDA is unicast, but the ingress RBridge does 747 not know its location in the frame's VLAN; 749 2. multicast frames for which the Layer 2 destination address is 750 derived from an IP multicast address: the Inner.MacDA is 751 multicast, from the set of Layer 2 multicast addresses derived 752 from IPv4 [RFC1112] or IPv6 [RFC2464] multicast addresses; these 753 frames are handled somewhat differently in different subcases: 755 2.1 IGMP [RFC3376] and MLD [RFC2710] multicast group membership 756 reports; 758 2.2 IGMP [RFC3376] and MLD [RFC2710] queries and MRD [RFC4286] 759 announcement messages; 761 2.3 other IP derived Layer 2 multicast frames; 763 3. multicast frames for which the Layer 2 destination address is not 764 derived from an IP multicast address: the Inner.MacDA is 765 multicast, and not from the set of Layer 2 multicast addresses 766 derived from IPv4 or IPv6 multicast addresses; 768 4. broadcast frames: the Inner.MacDA is broadcast (FF-FF-FF-FF-FF- 769 FF). 771 RBridges build distribution trees (see Section 4.5) and use these 772 trees for forwarding multi-destination frames. Each distribution tree 773 reaches all RBridges in the campus, is shared across all VLANs, and 774 may be used for the distribution of a native frame that is in any 775 VLAN. However, the distribution of any particular frame on a 776 distribution tree is pruned in different ways for different cases to 777 avoid unnecessary propagation of the frame. 779 2.5 RBridges and VLANs 781 A VLAN is a way to partition end nodes in a campus into different 782 Layer 2 communities [802.1Q-2005]. Use of VLANs requires 783 configuration. By default, the port of receipt determines the VLAN 784 of a frame sent by an end station. End stations can also explicitly 785 insert this information in a frame. 787 IEEE [802.1Q-2005] bridges can be configured to support multiple 788 customer VLANs over a single simple link by inserting / removing a 789 VLAN tag in the frame. VLAN tags used by TRILL have the same format 790 as VLAN tags defined in IEEE [802.1Q-2005]. As shown in Figure 2.2 791 there are two places where such tags may be present in a TRILL- 792 encapsulated frame sent over an IEEE [802.3] link: one in the outer 793 header (Outer.VLAN) and one in the inner header (Inner.VLAN). Inner 794 and outer VLANs are further discussed in Section 4.1. 796 RBridges enforce delivery of a native frame originating in a 797 particular VLAN only to other links in the same VLAN; however, there 798 are a few differences in the handling of VLANs between an RBridge 799 campus and an 802.1 bridged LAN as described below. 801 (See Section 4.2.4 for further discussion of TRILL IS-IS operation on 802 a link.) 804 2.5.1 Link VLAN Assumptions 806 Certain configurations of bridges may cause partitions of a VLAN on a 807 link. For such configurations, a frame sent by one RBridge to a 808 neighbor on that link, might not arrive, if tagged with a VLAN that 809 is partitioned due to bridge configuration. 811 TRILL requires at least one VLAN per link that gives full 812 connectivity to all the RBridges on that link. The default VLAN is 1, 813 though RBridges may be configured to use a different VLAN. The DRB 814 dictates to the other RBridges which VLAN to use. 816 Since there will be only one appointed forwarder for any VLAN, say 817 VLAN-x, on a link, if bridges are configured to cause VLAN-x to be 818 partitioned on a link, some VLAN-x end nodes on that link may be 819 orphaned (unable to communicate with the rest of the campus). 821 It is possible for bridge and port configuration to cause VLAN 822 mapping on a link (where a VLAN-x frame turns into a VLAN-y frame). 823 TRILL detects this by inserting a copy of the outer VLAN into TRILL- 824 Hello messages and checking it on receipt. If detected, it takes 825 steps to ensure that there is at most a single appointed forwarder on 826 the link, to avoid possible frame duplication or loops (see Section 827 4.4.5). 829 TRILL behaves as conservatively as possible, avoiding loops rather 830 than avoiding partial connectivity. As a result, lack of connectivity 831 may result from bridge or port misconfiguration. 833 2.6 RBridges and IEEE 802.1 Bridges 835 RBridge ports are, except as described below, layered on top of IEEE 836 [802.1Q-2005] port facilities. 838 2.6.1 RBridge Ports and 802.1 Layering 840 RBridge ports make use of [802.1Q-2005] port VLAN and priority 841 processing. In addition, they MAY implement other lower level 802.1 842 protocols as well as protocols for the link in use, such as PAUSE 843 (Annex 31B of [802.3]), port based access control [802.1X], MAC 844 security [802.1AE], or link aggregation [802.1AX]. 846 However, RBridges do not use spanning tree and do not block ports as 847 spanning tree does. Figure 2.4 shows a high-level diagram of an 848 RBridge with one port connected to an IEEE 802.3 link. Single lines 849 represent the flow of control information, double lines the flow of 850 both frames and control information. 852 +----------------------------------------- 853 | RBridge 854 | 855 | Forwarding Engine, IS-IS, Etc. 856 | Processing of native and TRILL frames 857 | 858 +----+---+--------++---------------------- 859 | | || other ports... 860 +-------------+ | || 861 | | || 862 +------------+-------------+ | || 863 | RBridge | | +----++-------+ <- EISS 864 | | | | | 865 | High-level Control Frame | | | 802.1Q-2005 | 866 | Processing (BPDU, VRP) | | | Port VLAN | 867 | | | | & Priority | 868 +-----------++-------------+ | | Processing | 869 || | | | 870 +---------++-----------------+---+-------------+ <-- ISS 871 | | 872 | 802.1/802.3 Low Level Control Frame | 873 | Processing, Port/Link Control Logic | 874 | | 875 +-----------++---------------------------------+ 876 || 877 || +------------+ 878 || | 802.3 PHY | 879 |+--------+ (Physical +--------- 802.3 880 +---------+ Interface) +--------- Link 881 | | 882 +------------+ 884 Figure 2.4: RBridge Port Model 886 The upper interface to the low-level port / link control logic 887 corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005]. 888 In RBridges, high-level control frames are processed above the ISS 889 interface. 891 The upper interface to the port VLAN and priority processing 892 corresponds to the Extended Internal Sublayer Service (EISS) in 893 [802.1Q-2005]. In RBridges, native and TRILL frames are processed 894 above the EISS interface and are subject to port VLAN and priority 895 processing. 897 2.6.2 Incremental Deployment 899 Because RBridges are compatible with IEEE [802.1Q-2005] customer 900 bridges, except as discussed in this document, a bridged LAN can be 901 upgraded by incrementally replacing such bridges with RBridges. 902 Bridges that have not yet been replaced are transparent to RBridge 903 traffic. The physical links directly interconnected by such bridges, 904 together with the bridges themselves, constitute bridged LANs. These 905 bridged LANs appear to RBridges to be multi-access links. 907 If the bridges replaced by RBridges were default configuration 908 bridges, then their RBridge replacements will not require 909 configuration. 911 Because RBridges, as described in this document, only provide 912 customer services, they cannot replace provider bridges or provider 913 backbone bridges, just as a customer bridge can't replace a provider 914 bridge. However, such provider devices can be part of the bridged LAN 915 between RBridges. Extension of TRILL to support provider services is 916 left for future work and will be separately documented. 918 Of course, if the bridges replaced had any port level protocols 919 enabled, such as port based access control [802.1X] or MAC security 920 [802.1AE], replacement RBridges would need the same port level 921 protocols enabled and similarly configured. In addition, the 922 replacement RBridges would have to support the same link type and 923 link level protocols as the replaced bridges. 925 An RBridge campus will work best if all IEEE [802.1D] and 926 [802.1Q-2005] bridges are replaced with RBridges, assuming the 927 RBridges have the same speed and capacity as the bridges. However, 928 there may be intermediate states, where only some bridges have been 929 replaced by RBridges, with inferior performance. 931 See Appendix A for further discussion of incremental deployment. 933 3. Details of the TRILL Header 935 This section specifies the TRILL header. Section 4 below provides 936 other RBridge design details. 938 3.1 TRILL Header Format 940 The TRILL header is shown in Figure 3.1 and is independent of the 941 data link layer used. When that layer is IEEE [802.3], it is prefixed 942 with the 16-bit TRILL Ethertype [RFC5342], making it 64 bit aligned. 943 If Op-Length is a multiple of 64 bits, then 64-bit alignment is 944 normally maintained for the content of an encapsulated frame. 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | V | R |M|Op-Length| Hop Count | 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | Egress RBridge Nickname | Ingress RBridge Nickname | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | Options... 952 +-+-+-+-+-+-+-+-+-+-+-+- 953 Figure 3.1: TRILL Header 955 The header contains the following fields that are described in the 956 sections referenced: 958 o V (Version): 2-bit unsigned integer. See Section 3.2. 960 o R (Reserved): 2 bits. See Section 3.3. 962 o M (Multi-destination): 1 bit. See Section 3.4. 964 o Op-Length (Options Length): 5-bit unsigned integer. See Section 965 3.5. 967 o Hop Count: 6-bit unsigned integer. See Section 3.6. 969 o Egress RBridge Nickname: 16-bit identifier. See Section 3.7.1. 971 o Ingress RBridge Nickname: 16-bit identifier. See Section 3.7.2. 973 o Options: present if Op-Length is non-zero. See Section 3.8. 975 3.2 Version (V) 977 Version (V) is a two-bit field. Version zero of TRILL is specified in 978 this document. An RBridge RB1 MUST check the V field in a received 979 TRILL-encapsulated frame. If the V field has a value not recognized 980 by RB1, then RB1 MUST silently discard the frame. The allocation of 981 new TRILL Version numbers requires an IETF Standards Action. 983 3.3 Reserved (R) 985 The two R bits are reserved for future use in extensions to this 986 version zero of the TRILL protocol. They MUST be set to zero when the 987 TRILL header is added by an ingress RBridge, transparently copied but 988 otherwise ignored by transit RBridges, and ignored by egress 989 RBridges. The allocation of reserved TRILL Header bits requires an 990 IETF Standards Action. 992 3.4 Multi-destination (M) 994 The Multi-destination bit (see Section 2.4.2) indicates that the 995 frame is to be delivered to a class of destination end stations via a 996 distribution tree and that the egress RBridge nickname field 997 specifies this tree. In particular: 999 o M = 0 (FALSE) - The egress RBridge nickname contains a nickname of 1000 the egress Rbridge for a known unicast MAC address; 1002 o M = 1 (TRUE) - The egress RBridge nickname field contains a 1003 nickname that specifies a distribution tree. This nickname is 1004 selected by the ingress RBridge for a TRILL data frame or by the 1005 source RBridge for a TRILL ESADI frame. 1007 3.5 Op-Length 1009 There are provisions to express in the TRILL Header that a frame is 1010 using an optional capability and to encode information into the 1011 header in connection with that capability. 1013 The Op-Length header field gives the length of the TRILL Header 1014 options in units of 4 octets, which allows up to 124 octets of 1015 options area. If Op-Length is zero there are no options present. If 1016 options are present, they follow immediately after the Ingress 1017 Rbridge Nickname field. 1019 See Section 3.8 for more information on TRILL Header options. 1021 3.6 Hop Count 1023 The Hop Count field is a 6-bit unsigned integer. An Rbridge drops 1024 frames received with a hop count of zero, otherwise it decrements the 1025 hop count. (This behavior is different from IPv4 and IPv6 in order 1026 to support the later addition of a traceroute-like facility that 1027 would be able to get a hop count exceeded from an egress RBridge.) 1029 For known unicast frames, the ingress RBridge SHOULD set the Hop 1030 Count in excess of the number of RBridge hops it expects to the 1031 egress RBridge to allow for alternate routing later in the path. 1033 For multi-destination frames, the Hop Count SHOULD be set by the 1034 ingress RBridge (or source RBridge for a TRILL ESADI frame) to at 1035 least the expected number of hops to the most distant RBridge. To 1036 accomplish this, RBridge RBn calculates, for each branch from RBn of 1037 the specified distribution tree rooted at RBi, the maximum number of 1038 hops in that branch. 1040 Multi-destination frames are of particular danger because a loop 1041 involving one or more distribution tree forks could result in the 1042 rapid generation of multiple copies of the frame, even with the 1043 normal TTL mechanism. It is for this reason that multi-destination 1044 frames are subject to a stringent Reverse Path Forwarding Check and 1045 other checks as described in Section 4.5.2. As an optional additional 1046 traffic control measure, when forwarding a multi-destination frame 1047 onto a distribution tree branch, transit RBridge RBm MAY decrease the 1048 hop count by more than 1, unless decreasing the hop count by more 1049 than 1 would result in a Hop Count insufficient to reach all 1050 destinations in that branch of the tree rooted at RBi. Using a Hop 1051 Count close or equal to the minimum needed on multi-destination 1052 frames provides additional protection against problems with temporary 1053 loops when forwarding. 1055 Although the RBridge MAY decrease the hop count of multi-destination 1056 frames by more than 1, under the circumstances described above, the 1057 RBridge forwarding a frame MUST decrease the hop count by at least 1, 1058 and discards the frame if it cannot do so because the hop count is 0. 1059 The option to decrease the hop count by more than 1 under the 1060 circumstances described above applies only to multi-destination 1061 frames, not to known unicast frames. 1063 3.7 RBridge Nicknames 1065 Nicknames are 16-bit dynamically assigned quantities that act as 1066 abbreviations for RBridges' IS-IS IDs to achieve a more compact 1067 encoding and can be used to specify potentially different trees with 1068 the same root. This assignment allows specifying up to 2**16 1069 RBridges; however, the value 0x0000 is reserved to indicate that a 1070 nickname is not specified, the values 0xFFC0 through 0xFFFE are 1071 reserved for future specification, and the value 0xFFFF is 1072 permanently reserved. RBridges piggyback a nickname acquisition 1073 protocol on the link state protocol (see Section 3.7.3) to acquire 1074 one or more nicknames unique within the campus. 1076 3.7.1 Egress RBridge Nickname 1078 There are two cases for the contents of the egress RBridge nickname 1079 field, depending on the M-bit (see Section 3.4). The nickname is 1080 filled in by the ingress RBridge for TRILL data frames and by the 1081 source RBridge for TRILL ESADI frames. 1083 o For known unicast TRILL data frames, M == 0 and the egress RBridge 1084 nickname field specifies the egress RBridge, that is, it specifies 1085 the RBridge that needs to remove the TRILL encapsulation and 1086 forward the native frame. Once the egress nickname field is set, 1087 it MUST NOT be changed by any subsequent transit RBridge. 1089 o For multi-destination TRILL data frames and for TRILL ESADI 1090 frames, M == 1. The egress RBridge nickname field contains a 1091 nickname specifying the distribution tree selected to be used to 1092 forward the frame. This root nickname MUST NOT be changed by 1093 transit RBridges. 1095 3.7.2 Ingress RBridge Nickname 1097 The ingress RBridge nickname is set to a nickname of the ingress 1098 RBridge for TRILL data frames and to a nickname of the source RBridge 1099 for TRILL ESADI frames. If the RBridge setting the ingress nickname 1100 has multiple nicknames, it SHOULD use the same nickname in the 1101 ingress field whenever it encapsulates a frame with any particular 1102 Inner.MacSA and Inner.VLAN value. This simplifies end node learning. 1104 Once the ingress nickname field is set, it MUST NOT be changed by any 1105 subsequent transit RBridge. 1107 3.7.3 RBridge Nickname Selection 1109 The nickname selection protocol is piggybacked on TRILL IS-IS as 1110 follows: 1112 o The nickname or nicknames being used by an RBridge are carried in 1113 an IS-IS TLV (type-length-value data element) along with a 1114 priority of use value [layer2]. Each RBridge chooses its own 1115 nickname or nicknames. 1117 o Nickname values MAY be configured. An RBridge that has been 1118 configured with one or more nickname values will have priority for 1119 those nickname values over all Rbridges with non-configured 1120 nicknames. 1122 o The nickname value 0x0000 and the values from 0xFFC0 through 1123 0xFFFF are reserved and MUST NOT be selected by or configured for 1124 an RBridge. The value 0x0000 is used to indicate that a nickname 1125 is not known. 1127 o The priority of use field reported with a nickname is an unsigned 1128 8-bit value, where the most significant bit (0x80) indicates that 1129 the nickname value was configured. The bottom 7 bits have the 1130 default value 0x40, but MAY be configured to be some other value. 1131 Additionally, an RBridge MAY increase its priority after holding a 1132 nickname for some amount of time. However, the most significant 1133 bit of the priority MUST NOT be set unless the nickname value was 1134 configured. 1136 o Once an RBridge has successfully acquired a nickname it SHOULD 1137 attempt to reuse it in the case of a reboot. 1139 o Each RBridge is responsible for ensuring that its nickname or each 1140 of its nicknames is unique. If RB1 chooses nickname x, and RB1 1141 discovers, through receipt of an LSP for RB2 at any later time, 1142 that RB2 has also chosen x, then the RBridge with the numerically 1143 higher priority keeps the nickname, or if there is a tie in 1144 priority, the RBridge with the numerically higher IS-IS System ID 1145 keeps the nickname, and the other RBridge MUST select a new 1146 nickname. This can require an RBridge with a configured nickname 1147 to select a replacement nickname. 1149 o To minimize the probability of nickname collisions, an RBridge 1150 selects a nickname randomly from the apparently available 1151 nicknames, based on its copy of the link state. This random 1152 selection can be by the RBridge hashing some of its parameters, 1153 e.g., SystemID, time and date, and other entropy sources, such as 1154 those given in [RFC4086], each time or by the RBridge using such 1155 hashing to create a seed and making any selections based on 1156 pseudo-random numbers generated from that seed [RFC4086]. The 1157 random numbers or seed and the algorithm used SHOULD make 1158 uniformly distributed selections over the available nicknames. 1159 Convergence to a nickname-collision free campus is accelerated by 1160 selecting new nicknames only from those that appear to be 1161 available and by having the highest priority nickname involved in 1162 a nickname conflict retain its value. There is no reason for all 1163 Rbridges to use the same algorithm for selecting nicknames. 1165 o If two RBridge campuses merge, then transient nickname collisions 1166 are possible. As soon as each RBridge receives the LSPs from the 1167 other RBridges, the RBridges that need to change nicknames select 1168 new nicknames that do not, to the best of their knowledge, collide 1169 with any existing nicknames. Some RBridges may need to change 1170 nicknames more than once before the situation is resolved. 1172 o To minimize the probability of a new RBridge usurping a nickname 1173 already in use, an RBridge SHOULD wait to acquire the link state 1174 database from a neighbor before it announces any nicknames that 1175 were not configured. 1177 o An RBridge by default has only a single nickname but MAY be 1178 configured to request multiple nicknames. Each such nickname would 1179 specify a shortest path tree with the RBridge as root but, since 1180 the tree number is used in tiebreaking when there are multiple 1181 equal cost paths (see Section 4.5.1), the trees for the different 1182 nicknames will likely utilize different links. Because of the 1183 potential tree computation load it imposes, this capability to 1184 request multiple nicknames for an RBridge should be used 1185 sparingly. For example, at a few RBridges that, because of campus 1186 topology, are particularly good places from which to calculate 1187 multiple different shortest path distribution trees. Such trees 1188 need separate nicknames so traffic can be multipathed across them. 1190 o If it is desired for a pseudonode to be a tree root, the DRB MAY 1191 request one or more nicknames in the pseudonode LSP. 1193 Every nickname in use in a campus identifies an RBridge (or 1194 pseudonode) and every nickname designates a distribution tree rooted 1195 at the RBridge (or pseudonode) it identifies. However, only a limited 1196 number of these potential distribution trees are actually computed by 1197 all the RBridges in a campus as discussed in Section 4.5. 1199 3.8 TRILL Header Options 1201 All Rbridges MUST be able to skip the number of 4-octet chunks 1202 indicated by the Op-Length field (see Section 3.5) in order to find 1203 the inner frame, since RBridges must be able to find the destination 1204 MAC address and VLAN tag in the inner frame. (Transit RBridges need 1205 such information to filter VLANs, IP multicast, and the like. Egress 1206 Rbridges need to find the inner header to correctly decapsulate and 1207 handle the inner frame.) 1209 To ensure backward compatible safe operation, when Op-Length is non- 1210 zero indicating that options are present, the top two bits of the 1211 first octet of the options area are specified as follows: 1213 +------+------+----+----+----+----+----+----+ 1214 | CHbH | CItE | Reserved | 1215 +------+------+----+----+----+----+----+----+ 1217 Figure 3.2: Options Area Initial Flags Octet 1219 If the CHbH (Critical Hop by Hop) bit is one, one or more critical 1220 hop-by-hop options are present. Transit RBridges that do not support 1221 all of the critical hop-by-hop options present, for example an 1222 RBridge that supported no options, MUST drop the frame. If the CHbH 1223 bit is zero, the frame is safe, from the point of view of options 1224 processing, for a transit RBridge to forward, regardless of what 1225 options that RBridge does or does not support. A transit RBridge that 1226 supports none of the options present MUST transparently forward the 1227 options area when it forwards a frame. 1229 If the CItE (Critical Ingress to Egress) bit is a one, one or more 1230 critical ingress-to-egress options are present. If it is zero, no 1231 such options are present. If either CHbH or CItE is non-zero, egress 1232 RBridges that don't support all critical option present, for example 1233 an RBridge that supports no options, MUST drop the frame. If both 1234 CHbH and CItE are zero, the frame is safe, from the point of view of 1235 options, for any egress RBridge to process, regardless of what 1236 options that RBridge does or does not support. 1238 Options, including the meaning of the bits labeled as Reserved in 1239 Figures 3.2, will be further specified in other documents and are 1240 expected to include provisions for hop-by-hop and ingress-to-egress 1241 options as well as critical and non-critical options. 1243 Note: Most RBridge implementations are expected to be optimized for 1244 the simplest and most common cases of frame forwarding and 1245 processing. The inclusion of options may and the inclusion of 1246 complex or lengthy options likely will cause frame processing 1247 using a "slow path" with inferior performance to "fast path" 1248 processing. Limited slow path throughput may cause such frames to 1249 be discarded. 1251 4. Other RBridge Design Details 1253 Section 3 above specifies the TRILL header, while this Section 1254 specifies other RBridge design details. 1256 4.1 Ethernet Data Encapsulation 1258 TRILL data and ESADI frames in transit on Ethernet links are 1259 encapsulated with an outer Ethernet header (see Figure 2.2). This 1260 outer header looks, to a bridge on the path between two RBridges, 1261 like the header of a regular Ethernet frame and therefore bridges 1262 forward the frame as they normally would. To enable RBridges to 1263 distinguish such TRILL data frames, a new TRILL Ethertype (see 1264 Section 7.2) is used in the outer header. 1266 Figure 4.1 details a TRILL data frame with an outer VLAN tag 1267 traveling on an Ethernet link as shown at the top of the Figure, that 1268 is, between transit RBridges RB3 and RB4. The native frame originated 1269 at end station ESa, was encapsulated by ingress RBridge RB1 and will 1270 ultimately be decapsulated by egress RBridge RB2 and delivered to 1271 destination end station ESb. The encapsulation shown has the 1272 advantage, if TRILL options are absent or the length of such options 1273 is a multiple of 64 bits, of aligning the original Ethernet frame at 1274 a 64-bit boundary. 1276 When a TRILL data frame is carried over an Ethernet cloud it has 1277 three pairs of addresses: 1279 o Outer Ethernet Header: Outer Destination MAC Address (Outer.MacDA) 1280 and Outer Source MAC Address (Outer.MacSA): These addresses are 1281 used to specify the next hop RBridge and the transmitting RBridge, 1282 respectively. 1284 o TRILL Header: Egress Nickname and Ingress Nickname. These specify 1285 nicknames of the egress and ingress RBridges, respectively, unless 1286 the frame is multi-destination, in which case the Egress Nickname 1287 specifies the distribution tree on which the frame is being sent. 1289 o Inner Ethernet Header: Inner Destination MAC Address (Inner.MacDA) 1290 and Inner Source MAC Address (Inner.MacSA): These addresses are as 1291 transmitted by the original end station, specifying, respectively, 1292 the destination and source of the inner frame. 1294 A TRILL data frame also potentially has two VLAN tags, as discussed 1295 in Sections 4.1.2 and 4.1.3 below, that can carry two different VLAN 1296 Identifiers and specify priority. 1298 Flow: 1299 +-----+ +-------+ +-------+ +-------+ +-------+ +----+ 1300 | ESa +--+ RB1 +---+ RB3 +-------+ RB4 +---+ RB2 +--+ESb | 1301 +-----+ |ingress| |transit| ^ |transit| |egress | +----+ 1302 +-------+ +-------+ | +-------+ +-------+ 1303 | 1304 Outer Ethernet Header: | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Outer Destination MAC Address (RB4) | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Outer Destination MAC Address | Outer Source MAC Address | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | Outer Source MAC Address (RB3) | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Ethertype = C-Tag [802.1Q] | Outer.VLAN Tag Information | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 TRILL Header: 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Ethertype = TRILL | V | R |M|Op-Length| Hop Count | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | Egress (RB2) Nickname | Ingress (RB1) Nickname | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 Inner Ethernet Header: 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Inner Destination MAC Address (ESb) | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Inner Destination MAC Address | Inner Source MAC Address | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Inner Source MAC Address (ESa) | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 Payload: 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Ethertype of Original Payload | | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1334 | Original Ethernet Payload | 1335 | | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 Frame Check Sequence: 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | New FCS (Frame Check Sequence) | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Figure 4.1: TRILL Data Encapsulation over Ethernet 1344 4.1.1 VLAN Tag Information 1346 A "VLAN Tag" (formerly known as a Q-tag), also known as a "C-tag" for 1347 customer tag, includes a VLAN ID and a priority field as shown in 1348 Figure 4.2. The "VLAN ID" may be zero, indicating the no VLAN is 1349 specified, just a priority, although such frames are called "priority 1350 tagged" rather than "VLAN tagged" [802.1Q-2005]. 1352 [802.1Qad] S-tags, also known as service tags, are beyond the scope 1353 of this document. 1355 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1356 | Priority | C | VLAN ID | 1357 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1359 Figure 4.2: VLAN Tag Information 1361 As recommended in [802.1Q-2005], Rbridges SHOULD be implemented so as 1362 to allow use of the full range of VLAN IDs from 0x001 through 0xFFE. 1363 Rbridges MAY support a smaller number of simultaneously active VLAN 1364 IDs. VLAN ID zero is the null VLAN identifier and indicates that no 1365 VLAN is specified while VLAN ID 0xFFF is reserved. 1367 The VLAN ID 0xFFF MUST NOT be used. Rbridges MUST discard any frame 1368 they receive with an Outer.VLAN ID of 0xFFF. Rbridges MUST discard 1369 any frame for which they examine the Inner.VLAN ID and find it to be 1370 0xFFF; such examination is required at all egress Rbridges which 1371 decapsulate a frame. 1373 The "C" bit shown in Figure 4.2 is not used in TRILL. It MUST be set 1374 to zero and is ignored by receivers. 1376 As specified in [802.1Q-2005], the priority field contains an 1377 unsigned value from 0 through 7 where 1 indicates the lowest 1378 priority, 7 the highest priority, and the default priority zero is 1379 considered to be higher than priority 1 but lower than priority 2. 1380 The [802.1ad] amendment to [802.1Q-2005] permits mapping some 1381 adjacent pairs of priority levels into a single priority level with 1382 and without drop eligibility. Ongoing work in IEEE 802.1 (802.1az, 1383 Appendix E) suggests the ability to configure "priority groups" that 1384 have a certain guaranteed bandwidth. RBridges ports MAY also 1385 implement such options. RBridges are not required to implement any 1386 particular number of distinct priority levels but may treat one or 1387 more adjacent priority levels in the same fashion. 1389 Frames with the same source address, destination address, VLAN, and 1390 priority that are received on the same port as each other and are 1391 transmitted on the same port MUST be transmitted in the order 1392 received unless the RBridge classifies the frames into more fine 1393 grained flows, in which case this ordering requirement applies to 1394 each such flow. (Such frames might not be sent out the same port if 1395 multipath is implemented. See Appendix C.) 1397 The C-Tag Ethertype [RFC5342] is 0x8100. 1399 4.1.2 Inner VLAN Tag 1401 The "Inner VLAN Tag Information" (Inner.VLAN) field contains the VLAN 1402 tag information associated with the native frame when it was 1403 ingressed or the VLAN tag information associated with a TRILL ESADI 1404 frame when that frame was created. When a TRILL frame passes through 1405 a transit RBridge, the Inner.VLAN MUST NOT be changed except when 1406 VLAN mapping is being intentionally performed within that RBridge. 1408 When a native frame arrives at an RBridge, the associated VLAN ID and 1409 priority are determined as specified in [802.1Q-2005] (see Appendix D 1410 and [802.1Q-2005] Section 6.7). If the RBridge is an appointed 1411 forwarder for that VLAN and the delivery of the frame requires 1412 transmission to one or more other links, this ingress RBridge forms a 1413 TRILL data frame with the associated VLAN ID and priority placed in 1414 the Inner.VLAN information. 1416 The VLAN ID is required at the ingress Rbridge as one element in 1417 determining the appropriate egress Rbridge for a known unicast frame 1418 and is needed at the ingress and every transit Rbridge for multi- 1419 destination frames to correctly prune the distribution tree. 1421 4.1.3 Outer VLAN Tag 1423 TRILL frames sent by an RBridge, except for some TRILL-Hello frames, 1424 use an Outer.VLAN ID specified by the Designated RBridge (DRB) for 1425 the link onto which they are being sent, referred to as the 1426 Designated VLAN. For TRILL data and ESADI frames, the priority in the 1427 Outer.VLAN tag SHOULD be set to the priority in the Inner.VLAN tag. 1429 TRILL frames forwarded by a transit RBridge use the priority present 1430 in the Inner.VLAN of the frame as received. TRILL data frames are 1431 sent with the priority associated with the corresponding native frame 1432 when received (see Appendix D). TRILL IS-IS frames SHOULD be sent 1433 with priority 7. 1435 Whether an Outer.VLAN tag actually appears on the wire when a TRILL 1436 frame is sent depends on the configuration of the RBridge port 1437 through which it is sent in the same way as the appearance of a VLAN 1438 tag on a frame sent by an [802.1Q-2005] bridge depends on the 1439 configuration of the bridge port (see Section 4.9.2). 1441 4.1.4 Frame Check Sequence (FCS) 1443 Each Ethernet frame has a single Frame Check Sequence (FCS) that is 1444 computed to cover the entire frame, for detecting frame corruption 1445 due to bit errors on a link. Thus, when a frame is encapsulated, the 1446 original FCS is not included but is discarded. Any received frame for 1447 which the FCS check fails SHOULD be discarded (this may not be 1448 possible in the case of cut through forwarding). The FCS normally 1449 changes on encapsulation, decapsulation, and every TRILL hop due to 1450 changes in the outer destination and source addresses, the 1451 decrementing of the hop count, etc. 1453 Although the FCS is normally calculated just before transmission, it 1454 is desirable, when practical, for an FCS to accompany a frame within 1455 an RBridge after receipt. That FCS could then be dynamically updated 1456 to account for changes to the frame during Rbridge processing and 1457 used for transmission or checked against the FCS calculated for frame 1458 transmission. This optional, more continuous use of an FCS would be 1459 helpful in detecting some internal RBridge failures such as memory 1460 errors. 1462 4.2 Link State Protocol (IS-IS) 1464 TRILL uses an extension of IS-IS [ISO10589] [RFC1195] as its routing 1465 protocol. IS-IS has the following advantages: 1467 o it runs directly over Layer 2, so therefore it may be run without 1468 configuration (no IP addresses need to be assigned); 1470 o it is easy to extend by defining new TLV (type-length-value) data 1471 elements and sub-elements for carrying TRILL information; 1473 This section describes TRILL use of IS-IS, except for the TRILL-Hello 1474 protocol, which is described in Section 4.4, and the MTU-probe and 1475 MTU-ack messages that are described in Section 4.3. 1477 4.2.1 IS-IS RBridge Identity 1479 Each RBridge has a unique 48-bit (6-octet) IS-IS System ID. This ID 1480 may be derived from any of the RBridge's unique MAC addresses. 1482 A pseudonode is assigned a 7-octet ID by the DRB that created it, by 1483 taking a 6-octet ID owned by the DRB, and appending another octet. 1484 The 6-octet ID used to form a pseudonode ID SHOULD be the DRB's ID 1485 unless the DRB has to create IDs for pseudonodes for more than 255 1486 links. The only constraint for correct operation is that the 7-octet 1487 ID be unique within the campus, and that the 7th octet be nonzero. An 1488 RBridge has a 7-octet ID consisting of its 6-octet system ID 1489 concatenated with a zero octet. 1491 In this document we use the term "IS-IS ID" to refer to the 7-octet 1492 quantity that can either be the ID of an RBridge or a pseudonode. 1494 4.2.2 IS-IS Instances 1496 TRILL implements a separate IS-IS instance from any used by Layer 3, 1497 that is, different from the one used by routers. Layer 3 IS-IS frames 1498 must be distinguished from TRILL IS-IS frames even when those Layer 3 1499 IS-IS frames are transiting an RBridge campus. 1501 Layer 3 IS-IS native frames have special multicast destination 1502 addresses specified for that purpose, such as AllL1ISs or AllL2ISs. 1503 When they are TRILL encapsulated, these multicast addresses appear as 1504 the Inner.MacDA and the Outer.MacDA will be the All-RBridges 1505 multicast address. 1507 Within TRILL, there is an IS-IS instance across all Rbridges in the 1508 campus as described in Section 4.2.3. This instance uses TRILL IS-IS 1509 frames that are distinguished by having a different Ethertype "L2-IS- 1510 IS". Additionally, for TRILL IS-IS frames that are multicast, there 1511 is a distinct multicast destination address of All-IS-IS-RBridges. 1512 TRILL IS-IS frames do not have a TRILL Header. 1514 ESADI is a separate protocol from the IS-IS instance implemented by 1515 all the RBridges. There is a separate ESADI instance for each VLAN, 1516 and ESADI frames are encapsulated just like TRILL data frames. After 1517 the TRILL header, the ESADI frame has an inner Ethernet header with 1518 the Inner.MacDA of "All-ESADI-RBridges" and the "L2-IS-IS" Ethertype 1519 followed by the ESADI frame. 1521 4.2.3 TRILL IS-IS Frames 1523 All Rbridges must participate in the TRILL IS-IS instance, which 1524 constitutes a single Level 1 IS-IS area using the fixed area-ID zero. 1525 TRILL IS-IS frames are never forwarded by an RBridge but are locally 1526 processed on receipt. (Such processing may cause the RBridge to send 1527 additional TRILL IS-IS frames.) 1529 A TRILL IS-IS frame on an 802.3 link is structured as shown below. 1530 All such frames are Ethertype encoded. The RBridge port out which 1531 such a frame is sent will strip the outer VLAN tag if configured to 1532 do so. 1534 Outer Ethernet Header: 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | All-IS-IS-RBridges Multicast Address | 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1538 | All-IS-IS-RBridges continued | Source RBridge MAC Address | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 | Source RBridge MAC Address continued | 1541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1542 | Ethertype = C-Tag [802.1Q] | Outer.VLAN Tag Information | 1543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1544 | L2-IS-IS Ethertype | 1545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1546 IS-IS Payload: 1547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1548 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 1550 Frame Check Sequence: 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | FCS (Frame Check Sequence) | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 Figure 4.3: TRILL IS-IS Frame Format 1557 The VLAN specified in the Outer.VLAN information will be the 1558 Designated VLAN for the link on which the frame is sent, except in 1559 the case of some TRILL-Hellos. 1561 4.2.4 TRILL Link Hellos, DRBs, and Appointed Forwarders 1563 RBridges default to using TRILL Hellos unless, on a per port basis, 1564 they are configured to use P2P Hellos. TRILL-Hello frames are 1565 specified in Section 4.4. 1567 RBridges are normally configured to use P2P Hellos only when there 1568 are exactly two of them on a link. However, it can occur that 1569 RBridges are misconfigured as to which type of hello to use. This is 1570 safe but may cause lack of RBridge to RBridge connectivity. An 1571 RBridge port configured to use P2P Hellos ignores TRILL Hellos and an 1572 RBridge port configured to use TRILL Hellos ignores P2P Hellos. 1574 If any of the RBridge ports on a link is configured to use TRILL 1575 Hellos, one of such RBridge ports using TRILL Hellos is elected DRB 1576 (Designated RBridge) for the link. This election is based on 1577 configured priority (most significant field), and source MAC address, 1578 as communicated by TRILL-Hello frames. The DRB, as described in 1579 Section 4.2.4.2, designates the VLAN to be used on the link for 1580 inter-RBridge communication by the non-P2P RBridge ports and appoints 1581 itself or other RBridges on the link as appointed forwarder (see 1582 Section 4.2.4.3) for VLANs on the link. 1584 4.2.4.1 P2P Hello Links 1586 RBridge ports can be configured to use IS-IS P2P Hellos. This implies 1587 that the port is a point-to-point link to another RBridge. An RBridge 1588 MUST NOT provide any end station (native frame) service on a port 1589 configured to use P2P Hellos. 1591 As with Layer 3 IS-IS, such P2P ports do not participate in a DRB 1592 election. They send all frames VLAN tagged as being in the Desired 1593 Designated VLAN configured for the port although this tag may be 1594 stripped if the port is so configured. Since all traffic through the 1595 port should be TRILL frames or layer 2 control frames, such a port 1596 cannot be an appointed forwarder. RBridge P2P ports MUST use the IS- 1597 IS three-way handshake [RFC5303] so that extended circuit IDs are 1598 associated with the link for tie breaking purposes (see Section 1599 4.5.2). 1601 Even if all simple links in a network are physically point-to-point, 1602 if some of the nodes are bridges, the bridged LANs that include those 1603 bridges appear to be multi-access link to attached RBridges. This 1604 would necessitate using TRILL-Hellos for proper operation in many 1605 cases. 1607 While it is safe to erroneously configure ports as P2P, this may 1608 result in lack of connectivity. 1610 4.2.4.2 Designated RBridge 1612 TRILL IS-IS elects one RBridge for each LAN link to be the Designated 1613 RBridge (DRB), that is, to have special duties. The Designated 1614 RBridge: 1616 o Chooses, for the link, and announces in its TRILL Hellos, the 1617 Designated VLAN ID to be used for inter-RBridge communication. 1618 This VLAN is used for all TRILL-encapsulated data and ESADI frames 1619 and TRILL IS-IS frames except some TRILL-Hello frames. 1621 o If the link is represented in the IS-IS topology as a pseudonode, 1622 chooses a pseudonode ID and announces that in its TRILL Hellos and 1623 issues an LSP on behalf of the pseudonode. 1625 o Issues CSNPs. 1627 o For each VLAN-x appearing on the link, chooses an RBridge on the 1628 link to be the appointed VLAN-x forwarder (the DRB MAY choose 1629 itself to be the appointed VLAN-x forwarder for all or some of the 1630 VLANs). 1632 o Before appointing a VLAN-x forwarder (including appointing 1633 itself), wait at least its Holding Time (to ensure it is DRB). 1635 o If configured to send TRILL-Hello frames, continues to send them 1636 on all its enabled VLANs that have been configured in the 1637 Announcing VLANs set of the DRB, which defaults to all enabled 1638 VLANs. 1640 4.2.4.3 Appointed VLAN-x Forwarder 1642 The appointed VLAN-x forwarder for a link is responsible for the 1643 following points. In connection with the loop avoidance points, when 1644 an appointed forwarder for a port is "inhibited", it drops any native 1645 frames it receives and does not transmit but instead drops any native 1646 frames it decapsulates, in the VLAN for which it is appointed. 1648 o Loop avoidance: 1650 - Inhibiting itself for a time, configurable per port from zero 1651 to 30 seconds, which defaults to 30 seconds, after it sees a 1652 root bridge change on the link (see Section 4.9.3.2). 1654 - Inhibiting itself for VLAN-x, if it has received a Hello in 1655 which the sender asserts that it is appointed forwarder and 1656 that is either 1657 + received on VLAN-x (has VLAN-x as its Outer.VLAN) or 1658 + was originally sent on VLAN-x as indicated inside the body 1659 of the Hello. 1661 - Optionally, not decapsulating a frame from ingress RBridge RBm 1662 unless it has RBm's LSP, and the root bridge on the link it is 1663 about to forward onto is not listed in RBm's list of root 1664 bridges for VLAN-x. This is known as the "decapsulation check" 1665 or "root bridge collision check". 1667 o Unless inhibited (see above), receiving VLAN-x native traffic from 1668 the link and, forwarding it as appropriate. 1670 o Receiving VLAN-x traffic for the link and, unless inhibited, 1671 transmitting it in native form after decapsulating it as 1672 appropriate. 1674 o Learning the MAC address of local VLAN-x nodes by looking at the 1675 source address of VLAN-x frames from the link. 1677 o Optionally learning the port of local VLAN-x nodes based on any 1678 sort of Layer 2 registration protocols, such as IEEE 802.11 1679 association and authentication. 1681 o Keeping track of the { egress RBridge, VLAN, MAC address } of 1682 distant VLAN-x end nodes, learned by looking at the fields { 1683 ingress RBridge, Inner.VLAN ID, Inner.MacSA } from VLAN-x frames 1684 being received for decapsulation onto the link. 1686 o Optionally observe native IGMP [RFC3376], MLD [RFC2710], and MRD 1687 [RFC4286] frames to learn the presence of local multicast 1688 listeners and multicast routers. 1690 o Optionally listening to TRILL ESADI messages for VLAN-x to learn { 1691 egress RBridge, VLAN-x, MAC address } triplets and the confidence 1692 level of such explicitly advertised end nodes. 1694 o Optionally advertising VLAN-x end nodes, on links for which it is 1695 appointed VLAN-x forwarder, in ESADI messages. 1697 o Sending TRILL-Hello frames on VLAN-x unless the Announcing VLANs 1698 set for the port has been configured to disable them. 1700 o Listening to BPDUs on the common spanning tree to learn the root 1701 bridge, if any, for that link and to report in its LSP the 1702 complete set of root bridges seen on any of its links for which it 1703 is appointed forwarder for VLAN-x. 1705 When an appointed forwarder observes that the DRB on a link has 1706 changed, it no longer considers itself appointed for that link until 1707 appointed by the new DRB. 1709 4.2.4.4 TRILL LSP Information 1711 The information items in the TRILL IS-IS LSP that are mentioned 1712 elsewhere in this document are listed below. Unless an item is stated 1713 in the list below to be optional, it MUST be included. Other items 1714 MAY be included unless their inclusion is prohibited elsewhere in 1715 this document. The actual encoding of this information and the IS-IS 1716 Type or sub-Type values for any new IS-IS TLV or sub-TLV data 1717 elements are specified in a separate document [layer2]. 1719 1. The IS-IS IDs of neighbors (pseudonodes as well as RBridges) of 1720 RBridge RBn, and the cost of the link to each of those neighbors. 1721 RBridges MUST use the Extended IS Reachability TLV (#22, also 1722 known as "wide metric" [RFC5305]) and MUST NOT use the IS 1723 Reachability TLV (#2, also known as "narrow metric"). To 1724 facilitate efficient operation without configuration and 1725 consistent with [802.1D], RBridges SHOULD, by default, set the 1726 cost of a link to the integer part of twenty trillion 1727 (20,000,000,000,000) divided by the RBridge port's bit rate but 1728 not more than 2**24-2 (16,777,214); for example, the cost for a 1729 link accessed by a 1Gbps port would default to 20,000. (Note that 1730 2**24-1 has a special meaning in IS-IS and would exclude the link 1731 from SPF routes.) However, the link cost MAY, by default, be 1732 decreased for aggregated links and/or increased to not more than 1733 2**24-2 if the link appears to be a bridged LAN. The tested MTU 1734 for the link (see Section 4.3) MAY be included via a sub-TLV. 1736 2. The following information in connection with the nickname or each 1737 of the nicknames of RBridge RBn: 1739 2.1 The nickname value (2 octets). 1741 2.2 The unsigned 8-bit priority for RBn to have that nickname (see 1742 Section 3.7.3). 1744 2.3 The 16-bit unsigned priority of that nickname to becoming a 1745 distribution tree root. 1747 3. The maximum TRILL Header Version supported by RBridge RBn. 1749 4. The following information, in addition to the per nickname tree 1750 root priority, in connection with distribution tree determination 1751 and announcement. (See Section 4.5 for further details on how this 1752 information is used.) 1754 4.1 An unsigned 16-bit number that is the number of trees all 1755 RBridges in the campus calculate if RBn has the highest 1756 priority tree root. 1758 4.2 A second unsigned 16-bit number that is the number of trees 1759 RBn would like to use. 1761 4.3 A third unsigned 16-bit number that is the maximum number of 1762 distribution trees that RBn is able to calculate. 1764 4.4 A first list of nicknames that are intended distribution trees 1765 for all RBridges in the campus to calculate. 1767 4.5 A second list of nicknames that are distribution trees RBn 1768 would like to use when ingressing multi-destination frames. 1770 5. The list of VLAN IDs of VLANs directly connected to RBn for links 1771 on which RBn is the appointed forwarder for that VLAN. (Note: an 1772 RBridge may advertise that it is connected to additional VLANs in 1773 order to receive additional frames to support certain VLAN based 1774 features beyond the scope of this specification as mentioned in 1775 Section 4.8.4 and in a separate document concerning VLAN mapping 1776 inside RBridges.) RBridges may associate advertised connectivity 1777 to different groups of VLANs with specific nicknames they hold. In 1778 addition, the LSP contains the following information on a per-VLAN 1779 basis: 1781 5.1 Per VLAN Multicast Router attached flags: This is two bits of 1782 information that indicate whether there is an IPv4 and/or IPv6 1783 multicast router attached to the Rbridge on that VLAN. An 1784 RBridge that does not do IP multicast control snooping MUST 1785 set both of these bits (see Section 4.5.4). This information 1786 is used because IGMP [RFC3376] and MLD [RFC2710] Membership 1787 Reports MUST be transmitted to all links with IP multicast 1788 routers, and SHOULD NOT be transmitted to links without such 1789 routers. Also, all frames for IP-derived multicast addresses 1790 MUST be transmitted to all links with IP multicast routers 1791 (within a VLAN), in addition to links from which an IP node 1792 has explicitly asked to join the group the frame is for, 1793 except for some IP multicast addresses that MUST be treated as 1794 broadcast. 1796 5.2 Per VLAN mandatory announcement of the set of IDs of Root 1797 bridges for any of RBn's links on which RBn is appointed 1798 forwarder for that VLAN. Where MSTP (Multiple Spanning Tree 1799 Protocol) is running on a link, this is the root bridge of the 1800 CIST (Common and Internal Spanning Tree). This is to quickly 1801 detect cases where two Layer 2 clouds accidentally get merged, 1802 and where there might otherwise temporarily be two DRBs for 1803 the same VLAN on the same link. (See Section 4.2.4.3.) 1805 5.3 Optionally, per VLAN Layer 2 multicast addresses derived from 1806 IPv4 IGMP and IPv6 MLD notification messages received from 1807 attached end nodes on that VLAN, indicating the location of 1808 listeners for these multicast addresses (see Section 4.5.5). 1810 5.4 Per VLAN ESADI protocol participation flag, priority, and 1811 holding time. If this flag is one, it indicates that the 1812 RBridge wishes to receive such TRILL ESADI frames (see Section 1813 4.2.5.1). 1815 5.5 Per VLAN appointed forwarder status lost counter (see Section 1816 4.8.3). 1818 6. Optionally, the largest TRILL IS-IS frame that the RBridge can 1819 handle using the originatingLSPBufferSize TLV #14 (see Section 1820 4.3). 1822 7. Optionally, a list of VLAN groups where address learning is shared 1823 across that VLAN group (see Section 4.8.4). Each VLAN group is a 1824 list of VLAN IDs, where the first VLAN ID listed in a group, if 1825 present, is the "primary" and the others are "secondary". This is 1826 to detect misconfiguration of features outside the scope of this 1827 document. RBridges that do not support features such as "shared 1828 VLAN learning" ignore this field. 1830 8. Optionally, the Authentication TLV #10 (see Section 6). 1832 4.2.5 The TRILL ESADI Protocol 1834 RBridges that are the appointed VLAN-x forwarder for a link MAY 1835 participate in the TRILL end station address distribution information 1836 (ESADI) protocol for that VLAN. But all transit RBridges MUST 1837 properly forward TRILL ESADI frames as if they were multicast TRILL 1838 data frames. TRILL ESADI frames are structured like IS-IS frames but 1839 are always TRILL encapsulated on the wire as if they were TRILL data 1840 frames. 1842 Because of this forwarding, it appears to the ESADI protocol at an 1843 RBridge that it is directly connected by a shared virtual link to all 1844 other RBridges in the campus running ESADI for that VLAN. RBridges 1845 that do not implement the ESADI protocol or are not appointed 1846 forwarder for that VLAN do not decapsulate or locally process any 1847 TRILL ESADI frames they receive for that VLAN. In other words, these 1848 frames are transparently tunneled through transit RBridges. Such 1849 transit RBridges treat them exactly as multicast TRILL data frames 1850 and no special processing is invoked due to such forwarding. 1852 TRILL ESADI frames sent on an IEEE 802.3 link are structured as shown 1853 below. The outer VLAN tag will not be present if it was stripped by 1854 the port out which the frame was sent. 1856 Outer Ethernet Header: 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Next Hop Destination Address | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Next Hop Destination Address | Sending RBridge MAC Address | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Sending RBridge Port MAC Address | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 | Ethertype = C-Tag [802.1Q] | Outer.VLAN Tag Information | 1865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 TRILL Header: 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 | Ethertype = TRILL | V | R |M|Op-Length| Hop Count | 1869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | Egress (Dist. Tree) Nickname | Ingress (Origin) Nickname | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 Inner Ethernet Header: 1873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1874 | All-ESADI-RBridges Multicast Address | 1875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1876 | All-ESADI-RBridges continued | Origin RBridge MAC Address | 1877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1878 | Origin RBridge MAC Address continued | 1879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1880 | Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 1881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 | Ethertype = L2-IS-IS | 1883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 ESADI Payload (formatted as IS-IS): 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 1888 Frame Check Sequence: 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | FCS (Frame Check Sequence) | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 Figure 4.4: TRILL ESADI Frame Format 1895 The Next Hop Destination Address or Outer.MacDA is the All-RBridges 1896 multicast address. The VLAN specified in the Outer.VLAN information 1897 will always be the Designated VLAN for the link on which the frame is 1898 sent. The V and R fields will be zero while the M field will be one. 1899 The VLAN specified in the Inner.VLAN information will be the VLAN to 1900 which the ESADI frame applies. The Origin RBridge MAC Address or 1901 Inner.MacSA MUST be a globally unique MAC address owned by the 1902 RBridge originating the ESADI frame, for example any of its port MAC 1903 addresses, and each RBridge MUST use the same Inner.MacSA for all of 1904 the ESADI frames that RBridge originates. 1906 4.2.5.1 TRILL ESADI Participation 1908 An RBridge does not send any Hellos because of participation in the 1909 ESADI protocol. The information available in the TRILL IS-IS link 1910 state database is sufficient to determine the ESADI DRB on the 1911 virtual link for the ESADI protocol for each VLAN. In particular, the 1912 link state database information for each RBridge includes the VLANs, 1913 if any, for which that RBridge is participating in the ESADI 1914 protocol, its priority for being selected as DRB for the ESADI 1915 protocol for each of those VLANs, its holding time, and its IS-IS 1916 system ID for breaking ties in priority. 1918 An RBridge need not perform any routing calculation because of 1919 participation in the ESADI protocol. Since all RBridges participating 1920 in ESADI for a particular VLAN appear to be connected to the same 1921 single virtual link, there are no routing decisions to be made. A 1922 participating RBridge merely transmits the ESADI frames it originates 1923 on this virtual link. 1925 The ESADI DRB sends TRILL-ESADI-CSNP frames on the ESADI virtual 1926 link. For robustness, a participating RBridge that determines that 1927 some other RBridge should be ESADI DRB on such a virtual link but has 1928 not received or sent a TRILL-ESADI-CSNP in at least the ESADI DRB 1929 holding time MAY also send a TRILL-ESADI-CSNP on the virtual link. A 1930 participating RBridge that determines that no other RBridges are 1931 participating in the ESADI protocol for a particular VLAN SHOULD NOT 1932 send ESADI information or TRILL-ESADI-CSNPs on the virtual link for 1933 that VLAN. 1935 4.2.5.2 TRILL ESADI Information 1937 The information distributed with the ESADI protocol is the list of 1938 local end station MAC addresses known to the originating RBridge and, 1939 for each such address, a one octet unsigned "confidence" rating in 1940 the range 0-254 (see Section 4.8). 1942 It is intended to optionally provide for VLAN ID translation within 1943 RBridges, as specified in a separate document. This includes 1944 translating TRILL ESADI frames. If TRILL ESADI frames could contain 1945 VLAN IDs in arbitrary internal locations, such translation would be 1946 impractical. Thus, TRILL ESADI frames MUST NOT contain the VLAN ID of 1947 the VLAN to which they apply in the body of the frame after the 1948 Inner.VLAN tag. 1950 4.2.6 SPF, Forwarding, and Ambiguous Destinations 1952 This section describes the logical result desired. Alternative 1953 implementation methods may be used as long as they produce the same 1954 forwarding behavior. 1956 When building a forwarding table, an RBridge RB1 calculates shortest 1957 paths from itself as described in [RFC1195] Appendix C.1. Nicknames 1958 are added into the shortest path calculation as a final step, just as 1959 with an end node. If multiple RBridges, say RBa and RBb, claim the 1960 same nickname, this is a transitory condition and one of RBa or RBb 1961 will defer and choose a new nickname. However, RB1 simply adds that 1962 nickname as if it were attached to both RBa and RBb, and uses its 1963 standard shortest path calculation to choose the next hop 1965 An ingress RBridge RB2 maps a native frame's known unicast 1966 destination MAC address and VLAN into an egress RBridge nickname. If 1967 RB2 learns addresses only from the observation of received and 1968 decapsulated frames, then such MAC addresses cannot be duplicated 1969 within a VLAN in RB2 tables because more recent learned information, 1970 if of a higher or equal confidence, overwrites previous information 1971 and, if of a lower confidence, is ignored. However, duplicates of the 1972 same MAC within a VLAN can appear in ESADI data and between ESADI 1973 data and addresses learned from the observation of received and 1974 decapsulated frames, entered by manual configuration, or learned 1975 through layer 2 registration protocols. If duplicate MAC addresses 1976 occur within a VLAN, RB2 sends frames to the MAC with the highest 1977 confidence. If confidences are also tied between the duplicates, for 1978 consistency it is suggested that RB2 direct all such frames (or all 1979 such frames in the same ECMP flow) toward the same egress RBridge; 1980 however, the use of other policies will not cause a network problem 1981 since transit RBridges do not examine the Inner.MacDA for known 1982 unicast frames. 1984 4.3 Inter-RBridge Link MTU Size 1986 There are two reasons why it is important to know what size of frame 1987 each inter-RBridge link in the campus can support: 1989 1. RBridge RB1 must know what size of link state information messages 1990 it can generate, that will be guaranteed to be forwardable across 1991 all inter-RBridge links in the campus. 1993 2. If traffic engineering tools know which links support larger than 1994 minimally acceptable data packet sizes, paths can be computed that 1995 can support large data packets. 1997 4.3.1 Determining Campus-Wide TRILL IS-IS MTU Size 1999 There must be an agreement among all RBridges on the value of "Sz", 2000 the minimum acceptable inter-RBridge link size for the campus for the 2001 proper operation of TRILL IS-IS. Once Sz is known, all RBridges MUST 2002 format their link state information messages to be in chunks of size 2003 at most Sz. Also, every RBridge RB1 SHOULD test each of its RBridge 2004 adjacencies, say to RB2, to ensure that the RB1-RB2 link can forward 2005 packets of at least size Sz. 2007 Sz has no direct effect on end-stations and is not directly related 2008 to any end-station to end-station "path MTU". Methods of using Sz or 2009 any link MTU information gathered by TRILL IS-IS in the traffic 2010 engineering of routes or the determination of any path MTU is beyond 2011 the scope of this document. Native frames that, after TRILL 2012 encapsulation, exceed the MTU of a link on which they are sent will 2013 generally be discarded. 2015 Sz is determined by having each RBridge (optionally) advertise, in 2016 its LSP, its assumption of the value of the campus-wide Sz. This LSP 2017 element is known in IS-IS as the originatingLSPBufferSize, TLV #14. 2018 The default and minimum value for Sz, and the implicitly advertised 2019 value of Sz if the TLV is absent, is 1470 octets. This length (which 2020 is also the maximum size of a TRILL-Hello) was chosen to make it 2021 extremely unlikely that a TRILL control frame, even with reasonable 2022 additional headers, tags, and/or encapsulation, would encounter MTU 2023 problems on an inter-RBridge link. 2025 The campus-wide value of Sz is the smallest value of Sz advertised by 2026 any RBridge. 2028 4.3.2 Testing Link MTU Size 2030 There are two new TRILL IS-IS message types for use between pairs of 2031 RBridge neighbors to test the bidirectional packet size capacity of 2032 their connection. These messages are: 2034 -- MTU-probe 2035 -- MTU-ack 2037 Both the MTU-probe and the MTU-ack are padded to the size being 2038 tested. 2040 Sending of MTU-probes is optional; however, an RBridge RB2 that 2041 receives an MTU-probe from RB1 MUST respond with an MTU-ack padded to 2042 the same size as the MTU-probe. The MTU-probe MAY be multicast to 2043 All-RBridges, or unicast to a specific RBridge. The MTU-ack is 2044 normally unicast to the source of the MTU-probe to which it responds 2045 but MAY be multicast to All-RBridges. 2047 If RB1 fails to receive an MTU-ack to a probe of size X from RB2 2048 after k tries (where k is a configurable parameter whose default is 2049 3), then RB1 assumes the RB1-RB2 link cannot support size X. If X is 2050 not greater than Sz, then RB1 sets the "failed minimum MTU test" flag 2051 for RB2 in RB1's Hello. If size X succeeds, and X > Sz, then RB1 2052 advertises the largest tested X for each adjacency in the TRILL 2053 Hellos RB1 sends on that link, and RB1 MAY advertise X as an 2054 attribute of the link to RB2 in RB1's LSP. 2056 4.4 TRILL-Hello Protocol 2058 The TRILL-Hello protocol is a little different from the layer 3 IS-IS 2059 LAN Hello protocol and uses a new type of IS-IS message known as a 2060 TRILL-Hello. 2062 4.4.1 TRILL-Hello Rationale 2064 The reason for defining this new type of link in TRILL is that in 2065 layer 3 IS-IS, the LAN Hello protocol may elect multiple Designated 2066 Routers (DRs) since, when choosing a DR, routers ignore other routers 2067 with whom they do not have 2-way connectivity. Also, layer 3 IS-IS 2068 LAN Hellos are padded, to avoid forming adjacencies between neighbors 2069 that can't speak the maximum sized packet to each other. This means, 2070 in layer 3 IS-IS, that neighbors that have connectivity to each 2071 other, but with an MTU on that connection less than what they 2072 perceive as maximum sized packets, will not see each other's Hellos. 2073 The result is that routers might form cliques, resulting in the link 2074 turning into multiple pseudonodes. 2076 This behavior is fine for layer 3, but not for layer 2, where loops 2077 may form if there are multiple DRBs. Therefore, the TRILL-Hello 2078 protocol is a little different from layer 3 IS-IS's LAN Hello 2079 protocol. 2081 One other issue with TRILL-Hellos is to ensure that subsets of the 2082 information can appear in any single message, and be processable, in 2083 the spirit of IS-IS LSPs and CSNPs. TRILL-Hello frames, even though 2084 they are not padded, can become very large. An example where this 2085 might be the case is when some sort of backbone technology 2086 interconnects hundreds of TRILL sites over what would appear to TRILL 2087 to be a giant Ethernet, where the RBridges connected to that cloud 2088 will perceive that backbone to be a single link with hundreds of 2089 neighbors. 2091 In TRILL (unlike in layer 3 IS-IS), the DRB is selected based solely 2092 on priority and MAC address. In other words, if RB2 receives a TRILL- 2093 Hello from RB1 with higher (priority, MAC), RB2 defers to RB1 as DRB, 2094 regardless of whether RB1 lists RB2 in RB1's TRILL-Hello. 2096 Although the neighbor list in a TRILL-Hello does not influence the 2097 DRB election, it does determine what is announced in LSPs. RB1 only 2098 reports links to RBridges that it has two-way connectivity with. If 2099 RB1 is DRB on a link, and for whatever reason (MTU mismatch, or one- 2100 way connectivity) RB1 and RB2 do not have two-way connectivity, then 2101 RB2 does not report a link to RB1 (or the pseudonode), and RB1 (or 2102 RB1 on behalf of the pseudonode) does not report a link to RB2. 2104 4.4.2 TRILL-Hello Contents and Timing 2106 The TRILL-Hello has a new IS-IS message type. It starts with the same 2107 fixed header as an IS-IS LAN Hello, which includes the 7-bit priority 2108 for the issuing RBridge to be DRB on that link. TRILL-Hellos are sent 2109 with the same timing as IS-IS LAN Hellos. 2111 TRILL-Hello messages, including their Outer.MacDA and Outer.MacSA, 2112 but excluding any Outer.VLAN or other tags, MUST NOT exceed 1470 2113 octets in length and SHOULD NOT be padded. The following information 2114 MUST appear in every TRILL-Hello. References to "TLV" may actually be 2115 a "sub-TLV" as specified in a separate document [layer2]. 2117 1. The VLAN ID of the Designated VLAN for the link. 2119 2. A copy of the Outer.VLAN ID with which the Hello was tagged on 2120 sending. 2122 3. A 16-bit port ID assigned by the sending RBridge to the port the 2123 TRILL-Hello is sent on such that no two ports of that RBridge have 2124 the same port ID. 2126 4. A nickname of the sending RBridge. 2128 5. Two flags as follows: 2130 5.a A flag which, if set, indicates that the sender has detected 2131 VLAN mapping on the link, within the past 2 of its Holding 2132 Times. 2134 5.b A flag which, if set, indicates that the sender believes it is 2135 appointed forwarder for the VLAN and port on which the TRILL- 2136 Hello was sent. 2138 The following information MAY appear 2139 1. The set of VLANs for which end station service is enabled on the 2140 port. 2142 2. Several flags as follows: 2144 2.a A flag which, if set, indicates that the sender's port was 2145 configured as an access port. 2147 2.b A flag which, if set, indicates that the sender's port was 2148 configured as a trunk port. 2150 2.c A bypass pseudonode flag, as described below in this section. 2152 3. If the sender is DRB, the Rbridges (excluding itself) that it 2153 appoints as forwarders for that link and the VLANs for which it 2154 appoints them. As described below, this TLV is designed so that 2155 not all the appointment information need be included in each 2156 Hello. Its absence means that appointed forwarders should continue 2157 as previously assigned. 2159 4. The TRILL neighbor list. This is a new TLV, not the same as the 2160 IS-IS Neighbor TLV, in order to accommodate fragmentation and 2161 reporting MTU on the link (see Section 4.4.2.1). 2163 The Appointed Forwarders TLV specifies a range of VLANs and, within 2164 that range, specifies which Rbridge, if any, other than the DRB, is 2165 appointed forwarder for the VLANs in that range [layer2]. Such TLVs 2166 sent by the DRB must eventually cover every possible VLAN. Appointing 2167 an RBridge as forwarder on a port for a VLAN that is not enabled on 2168 that port has no effect. 2170 It is anticipated that many links between RBridges will be point-to- 2171 point, in which case using a pseudonode merely adds to the 2172 complexity. If the DRB specifies the bypass pseudonode bit in its 2173 TRILL-Hellos, the RBridges on the link just report their adjacencies 2174 as point-to-point. This has no effect on how LSPs are flooded on a 2175 link. It only affects what LSPs are generated. 2177 For example, if RB1 and RB2 are the only RBridges on the link and RB1 2178 is DRB, then if RB1 creates a pseudonode that is used, there are 3 2179 LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, where RB1.25 2180 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say 2181 they are connected to RB1.25. Whereas if DRB RB1 sets the bypass 2182 pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and 2183 RB2 each reporting connectivity to each other. 2185 A DRB SHOULD set the bypass pseudonode bit for its links unless, for 2186 a particular link, it has seen at least two simultaneous adjacencies 2187 on the link at some point since it last re-booted. 2189 4.4.2.1 TRILL Neighbor List 2191 The new TRILL Neighbor TLV includes the following information for 2192 each neighbor it lists: 2194 1. The neighbor's MAC address. 2196 2. MTU size to this neighbor as a two-octet unsigned integer in units 2197 of 4-octet chunks. The value zero indicates that the MTU is 2198 untested. 2200 3. A flag for "failed minimum MTU test". 2202 To allow partial reporting of neighbors, the neighbor IDs MUST be 2203 sorted by ID. If a set of neighbors { X1, X2, X3, ... Xn } are 2204 reported in RB1's Hello, then X1 < X2 < X3, ... < Xn. If RBridge 2205 RB2's ID is between X1 and Xn, and does not appear in RB1's Hello, 2206 then RB2 knows that RB1 has not heard RB2's Hello. 2208 Additionally there are two overall TRILL Neighbor List TLV flags: 2209 "the smallest ID I reported in this Hello is the smallest ID of any 2210 neighbor", and "the largest ID I reported in this Hello is the 2211 largest ID of any neighbor". If all the neighbors fit in RB1's 2212 TRILL-Hello, both flags will be set. 2214 If RB1 reports { X1, ... Xn } in its Hello, with the "smallest" flag 2215 set, and RB2's ID is smaller than X1, then RB2 knows that RB1 has not 2216 heard RB2's Hello. Similarly, if RB2's ID is larger than Xn and the 2217 "largest" flag is set, then RB2 knows that RB1 has not heard RB2's 2218 Hello. 2220 To ensure that any RBridge RB2 can definitively determine whether RB1 2221 can hear RB2, RB1's neighbor list must eventually cover every 2222 possible range of IDs. In other words, if X1 is the smallest reported 2223 in one of RB1's neighbor lists, and the "smallest" flag is not set, 2224 then X1 must appear in a different TRILL-Hello fragment as well, as 2225 the largest ID reported in that fragment. Or, fragments may overlap, 2226 as long as there is no gap, such that some range, say between Xi and 2227 Xj, never appears in any fragment. 2229 4.4.3 TRILL MTU probe and TRILL Hello VLAN Tagging 2231 The MTU probe mechanism is designed to determine the MTU for 2232 transmissions between RBridges. MTU probes and probe acknowledgements 2233 are only sent on the Designated VLAN. 2235 An RBridge RBn maintains for each port the same VLAN information as a 2236 customer IEEE [802.1Q-2005] bridge, including the set of VLANs 2237 enabled for output through that port (see Section 4.9.2). In 2238 addition, RBn maintains the following TRILL specific VLAN parameters 2239 per port: 2241 a) Desired Designated VLAN: the VLAN that RBn, if it is DRB, will 2242 specify in its TRILL-Hellos as the VLAN to be used by all 2243 RBridges on the link to communicate all TRILL frames, except 2244 some TRILL-Hellos. This MUST be a VLAN enabled on RBn's port. 2245 It defaults to the numerically lowest enabled VLAN ID, which is 2246 VLAN 1 for a default configuration RBridge. 2248 b) Designated VLAN: the VLAN being used on the link for all TRILL 2249 frames except some TRILL Hellos. This is RBn's Desired 2250 Designated VLAN if RBn believes it is the DRB or the Designated 2251 VLAN in the DRB's Hellos if RBn is not the DRB. 2253 c) Announcing VLANs set. This defaults to the enabled VLANs set on 2254 the port but may be configured to be a subset of the enabled 2255 VLANs. 2257 d) Forwarding VLANs set: the set of VLANs for which an RBridge 2258 port is appointed VLAN forwarder on the port. This MUST contain 2259 only enabled VLANs for the port, possibly all enabled VLANs. 2261 On each of its ports that is not configured to use P2P Hellos, an 2262 RBridge sends TRILL-Hellos Outer.VLAN tagged with each VLAN in a set 2263 of VLANs. This set depends on the RBridge's DRB status and the above 2264 VLAN parameters. RBridges send TRILL Hellos Outer.VLAN tagged with 2265 the Designated VLAN, unless that VLAN is not enabled on the port. In 2266 addition, the DRB sends TRILL Hellos Outer.VLAN tagged with each 2267 enabled VLAN in its Announcing VLANs set. All non-DRB RBridges send 2268 TRILL-Hellos Outer.VLAN tagged with all enabled VLANs that are in the 2269 intersection of their Forwarding VLANs set and their Announcing VLANs 2270 set. More symbolically, TRILL-Hello frames, when sent, are sent as 2271 follows: 2273 If sender is DRB 2274 intersection ( Enabled VLANs, 2275 union ( Designated VLAN, Announcing VLANs ) ) 2277 If sender is not DRB 2278 intersection ( Enabled VLANs, 2279 union ( Designated VLAN, 2280 intersection ( Forwarding VLANs, Announcing VLANs ) ) ) 2282 Configuring the Announcing VLANs set to be null minimizes the number 2283 of TRILL-Hellos. In that case, TRILL-Hellos are only tagged with the 2284 Designated VLAN. Great care should be taken in configuring an RBridge 2285 to not send TRILL Hellos on any VLAN where that RBridge is appointed 2286 forwarder as, under some circumstances, this can lead to loops. 2288 The number of TRILL-Hellos is maximized, within this specification, 2289 by configuring the Announcing VLANs set to be the set of all enabled 2290 VLAN IDs, which is the default. In that case, the DRB will send 2291 TRILL-Hello frames tagged with all its Enabled VLAN tags; in 2292 addition, any non-DRB RBridge RBn will send TRILL-Hello frames tagged 2293 with the Designated VLAN, if enabled, and tagged with all VLANs for 2294 which RBn is an appointed forwarder. (It is possible to send even 2295 more TRILL-Hellos. In particular, non-DRB RBridges could send TRILL- 2296 Hellos on enabled VLANs for which they are not an appointed forwarder 2297 and which are not the Designated VLAN. This would cause no harm other 2298 than a further communications and processing burden.) 2300 When an RBridge port comes up, until it has heard a TRILL-Hello from 2301 a higher priority RBridge, it considers itself to be DRB on that port 2302 and sends TRILL-Hellos on that basis. Similarly, even if it has at 2303 some time recognized some other RBridge on the link as DRB, if it 2304 receives no TRILL-Hellos on that port from an RBridge with higher 2305 priority as DRB for a long enough time, as specified by IS-IS, it 2306 will revert to believing itself DRB. 2308 4.4.4 Multiple Ports on the Same Link 2310 It is possible for an RBridge RB1 to have multiple ports to the same 2311 link. It is important for RB1 to recognize which of its ports are on 2312 the same link, so, for instance, if RB1 is appointed forwarder for 2313 VLAN A, RB1 knows that only one of its ports acts as appointed 2314 forwarder for VLAN A on that link. 2316 RB1 detects this condition based on receiving TRILL-Hello messages 2317 with the same IS-IS pseudonode ID on multiple ports. RB1 might have 2318 one set of ports, say { p1, p2, p3 } on one link, and another set of 2319 ports { p4, p5 } on a second link, and yet other ports, say p6, p7, 2320 p8, that are each on distinct links. Let us call a set of ports on 2321 the same link as a "port group". 2323 If RB1 detects that a set of ports, say { p1, p2, p3 } are a port 2324 group on a link, then RB1 MUST ensure that it does not cause loops 2325 when it encapsulates and decapsulates traffic from/to that link. If 2326 RB1 is appointed forwarder for VLAN A on that Ethernet link, RB1 MUST 2327 encapsulate / decapsulate VLAN A on only one of the ports. However, 2328 if RB1 is appointed forwarder for more than one VLAN, RB1 MAY choose 2329 to load split among its ports, using one port for some set of VLANs, 2330 and another port for a disjoint set of VLANs. 2332 If RB1 detects VLAN mapping occurring, (see Section 4.4.5), then RB1 2333 MUST NOT load split as appointed forwarder, and instead MUST act as 2334 appointed VLAN forwarder on that link on only one of its ports in the 2335 port group. 2337 When forwarding TRILL-encapsulated multi-destination frames to/from a 2338 link on which RB1 has a port group, RB1 MAY choose to load-split 2339 among its ports, provided that it does not duplicate frames, and 2340 provided that it keeps frames for the same flow on the same port. If 2341 RB1's neighbor on that link, RB2, accepts multi-destination frames on 2342 that tree on that link from RB1, RB2 MUST accept the frame from any 2343 of RB2's adjacencies to RB1 on that link. 2345 If an RBridge has more than one port connected to a link and those 2346 ports have the same MAC address, they can be distinguished by the 2347 port ID contain in TRILL-Hellos. 2349 4.4.5 VLAN Mapping Within a Link 2351 IEEE [802.1Q-2005] does not provide for bridges changing the C-tag 2352 VLAN ID for a tagged frame they receive, that is, mapping VLANs. 2353 Nevertheless, some bridge products provide this capability and, in 2354 any case, bridged LANs can be configured to display this behavior. 2355 For example, a bridge port can be configured to strip VLAN tags on 2356 output and send the resulting untagged frames onto a link leading to 2357 another bridge's port configured to tag these frames with a different 2358 VLAN. Although each port's configuration is legal under 2359 [802.1Q-2005], in the aggregate they perform manipulations not 2360 permitted on a single customer [802.1Q-2005] bridge. Since RBridge 2361 ports have the same VLAN capabilities as customer [802.1Q-2005] 2362 bridges, this can occur even in the absence of bridges. (VLAN mapping 2363 is referred to in IEEE 802.1 as "VLAN ID translation".) 2365 RBridges include the Outer.VLAN ID inside every TRILL-Hello message. 2366 When a TRILL-Hello is received, RBridges compare this saved copy with 2367 the Outer.VLAN ID information associated with the received frame. If 2368 these differ and the VLAN ID inside the Hello is X and the Outer.VLAN 2369 is Y, it can be assumed that VLAN ID X is being mapped into VLAN ID 2370 Y. 2372 When non-DRB RB2 detects VLAN mapping, based on receiving a TRILL- 2373 Hello where the VLAN tag in the body of the Hello differs from the 2374 one in the outer header, it sets a flag in all of its TRILL-Hellos 2375 for a period of two of its Holding Times since the last time RB2 2376 detected VLAN mapping. When DRB RB1 is informed of VLAN mapping, 2377 either because of receiving a TRILL-Hello that has been VLAN-mapped, 2378 or because of seeing the "VLAN Mapping detected" flag in a neighbor's 2379 TRILL-Hello on the link, RB1 re-assigns VLAN forwarders to ensure 2380 there is only a single forwarder on the link for all VLANs. 2382 4.5 Distribution Trees 2384 RBridges use distribution trees to forward multi-destination frames 2385 (see Section 2.4.2). Distribution Trees are bidirectional. Although 2386 a single tree is logically sufficient for the entire campus, the 2387 computation of additional distribution trees is warranted for the 2388 following reasons: it enables multipathing of multi-destination 2389 frames and enables the choice of a tree root closer to or, in the 2390 limit, identical with the ingress RBridge. Such a closer tree root 2391 improves the efficiency of the delivery of multi-destination frames 2392 that are being delivered to a subset of the links in the campus and 2393 reduces out-of-order delivery when a unicast address transitions 2394 between unknown and known. If applications are in use where 2395 occasional out-of-order unicast frames due to such transitions are a 2396 problem, the RBridge campus should be engineered to make sure they 2397 are of extremely low probability, such as by using the ESADI 2398 protocol, configuring addresses to eliminate unknown destination 2399 unicast frames, or using keep alive frames. 2401 An additional level of flexibility is the ability of an RBridge to 2402 acquire multiple nicknames, and therefore have multiple trees rooted 2403 at the same RBridge. Since the tree number is used as a tiebreaker 2404 for equal cost paths, the different trees, even if rooted at the same 2405 RBridge, will likely utilize different equal cost paths. 2407 How an ingress RBridge chooses the distribution tree or trees that it 2408 uses for multi-destination frames is beyond the scope of this 2409 document. However, for the reasons stated above, in the absence of 2410 other factors, a good choice is the tree whose root is least cost 2411 from the ingress RBridge and that is the default for an ingress 2412 RBridge that uses a single tree to distribute multi-destination 2413 frames. 2415 RBridges will precompute all the trees that might be used, and keep 2416 state for Reverse Path Forwarding Check filters (see Section 4.5.2). 2417 Also, since the tree number is used as a tiebreaker, it is important 2418 for all RBridges to know: 2420 o how many trees to compute 2421 o which trees to compute 2422 o what the tree number for each tree is 2423 o which trees each ingress RBridge might choose (for building 2424 Reverse Path Forwarding Check filters). 2426 Each RBridge advertises in its LSP a "tree root" priority for its 2427 nickname or for each of its nicknames if it has been configured to 2428 have more than one. This is a 16-bit unsigned integer that defaults, 2429 for an unconfigured RBridge, to 0x8000. Tree roots are ordered with 2430 highest numerical priority being highest priority, then with system 2431 ID of the RBridge (numerically higher = higher priority) as 2432 tiebreaker, and if that is equal, by the numerically higher nickname 2433 value, as an unsigned integer, having priority. 2435 Each RBridge advertises in its LSP the maximum number of distribution 2436 trees that it can compute and the number of trees that it wants all 2437 RBridges in the campus to compute. The number of trees, k, that are 2438 computed for the campus is the number wanted by the RBridge RB1, 2439 which has the nickname with the highest "tree root" priority, but no 2440 more than the number of trees supported by the RBridge in the campus 2441 which supports the fewest trees. If RB1 does not specify the specific 2442 distribution tree roots as described below, then the k highest 2443 priority trees are the trees that will be computed by all RBridges. 2444 Note that some of these k highest priority trees might be rooted at 2445 the same RBridge, if that RBridge has multiple nicknames. 2447 If an RBridge specifies the number of trees it can compute, or the 2448 number of trees it wants computed for the campus, as 0, it is treated 2449 as specifying them as 1. Thus k defaults to 1. 2451 In addition, the RBridge RB1 having the highest root priority 2452 nickname might explicitly advertise a set of s trees by providing a 2453 list of s nicknames. In that case, the first k of those s trees will 2454 be computed. If s is less than k, or if any of the s nicknames 2455 associated with the trees RB1 is advertising does not exist within 2456 the LSP database, then the RBridges still compute k trees, but the 2457 remaining trees they select are the highest priority trees, such that 2458 k trees are computed. 2460 There are two exceptions to the above, which can cause fewer 2461 distribution trees to be computed, as follows: 2463 o A nickname whose tree root priority is zero is never used as a 2464 tree root except that if all nicknames have priority zero, the 2465 highest priority among them as determined by the tiebreakers is 2466 used as a tree root so that there is always guaranteed to be at 2467 least one distribution tree. 2469 o As a transient condition, two or more identical nicknames can 2470 appear in the list of roots for trees to be computed. In such a 2471 case, it is useless to compute a tree for the nickname(s) that are 2472 about to be lost by the RBridges holding them. So a distribution 2473 tree is only computed for the instance of the nickname where the 2474 priority to hold that nickname value is highest, reducing the 2475 total number of trees computed. (It would also be of little use to 2476 go further down the priority ordered list of possible tree root 2477 nicknames to maintain the number of tree as the additional tree 2478 roots found this way would only be valid for a very brief nickname 2479 transition period.) 2481 The k trees calculated for a campus are ordered and numbered from 1 2482 to k. In addition to advertising the number k, RB1 might explicitly 2483 advertise a set of s trees by providing a list of s nicknames as 2484 described above. 2486 - If s == k, then the trees are numbered in the order that RB1 2487 advertises them. 2489 - If s == 0, then the trees are numbered in order of decreasing 2490 priority. For example, if RB1 advertises only that k=2, then the 2491 highest priority tree is number 1 and the 2nd highest priority 2492 tree is number 2. 2494 - If s < k, then those advertised by RB1 are numbered from 1 in the 2495 order advertised. Then the remainder are chosen by priority order 2496 from among the remaining possible trees with the numbering 2497 continuing. For example, if RB1 advertises k=4, advertises { Tx, 2498 Ty } as the nicknames of the root of the trees, and the campus 2499 wide priority ordering of trees in decreasing order is Ty > Ta > 2500 Tc > Tb > Tx, the numbering will be as follows: Tx is 1 and Ty is 2501 2 since that is the order they are advertised in by RB1. Then Ta 2502 is 3 and Tc is 4 because they are the highest priority trees that 2503 have not already been numbered. 2505 4.5.1 Distribution Tree Calculation 2507 RBridges do not use spanning tree to calculate distribution trees. 2508 Instead, distribution trees are calculated based on the link state 2509 information, selecting a particular RBridge nickname as the root. 2510 Each RBridge RBn independently calculates a tree rooted at RBi by 2511 performing the SPF (Shortest Path First) calculation with RBi as the 2512 root without requiring any additional exchange of information. 2514 It is important, when building a distribution tree, that all RBridges 2515 choose the same links for that tree. Therefore, when there are equal 2516 cost paths for a particular tree, all RBridges need to use the same 2517 tiebreakers. It is also desirable to allow splitting of traffic on 2518 as many links as possible. For this reason, a simple tiebreaker such 2519 as "always choose the parent with lower ID" would not be desirable. 2520 Instead, TRILL uses the tree number as a parameter in the tiebreaking 2521 algorithm. 2523 When building the tree number j, remember all possible equal cost 2524 parents for node N. After calculating the entire "tree" (actually, 2525 directed graph), for each node N, if N has "p" parents, then order 2526 the parents according to 7-octet IS-IS ID. For tree j, choose N's 2527 parent as choice j mod p. 2529 Note that there might be multiple equal cost links between N and 2530 potential parent P that have no pseudonodes, either because they are 2531 point-to-point links, or pseudonode-suppressed links. Such links will 2532 be treated as a single link for the purpose of tree building, because 2533 they all have the same parent P, whose IS-IS ID is "P.0". 2535 In other words, the set of potential parents for N, for the tree 2536 rooted at R, are those that give equally minimal cost paths from N to 2537 R, and which have distinct IS-IS IDs, based on what is reported in 2538 LSPs. 2540 4.5.2 Multi-destination Frame Checks 2542 When a multi-destination TRILL encapsulated frame is received by an 2543 RBridge, there are four checks performed, each of which may cause the 2544 frame to be discarded: 2546 1. Tree Adjacency Check: Each RBridge RBn keeps a set of adjacencies 2547 ( { port, neighbor } pairs ) for each distribution tree it is 2548 calculating. One of these adjacencies is toward the tree root RBi 2549 and the others are toward the leaves. Once the adjacencies are 2550 chosen, it is irrelevant which ones are towards the root RBi, and 2551 which are away from RBi. RBridges MUST drop a multi-destination 2552 frame that arrives at a port from an RBridge that is not an 2553 adjacency for the tree on which the frame is being distributed. 2554 Let's suppose that RBn has calculated that adjacencies a, c, and f 2555 are in the RBi tree. A multi-destination frame for the 2556 distribution tree RBi is received only from one of the adjacencies 2557 a, c, or f (otherwise it is discarded) and forwarded to the other 2558 two adjacencies. Should RBn have multiple ports on a link, a 2559 multi-destination frame it sends on one of these ports will be 2560 received by the others but will be discarded as an RBridge is not 2561 adjacent to itself. 2563 2. RPF Check: Another technique used by RBridges for avoiding 2564 temporary multicast loops during topology changes is the Reverse 2565 Path Forwarding Check. It involves checking that a multi- 2566 destination frame, based on the tree and the ingress RBridge, 2567 arrives from the expected link. RBridges MUST drop multi- 2568 destination frames that fail the RPF check. 2570 To limit the amount of state necessary to perform the RPF check, 2571 each RBridge RB2 MUST announce which trees RB2 may choose when RB2 2572 ingresses a multi-destination packet. When any RBridge, say, RB3, 2573 is computing the tree from nickname X, RB3 computes, for each 2574 RBridge RB2 that might act as ingress for tree X, the link on 2575 which RB3 should receive a packet from ingress RB2 on tree X, and 2576 note for that link that RB2 is a legal ingress RBridge for tree X. 2578 The information to determine which trees RB2 might choose is 2579 included in RB2's LSP. Similarly to how the highest priority 2580 RBridge RB1 specifies the k trees that will be computed by all 2581 RBridges, RB2 specifies a number j, which is the total number of 2582 different trees RB2 might specify, and the specific trees RB2 2583 might specify are a combination of specified trees and trees 2584 selected from highest priority trees. If RB2 specifies any trees 2585 that are not in the k trees as specified by RB1, they are ignored. 2587 The j potential ingress trees for RB2 are the ones with nicknames 2588 that RB2 has explicitly specified in "specified ingress tree 2589 nicknames" (and that are included in the k campus-wide trees 2590 selected by highest priority RBridge RB1), with the remainder (up 2591 to the maximum of {j,k}) being the highest priority of the k 2592 campus-wide trees. 2594 The default value for j is 1. The value 0 for j is special and 2595 means that RB2 can pick any of the k trees being computed for the 2596 campus. 2598 3. Parallel Links Check: If the tree-building and tiebreaking for a 2599 particular multi-destination frame distribution tree selects a 2600 non-pseudonode link between RB1 and RB2, that "RB1-RB2 link" might 2601 actually consist of multiple links. These parallel links would be 2602 visible to RB1 and RB2, but not to the rest of the campus (because 2603 the links are not represented by pseudonodes). If this bundle of 2604 parallel links is included in a tree, it is important for RB1 and 2605 RB2 to decide which link to use, but is irrelevant to other 2606 RBridges, and therefore, the tiebreaking algorithm need not be 2607 visible to any RBridges other than RB1 and RB2. In this case, 2608 RB1-RB2 adjacencies are ordered as follows, with the one "most 2609 preferred" adjacency being the one on which RB1 and RB2 transmit 2610 to and receive multi-destination frames from each other. 2612 a) Most preferred are those established by P2P Hellos. 2613 Tiebreaking among those is based on preferring the one with the 2614 numerically highest Extended Circuit ID as associated with the 2615 adjacency by the RBridge with the highest System ID. 2617 b) Next considered are those established through TRILL-Hello 2618 frames, with suppressed pseudonodes. Note that the pseudonode 2619 is suppressed in LSPs, but still appears in the TRILL-Hello, 2620 and therefore is available for this tiebreaking. Among these 2621 links, the one with the numerically largest pseudonode ID is 2622 preferred. 2624 4. Port Group Check: If an RBridge has multiple ports attached to the 2625 same link, a multi-destination frame it is receiving will arrive 2626 on all of them. All but one received copy of such a frame MUST be 2627 discarded to avoid duplication. All such frames that are part of 2628 the same flow must be accepted on the same port to avoid re- 2629 ordering. 2631 When a topology change occurs (including apparent changes during 2632 start up), an RBridge MUST adjust its input distribution tree filters 2633 no later than it adjusts its output forwarding. 2635 4.5.3 Pruning the Distribution Tree 2637 Each distribution tree SHOULD be pruned per-VLAN, eliminating 2638 branches that have no potential receivers downstream. Multi- 2639 destination TRILL data frames SHOULD only be forwarded on branches 2640 that are not pruned. 2642 Further pruning SHOULD be done in two cases: (1) IGMP [RFC3376], MLD 2643 [RFC2710], and MRD [RFC4286] messages, where these are to be 2644 delivered only to links with IP Multicast routers; and (2) other 2645 multicast frames derived from an IP multicast address that should be 2646 delivered only to links that have registered listeners, plus links 2647 which have IP Multicast routers, except for IP multicast addresses 2648 which must be broadcast. Each of these cases are scoped per-VLAN. 2650 Let's assume that RBridge RBn knows that adjacencies (a, c, and f) 2651 are in the nickname1 distribution tree. RBn marks pruning 2652 information for each of the adjacencies in the nickname1-tree. For 2653 each adjacency and for each tree, RBn marks: 2655 o the set of VLANs reachable downstream, 2657 o for each one of those VLANs, flags indicating whether there are 2658 IPv4 or IPv6 multicast routers downstream, and 2660 o the set of Layer 2 multicast addresses derived from IP multicast 2661 groups for which there are receivers downstream. 2663 4.5.4 Tree Distribution Optimization 2665 RBridges MUST determine the VLAN associated with all native frames 2666 they ingress and properly enforce VLAN rules on the emission of 2667 native frames at egress RBridge ports according to how those ports 2668 are configured and designated as appointed forwarders. RBridges 2669 SHOULD also prune the distribution tree of multi-destination frames 2670 according to VLAN. But, since they are not required to do such 2671 pruning, they may receive TRILL data or ESADI frames that should have 2672 been VLAN pruned earlier in the tree distribution. They silently 2673 discard such frames. A campus may contain some Rbridges that prune 2674 distribution trees on VLAN and some that do not. 2676 The situation is more complex for multicast. RBridges SHOULD analyze 2677 IP derived native multicast frames, and learn and announce listeners 2678 and IP multicast routers for such frames as discussed in Section 4.7 2679 below. And they SHOULD prune the distribution of IP derived multicast 2680 frames based on such learning and announcements. But, they are not 2681 required to prune based on IP multicast listener and router 2682 attachment state. And, unlike VLANs, where VLAN attachment state of 2683 ports MUST be maintained and honored, RBridges are not required to 2684 maintain IP multicast listener and router attachment state. 2686 An RBridge that does not examine native IGMP [RFC3376], MLD 2687 [RFC2710], and MRD [RFC4286] frames that it ingresses MUST advertise 2688 that it has IPv4 and IPv6 IP multicast routers attached for all the 2689 VLANs for which it is an appointed forwarder. It need not advertise 2690 any IP derived multicast listeners. This will cause all IP derived 2691 multicast traffic to be sent to this RBridge for those VLANs. It then 2692 egresses that traffic onto the links for which it is appointed 2693 forwarder where the VLAN of the traffic matches the VLAN for which it 2694 is appointed forwarder on that link. (This may cause the suppression 2695 of certain IGMP membership report messages from end stations but that 2696 is not significant as any multicast traffic such reports would be 2697 requesting will be sent to such end stations under these 2698 circumstances.) 2700 A campus may contain a mixture of Rbridges with different levels of 2701 IP derived multicast optimization. An RBridge may receive IP derived 2702 multicast frames that should have been pruned earlier in the tree 2703 distribution. It silently discards such frames. 2705 See also "Considerations for Internet Group Management Protocol 2706 (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" 2707 [RFC4541]. 2709 4.5.5 Forwarding Using a Distribution Tree 2711 With full optimization, forwarding a multi-destination data frame is 2712 done as follows. References to adjacencies below do not include the 2713 adjacency on which a frame was received. 2715 o The RBridge RBn receives a multi-destination TRILL data frame with 2716 inner VLAN-x and a TRILL header indicating that the selected tree 2717 is the nickname1 tree; 2719 o if the source from which the frame was received is not one of the 2720 adjacencies in the nickname1 tree for the specified ingress 2721 RBridge, the frame is dropped (see Section 4.5.1); 2723 o else, if the frame is an IGMP or MLD announcement message or an 2724 MRD query message, then the encapsulated frame is forwarded onto 2725 adjacencies in the nickname1 tree that indicate there are 2726 downstream VLAN-x IPv4 or IPv6 multicast routers as appropriate; 2728 o else, if the frame is for a Layer 2 multicast address derived from 2729 an IP multicast group, but its IP address is not the range of IP 2730 multicast addresses that must be treated as broadcast, the frame 2731 is forwarded onto adjacencies in the nickname1 tree that indicate 2732 there are downstream VLAN-x IP multicast routers of the 2733 corresponding type (IPv4 or IPv6), as well as adjacencies that 2734 indicate there are downstream VLAN-x receivers for that group 2735 address; 2737 o else (the inner frame is for a Layer 2 multicast address not 2738 derived from an IP multicast group or an unknown destination or 2739 broadcast or an IP multicast address which is required to be 2740 treated as broadcast) the frame is forwarded onto an adjacency if 2741 and only if that adjacency is in the nickname1 tree, and marked as 2742 reaching VLAN-x links. 2744 For each link for which RBn is appointed forwarder, RBn additionally 2745 checks to see if it should decapsulate the frame and send it to the 2746 link in native form, or process the frame locally. 2748 TRILL ESADI frames will be delivered only to RBridges that are 2749 appointed forwarders for their VLAN. Such frames will be multicast 2750 throughout the campus, like other non-IP-derived multicast data 2751 frames, on the distribution tree chosen by the RBridge which created 2752 the TRILL ESADI frame, and pruned according to the Inner.VLAN ID. 2753 Thus all the RBridges that are appointed forwarders for a link in 2754 that VLAN receive them. 2756 4.6 Frame Processing Behavior 2758 This section describes RBridge behavior for all varieties of received 2759 frames, including how they are forwarded when appropriate. Section 2760 4.6.1 covers native frames, Section 4.6.2 covers TRILL frames, and 2761 Section 4.6.3 covers layer 2 control frames. Processing may be 2762 organized or sequenced in a different way than described here as long 2763 as the result is the same. See Section 1.4 for frame type 2764 definitions. 2766 Corrupt frames, for example frames that are not a multiple of 8 bits, 2767 are too short or long for the link protocol/hardware in use, or have 2768 a bad FCS are discarded on receipt by an RBridge port as they are 2769 discarded on receipt at an IEEE 802.1 bridge port. 2771 Source address information ( { VLAN, Outer.MacSA, port } ) is learned 2772 by default from any frame with a unicast source address (see Section 2773 4.8). 2775 4.6.1 Receipt of a Native Frame 2777 If the port is configured as disabled or if end station service is 2778 disabled on the port by configuring it as a trunk port or configuring 2779 it to use P2P Hellos, the frame is discarded. 2781 The ingress Rbridge RB1 determines the VLAN ID for a native frame 2782 according to the same rules as IEEE [802.1Q-2005] bridges do (see 2783 Appendix D and Section 4.9.2). Once the VLAN is determined, if RB1 is 2784 not the appointed forwarder for that VLAN on the port where the frame 2785 was received or is inhibited, the frame is discarded. If it is 2786 appointed forwarder for that VLAN and is not inhibited (see Section 2787 4.2.4.3), then the native frame is forwarded according to 4.6.1.1 if 2788 it is unicast and according to 4.6.1.2 if it is multicast or 2789 broadcast. 2791 4.6.1.1 Native Unicast Case 2793 If the destination MAC address of the native frame is a unicast 2794 address, the following steps are performed. 2796 The Layer 2 destination address and VLAN are looked up in the ingress 2797 RBridge's database of MAC addresses and VLANs to find the egress 2798 RBridge RBm or the local egress port or to discover that the 2799 destination is the receiving RBridge or is unknown. One of the 2800 following four cases will apply: 2802 1. If the destination is the receiving RBridge, the frame is locally 2803 processed. 2805 2. If the destination is known to be on the same link from which the 2806 native frame was received but is not the receiving RBridge, the 2807 RBridge silently discards the frame, since the destination should 2808 already have received it. 2810 3. If the destination is known to be on a different local link for 2811 which RBm is the appointed forwarder, then RB1 converts the native 2812 frame to a TRILL data frame with an Outer.MacDA of the next hop 2813 RBridge towards RBm, a TRILL header with M = 0, an ingress 2814 nickname for RB1, and the egress nickname for RBm. If ingress RB1 2815 has multiple nicknames, it SHOULD use the same nickname in the 2816 ingress nickname field whenever it encapsulates a native frame 2817 from any particular source MAC address and VLAN. This simplifies 2818 end node learning. If RBm is RB1, processing then proceeds as in 2819 4.6.2.4; otherwise, the Outer.MacSA is set to the MAC address of 2820 the RB1 port on the path to the next hop RBridge towards RBm and 2821 the frame is queued for transmission out that port. 2823 4. If a unicast destination MAC is unknown in the frame's VLAN, RB1 2824 handles the frame as described in Section 4.6.1.2 for a broadcast 2825 frame except that the Inner.MacDA is the original native frame's 2826 unicast destination address. 2828 4.6.1.2 Native Multicast and Broadcast Frames 2830 If the RBridge has multiple ports attached to the same link, all but 2831 one received copy of a native multicast or broadcast frame is 2832 discarded to avoid duplication. All such frames that are part of the 2833 same flow must be accepted on the same port to avoid re-ordering. 2835 If the frame is a native IGMP [RFC3376], MLD [RFC2710], or MRD 2836 [RFC4286] frame, then RB1 SHOULD analyze it, learn any group 2837 membership or IP multicast router presence indicated, and announce 2838 that information for the appropriate VLAN in its LSP (see Section 2839 4.7). 2841 For all multi-destination native frames, RB1 forwards the frame in 2842 native form to its links where it is appointed forwarder for the 2843 frame's VLAN, subject to further pruning and inhibition. In addition, 2844 it converts the native frame to a TRILL data frame with the All- 2845 RBridges multicast address as Outer.MacDA, a TRILL header with the 2846 multi-destination bit M = 1, the ingress nickname for RB1, and the 2847 egress nickname for the distribution tree it decides to use. It then 2848 forwards the frame on the pruned distribution tree (see Section 4.5) 2849 setting the Outer.MacSA of each copy sent to the MAC address of the 2850 RB1 port on which it is sent. 2852 The default is for RB1 to write into the egress nickname field the 2853 nickname for a distribution tree, from the set of distribution trees 2854 RB1 has announced it might use, whose root is least cost from RB1. 2855 RB1 MAY choose different distribution trees for different frames if 2856 RB1 has been configured to path-split multicast. In that case RB1 2857 MUST select a tree by specifying a nickname that is a distribution 2858 tree root (see Section 4.5). Also, RB1 MUST select a nickname that 2859 RB1 has announced (in RB1's own LSP) to be one of those that RB1 2860 might use. The strategy RB1 uses to select distribution trees in 2861 multipathing multi-destination frames is beyond the scope of this 2862 document. 2864 4.6.2 Receipt of a TRILL Frame 2866 A TRILL frame has either the TRILL or L2-IS-IS Ethertype or has a 2867 multicast Outer.MacDA allocated to TRILL (see Section 7.2). The 2868 following tests are performed sequentially and the first which 2869 matches controls the handling of the frame: 2871 1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is 2872 L2-IS-IS, the frame is handled as described in Section 4.6.2.1. 2874 2. If the Outer.MacDA is a multicast address allocated to TRILL other 2875 than All-RBridges, the frame is discarded. 2877 3. If the Outer.MacDA is a unicast address other than the address of 2878 the receiving Rbridge, the frame is discarded. (Such discarded 2879 frames are most likely addressed to another RBridge on a multi- 2880 access link and that other Rbridge will handle them.) 2882 4. If the Ethertype is not TRILL, the frame is discarded. 2884 5. If the Version field in the TRILL Header is greater than 0, the 2885 frame is discarded. 2887 6. If the hop count is 0, the frame is discarded. 2889 7. If the Outer.MacDA is multicast and the M bit is zero or if the 2890 Outer.MacDA is unicast and M bit is one, the frame is discarded. 2892 8. By default, an RBridge MUST NOT forward TRILL-encapsulated frames 2893 from a neighbor that it does not have a TRILL IS-IS adjacency 2894 with. RBridges MAY be configured per port to accept these frames 2895 for forwarding in cases where it is known that a non-peering 2896 device (such as an end-station) is configured to originate TRILL- 2897 encapsulated frames that can be safely forwarded. 2899 9. The Inner.MacDA is then tested. If it is the All-ESADI-RBridges 2900 multicast address and RBn implements the ESADI protocol, 2901 processing proceeds as in Section 4.6.2.2 below. If it is any 2902 other address or RBn does not implement ESADI, processing proceeds 2903 as in Section 4.6.2.3. 2905 4.6.2.1 TRILL Control Frames 2907 The frame is processed by the TRILL IS-IS instance on RBn and is not 2908 forwarded. 2910 4.6.2.2 TRILL ESADI Frames 2912 If M == 0, the frame is silently discarded. 2914 The egress nickname designates the distribution tree. The frame is 2915 forwarded as described in Section 4.6.2.5. In addition, if the 2916 forwarding Rbridge is an appointed forwarder for a link in the 2917 specified VLAN and implements the TRILL ESADI protocol and ESADI is 2918 enabled at the forwarding Rbridge for that VLAN, the inner frame is 2919 decapsulated and provided to that local ESADI protocol. 2921 4.6.2.3 TRILL Data Frames 2923 The M flag is then checked. If it is zero, processing continues as 2924 described in Section 4.6.2.4, if it is one, processing continues as 2925 described in Section 4.6.2.5. 2927 4.6.2.4 Known Unicast TRILL Data Frames 2929 The egress nickname in the TRILL header is examined and, if it is 2930 unknown or reserved, the frame is discarded. 2932 If RBn is a transit RBridge the hop count is decremented by one and 2933 the frame forwarded to the next hop RBridge towards the egress 2934 RBridge. (The provision permitting RBridges to decrease the hop count 2935 by more than one under some circumstances (see Section 3.6) applies 2936 only to multi-destination frames, not to the known unicast frames 2937 considered in this subsection.) The Inner.VLAN is not examined by a 2938 transit RBridge when it forwards a known unicast TRILL data frame. 2939 For the forwarded frame, the Outer.MacSA is the MAC address of the 2940 transmitting port, the Outer.MacDA is the unicast address of the next 2941 hop RBridge, and the VLAN is the Designated VLAN on the link onto 2942 which the frame is being transmitted. 2944 If RBn is not a transit RBridge, that is if the egress RBridge 2945 indicated is the RBridge performing the processing, the Inner.MacSA 2946 and Inner.VLAN ID are, by default, learned as associated with the 2947 ingress nickname unless that nickname is unknown or reserved or the 2948 Inner.MacSA is not unicast. Then the frame being forwarded is 2949 decapsulated to native form and the following checks are performed: 2951 o The Inner.MacDA is checked. If it is not unicast, the frame is 2952 discarded. 2954 o If the Inner.MacDA corresponds to the RBridge doing the 2955 processing, the frame is locally delivered. 2957 o The Inner.VLAN ID is checked. If it is 0x0 or 0xFFF, the frame is 2958 discarded. 2960 o The Inner.MacDA and Inner.VLAN ID are looked up in RBn's local 2961 address cache and the frame is then either sent onto the link 2962 containing the destination, if the RBridge is appointed forwarder 2963 for that link for the frame's VLAN and is not inhibited (or 2964 discarded if it is inhibited), or processed as in one of the 2965 following two paragraphs. 2967 A known unicast TRILL data frame can arrive at the egress Rbridge 2968 only to find that the combination of Inner.MacDA and Inner.VLAN is 2969 not actually known by that RBridge. One way this can happen is that 2970 the address information may have timed out in the egress RBridge MAC 2971 address cache. In this case, the egress RBridge sends the native 2972 frame out on all links that are in the frame's VLAN for which the 2973 RBridge is appointed forwarder and has not been inhibited, except 2974 that it MAY refrain from sending the frame on links where it knows 2975 there cannot be an end station with the destination MAC address, for 2976 example the link port is configured as a trunk (see Section 4.9.1). 2978 If, due to manual configuration or learning from layer 2 2979 registration, the destination MAC and VLAN appear in RBn's local 2980 address cache for two or more links for which RBn is an uninhibited 2981 appointed forwarder for the frame's VLAN, RBn sends the native frame 2982 on all such links. 2984 4.6.2.5 Multi-Destination TRILL Data Frames 2986 The egress and ingress nicknames in the TRILL header are examined 2987 and, if either is unknown or reserved, the frame is discarded. 2989 The Outer.MacSA is checked and the frame discarded if it is not a 2990 tree adjacency for the tree indicated by the egress RBridge nickname 2991 on the port where the frame was received. The Reverse Path 2992 Forwarding Check is performed on the ingress and egress nicknames and 2993 the frame discarded if it fails. If there are multiple TRILL-Hello 2994 pseudonode suppressed parallel links to the previous hop RBridge, the 2995 frame is discarded if it has been received on the wrong one. If the 2996 RBridge has multiple ports connected to the link, the frame is 2997 discarded unless it was received on the right one. For more 2998 information on the checks in this paragraph, see Section 4.5.2. 3000 If the Inner.VLAN ID of the frame is 0x0 or 0xFFF, the frame is 3001 discarded. 3003 If the RBridge is an appointed forwarder for the Inner.VLAN ID of the 3004 frame, the Inner.MacSA and Inner.VLAN ID are, by default, learned as 3005 associated with the ingress nickname unless that nickname is unknown 3006 or reserved or the Inner.MacSA is not unicast. A copy of the frame is 3007 then decapsulated, sent in native form on those links in its VLAN for 3008 which the RBridge is appointed forwarder subject to additional 3009 pruning and inhibition as described in Section 4.2.4.3, and/or 3010 locally processed as appropriate. 3012 The hop count is decreased (possibly by more than one, see Section 3013 3.6) and the frame is forwarded down the tree specified by the egress 3014 RBridge nickname pruned as described in Section 4.5. 3016 For the forwarded frame, the Outer.MacSA is set to that of the port 3017 on which the frame is being transmitted, the Outer.MacDA is the All- 3018 RBridges multicast address, and the VLAN is the Designated VLAN of 3019 the link on which the frame is being transmitted. 3021 4.6.3 Receipt of a Layer 2 Control Frame 3023 Low-level control frames received by an RBridge are handled within 3024 the port where they are received as described in Section 4.9. 3026 There are two types of high-level control frames, distinguished by 3027 their destination address, which are handled as described in the 3028 sections referenced below. 3030 Name Section Destination Address 3032 BPDU 4.9.3 01-80-C2-00-00-00 3033 VRP 4.9.4 01-80-C2-00-00-21 3035 4.7 IGMP, MLD, and MRD Learning 3037 Ingress RBridges SHOULD learn, based on native IGMP [RFC3376], MLD 3038 [RFC2710], and MRD [RFC4286] frames they receive in VLANs for which 3039 they are an uninhibited appointed forwarder, which IP derived 3040 multicast messages should be forwarded onto which links. Such frames 3041 are also, in general, encapsulated as TRILL data frames and 3042 distributed as described below and in Section 4.5. 3044 An IGMP or MLD membership report received in native form from a link 3045 indicates a multicast group listener for that group on that link. An 3046 IGMP or MLD query or an MRD advertisement received in native form 3047 from a link indicates the presence of an IP multicast router on that 3048 link. 3050 IP multicast group membership reports have to be sent throughout the 3051 campus and delivered to all IP multicast routers, distinguishing IPv4 3052 and IPv6. All IP-derived multicast traffic must also be sent to all 3053 IP multicast routers for the same version of IP. 3055 IP multicast data SHOULD only be sent on links where there is either 3056 an IP multicast router for that IP type (IPv4 or IPv6) or an IP 3057 multicast group listener for that IP multicast derived MAC address, 3058 unless the IP multicast address is in the range required to be 3059 treated as broadcast. 3061 RBridges do not need to announce themselves as listeners to the IPv4 3062 All-Snoopers multicast group (the group used for MRD reports 3063 [RFC4286]), because the IPv4 multicast address for that group is in 3064 the range where all frames sent to that IP multicast addresses must 3065 be broadcast (see [RFC4541], Section 2.1.2). However, RBridges that 3066 are performing IPv6 derived multicast optimization MUST announce 3067 themselves as listeners to the IPv6 All-Snoopers multicast group. 3069 See also "Considerations for Internet Group Management Protocol 3070 (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" 3071 [RFC4541]. 3073 4.8 End Station Address Details 3075 RBridges have to learn the MAC addresses and VLANs of their locally 3076 attached end stations for link/VLAN pairs for which they are the 3077 appointed forwarder. Learning this enables them to do the following: 3079 o Forward the native form of incoming known unicast TRILL data 3080 frames onto the correct link. 3082 o Decide, for an incoming native unicast frame from a link, where 3083 the RBridge is the appointed forwarder for the frame's VLAN, 3084 whether the frame is 3086 - known to have been destined for another end station on the same 3087 link, so the RBridge need do nothing, or 3089 - has to be converted to a TRILL data frame and forwarded. 3091 RBridges need to learn the MAC addresses, VLANs, and remote RBridges 3092 of remotely attached end stations for VLANs for which they and the 3093 remote RBridge are an appointed forwarder, so they can efficiently 3094 direct native frames they receive that are unicast to those addresses 3095 and VLANs. 3097 4.8.1 Learning End Station Addresses 3099 There are five independent ways an RBridge can learn end station 3100 addresses as follows: 3102 1. From the observation of VLAN-x frames received on ports where it 3103 is appointed VLAN-x forwarder, learning the { source MAC, VLAN, 3104 port } triplet of received frames. 3106 2. The { source MAC, VLAN, ingress RBridge nickname } triplet of any 3107 native frames that it decapsulates. 3109 3. By Layer 2 registration protocols learning the { source MAC, VLAN, 3110 port } of end stations registering at a local port. 3112 4. By running the TRILL ESADI protocol for one or more VLANs and 3113 thereby receiving remote address information and/or transmitting 3114 local address information. 3116 5. By management configuration. 3118 RBridges MUST implement capabilities 1 and 2 above. RBridges use 3119 these capabilities unless configured, for one or more particular 3120 VLANs and/or ports, not to learn from either received frames or from 3121 decapsulating native frames to be transmitted or both. 3123 RBridges MAY implement capabilities 3 and 4 above. If capability 4 is 3124 implemented, the ESADI protocol is run only when the RBridge is 3125 configured to do so on a per-VLAN basis. 3127 RBridges SHOULD implement capability 5. 3129 Entries in the table of learned MAC and VLAN addresses and associated 3130 information also have a one octet unsigned confidence level 3131 associated with each entry whose rationale is given below. Such 3132 information learned from the observation of data has a confidence of 3133 0x20 unless configured to have a different confidence. This 3134 confidence level can be configured on a per RBridge basis separately 3135 for information learned from local native frames and that learned 3136 from remotely originated encapsulated frames. Such information 3137 received via the TRILL ESADI protocol is accompanied by a confidence 3138 level in the range 0 to 254. Such information configured by 3139 management defaults to a confidence level of 255 but may be 3140 configured to have another value. 3142 The table of learned MAC addresses includes (1) { confidence, VLAN, 3143 MAC address, local port } for addresses learned from local native 3144 frames and local registration protocols, (2) { confidence, VLAN, MAC 3145 address, egress RBridge nickname } for addresses learned from remote 3146 encapsulated frames and ESADI link state databases, and (3) 3147 additional information to implement timeout of learned addresses, 3148 statically configured addresses, and the like. 3150 When a new address and related information learned from observing 3151 data frames are to be entered into the local database there are three 3152 possibilities: 3154 A. If this is a new { address, VLAN } pair, the information is 3155 entered accompanied by the confidence level. 3157 B. If there is already an entry for this { address, VLAN } pair with 3158 the same accompanying delivery information, the confidence level 3159 in the local database is set to the maximum of its existing 3160 confidence level and the confidence level with which it is being 3161 learned. In addition, if the information is being learned with the 3162 same or a higher confidence level than its existing confidence 3163 level, timer information is reset. 3165 C. If there is already an entry for this { address, VLAN } pair with 3166 different information, the learned information replaces the older 3167 information only if it is being learned with higher or equal 3168 confidence than that in the database entry. If it replaces older 3169 information, timer information is also reset. 3171 4.8.2 Learning Confidence Level Rationale 3173 The confidence level mechanism allows an RBridge campus manager to 3174 cause certain address learning sources to prevail over others. In a 3175 default configuration, without the optional ESADI protocol, addresses 3176 are only learned from observing local native frames and the 3177 decapsulation of received TRILL data frames. Both of these sources 3178 default to confidence level 0x20 so, since learning at an equal or 3179 high confidence overrides previous learning, the learning in such a 3180 default case mimics default 802.1 bridge learning. 3182 While RBridge campus management policies are beyond the scope of this 3183 document, here are some example types of policies that can be 3184 implemented with the confidence mechanism and the rationale for each: 3186 o Locally received native frames might be considered more reliable 3187 than decapsulated frames received from remote parts of the campus. 3188 To stop MAC addresses learned from such local frames from being 3189 usurped by remotely received forged frames, the confidence in 3190 locally learned addresses could be increased or that in addresses 3191 learned from remotely sourced decapsulated frames decreased. 3193 o MAC address information learned through a cryptographically 3194 authenticated Layer 2 registration protocol, such as 802.1X with a 3195 cryptographically based EAP method, might be considered more 3196 reliable than information learned through the mere observation of 3197 data frames. When such authenticated learned address information 3198 is transmitted via the ESADI protocol, the use of authentication 3199 in the TRILL ESADI LSP frames could make tampering with it in 3200 transit very difficult. As a result, it might be reasonable to 3201 announce such authenticated information via the ESADI protocol 3202 with a high confidence, so it would override any alternative 3203 learning from data observation. 3205 Manually configured address information is generally considered 3206 static and so defaults to a confidence of 0xFF while no other source 3207 of such information can be configured to a confidence any higher than 3208 0xFE. However, for other cases, such as where the manual 3209 configuration is just a starting point which the Rbridge campus 3210 manager wishes to be dynamically overrideable, the confidence of such 3211 manually configured information may be configured to a lower value. 3213 4.8.3 Forgetting End Station Addresses 3215 While RBridges need to learn end station addresses as described 3216 above, it is equally important that they be able to forget such 3217 information. Otherwise, frames for end stations that have moved to a 3218 different part of the campus could be indefinitely black holed by 3219 RBridges with stale information as to the link to which the end 3220 station is attached. 3222 For end station address information locally learned from frames 3223 received, the time out from the last time a native frame was received 3224 or decapsulated with the information conforms to the recommendations 3225 of [802.1D]. It is referred to as the "Ageing Time" and is 3226 configurable per RBridge with a range of from 10 seconds to 1,000,000 3227 seconds and a default value of 300 seconds. 3229 The situation is different for end station address information 3230 acquired via the TRILL ESADI protocol. It is up to the originating 3231 RBridge to decide when to remove such information from its ESADI LSPs 3232 (or up to ESADI protocol timeouts if the originating RBridge becomes 3233 inaccessible). 3235 When an RBridge ceases to be appointed forwarder for VLAN-x on a 3236 port, it forgets all end station address information learned from the 3237 observation of VLAN-x native frames received on that port. It also 3238 increments a per VLAN counter of the number of times it lost 3239 appointed forwarder status on one of its ports for that VLAN. 3241 When, for all of its ports, RBridge RBn is no longer appointed 3242 forwarder for VLAN-x, it forgets all end station address information 3243 learned from decapsulating VLAN-x native frames. Also, if RBn is 3244 participating in the TRILL ESADI protocol for VLAN-x, it ceases to so 3245 participate after sending a final LSP nulling out the end station 3246 address information for that VLAN which it had been originating. In 3247 addition, all other RBridges that are VLAN-x forwarder on at least 3248 one of their ports notice that the link state data for RBn has 3249 changed to show that it no longer has a link on VLAN-x. In response, 3250 they forget all end station address information they have learned 3251 from decapsulating VLAN-x frames that show RBn as the ingress 3252 RBridge. 3254 When the appointed forwarder lost counter for RBridge RBn for VLAN-x 3255 is observed to increase via the TRILL IS-IS link state database but 3256 RBn continues to be an appointed forwarder for VLAN-x on at least one 3257 of its ports, every other RBridge that is an appointed forwarder for 3258 VLAN-x modifies the aging of all the addresses it has learned by 3259 decapsulating native frames in VLAN-x from ingress RBridge RBn as 3260 follows: The time remaining for each entry is adjusted to be no 3261 larger than a per RBridge configuration parameter called (to 3262 correspond to [802.1D]) "Forward Delay". This parameter is in the 3263 range of 4 to 30 seconds with a default value of 15 seconds. 3265 4.8.4 Shared VLAN Learning 3267 RBridges can map VLAN IDs into a smaller number of identifiers for 3268 purposes of address learning, as [802.1Q-2005] bridges can. Then, 3269 when a lookup is done in learned address information, this identifier 3270 is used for matching in place of the VLAN ID. If the ID of the VLAN 3271 on which the address was learned is not retained, then there are the 3272 following consequences: 3274 o The RBridge no longer has the information needed to participate in 3275 the TRILL ESADI protocol for the VLANs whose ID is not being 3276 retained. 3278 o In cases where Section 4.8.3 above requires the discarding of 3279 learned address information based on a particular VLAN, when the 3280 VLAN ID is not available for entries under a shared VLAN 3281 identifier, instead the time remaining for each entry under that 3282 shared VLAN identifier is adjusted to be no longer than the 3283 RBridge's "Forward Delay". 3285 Although outside the scope of this specification, there are some 3286 Layer 2 features in which a set of VLANs has shared learning, where 3287 one of the VLANs is the "primary" and the other VLANs in the group 3288 are "secondaries". An example of this is where traffic from different 3289 communities are separated using VLAN tags, and yet some resource 3290 (such as an IP router or DHCP server) is to be shared by all the 3291 communities. A method of implementing this feature is to give a VLAN 3292 tag, say Z, to a link containing the shared resource, and have the 3293 other VLANs, say A, C, and D, be part of the group { primary = Z, 3294 secondaries = A, C, D }. An RBridge, aware of this grouping, attached 3295 to one of the secondary VLANs in the group also claims to be attached 3296 to the primary VLAN. So an RBridge attached to A would claim to also 3297 be attached to Z. An RBridge attached to the primary would claim to 3298 be attached to all the VLANs in the group. 3300 This document does not specify how VLAN groups might be used. Only 3301 RBridges that participate in a VLAN group will be configured to know 3302 about the VLAN group. However, to detect misconfiguration, an RBridge 3303 configured to know about a VLAN group SHOULD report the VLAN group in 3304 its LSP. 3306 4.9 RBridge Ports 3308 Section 4.9.1 below describes the several RBridge port configuration 3309 bits, Section 4.9.2 gives a logical port structure in terms of frame 3310 processing, and Sections 4.9.3 and 4.9.4 describe the handling of 3311 high-level control frames. 3313 4.9.1 RBridge Port Configuration 3315 There are four per port configuration bits as follows: 3317 o Disable port bit. When this bit is set, all frames received or to 3318 be transmitted are discarded, with the possible exception of some 3319 layer 2 control frames that may be generated and transmitted or 3320 received and processed within the port. By default, ports are 3321 enabled. 3323 o End station service disable (trunk port) bit. When this bit is 3324 set, all native frames received on the port and all native frames 3325 that would have been sent on the port are discarded. (See Appendix 3326 B.) (Note that, for this document, "native frames" does not 3327 include layer 2 control frames.) By default, ports are not 3328 restricted to being trunk ports. 3330 If a port with end station service disabled reports, in a TRILL- 3331 Hello frame it sends out that port, which VLANs it provides end 3332 station support for, it reports that there are none. 3334 o TRILL traffic disable (access port) bit. If this bit is set, the 3335 goal is to avoid sending any TRILL frames, except TRILL-Hello 3336 frames, on the port since it is intended only for native end 3337 station traffic. By default, ports are not restricted to being 3338 access ports. This bit is reported in TRILL-Hello frames. If RB1 3339 is the DRB and has this bit set in its TRILL-Hello, the DRB still 3340 appoints VLAN forwarders. However, usually no pseudonode is 3341 reported, and none of the inter-RBridge links associated with that 3342 link are reported in LSPs. 3344 If the DRB RB1 does not have this bit set, but neighbor RB2 on the 3345 link does have the bit set, then RB1 does not appoint RB2 as 3346 appointed forwarder for any VLAN, and none of the RBridges 3347 (including the pseudonode) report RB2 as a neighbor in LSPs. 3349 In some cases even though the DRB has the "access port" flag set, 3350 the DRB MAY choose to create a pseudonode for the access port. In 3351 this case, the other RBridges report connectivity to the 3352 pseudonode in their LSP, but the DRB sets the "overload" flag in 3353 the pseudonode LSP. 3355 o Use P2P Hellos bit. If this bit is set, Hellos sent on this port 3356 are IS-IS P2P Hellos. By default TRILL-Hellos are used. See 3357 Section 4.2.4.1 for more information on P2P links. 3359 The dominance relationship of these four configuration bits is as 3360 follows, where configuration bits to the left dominate those to the 3361 right. That is to say, when any pair of bits is asserted, 3362 inconsistencies in behavior they mandate are resolved in favor of 3363 behavior mandated by the bit to the left of the other bit in the this 3364 list. 3366 Disable > P2P > Access > Trunk 3368 4.9.2 RBridge Port Structure 3370 An RBridge port can be modeled as having a lower level structure 3371 similar to that of an [802.1Q-2005] bridge port as shown in Figure 3372 4.5. In this figure, the double lines represent the general flow of 3373 the frames and information while single lines represent information 3374 flow only. The dashed lines in connection with VRP (GVRP/MVRP) are to 3375 show that VRP support is optional. An actual RBridge port 3376 implementation may be structured in any way that provides the correct 3377 behavior. 3379 +---------------------------------------------- 3380 | RBridge 3381 | 3382 | Interport Forwarding, IS-IS. Management, ... 3383 | 3384 +----++----------------------+-------------++-- 3385 || | || 3386 Trill || Data | || 3387 || +--+---------+ || 3388 +-------------++-----+ | TRILL | || 3389 | Encapsulation | +------+ IS-IS Hello| || 3390 | Decapsulation | | | Processing | || 3391 | Processing | | +-----++-----+ || 3392 +--------------------+ | || || 3393 | RBridge Appointed +------+ || || 3394 +---+ Forwarder and | || || 3395 | | Inhibition Logic +==============\\ || //====++ 3396 | +---------+--------+-+ Native \\ ++ // 3397 | | | Frames \++/ 3398 | | | || 3399 +----+-----+ +- - + - - + | || 3400 | RBridge | | RBridge | | || All TRILL and 3401 | BPDU | | VRP | | || Native Frames 3402 |Processing| |Processing| | || 3403 +-----++---+ + - - -+- -+ | +--------++--+ <- EISS 3404 || | | | 802.1Q | 3405 || | | | Port VLAN | 3406 || | | |and priority| 3407 || | | | Processing | 3408 +---++------------++------+------------+------------+ <-- ISS 3409 | 802.1/802.3 Low Level Control Frame | 3410 | Processing, Port/Link Control Logic | 3411 +------------++-------------------------------------+ 3412 || 3413 || +------------+ 3414 || | 802.3 PHY | 3415 ++========+ (Physical +======== 802.3 3416 | Interface) | Link 3417 +------------+ 3419 Figure 4.5: Detailed RBridge Port Model 3421 Low-level control frames are handled in the lower level port / link 3422 control logic in the same way as in an [802.1Q-2005] bridge port. 3423 This can optionally include a variety of 802.1 or link specific 3424 protocols such as PAUSE (Annex 31B of [802.3]), link layer discovery 3425 [802.1AB], link aggregation [802.1AX], MAC security [802.1AE], or 3426 port based access control [802.1X]. While handled at a low level, 3427 these frames may affect higher level processing. For example, a Layer 3428 2 registration protocol may affect the confidence in learned 3429 addresses. The upper interface to this lower level port control logic 3430 corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005]. 3432 High-level control frames (BPDUs and, if supported, VRP frames) are 3433 not VLAN tagged. Although they extend through the ISS interface, they 3434 are not subject to port VLAN processing. Behavior on receipt of a 3435 VLAN tagged BPDU or VLAN tagged VRP frame, is unspecified. If a VRP 3436 is not implemented, then all VRP frames are discarded. Handling of 3437 BPDUs is described in Section 4.9.3. Handling of VRP frames is 3438 described in Section 4.9.4. 3440 Frames other than layer 2 control frames, that is, all TRILL and 3441 native frames, are subject to Port VLAN and priority processing which 3442 is the same as for an [802.1Q-2005] bridge. The upper interface to 3443 the port VLAN and priority processing corresponds to the Extended 3444 Internal Sublayer Service (EISS) in [802.1Q-2005]. 3446 In this model, RBridge port processing below the EISS layer is 3447 identical to an [802.1Q-2005] bridge except for (1) the handling of 3448 high-level control frames and (2) that the discard of frames that 3449 have exceeded the Maximum Transit Delay is not mandatory but MAY be 3450 done. 3452 As described in more detail elsewhere in this document, incoming 3453 native frames are only accepted if the RBridge is an uninhibited 3454 appointed forwarder for the frame's VLAN, after which they are 3455 normally encapsulated and forwarded; outgoing native frames are 3456 usually obtained by decapsulation and are only output if the RBridge 3457 is an uninhibited appointed forwarder for the frame's VLAN. 3459 TRILL-Hellos, MTU-probes, and MTU-acks are handled per port and, like 3460 all TRILL IS-IS frames, are never forwarded. They can affect the 3461 appointed forwarder and inhibition logic as well as the RBridge's 3462 LSP. 3464 Except TRILL-Hellos, MTU-probes, and MTU-acks, all TRILL control as 3465 well as TRILL data and ESADI frames are passed up to higher level 3466 RBridge processing on receipt and passed down for transmission on 3467 creation or forwarding. Note that these frames are never blocked due 3468 to the appointed forwarder and inhibition logic, which affects only 3469 native frames, but there are additional filters on some of them such 3470 as the Reverse Path Forwarding Check. 3472 4.9.3 BPDU Handling 3474 If RBridge campus topology were static, RBridges would simply be end 3475 stations from a bridging perspective, terminating but not otherwise 3476 interacting with spanning tree. However, there are reasons for 3477 RBridges to listen to and sometimes to transmit BPDUs as described 3478 below. Even when RBridges listen to and transmit BPDUs, this is a 3479 local RBridge port activity. The ports of a particular RBridge never 3480 interact so as to make the RBridge as a whole a spanning tree node. 3482 4.9.3.1 Receipt of BPDUs 3484 Rbridges MUST listen to spanning tree configuration BPDUs received on 3485 a port and keep track of the root bridge, if any, on that link. If 3486 MSTP is running on the link, this is the CIST root. This information 3487 is reported per VLAN by the RBridge in its LSP and may be used as 3488 described in Section 4.2.4.3. In addition, the receipt of spanning 3489 tree configuration BPDUs is used as an indication that a link is a 3490 bridged LAN, which can affect the RBridge transmission of BPDUs. 3492 An RBridge MUST NOT encapsulate or forward any BPDU frame it 3493 receives. 3495 RBridges discard any topology change BPDUs they receive, but note 3496 Section 4.9.3.3. 3498 4.9.3.2 Root Bridge Changes 3500 A change in the root bridge seen in the spanning tree BPDUs received 3501 at an RBridge port may indicate a change in bridged LAN topology, 3502 including the possibility of the merger of two bridged LANs or the 3503 like, without any physical indication at the port. During topology 3504 transients, bridges may go into pre-forwarding states that block 3505 TRILL-Hello frames. For these reasons, when an RBridge sees a root 3506 bridge change on a port for which it is appointed forwarder for one 3507 or more VLANs, it is inhibited (discards all native frames received 3508 from or which it would otherwise have sent to the link) for a period 3509 of time between zero and 30 seconds. This time period is configurable 3510 per port and defaults to 30 seconds. 3512 For example, consider two bridged LANs carrying multiple VLANs, each 3513 with various RBridge appointed forwarders. Should they become merged, 3514 due to a cable being plugged in or the like, those RBridges attached 3515 to the original bridged LAN with the lower priority root will see a 3516 root bridge change while those attached to the other original bridged 3517 LAN will not. Thus all appointed forwarders in the lower priority set 3518 will be inhibited for a time period while things are sorted out by 3519 BPDUs within the merged bridged LAN and TRILL-Hello frames between 3520 the RBridges involved. 3522 4.9.3.3 Transmission of BPDUs 3524 When an RBridge ceases to be appointed forwarder for one or more 3525 VLANs out a particular port it SHOULD, as long as it continues to 3526 receive spanning tree BPDUs on that port, send topology change BPDUs 3527 until it sees the topology change acknowledged in a spanning tree 3528 configuration BPDU. 3530 RBridges MAY support a capability for sending spanning tree BPDUs for 3531 the purpose of attempting to force a bridged LAN to partition as 3532 discussed in Section A.3.3. 3534 4.9.4 Dynamic VLAN Registration 3536 Dynamic VLAN registration provides a means for bridges (and less 3537 commonly end stations) to request that VLANs be enabled or disabled 3538 on ports leading to the requestor. This is done by VLAN registration 3539 protocol (VRP) frames: GVRP or MVRP. RBridges MAY implement GVRP 3540 and/or MVRP as described below. 3542 VRP frames are never encapsulated as TRILL frames between RBridges or 3543 forwarded in native form by an RBridge. If an RBridge does not 3544 implement a VRP, it discards any VRP frames received and sends none. 3546 RBridge ports may have dynamically enabled VLANs. If an RBridge 3547 supports a VRP, the actual enablement of dynamic VLANs is determined 3548 by GVRP/MVRP frames received at the port as it would be for an 3549 [802.1Q-2005] / [802.1ak] bridge. 3551 An RBridge that supports a VRP sends GVRP/MVRP frames as an 3552 [802.1Q-2005] / [802.1ak] bridge would send on each port that is not 3553 configured as an RBridge trunk port or P2P port. For this purpose, it 3554 sends VRP frames to request traffic in the VLANs for which it is 3555 appointed forwarder and in the Designated VLAN, unless the Designated 3556 VLAN is disabled on the port, and to not request traffic in any other 3557 VLAN. 3559 5. RBridge Parameters 3561 This section lists parameters for RBridges. It is expected that the 3562 TRILL MIB will include many of the items listed in this section plus 3563 additional Rbridge status and data including traffic and error 3564 counts. 3566 The default value and range are given for parameters added by TRILL. 3567 Where a parameter is defined as a 16-bit unsigned integer and an 3568 explicit maximum is not given, that maximum is 2**16-1. For 3569 parameters imported from [802.1Q-2005], [802.1D], or IS-IS [ISO10589] 3570 [RFC1195], see those standards for default and range if not given 3571 here. 3573 5.1 Per RBridge 3575 The following parameters occur per RBridge: 3577 o Number of nicknames, which defaults to 1 and may be configured 3578 in the range of 1 to 256. 3580 o The desired number of distribution trees to be calculated by 3581 every RBridge in the campus and a desired number of 3582 distribution trees for the advertising RBridge to use, both of 3583 which are unsigned 16-bit integers that default to 1 (see 3584 Section 4.5). 3586 o The maximum number of distribution trees the RBridge can 3587 compute. This is a 16 bit unsigned integer which is 3588 implementation and environment dependent and not subject to 3589 management configuration. 3591 o Two lists of nicknames, one designating the distribution trees 3592 to be computed and one designating distribution trees to be 3593 used as discussed in Section 4.5. By default, these lists are 3594 empty. 3596 o The parameters Ageing Timer and Forward Delay with the default 3597 and range specified in [802.1Q-2005]. 3599 o Two unsigned octets that are, respectively, the confidence in { 3600 MAC, VLAN, local port } triples learned from locally received 3601 native frames and the confidence in { MAC, VLAN, remote RBridge 3602 } triples learned from decapsulating frames. These each default 3603 to 0x20 and may each be configured to values from 0x00 to 0xFE. 3605 o The desired minimum acceptable inter-RBridge link MTU for the 3606 campus, that is, originatingLSPBufferSize. This is a 16 bit 3607 unsigned integer number of octets that defaults to 1470 bytes, 3608 which is the minimum valid value. Any lower value being 3609 advertised by an RBridge is ignored. 3611 o The number of failed MTU-probes before the RBridge concludes 3612 that a particular MTU is not supported, which defaults to 3 and 3613 may be configured between 1 and 255. 3615 Static end station address information and confidence in such end 3616 station information statically configured can also be configured with 3617 a default confidence of 0xFF and range of 0x00 to 0xFF. By default, 3618 there is no such static address information. The quantity of such 3619 information that can be configured is implementation dependent. 3621 5.2 Per Nickname Per RBridge 3623 The following configuration information per nickname at each RBridge: 3625 o Priority to hold the nickname, which defaults to 0x40 if no 3626 specific value has been configured or 0xC0 if it is configured 3627 (see Section 3.7.3). 3629 o Nickname priority to be selected as a distribution tree root, a 3630 16-bit unsigned integer that defaults to 0x8000. 3632 o Nickname value, an unsigned 16-bit quantity which defaults to 3633 the configured value if configured, else to the last value held 3634 if the RBridge coming up after a re-boot and that value is 3635 remembered, else to a random value; however, in all cases the 3636 reserved values 0x0000 and 0xFFC0 through 0xFFFF are excluded 3637 (see Section 3.7.3). 3639 5.3 Per Port Per RBridge 3641 An RBridge has the following per port configuration parameters: 3643 o The same parameters as an [802.1Q-2005] port in terms of C-VLAN 3644 IDs. In addition, an Announcing VLANs set that defaults to the 3645 enabled VLANs on the port (see Section 4.4.3) and ranges from 3646 the null set to the set of all legal VLAN IDs. 3648 o The same parameters as an [802.1Q-2005] port in terms of frame 3649 priority code point mapping (see [802.1Q-2005]). 3651 o The inhibition time for the port when it observed a change in 3652 the root bridge of an attached bridged LAN. This is in units of 3653 seconds, defaults to 30, and can be configured to any value 3654 from 0 to 30. 3656 o The desired designated VLAN that the RBridge will advertise in 3657 its TRILL Hellos if it is DRB for the link via that port. This 3658 defaults to the lowest VLAN ID enabled on the port and may be 3659 configured to any valid VLAN ID that is enabled on the port 3660 (0x001 through 0xFFE). 3662 o Four per-port configuration bits: disable port (default 0 == 3663 enabled), disable end station service (trunk, default 0 == 3664 enabled), access port (default 0 == not restricted to being an 3665 access port), and use P2P Hellos (default 0 == use TRILL 3666 Hellos). (See Section 4.9.1.) 3668 o One bit per port such that, if the bit is set, it disables 3669 learning { MAC address, VLAN, port } triples from locally 3670 received native frames on the port. Default value is 0 == 3671 learning enabled. 3673 o The priority of the RBridge to be DRB and its Holding Time via 3674 that port with defaults and range as specified in IS-IS 3675 [ISO10589] [RFC1195]. 3677 o A bit which, when set, enables the receipt of TRILL- 3678 encapsulated frames from an Outer.MacSA with which the RBridges 3679 does not have an IS-IS adjacency. Default value is 0 == 3680 disabled. 3682 o Configuration for the optional send-BPDUs solution to the 3683 wiring closet topology problem as described in Section A.3.3. 3684 Default Bridge Address is the System ID of the RBridge with 3685 lowest System ID. If RB1 and RB2 are part of a wiring closet 3686 topology, both need to be configured to know about this, and 3687 know the ID that should be used in the spanning tree protocol 3688 on the specified port. 3690 5.4 Per VLAN Per RBridge 3692 An RBridge has the following per VLAN configuration parameters: 3694 o Per VLAN ESADI protocol participation flag, 7-bit priority, and 3695 Holding Time. Default participation flag is 0 == not 3696 participating. Default and range of priority and Holding Time 3697 as specified in IS-IS [ISO10589] [RFC1195]. 3699 o One bit per VLAN that, if set, disables learning { MAC address, 3700 VLAN, remote RBridge } triples from frames decapsulated in the 3701 VLAN. Defaults to 0 == learning enabled. 3703 6. Security Considerations 3705 Layer 2 bridging is not inherently secure. It is, for example, 3706 subject to spoofing of source addresses and bridging control 3707 messages. A goal for TRILL is that RBridges do not add new issues 3708 beyond those existing in current bridging technology. 3710 Countermeasures are available such as to configure the TRILL IS-IS 3711 and ESADI protocols to use IS-IS security [RFC5304] and ignore 3712 unauthenticated TRILL control and ESADI frames received. RBridges 3713 using IS-IS security will need configuration. 3715 IEEE 802.1 port admission and link security mechanisms, such as 3716 [802.1X] and [802.1AE], can also be used. These are best thought of 3717 as being implemented below TRILL (see Section 4.9.2) and are outside 3718 the scope of TRILL (just as they are generally out of scope for 3719 bridging standards [802.1D] and 802.1Q); however, TRILL can make use 3720 of secure registration through the confidence level communicated in 3721 the optional TRILL ESADI protocol (see Section 4.8). 3723 TRILL encapsulates native frames inside the RBridge campus while they 3724 are in transit between ingress RBridge and egress RBridge(s) as 3725 described in Sections 2.3 and 4.1. Thus, TRILL ignorant devices with 3726 firewall features that cannot be detected by RBridges as end stations 3727 will generally not be able to inspect the content of such frames for 3728 security checking purposes. This may render them ineffective. Layer 3729 3 routers and hosts appear to RBridges to be end stations and native 3730 frames will be decapsulated before being sent to such devices. Thus 3731 they will not see the TRILL Ethertype. Firewall devices that do not 3732 appear to an RBridge to be an end station, for example bridges with 3733 co-located firewalls, should be modified to understand TRILL 3734 encapsulation. 3736 RBridges do not prevent nodes from impersonating other nodes, for 3737 instance, by issuing bogus ARP/ND replies. However, RBridges do not 3738 interfere with any schemes that would secure neighbor discovery. 3740 6.1 VLAN Security Considerations 3742 TRILL supports VLANs. These provide logical separation of traffic but 3743 care should be taken in using VLANs for security purposes. To have 3744 reasonable assurance of such separation, all the RBridges and links 3745 (including bridged LANs) in a campus must be secured and configured 3746 so as to prohibit end stations from using dynamic VLAN registration 3747 frames or otherwise gaining access to any VLAN carrying traffic for 3748 which they are not authorized to read and/or inject. 3750 Furthermore, if VLANs were used to keep some information off links 3751 where it might be observed in a bridged LAN, this will no longer 3752 work, in general, when bridges are replaced with RBridges; with 3753 encapsulation and a different outer VLAN tag, the data will travel 3754 the least cost transit path regardless of VLAN. Appropriate counter 3755 measures are to use end-to-end encryption or an appropriate TRILL 3756 security option should one be specified. 3758 6.2 BPDU/Hello Denial of Service Considerations 3760 The TRILL protocol requires that an appointed forwarder at an RBridge 3761 port be temporarily inhibited if it sees a TRILL-Hello from another 3762 RBridge claiming to be the appointed forwarder for the same VLAN or 3763 sees a root bridge change out that port. Thus it would seem that 3764 forged BPDUs showing repeated root bridge changes and forged TRILL- 3765 Hello frames with the Appointed Forwarder flag set could represent a 3766 significant denial of service attack. However, the situation is not 3767 as bad as it seems. 3769 The best defense against forged TRILL-Hello frames or other IS-IS 3770 messages is the use of IS-IS security [RFC5304]. Rogue end-stations 3771 would not normally have access to the required IS-IS keying material 3772 needed to forge authenticatible messages. 3774 Authentication similar to IS-IS security is usually unavailable for 3775 BPDUs. However, it is also the case that in typical modern wired 3776 LANs, all the links are point-to-point. If you have an all-RBridged 3777 point-to-point campus, then the worst that an end-station can do by 3778 forging BPDUs or TRILL-Hello frames is to deny itself service. This 3779 could be either through falsely inhibiting the forwarding of native 3780 frames by the RBridge to which it is connected or by falsely 3781 activating the optional decapsulation check (see Section 4.2.4.3). 3783 However, when an RBridge campus contains bridged LANs, those bridged 3784 LANs appear to any connected RBridges to be multi-access links. The 3785 forging of BPDUs by an end-station attached to such a bridged LAN 3786 could affect service to other end-stations attached to the same 3787 bridged LAN. Note that bridges never forward BPDUs but process them, 3788 although this processing may result in the issuance of further BPDUs. 3789 Thus, for an end-station to forge BPDUs to cause continuing changes 3790 in the root bridge as seen by an RBridge through intervening bridges 3791 would typically require it to cause root bridge thrashing throughout 3792 the bridged LAN that would be disruptive even in the absence of 3793 RBridges. 3795 Some bridges can be configured to not send BPDUs and/or to ignore 3796 BPDUs on particular ports and RBridges can be configured not to 3797 inhibit appointed forwarding on a port due to root bridge changes; 3798 however, such configuration should be used with caution as it can be 3799 unsafe. 3801 7. Assignment Considerations 3803 This section discuses IANA and IEEE 802 assignment considerations. 3804 See [RFC5226]. 3806 7.1 IANA Considerations 3808 A new IANA registry is created for TRILL Parameters with two 3809 subregistries as below. 3811 The initial contents of the TRILL Nicknames subregistry is as 3812 follows: 3814 0x0000 Reserved to indicate no nickname specified 3815 0x0001-0xFFBF Dynamically allocated by the RBridges within each 3816 RBridge campus 3817 0xFFC0-0xFFFE Available for allocation by RFC Required (single 3818 value) or IETF Review (single or multiple values) 3819 0xFFFF Permanently reserved 3821 The initial contents of the TRILL Multicast Address subregistry is as 3822 follows: 3824 01-80-C2-XX-XX-X0 Assigned as All-RBridges 3825 01-80-C2-XX-XX-X1 Assigned as All-IS-IS-RBridges 3826 01-80-C2-XX-XX-X2 Assigned as All-ESADI-RBridges 3827 01-80-C2-XX-XX-X3 to 01-80-C2-XX-XX-XF Available for allocation 3828 by IETF Review 3830 7.2 IEEE Registration Authority Considerations 3832 The Ethertype is assigned by the IEEE Registration Authority to 3833 the TRILL Protocol. 3835 The Ethertype is assigned by the IEEE Registration Authority 3836 for L2-IS-IS. 3838 The block of 16 multicast MAC addresses from <01-80-C2-XX-XX-X0> to 3839 <01-80-C2-XX-XX-XF> are assigned by the IEEE Registration Authority 3840 for IETF TRILL protocol use. 3842 8. Normative References 3844 [802.1ak] "IEEE Standard for Local and metropolitan area networks / 3845 Virtual Bridged Local Area Networks / Multiple Registration 3846 Protocol", IEEE Standard 802.1ak-2007, 22 June 2007. 3848 [802.1D] "IEEE Standard for Local and metropolitan area networks / 3849 Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004. 3851 [802.1Q-2005] "IEEE Standard for Local and metropolitan area networks 3852 / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006. 3854 [802.3] "IEEE Standard for Information technology / 3855 Telecommunications and information exchange between systems / 3856 Local and metropolitan area networks / Specific requirements Part 3857 3: Carrier sense multiple access with collision detection 3858 (CSMA/CD) access method and physical layer specifications", 3859 802.3-2008, 26 December 2008. 3861 [ISO10589] ISO/IEC 10589:2002, "Intermediate system to Intermediate 3862 system routeing information exchange protocol for use in 3863 conjunction with the Protocol for providing the Connectionless- 3864 mode Network Service (ISO 8473)," ISO/IEC 10589:2002. 3866 [layer2] Banerjee, A., et al., "Extensions to IS-IS for Layer-2 3867 Systems", draft-ietf-isis-layer2, work in progress. 3869 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, 3870 RFC 1112, Stanford University, August 1989. 3872 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 3873 dual environments", RFC 1195, December 1990. 3875 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3876 Requirement Levels", BCP 14, RFC 2119, March 1997. 3878 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 3879 Networks", RFC 2464, December 1998. 3881 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 3882 Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 3884 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 3885 Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3886 3376, October 2002. 3888 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 3889 Network Management Protocol (SNMP)", STD 62, RFC 3417, December 3890 2002. 3892 [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for 3893 Transport Addresses", RFC 3419, December 2002. 3895 [RFC4286] Haberman, B., Martin, J., "Multicast Router Discovery", RFC 3896 4286, December 2005. 3898 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3899 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 3901 [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way 3902 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, October 3903 2008. 3905 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 3906 Engineering", RFC 5305, October 2008. 3908 9. Informative References 3910 [802.1ad] "IEEE Standard for and metropolitan area networks / Virtual 3911 Bridged Local Area Networks / Provider Bridges", 802.1ad-2005, 26 3912 May 2005. 3914 [802.1ah] "IEEE Standard for Local and Metropolitan Area Networks / 3915 Virtual Bridged Local Area Networks / Provider Backbone Bridges", 3916 802.1ah-2008, 1 January 2008. 3918 [802.1aj] Virtual Bridged Local Area Networks / Two-Port Media Access 3919 Control (MAC) Relay, 802.1aj Draft 4.2, 24 September 2009. 3921 [802.1AE] "IEEE Standard for Local and metropolitan area networks / 3922 Media Access Control (MAC) Security", 802.1AE-2006, 18 August 3923 2006. 3925 [802.1AX] "IEEE Standard for Local and metropolitan area networks / 3926 Link Aggregation", 802.1AX-2008, 1 January 2008. 3928 [802.1X] "IEEE Standard for Local and metropolitan area networks / 3929 Port Based Network Access Control", 802.1X-REV Draft 2.9, 3 3930 September 2008. 3932 [RBridges] Perlman, R., "RBridges: Transparent Routing", Proc. 3933 Infocom 2005, March 2004. 3935 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3936 RFC 1661, July 1994. 3938 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 3939 Architecture for Describing Simple Network Management Protocol 3940 (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 3942 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 3943 "Randomness Requirements for Security", BCP 106, RFC 4086, June 3944 2005. 3946 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 3947 "Considerations for Internet Group Management Protocol (IGMP) and 3948 Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, 3949 May 2006. 3951 [RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network 3952 Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789, 3953 November 2006. 3955 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 3956 Authentication", RFC 5304, October 2008. 3958 [RFC5342] Eastlake 3rd., D., "IANA Considerations and IETF Protocol 3959 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008. 3961 [RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of 3962 Lots of Links (TRILL): Problem and Applicability Statement", RFC 3963 5556, May 2009. 3965 [RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches, 3966 and Internetworking Protocols, 2nd Edition", Addison Wesley 3967 Longman, Chapter 3, 1999. 3969 Appendix A: Incremental Deployment Considerations 3971 Some aspects of partial RBridge deployment are described below for 3972 link cost determination (Section A.1) and possible congestion due to 3973 appointed forwarder bottlenecks (Section A.2). A particular example 3974 of a problem related to the TRILL use of a single appointed forwarder 3975 per link per VLAN (the "wiring closet topology") is explored in 3976 detail in Section A.3. 3978 A.1 Link Cost Determination 3980 With an RBridged campus having no bridges or repeaters on the links 3981 between RBridges, the RBridges can accurately determine the number of 3982 physical hops involved in a path and the line speed of each hop, 3983 assuming this is reported by their port logic. With intervening 3984 devices, this is no longer possible. For example, as shown in Figure 3985 A.1, the two bridges B1 and B2 can completely hide a slow link so 3986 that both Rbridges RB1 and RB2 incorrectly believe the link is 3987 faster. 3989 +-----+ +----+ +----+ +-----+ 3990 | | Fast | | Slow | | Fast | | 3991 | RB1 +--------+ B1 +--------+ B2 +--------+ RB2 | 3992 | | Link | | Link | | Link | | 3993 +-----+ +----+ +----+ +-----+ 3995 Figure A.1: Link Cost of a Bridged Link 3997 Even in the case of a single intervening bridge, two RBridges may 3998 know they are connected but each see the link as a different speed 3999 from how it is seen by the other. 4001 However, this problem is not unique to RBridges. Bridges can 4002 encounter similar situations due to links hidden by repeaters and 4003 routers can encounter similar situations due to links hidden by 4004 bridges, repeaters or Rbridges. 4006 A.2 Appointed Forwarders and Bridged LANs 4008 With partial RBridge deployment, the RBridges may partition a bridged 4009 LAN into a relatively small number of relatively large remnant 4010 bridged LANs, or possibly not partition it at all so a single bridged 4011 LAN remains. Such configuration can result in the following problem: 4013 The requirement that native frames enter and leave a link via the 4014 link's appointed forwarder for the VLAN of the frame can cause 4015 congestion or suboptimal routing. (Similar problems can occur within 4016 a bridged LAN due to the spanning tree algorithm.) The extent to 4017 which such a problem will occur is highly dependent on the network 4018 topology. For example, if a bridged LAN had a star-like structure 4019 with core bridges that connected only to other bridges and peripheral 4020 bridges that connected to end stations and are connected to core 4021 bridges, the replacement of all of the core bridges by RBridges 4022 without replacing the peripheral bridges would generally improve 4023 performance without inducing appointed forwarder congestion. 4025 Solutions to this problem are discussed below and a particular 4026 example explored in Section A.3. 4028 Inserting RBridges so that all the bridged portions of the LAN stay 4029 connected to each other and have multiple RBridge connections is 4030 generally the least efficient arrangement. 4032 There are four techniques that may help if the problem above occurs 4033 and which can, to some extent, be used in combination: 4035 1. Replace more IEEE 802.1 customer bridges with RBridges so as to 4036 minimize the size of the remnant bridged LANs between RBridges. 4037 This requires no configuration of the RBridges unless the bridges 4038 they replace required configuration. 4040 2. Re-arrange network topology to minimize the problem. If the 4041 bridges and RBridges involved are configured, this may require 4042 changes in their configuration. 4044 3. Configure the RBridges and bridges so that end stations on a 4045 remnant bridged LAN are separated into different VLANs that have 4046 different appointed forwarders. If the end stations were already 4047 assigned to different VLANs, this is straightforward (see Section 4048 4.2.4.2). If the end stations were on the same VLAN and have to be 4049 split into different VLANs, this technique may lead to 4050 connectivity problems between end stations. 4052 4. Configure the RBridges such that their ports which are connected 4053 to the bridged LAN send spanning tree configuration BPDUs (see 4054 Section A.3.3) in such a way as to force the partition of the 4055 bridged LAN. (Note: A spanning tree is never formed through an 4056 RBridge but always terminates at RBridge ports.) To use this 4057 technique, the RBridges must support this optional feature, and 4058 would need to be configured to use it, but the bridges involved 4059 would rarely have to be configured. This technique makes the 4060 bridged LAN unavailable for TRILL through traffic because the 4061 bridged LAN partitions. 4063 Conversely to item 3 above, there may be bridged LANs that use VLANs, 4064 or use more VLANs than would otherwise be necessary, to support the 4065 Multiple Spanning Tree Protocol or otherwise reduce the congestion 4066 that can be caused by a single spanning tree. Replacing the IEEE 4067 802.1 bridges in such LANs with RBridges may enable a reduction in or 4068 elimination of VLANs and configuration complexity. 4070 A.3 Wiring Closet Topology 4072 If 802.1 bridges are present and RBridges are not properly 4073 configured, the bridge spanning tree or the DRB may make 4074 inappropriate decisions. Below is a specific example of the more 4075 general problem that can occur when a bridged LAN is connected to 4076 multiple RBridges. 4078 In cases where there are two (or more) groups of end nodes, each 4079 attached to a bridge (say B1 and B2), and each bridge is attached to 4080 an RBridge (say RB1 and RB2 respectively), with an additional link 4081 connecting B1 and B2 (see Figure A.2), it may be desirable to have 4082 the B1-B2 link only as a backup in case one of RB1 or RB2 or one of 4083 the links B1-RB1 or B2-RB2 fail. 4085 +-------------------------------+ 4086 | | | | 4087 | Data +-----+ +-----+ | 4088 | Center -| RB1 |----| RB2 |- | 4089 | +-----+ +-----+ | 4090 | | | | 4091 +-------------------------------+ 4092 | | 4093 | | 4094 +-------------------------------+ 4095 | | | | 4096 | +----+ +----+ | 4097 | Wiring | B1 |-----| B2 | | 4098 | Closet +----+ +----+ | 4099 | Bridged | 4100 | LAN | 4101 +-------------------------------+ 4103 Figure A.2: Wiring Closet Topology 4105 For example, B1 and B2 may be in a wiring closet and it may be easy 4106 to provide a short, high bandwidth, low cost link between them while 4107 RB1 and RB2 are at a distant data center such that the RB1-B1 and 4108 RB2-B2 links are slower and more expensive. 4110 Default behavior might be that one of RB1 or RB2 (say RB1) would 4111 become DRB for the bridged LAN including B1 and B2 and appoint itself 4112 forwarder for the VLANs on that bridged LAN. As a result, RB1 would 4113 forward all traffic to/from the link, so end nodes attached to B2 4114 would be connected to the campus via the path B2-B1-RB1, rather than 4115 the desired B2-RB2. This wastes the bandwidth of the B2-RB2 path and 4116 cuts available bandwidth between the end stations and the data center 4117 in half. The desired behavior would be to make use of both the RB1-B1 4118 and RB2-B2 links. 4120 Three solutions to this problem are described below. 4122 A.3.1 The RBridge Solution 4124 Of course, if B1 and B2 are replaced with RBridges, the right thing 4125 will happen without configuration (other than VLAN support), but this 4126 may not be immediately practical if bridges are being incrementally 4127 replaced by RBridges. 4129 A.3.2 The VLAN Solution 4131 If the end stations attached to B1 and B2 are already divided among a 4132 number of VLANs, RB1 and RB2 could be configured so that which ever 4133 becomes DRB for this link will appoint itself forwarder for some of 4134 these VLANs and appoint the other RBridge for the remaining VLANs. 4135 Should either of the RBridges fail or become disconnected, the other 4136 will have only itself to appoint as forwarder for all the VLANs. 4138 If the end stations are all on a single VLAN, then it would be 4139 necessary to assign them between at least two VLANs to use this 4140 solution. This may lead to connectivity problems that might require 4141 further measures to rectify. 4143 A.3.3 The Spanning Tree Solution 4145 Another solution is to configure the relevant ports on RB1 and RB2 to 4146 be part of a "wiring closet group", with a configured per RBridge 4147 port "Bridge Address" Bx (which may be RB1 or RB2's System ID). Both 4148 RB1 and RB2 emit spanning tree BPDUs on their configured ports as 4149 highest priority root Bx. This causes the spanning tree to logically 4150 partition the bridged LAN as desired by blocking the B1-B2 link at 4151 one end or the other (unless one of the bridges is configured to also 4152 have highest priority and has a lower ID, which we consider to be a 4153 misconfiguration). With the B1-B2 link blocked, RB1 and RB2 cannot 4154 see each other's TRILL-Hellos via that link and each acts as 4155 Designated RBridge and appointed forwarder for its respective 4156 partition. Of course, with this partition, no TRILL through traffic 4157 can flow through the RB1-B1-B2-RB2 path. 4159 In the spanning tree configuration BPDU, the Root is "Bx" with 4160 highest priority, cost to Root is 0, Designated Bridge ID is "RB1" 4161 when RB1 transmits and "RB2" when RB2 transmits, and port ID is a 4162 value chosen independently by each of RB1 and RB2 to distinguish each 4163 of its own ports. The topology change flag is zero and the topology 4164 change acknowledgement flag is set if and only if a topology change 4165 BPDU has been received on the port since the last configuration BPDU 4166 was transmitted on the port. (If RB1 and RB2 were actually bridges on 4167 the same shared medium with no bridges between them, the result would 4168 be that the one with the larger ID sees "better" BPDUs (because of 4169 the tiebreaker on the third field: the ID of the transmitting 4170 bridge), and would turn off its port.) 4172 Should either RB1 or the RB1-B1 link or RB2 or the RB2-B2 link fail, 4173 the spanning tree algorithm will stop seeing one of the RBx roots and 4174 will unblock the B1-B2 link maintaining connectivity of all the end 4175 stations with the data center. 4177 If the link RB1-B1-B2-RB2 is on the cut set of the campus and RB2 and 4178 RB1 have been configured to believe they are part of a wiring closet 4179 group, the campus becomes partitioned as the link is blocked. 4181 A.3.4 Comparison of Solutions 4183 Replacing all 802.1 customer bridges with RBridges is usually the 4184 best solution with the least amount of configuration required, 4185 possibly none. 4187 The VLAN solution works well with a relatively small amount of 4188 configuration if the end stations are already divided among a number 4189 of VLANs. If they are not, it becomes more complex and problematic. 4191 The spanning tree solution does quite well in this particular case. 4192 But it depends on both RB1 and RB2 having implemented the optional 4193 feature of being able to configure a port to emit spanning tree BPDUs 4194 as described in Section A.3.3 above. It also makes the bridged LAN 4195 whose partition is being forced unavailable for through traffic. 4196 Finally, while in this specific example it neatly breaks the link 4197 between the two bridges B1 and B2, if there were a more complex 4198 bridged LAN, instead of exactly two bridges, there is no guarantee 4199 that it would partition into roughly equal pieces. In such a case, 4200 you might end up with a highly unbalanced load on the RB1-B1 link and 4201 the RB2-B2 link although this is still better than using only one of 4202 these links exclusively. 4204 Appendix B: Trunk and Access Port Configuration 4206 Many modern bridged LANs are organized into a core and access model, 4207 The core bridges have only point-to-point links to other bridges 4208 while the access bridges connect to end stations, core bridges, and 4209 possibly other access bridges. It seems likely that some RBridge 4210 campuses will be organized in a similar fashion. 4212 An RBridge port can be configured as a trunk port, that is, a link to 4213 another RBridge or RBridges, by configuring it to disable end station 4214 support. There is no reason for such a port to have more than one 4215 VLAN enabled and in its Announcing Set on the port. Of course, the 4216 RBridge (or RBridges) to which it is connected must have the same 4217 VLAN enabled. There is no reason for this VLAN to be other than the 4218 default VLAN 1 unless the link is actually over carrier Ethernet or 4219 other facilities that only provide some other specific VLAN or the 4220 like. Such configuration minimizes wasted TRILL-Hellos and eliminates 4221 useless decapsulation and transmission of multi-destination traffic 4222 in native form onto the link. (see Sections 4.2.4 and 4.9.1) 4224 An RBridge access port would be expected to lead to a link with end 4225 stations and possibly one or more bridges. Such a link might also 4226 have more than one RBridge connected to it to provide more reliable 4227 service to the end stations. It would be a goal to minimize or 4228 eliminate transit traffic on such a link as it is intended for end 4229 station native traffic. This can be accomplished by turning on the 4230 access port configuration bit for the RBridge port or ports connected 4231 to the link as further detailed in Section 4.9.1. 4233 When designing RBridge configuration user interfaces, consideration 4234 should be given to making it convenient to configure ports as trunk 4235 and access ports. 4237 Appendix C: Multipathing 4239 Rbridges support multipathing of both known unicast and multi- 4240 destination traffic. Implementation of multipathing is optional. 4242 Multi-destination traffic can be multipathed by using different 4243 distribution tree roots for different frames. For example, assume 4244 that in Figure C.1 end stations attached to RBy are the source of 4245 various multicast streams each of which has multiple listeners 4246 attached to various of RB1 through RB9. Assuming equal bandwidth 4247 links, a distribution tree rooted at RBy will predominantly use the 4248 vertical links among RB1 through RB9 while one rooted at RBz will 4249 predominantly use the horizontal. If RBy chooses its nickname as the 4250 distribution tree root for half of this traffic and an RBz nickname 4251 as the root for the other half, it may be able to substantially 4252 increase the aggregate bandwidth by making use of both the vertical 4253 and horizontal links among RB1 through RB9. 4255 Since the distribution trees an RBridge must calculate are the same 4256 for all RBridges and transit RBridges MUST respect the tree root 4257 specified by the ingress RBridge, a campus will operate correctly 4258 with a mix of RBridges some of which use different roots for 4259 different multi-destination frames they ingress and some of which use 4260 a single root for all such frames. 4262 +---+ 4263 |RBy|---------------+ 4264 +---+ | 4265 / | \ | 4266 / | \ | 4267 / | \ | 4268 +---+ +---+ +---+ | 4269 |RB1|---|RB2|---|RB3| | 4270 +---+ +---+ +---+\ | 4271 | | | \ | 4272 +---+ +---+ +---+ \+---+ 4273 |RB4|---|RB5|---|RB6|-----|RBz| 4274 +---+ +---+ +---+ /+---+ 4275 | | | / 4276 +---+ +---+ +---+/ 4277 |RB7|---|RB8|---|RB9| 4278 +---+ +---+ +---+ 4280 Figure C.1: Multi-Destination Multipath 4282 Known unicast equal cost multipathing (ECMP) can occur at an RBridge 4283 if, instead of using a tiebreaker criterion when building SPF paths, 4284 information is retained about ports through which equal cost paths 4285 are available. Different unicast frames can then be sent through 4286 those different ports and will be forwarded by equal cost paths. For 4287 example, in Figure C.2, which shows only RBridges and omits any 4288 bridges present, there are three equal cost paths between RB1 and RB2 4289 and two equal cost paths between RB2 and RB5. Thus, for traffic 4290 transiting this part of the campus from left to right, RB1 may be 4291 able to perform three way ECMP and RB2 may be able to perform two way 4292 ECMP. 4294 A transit RBridge receiving a known unicast frame forwards it towards 4295 the egress RBridge and is not concerned with whether it believes 4296 itself to be on any particular path from the ingress RBridge or a 4297 previous transit RBridge. Thus a campus will operate correctly with 4298 a mix of RBridges some of which implement ECMP and some of which do 4299 not. 4301 There are actually three possibilities for the parallel paths between 4302 RB1 and RB2 as follows: 4304 1. If two or three of these paths have pseudonodes, then all three 4305 will be distinctly visible in the campus wide link state and ECMP 4306 as described above is applicable. 4307 2. If the paths use P2P Hellos or otherwise do not have pseudonodes, 4308 these three paths would appear as a single adjacency in the link 4309 state. In this case, multipathing across them would be an entirely 4310 local matter for RB1 and RB2. It can be freely done for known 4311 unicast frames but not for multi-destination frames as described 4312 in Section 4.5.2. 4313 3. If and only if the three paths between RB1 and RB2 are single hop 4314 equal bandwidth links with no intervening bridges, then it would 4315 be permissible to combine them into one logical link through the 4316 [802.1AX] "link aggregation" feature. Rbridges MAY implement link 4317 aggregation since that feature operates below TRILL (see Section 4318 4.9.2). 4320 +---+ double line = 10 Gbps 4321 ----- ===|RB3|--- single line = 1 Gbps 4322 / \ // +---+ \ 4323 +---+ +---+ +---+ 4324 ===|RB1|-----|RB2| |RB5|=== 4325 +---+ +---+ +---+ 4326 \ / \ +---+ // 4327 ----- ----|RB4|=== 4328 +---+ 4330 Figure C.2: Known Unicast Multipath 4332 When multipathing is used, frames that follow different paths will be 4333 subject to different delays and may be re-ordered. While some 4334 traffic may be order/delay insensitive, typically most traffic 4335 consists of flows of frames where re-ordering within a flow is 4336 damaging. How to determine flows or what granularity flows should 4337 have is beyond the scope of this document. (This issue is discussed 4338 in [802.1AX].) 4340 Appendix D: Determination of VLAN and Priority 4342 A high-level, informative summary of how VLAN ID and priority are 4343 determined for incoming native frames, omitting some details, is 4344 given in the bulleted items below. For more detailed information, see 4345 [802.1Q-2005]. 4347 o When an untagged native frame arrives, an unconfigured RBridge 4348 associates the default priority zero and the VLAN ID 1 with it. It 4349 actually sets the VLAN for the untagged frame to be the "port VLAN 4350 ID" associated with that port. The port VLAN ID defaults to VLAN 4351 ID 1 but may be configured to be any other VLAN ID. An Rbridge may 4352 also be configured on a per port basis to discard such frames or 4353 to associate a different priority code point with them. 4354 Determination of the VLAN ID associated with an incoming untagged 4355 non-control frame may also be made dependent on the Ethertype or 4356 NSAP (referred to in 802.1 as the Protocol) of the arriving frame, 4357 the source MAC address, or other local rules. 4359 o When a priority tagged native frame arrives, an unconfigured 4360 RBridge associates with it both the port VLAN ID, which defaults 4361 to 1, and the priority code point provided in the priority tag in 4362 the frame. An Rbridge may be configured on a per port basis to 4363 discard such frames or to associate them with a different VLAN ID 4364 as described in the point immediately above. It may also be 4365 configured to map the priority code point provided in the frame by 4366 specifying, for each of the eight possible values that might be in 4367 the frame, what actual priority code point will be associated with 4368 the frame by the RBridge. 4370 o When a C-tagged (formerly called Q-tagged) native frame arrives, 4371 an unconfigured RBridge associates with it the VLAN ID and 4372 priority in the C-tag. An RBridge may be configured on a per port 4373 per VLAN basis to discard such frames. It may also be configured 4374 on a per port basis to map the priority value as specified above 4375 for priority tagged frames. 4377 In 802.1, the process of associating a priority code point with a 4378 frame, including mapping a priority provided in the frame to another 4379 priority, is referred to as priority "regeneration". 4381 Appendix E: Support of IEEE 802.1Q-2005 Amendments 4383 This informational appendix briefly comments on RBridge support for 4384 completed and in-process amendments to IEEE [802.1Q-2005]. There is 4385 no assurance that existing RBridge protocol specifications or 4386 existing bridges will support not yet specified future [802.1Q-2005] 4387 amendments just as there is no assurance that existing bridge 4388 protocol specifications or existing RBridges will support not yet 4389 specified future TRILL amendments. 4391 The information below is frozen as of 25 October 2009. For the latest 4392 status, see the IEEE 802.1 working group ( 4393 http://grouper.ieee.org/groups/802/1/ ). 4395 E.1 Completed Amendments 4397 802.1ad-2005 Provider Bridges - Sometimes called "Q-in-Q", because 4398 VLAN tags used to be called "Q-tags", 802.1ad specifies 4399 Provider Bridges that tunnel customer bridge traffic within 4400 service VLAN tags (S-tags). If the customer LAN is an RBridge 4401 campus, that traffic will be bridged by Provider Bridges. 4402 Customer bridge features involving Provider Bridge awareness, 4403 such as the ability to configure a customer bridge port to add 4404 an S-tag to a frame before sending it to a Provider Bridge, are 4405 below the EISS layer and can be supported in RBridge ports 4406 without modification to the TRILL protocol. 4407 802.1ag-2007 Connectivity Fault Management (CFM) - This 802.1 feature 4408 is at least in part dependent on the symmetric path and other 4409 characteristics of spanning tree. The comments provided to the 4410 IETF TRILL working group by the IEEE 802.1 working group stated 4411 that "TRILL weakens the applicability of CFM.". 4412 802.1ak-2007 Multiple Registration Protocol - Supported to the extent 4413 described in Section 4.9.4. 4414 802.1ah-2008 Provider Backbone Bridges - Sometimes called "MAC-in- 4415 MAC", 802.1ah provides for Provider Backbone Bridges that 4416 tunnel customer bridge traffic within different outer MAC 4417 addresses and using a tag (the "I-tag") to preserve the 4418 original MAC addresses and signal other information. If the 4419 customer LAN is an RBridge campus, that traffic will be bridged 4420 by Provider Backbone Bridges. Customer bridge features 4421 involving Provider Backbone Bridge awareness, such as the 4422 ability to configure a customer bridge port to add an I-tag to 4423 a frame before sending it to a Provider Backbone Bridge, are 4424 below the EISS layer and can be supported in RBridge ports 4425 without modification to the TRILL protocol. 4426 802.1Qaw-2009 Management of Data-Driven and Data-Dependent 4427 Connectivity Fault - Amendment building on 802.1ag. See 4428 comments on 802.1ag-2007 above. 4430 802.1Qay-2009 Provider Backbone Bridge Traffic Engineering - 4431 Amendment building on 802.1ah to configure traffic engineered 4432 routing. See comments on 802.1ah-2008 above. 4434 E.2 In-process Amendments 4436 The following are amendments to IEEE [802.1Q-2005] that are in 4437 process. As such, the brief comments below are based on drafts and 4438 may be incorrect for later versions or any final amendment. 4440 802.1aj Two-port MAC Relay - This amendment specifies a MAC relay 4441 that will be transparent to RBridges. RBridges are compatible 4442 with IEEE 802.1aj devices as currently specified, in the same 4443 sense that IEEE 802.1Q-2005 bridges are compatible with such 4444 devices. 4445 802.1aq Shortest Path Bridging - This amendment provides for improved 4446 routing in bridged LANs. 4447 802.1Qat Stream Reservation Protocol - Modification to 802.1Q to 4448 support the 802.1 Timing and Synchronization. This protocol 4449 reserves resources for streams at supporting bridges. 4450 802.1Qau Congestion Notification - It currently appears that 4451 modifications to RBridge behavior above the EISS level would be 4452 needed to support this amendment. Such modifications are beyond 4453 the scope of this document. 4454 802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive 4455 Streams - Modification to 802.1Q to support the 802.1 Timing 4456 and Synchronization protocol. This amendment specifies methods 4457 to support the resource reservations made through the 802.1Qat 4458 protocol (see above). 4459 802.1Qaz Enhanced Transmission Selection - It appears that this 4460 amendment will be below the EISS layer and can be supported in 4461 RBridge ports without modification to the TRILL protocol. 4462 802.1Qbb Priority-based Flow Control - Commonly called "per priority 4463 pause", it appears that this amendment will be below the EISS 4464 layer and can be supported in RBridge ports without 4465 modification to the TRILL protocol. 4466 802.1bc Remote Customer Service Interfaces. This is an extension to 4467 802.1Q provider bridging. See 802.1ad-2005 above. 4468 802.1Qbe Multiple Backbone Service Instance Identifier (I-SID) 4469 Registration Protocol (MIRP). This is an extension to 802.1Q 4470 provider backbone bridging. See 802.1ah-2008 above. 4471 802.1Qbf Provider Backbone Bridge Traffic Engineering (PBB-TE) 4472 Infrastructure Segment Protection. This amendment extends 4473 802.1Q to support certain types of failover between provider 4474 backbone bridges. See 802.1ah-2008 above. 4476 Appendix Z: Revision History 4478 RFC Editor: Please delete this Appendix Z before publication. In 4479 addition, please replace the string "" where it 4480 occurs in this document with "RFC xxxx" where xxxx is the RFC number 4481 assigned to this document. 4483 Changes from -03 to -04 4485 1. Divide IANA Considerations section into IANA and IEEE parts. Add 4486 IANA considerations for TRILL Header variations and reserved bit 4487 and normative references to RFCs 2434 and 4020. 4489 2. Add note on the terms Rbridge and TRILL to section 1.2. 4491 3. Remove IS-IS marketing text. 4493 4. Split Section 3 into Sections 3 and 4. Add a new top level 4494 section "5. Pseudo Code", renumbering following sections. Move 4495 pseudo code that was in old Section 3 into Section 5 and make 4496 section 3 more textural. This idea is that Section 3 and 4 have 4497 more readable text descriptions with some corner cases left out 4498 for simplicity while section 5 has more structured and complete 4499 coverage. 4501 5. Revised and extended Security Considerations section. 4503 6. Move multicast router attachment bit and IGMP membership report 4504 information from the per-VLAN IS-IS instance to the core IS-IS 4505 instance so the information can be used by core RBridges to prune 4506 distribution trees. 4508 7. Remove ARP/ND optimization. 4510 8. Change TRILL Header to add option feature. Add option section. 4512 9. Change TRILL Header to expand Version field to the Variation 4513 field. Add TRILL message variations (8 bits) supported to the per 4514 RBridge link state information. 4516 10. Distinguish TRILL data and IS-IS messages by using Variation = 0 4517 and 1. 4519 11. Consistently state that VLAN pruning and IP derived multicast 4520 pruning of distribution trees are SHOULD. 4522 12. Add text and pseudo code to discard TRILL Ethertype data frames 4523 received on a port that does not have an IS-IS adjacency on it. 4525 13. Add end station address learning section. Specify end station 4526 address learning from decapsulated native frames. 4528 14. Add nickname allocation priority and optional nickname 4529 configuration. Reserve nickname values zero and 0xFFFF. 4531 15. Explain about multiple Designated RBridges because of multiple 4532 VLANS. 4534 16. Add Incremental Deployment Considerations Section incorporating 4535 expanded Wiring Closet Topology Section. 4537 17. Add more detail on VLAN tag information and material on frame 4538 priority. 4540 18. Miscellaneous minor editing and terminology updates. 4542 Changes from -04 to -05 4544 NOTE: Section 5 was NOT updated as indicated below but the remainder 4545 of the draft was so updated. 4547 1. Mention optional VLAN and multicast optimization in Abstract. 4549 2. Change to distinguish TRILL IS-IS from TRILL data frames based on 4550 the Inner.MacDA instead of a TRILL Header bit. 4552 3. Split IP multicast router attached bit in two so you can 4553 separately indicate attachment of IPv4 and IPv6 routers. Provide 4554 that these bits must be set if an RBridge does not actually do 4555 multicast control snooping on ingressed traffic. 4557 4. Add the term "port VLAN ID" (PVID). 4559 5. Drop references to PIM. Improve discussions of IGMP, MLD, and MRD 4560 messages. 4562 6. Move M bit over one and create two-bit pruning field at the 4563 bottom of the "V" combined field. 4565 7. Add pruning control values of V and discussion of same. 4567 8. Permit optional unicast transmission of multi-destination frames 4568 when there is only one received out a port. 4570 9. Miscellaneous minor editing and terminology updates. 4572 Changes from -05 to -06 4574 1. Revise Section 2 discussion of DRB determination in the presence 4575 of VLANs and move it to Section 2.2. Adjust VLAN handling 4576 description. 4578 2. Change "V" field to be a 2-bit version fields followed by 2 4579 reserved bits. Make corresponding changes to eliminate the 4580 inclusion in the header of frame analysis indicating type of 4581 multi-destination pruning which is proper for frame. Thus all 4582 non-ingress RBridges that wish to perform such pruning are forced 4583 to do full frame analysis. Make further corresponding changes in 4584 IANA Considerations. 4586 3. The Inner.MacDA for TRILL IS-IS frames is changed to a second 4587 multicast address: All-IS-IS-RBridges. IEEE Allocation 4588 Considerations, etc., are correspondingly changed. 4590 4. Note in Section 6 that bridges can hide slow links and generally 4591 make it harder from RBridges to determine the cost of an RBridge 4592 to RBridge hop that is a bridged LAN. 4594 5. Add material noting that replacement of bridges by RBridges can 4595 cause connectivity between previously isolated islands of the 4596 same VLAN. 4598 6. Expand Security Considerations by mentioning RFC 3567 and 4599 indicating that TRILL enveloping may reduce the effectively of 4600 TRILL-ignorant firewall functionality. 4602 7. Extensive updates to pseudo code. 4604 8. Change to one DRB per physical link that dictates the inter- 4605 RBridge VLAN for the link, appoints forwarders per-VLAN, can be 4606 configured to send Hellos on multiple VLANs, etc. 4608 9. Add a minimal management by SNMP statement to Section 2. 4610 10. Delete explicit requirement to process TRILL frames arriving on a 4611 port even if the port implements spanning tree and is in spanning 4612 tree blocked state. 4614 11. Miscellaneous minor editing and terminology updates. 4616 Changes from -06 to -07 4618 [WARNING: Section 5 of draft -07 was not fully updated to incorporate 4619 the changes below.] 4620 1. Drop recommendation to set "bridge" flags in some 802.1AB frame 4621 fields. 4623 2. Add Section 2.5 giving an informative description of zero 4624 configuration behavior for 802.1D and 802.1Q-2005 bridges and 4625 RBridges. 4627 3. Add Section 4.7 (renumbering the former 4.7 to be 4.9) on the 4628 receipt, handing, and transmission of MVRP and other MRP frames 4629 by RBridges. Add references to 802.1ak. 4631 4. Add Section 4.8 on Multipathing. 4633 5. Partial changes to Section 5 to correspond with changes elsewhere 4634 in the draft. 4636 6. Addition of frame category definitions in Section 1.2. 4638 7. Addition of Section 10, Acronyms. 4640 8. Add note in Section 6.2 that difficult in link cost determination 4641 due to intervening devices is not confined to RBridges. 4643 9. Re-ordered some sections in Section 6. 4645 10. Added a paragraph about taking care if trying to use VLANs for 4646 security to Security Considerations Section and re-ordered 4647 paragraphs in that section. 4649 11. Added mention of being able to configure a port so that native 4650 frames are not send and are dropped on receipt. Probably need to 4651 say more about this. 4653 12. Remove material about pseudo node suppression. 4655 13. Fix a few cases where hop count was off by one. 4657 14. Add option critical bits when option area length non-zero. 4659 15. Replace some remaining references to Q-tag with C-tag. 4661 16. Miscellaneous minor editing and terminology updates. Changed 4662 Figure numbers to be relative to major section. Added Table 4663 captions. 4665 Changes from -07 to -08 4667 1. Add "low" and "high" level control frame definitions to Section 4668 1.2 and note concerning frames that would qualify as both "TRILL" 4669 and "control" frames. Utilize these defined frame types more 4670 consistently through the document. 4672 2. Move substantial areas of tutorial, motivational, and 4673 informational text to Appendices, or a separate document, 4674 including Sections numbered 2.5, 4.8, 6.3, and 6.4 in version 4675 -07. Remove pseudo-code (Section 5 in version -07). 4677 3. Move link Hellos / VLAN specification and discussion to a new 4678 subsection of Section 4. 4680 4. Replace distribution tree root flag per RBridge with new logic 4681 which orders all RBridges in a campus as to their priority to be 4682 a distribution tree root and provides for the highest priority 4683 distribution tree root to dictate the numbers of trees in the 4684 campus. RBridges use the tree with least cost from themselves to 4685 the tree root for multi-destination frame distribution, or the n 4686 such trees if they multi-path multi-destination traffic. 4688 5. Add "Access" port configuration bit and Appendix on Trunk and 4689 Access Links. 4691 6. Add statement that use of S-tags in TRILL is outside the scope of 4692 this document. 4694 7. Add new section on RBridge port structure (Section 4.7) which 4695 includes discussion of RBridge interactions with BPDUs and 4696 revised interactions with VRP frames. Make provisions for dynamic 4697 VLAN registration a "MAY" implement and agnostic between GVRP and 4698 MVRP. Remove references to 802.1ak. Simplify text related to VRP. 4699 Remove related configuration option. 4701 8. Add requirement to adjust input filters no later than output 4702 forwarding. 4704 9. Add requirement for configurable (default 30 second) inhibition 4705 on RBridge decapsulation out a port if a root bridge change has 4706 just been observed on that port. 4708 10. Add provisions for propagating topology change to attached 4709 bridged LAN when an RBridge is de-appointed forwarder. Also other 4710 end station addressing forgetting details including per VLAN 4711 forwarding status dropped counter. 4713 11. Delete requirement that appointed forwarder wait until it has 4714 received all the LSPs listed in the first CSNP (if any) it has 4715 received from its neighbors before forwarding frames off a link. 4717 12. Add explicit criterion for when an RBridge port defers to the DRB 4718 indicated in a Hello it receives even if that Hello is not from 4719 the DRB or even from an RBridge in direct communication with the 4720 DRB. 4722 13. Add provisions for pseudonode minimization. 4724 14. Update reference to RFC 2434 to be to RFC 5226. 4726 15. Miscellaneous minor editing and terminology updates. Add Figures 4727 index after Table of Contents. 4729 Changes from -08 to -09 4731 1. Specify SHOULD as the implementation requirement for SNMPv3 4732 management. 4734 2. Change default confidence level to 0x20 for addresses learned 4735 from observing locally received native frames and from 4736 decapsulating TRILL data frames. This provides more space for 4737 lower confidence levels. 4739 3. Add security consideration for observation of traffic no longer 4740 constrained to links in its Inner.VLAN due to TRILL 4741 encapsulation. 4743 4. Updated bridge configuration assumptions in Section 2.3.1. 4745 5. Use "inhibited" to describe the status of an appointed forwarder 4746 when it is temporarily discarding all received native frames and 4747 not sending any native frames. 4749 6. In Section 4.4, there was an implication that the priority to be 4750 a tree root and the number of trees to be computed had not only 4751 default values for a zero configuration RBridge but could also be 4752 individually present or absent in the LSP for the RBridge. This 4753 tends to lead to a variable-length sub-TLV or multiple sub-TLVs 4754 in the LSP that leads to additional code paths to test. So 4755 various "if advertised" conditional clauses have been removed. 4757 7. Reserve nicknames 0xFFC0 through 0xFFFE as well as 0x0000 and 4758 0xFFFF and provide IANA Considerations for their allocation. 4760 8. Improve Figure 4.1, "TRILL Data Encapsulation over Ethernet" by 4761 generalizing it and adding an RBridge diagram. 4763 9. Add "access port" bit to Hello. Extend and clarify behavior for 4764 access ports and for the occurrence of the IS Neighbor TLV in 4765 TRILL Hellos. 4767 10. Miscellaneous minor editing. 4769 Changes from -09 to -10 4771 1. Split Section 2.4 into two subsections inserting 2.4.1 with a 4772 simplified RBridge port diagram and discussion of how RBridges 4773 mostly use the mechanisms of IEEE 802.1Q-2005 bridges below the 4774 EISS layer. 4776 2. Remove the "SHOULD" requirement that the hop count for multi- 4777 destination frames not be set by the ingress RBridge in excess of 4778 the distance through the distribution tree to the most remote 4779 RBridge. 4781 3. Remove any implication that addresses received by ESADI are 4782 always better than those learned from the data plane. 4784 4. Rephrase language concerning the case where a known unicast 4785 native frame in receive by an RBridge to be output in native form 4786 on another link of that RBridge so that instead of describing 4787 this as logically forwarding the frame in native form it is 4788 described as logically encapsulating and then decapsulating the 4789 frame. 4791 5. Remove language saying that a TRILL Ethertype frame with a 4792 broadcast outer destination address MAY be treated as if its 4793 outer destination address was All-RBridges. 4795 6. Clarify that all TRILL data frames with unknown or reserved 4796 egress nicknames are discarded. 4798 7. Substantially expand Figure 4.5 at the upper port layers and 4799 correspondingly expand the accompanying text that is now Section 4800 4.7.2. 4802 8. Change TRILL IS-IS frames so they are no longer encapsulated but 4803 have the All-IS-IS-RBridges Outer.MacDA. Change the Inner.MacDA 4804 of ESADI frames to be the new All-ESADI-RBridges multicast 4805 address. 4807 9. Update reference to RFC 3567 to be to RFC 5304. 4809 10. Miscellaneous minor editing changes. 4811 Changes from -10 to -11 4813 1. Add BPDU/Hello denial of service section to Security 4814 Considerations. 4816 2. Remove general prohibition on RBridges sending spanning tree 4817 BPDUs. 4819 3. Change ESADI from "End Station Address Distribution Instance" to 4820 "End Station Address Distribution Information". 4822 4. Delete redundant requirement that TRILL IS-IS Hellos contain an 4823 extra field distinguishing the port from which they are sent. 4824 This need is met by the source MAC address. 4826 5. Add Maximum Transit Delay for RBridges with enforcement a MAY. 4828 6. Confused note re DRB deferral deleted. 4830 7. Update boilerplate and make miscellaneous minor editing changes. 4832 Changes from -11 to -12 4834 1. Changes in the determination of the distribution trees to allow 4835 the highest priority RBridge to explicitly list some or all of 4836 the tree roots. Change the listing of distribution trees an 4837 RBridge can use in encapsulating multi-destination frames to 4838 allow the RBridge to not explicitly list all the roots it can 4839 use. 4841 2. Add figures and a little text illustrating the structure of TRILL 4842 IS-IS and TRILL ESADI frames. 4844 3. Add brief discussion of Hello size limitations. 4846 4. Extend appointed forwarder inhibition to also occur on receiving 4847 a Hello sent on VLAN-x as well as received on VLAN-x in cases of 4848 VLAN translation. 4850 5. Provide for the allocation of a block of 16 multicast addresses 4851 for TRILL use by the IETF Registration Authority. RBridges 4852 conforming to this specification discard frames sent to any of 4853 these addresses other than All-RBridges and All-IS-IS-RBridges. 4854 (All-ESADI-RBridges is only allowed as an Inner.MacDA.) 4856 6. Add text on MTU and add Protection Hellos so there are now two 4857 kinds of Hellos, Adjacency and Protection. 4859 7. Add text mandating the RBridges with the Extended IS Adjacency 4860 TLV (#22) and do not use the IS Adjacency TLV (#2). 4862 8. Add text requiring and specifying "tie breaking" to select only 4863 one when sending multi-destination frames between RBridges 4864 connected by multiple parallel links. Mandate three-way handshake 4865 on links configured to use P2P Hellos to provide Extended Circuit 4866 ID. 4868 9. Add section and material on using P2P Hellos. 4870 10. Miscellaneous minor editing changes. 4872 Changes from -12 to -13 4874 1. Eliminate all references to "Hello time", replacing with 4875 appropriate references to Holding Time. 4877 2. Response to IEEE 802.1 comments: Replace all occurrences to 4878 "[802.1Q]" with "[802.1Q-2005]" to make it absolutely, positively 4879 clear that we don't claim to support the "current" 802.1Q as 4880 amended. Add Appendix E to summarize the current state of support 4881 by this draft for the current 802.1Q adopted and in-process 4882 amendments. 4884 3. Improve wording on frame types terminology in Section 1.3. 4886 4. Permit multiple nicknames per Rbridge. 4888 5. Make tie breaker on building distribution trees be the "tree 4889 number" which counts trees rooted at different nicknames at the 4890 same Rbridge as different trees. 4892 6. Renumber 4.3 through 4.7 to be 4.5 through 4.9 and add new 4893 sections 4.3 on MTU-probe and MTU-probe-ack and 4.4 on the TRILL- 4894 Hello protocol that approximately corresponds to the previous 4895 Section 4.2.4. 4897 7. Change TRILL control (IS-IS) messages to be indicated by the 4898 L2-IS-IS Ethertype. Add that Ethertype to Section 5 and Section 4899 7.2. 4901 8. Eliminate references to TRILL IS-IS instance as "core". 4903 9. Eliminate feature whereby encapsulated multi-destination frames 4904 being sent to only one next hop RBridge of interest could be sent 4905 unicast. 4907 10. Update references to Problem and Applicability Statement draft to 4908 be to RFC 5556. 4910 11. Change how the Hop Count is handled so it is tested on receipt of 4911 an encapsulated frame and discarded if it is zero and then not 4912 tested when decremented on forwarding. 4914 12. Clarify and correct handling of multiple parallel links between 4915 adjacent RBridges providing tie-breaking. 4917 13. Correct DRB election to specify MAC address as tie breaker, not 4918 System ID. 4920 14. Change default number of multi-destination frames to be 4921 calculated for the campus from 2 to 1. Provide for RBridges to 4922 advertise how many trees they can calculate and limit number of 4923 trees to the minimum such number across all RBridges in the 4924 campus. 4926 15. Provide that when an appointed forwarder observes that the DRB on 4927 a link has changed, it no longer considers itself appointed for 4928 that link until appointed by the new DRB. 4930 16. Add new section 4.4.4 and material in 4.5.2 and other spots on 4931 port groups, renumbering the former 4.4.4 as 4.4.5. 4933 17. Miscellaneous editing changes. 4935 Changes from -13 to -14 4937 1. Clarify Section 4.5.2 and specify that the extended circuit ID 4938 specified by the RBridge with the highest System ID is the one 4939 use for tie breaking. 4941 2. Specify a maximum size for TRILL-Hello messages (1470 bytes) and 4942 that they SHOULD NOT be padded. 4944 3. Note in 4.2.4.4 that the measured MTU for a link may be 4945 advertised in a sub-TLV of wide metric. 4947 4. Add default link cost specification to 4.2.4.4 item 1. 4949 5. Add note that the VLANs an RBridge is advertising connectivity to 4950 may be associated with particular nicknames of that RBridge as 4951 per draft-ietf-isis-layer2-01.txt. 4953 6. Update 802.3 reference to 802.3-2008. 4955 7. Parts of Section 5 that duplicated Section 7 were eliminated from 4956 Section 5 and the RBridge configuration parameters description in 4957 Section 5 was made more complete. 4959 8. Add references to RFC 3417 and 3419 in connection with SNMP 4960 support. 4962 9. Update Appendix E. 4964 10. Update references to Clause 43 of 802.3 to be to 802.1AX-2008 and 4965 add a couple of references to Annex 31B of 802.3. 4967 11. Clarify that the ways in which RBridges differ in behavior from 4968 802.1Q-2005 bridges are specified in this document. 4970 12. Define "port" to clarify that it includes virtual and pseudo 4971 ports. 4973 13. Clarify that RBridges, as defined in this document, do *not* 4974 offer services equivalent to provider or provider backbone 4975 bridges and that extensions of TRILL in that direction are left 4976 for future work. However, provider and/or provider backbone 4977 bridges may be used to connect parts of an RBridge campus. 4979 14. Add a statement that the optimal and multipath features of TRILL 4980 are of more benefit to more mesh-like networks. 4982 15. Add rapid updating of MAC attachment location as a motivation for 4983 ESADI. 4985 16. Add explanation and motivation for optional decrease of hop 4986 count, for multi-destination frames only, by more than one. 4988 17. Clarify that an RBridge selecting a new nickname does so only 4989 from the nicknames which appear free, based on its copy of the 4990 link state database, which accelerates convergence to stable 4991 nicknames. 4993 18. Provide that priority to be tree root is per nickname, not per 4994 Rbridge, and recommend the sparing use of multiple-nicknames at 4995 an Rbridge. 4997 19. Specify that an RBridge campus is a single Level 1 IS-IS area 4998 with area-ID zero. 5000 20. Add material on ambiguous destinations to new section 4.2.6, 5001 4.6.2.4 and elsewhere: duplicate nicknames or VLAN/MAC addresses. 5003 21. Clarify that the link MTU testing and campus wide inter-RBridge 5004 MTU determination are to support proper TRILL IS-IS operation, do 5005 not relate directly to end station traffic, and do not provide 5006 and end-to-end path MTU service or determination. 5008 22. Specify that TRILL-Hellos are sent with the same timing as IS-IS 5009 LAN Hellos. 5011 23. Add brief statement on how to avoid re-ordering of frames when a 5012 VLAN/MAC address changes between known and unknown. 5014 24. Permit ports to be configured to accept TRILL-encapsulated frames 5015 from devices with which the RBridge does not have an IS-IS 5016 adjacency. 5018 25. Expand ECMP discussion in Appendix C to account for various cases 5019 under this current draft. 5021 26. Specify the default state for the port disable, trunk, access, 5022 and P2P configuration bits. 5024 27. Add definition of "campus". 5026 28. Add "SHOULD" requirement for an RBridge with multiple nicknames 5027 to use the same one as ingress when encapsulating native frames 5028 from the same MAC and VLAN. 5030 29. Drop IANA registries for TRILL Version numbers and Reserved TRILL 5031 Header bits. 5033 30. Many miscellaneous editing changes. 5035 Changes from -14 to -15 5037 There were only two technical changes from -14 to -15, as listed in 5038 items 1 and 9 below. 5040 1. Add port ID to TRILL-Hello by adding one sentence each to section 5041 4.4.2 and 4.4.4. 5043 2. Change name of IANA registry to "TRILL Parameter Registry". 5045 3. Clarify in Section 4.1.4 that the TRILL encapsulated frames have 5046 only one FCS, that is, the encapsulated payload does not include 5047 an FCS. 5049 4. Clarify description of tree numbering at the end of 4.5 5051 5. Clarify in Section 4.5.5 that multi-destination frames are not 5052 sent back out the port they are received on. 5054 6. Clarify that the meaning of the Reserved bits in Figure 3.2 will 5055 be specified in other documents. Improve wording of description 5056 of critical bits. 5058 7. Add normative references in Section 4.2 to draft-ietf-isis-layer2 5059 and add it to the normative references list. 5061 8. Clarify the TRILL IS-IS frames are always Ethertype encoded. 5063 9. Fix next to last paragraph of Section 4.7 so an RBridge doing 5064 IPv6 multicast optimization does have to announce it is in the 5065 IPv6 All-Snoopers Group. 5067 10. Fix about a dozen typos, mostly one character changes. 5069 Changes from -15 to -16 5071 1. Move Abstract to right after title as now permitted. 5073 2. Add a statement that it was not a goal of TRILL to scale 5074 significantly beyond bridged LANs in size. 5076 3. Replace "ESADI" with "ESADI protocol" and the like in various 5077 places for clarity. 5079 4. Add statement of options length requirements to maintain 64-bit 5080 alignment of encapsulated frame contents. 5082 5. Add options area to Figure 3.1 and do minor re-organization of 5083 Section 3. 5085 6. Add explicit statements that the allocation of new TRILL Version 5086 numbers or TRILL Header Reserved bits requires an IETF Standards 5087 Action. 5089 7. Add explicit statement that TRILL encapsulation may cause end 5090 station traffic to be dropped if it causes such frames to exceed 5091 link MTU. 5093 8. Require the nickname of the sending Rbridge in TRILL Hellos. 5095 9. Add to Section 4.5 a statement that how to choose which 5096 distribution tree or trees for an RBridge to use is beyond the 5097 scope of this document but that a tree whose root is least cost 5098 from the RBridge is a good choice in the absence of other 5099 considerations. 5101 10. Add new Section 4.8.2 (re-numbering following sections) giving 5102 rationale for address learning confidence level. 5104 11. Add, in Section 5, default and range information for parameters 5105 added by TRILL and re-organize the section a little. 5107 12. Re-word some text which tended to imply the only one distribution 5108 tree can be rooted at an RBridge. 5110 13. Numerous minor typo corrections and wording clarifications. 5112 Authors' Addresses 5114 Radia Perlman 5115 Intel Labs 5116 2200 Mission College Blvd. 5117 Santa Clara, CA 95054-1549 USA 5119 Phone: +1-408-765-8080 5120 Email: Radia@alum.mit.edu 5122 Donald E. Eastlake, 3rd 5123 Stellar Switches 5124 155 Beaver Street 5125 Milford, MA 01757 USA 5127 Phone: +1-508-634-2066 5128 Email: d3e3e3@gmail.com 5130 Dinesh G. Dutt 5131 Cisco Systems 5132 170 Tasman Drive 5133 San Jose, CA 95134-1706 USA 5135 Phone: +1-408-527-0955 5136 Email: ddutt@cisco.com 5138 Silvano Gai 5139 Cisco Systems 5140 2600 San Tomas Expressway 5141 Santa Clara, CA 95051 USA 5143 Phone: +1-408-387-6123 5144 Email: sgai@cisco.com 5146 Anoop Ghanwani 5147 Brocade Communications Systems 5148 1745 Technology Drive 5149 San Jose, CA 95110 USA 5151 Phone: +1-408-333-7149 5152 Email: anoop@brocade.com 5154 Copyright and IPR Provisions 5156 Copyright (c) 2010 IETF Trust and the persons identified as the 5157 document authors. All rights reserved. 5159 This document is subject to BCP 78 and the IETF Trust's Legal 5160 Provisions Relating to IETF Documents 5161 (http://trustee.ietf.org/license-info) in effect on the date of 5162 publication of this document. Please review these documents 5163 carefully, as they describe your rights and restrictions with respect 5164 to this document. Code Components extracted from this document must 5165 include Simplified BSD License text as described in Section 4.e of 5166 the Trust Legal Provisions and are provided without warranty as 5167 described in the BSD License. The definitive version of an IETF 5168 Document is that published by, or under the auspices of, the IETF. 5169 Versions of IETF Documents that are published by third parties, 5170 including those that are translated into other languages, should not 5171 be considered to be definitive versions of IETF Documents. The 5172 definitive version of these Legal Provisions is that published by, or 5173 under the auspices of, the IETF. Versions of these Legal Provisions 5174 that are published by third parties, including those that are 5175 translated into other languages, should not be considered to be 5176 definitive versions of these Legal Provisions. For the avoidance of 5177 doubt, each Contributor to the IETF Standards Process licenses each 5178 Contribution that he or she makes as part of the IETF Standards 5179 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 5180 language to the contrary, or terms, conditions or rights that differ 5181 from or are inconsistent with the rights and licenses granted under 5182 RFC 5378, shall have any effect and shall be null and void, whether 5183 published or posted by such Contributor, or included with or in such 5184 Contribution.