idnits 2.17.1 draft-ietf-trill-rbridge-protocol-15.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 2 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 (January 22, 2010) is 5198 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 Sun Microsystems 3 Intended status: Proposed Standard Donald Eastlake 3rd 4 Expires: July 21, 2010 Stellar Switches 5 Dinesh G. Dutt 6 Silvano Gai 7 Cisco Systems 8 Anoop Ghanwani 9 Brocade 10 January 22, 2010 12 RBridges: Base Protocol Specification 13 15 Status of This Document 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. This document may contain material 19 from IETF Documents or IETF Contributions published or made publicly 20 available before November 10, 2008. The person(s) controlling the 21 copyright in some of this material may not have granted the IETF 22 Trust the right to allow modifications of such material outside the 23 IETF Standards Process. Without obtaining an adequate license from 24 the person(s) controlling the copyright in such materials, this 25 document may not be modified outside the IETF Standards Process, and 26 derivative works of it may not be created outside the IETF Standards 27 Process, except to format it for publication as an RFC or to 28 translate it into languages other than English. 30 Distribution of this document is unlimited. Comments should be sent 31 to the TRILL working group mailing list . 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Abstract 51 RBridges provide optimal pair-wise forwarding without configuration, 52 safe forwarding even during periods of temporary loops, and support 53 for multipathing of both unicast and multicast traffic. They achieve 54 these goals using IS-IS routing and encapsulation of traffic with a 55 header that includes a hop count. 57 RBridges are compatible with previous IEEE 802.1 customer bridges as 58 well as IPv4 and IPv6 routers and end nodes. They are as invisible to 59 current IP routers as bridges are and, like routers, they terminate 60 the bridge spanning tree protocol. 62 The design supports VLANs and optimization of the distribution of 63 multi-destination frames based on VLAN and IP derived multicast 64 groups. It also allows unicast forwarding tables at transit RBridges 65 to be sized according to the number of RBridges (rather than the 66 number of end nodes), which allows their forwarding tables to be 67 substantially smaller than in conventional customer bridges. 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, James Carlson, Dino 76 Farinacci, Don Fedyk, Bill Fenner, Eric Gray, Joel Halpern, Andrew 77 Lange, Israel Meilik, David Melman, Nandakumar Natarajan, Erik 78 Nordmark, Jeff Pickering, Dan Romascanu, Sanjay Sane, Pekka 79 Savola, Matthew R. Thomas, Joe Touch, Mark Townsley, Kate Zebrose. 81 We invite you to join the mailing list at 82 http://www.postel.org/rbridge. 84 Table of Contents 86 Status of This Document....................................1 87 Abstract...................................................2 88 Acknowledgements...........................................2 90 1. Introduction............................................7 91 1.1 Algorhyme V2, by Ray Perlner...........................8 92 1.2 Normative Content and Precedence.......................8 93 1.3 Terminology and Notation in this document..............8 94 1.4 Categories of Layer 2 Frames...........................9 95 1.5 Acronyms..............................................10 97 2. RBridges...............................................12 98 2.1 General Overview......................................12 99 2.2 End Station Addresses.................................13 100 2.3 RBridge Encapsulation Architecture....................14 101 2.4 Forwarding Overview...................................16 102 2.4.1 Known-Unicast.......................................16 103 2.4.2 Multi-destination...................................17 104 2.5 RBridges and VLANs....................................18 105 2.5.1 Link VLAN Assumptions...............................18 106 2.6 RBridges and IEEE 802.1 Bridges.......................19 107 2.6.1 RBridge Ports and 802.1 Layering....................19 108 2.6.2 Incremental Deployment..............................21 110 3. Details of the TRILL Header............................22 111 3.1 TRILL Header Format...................................22 112 3.2 Version (V)...........................................22 113 3.3 Reserved (R)..........................................23 114 3.4 Multi-destination (M).................................23 115 3.5 TRILL Header Options..................................23 116 3.6 Hop Count.............................................24 117 3.7 RBridge Nicknames.....................................25 118 3.7.1 Egress RBridge Nickname.............................26 119 3.7.2 Ingress RBridge Nickname............................26 120 3.7.3 RBridge Nickname Selection..........................26 122 4. Other RBridge Design Details...........................29 123 4.1 Ethernet Data Encapsulation...........................29 124 4.1.1 VLAN Tag Information................................31 125 4.1.2 Inner VLAN Tag......................................32 126 4.1.3 Outer VLAN Tag......................................32 127 4.1.4 Frame Check Sequence (FCS)..........................33 128 4.2 Link State Protocol (IS-IS)...........................33 129 4.2.1 IS-IS RBridge Identity..............................33 130 4.2.2 IS-IS Instances.....................................34 131 4.2.3 TRILL IS-IS Frames..................................34 132 4.2.4 TRILL Link Hellos, DRBs, and Appointed Forwarders...35 133 4.2.4.1 P2P Hello Links...................................36 134 4.2.4.2 Designated RBridge................................36 136 Table of Contents Continued 138 4.2.4.3 Appointed VLAN-x Forwarder........................37 139 4.2.4.4 TRILL LSP Information.............................38 140 4.2.5 TRILL ESADI.........................................41 141 4.2.5.1 TRILL ESADI Participation.........................43 142 4.2.5.2 TRILL ESADI Information...........................43 143 4.2.6 SPF, Forwarding, and Ambiguous Destinations.........43 144 4.3 Inter-RBridge Link MTU Size...........................44 145 4.3.1 Determining Campus-Wide TRILL IS-IS MTU Size........44 146 4.3.2 Testing Link MTU Size...............................45 147 4.4 TRILL-Hello Protocol..................................46 148 4.4.1 Rationale...........................................46 149 4.4.2 TRILL-Hello Contents and Timing.....................47 150 4.4.2.1 TRILL Neighbor List...............................48 151 4.4.3 TRILL MTU probe and TRILL Hello VLAN Tagging........49 152 4.4.4 Multiple Ports on the Same Link.....................51 153 4.4.5 VLAN Mapping Within a Link..........................52 154 4.5 Distribution Trees....................................52 155 4.5.1 Distribution Tree Calculation.......................55 156 4.5.2 Multi-destination Frame Checks......................56 157 4.5.3 Pruning the Distribution Tree.......................58 158 4.5.4 Tree Distribution Optimization......................58 159 4.5.5 Forwarding Using a Distribution Tree................59 160 4.6 Frame Processing Behavior.............................60 161 4.6.1 Receipt of a Native Frame...........................61 162 4.6.1.1 Native Unicast Case...............................61 163 4.6.1.2 Native Multicast and Broadcast Frames.............62 164 4.6.2 Receipt of a TRILL Frame............................62 165 4.6.2.1 TRILL Control Frames..............................63 166 4.6.2.2 TRILL ESADI Frames................................63 167 4.6.2.3 TRILL Data Frames.................................64 168 4.6.2.4 Known Unicast TRILL Data Frames...................64 169 4.6.2.5 Multi-Destination TRILL Data Frames...............65 170 4.6.3 Receipt of a Layer 2 Control Frame..................66 171 4.7 IGMP, MLD, and MRD Learning...........................66 172 4.8 End Station Address Details...........................67 173 4.8.1 Learning End Station Addresses......................67 174 4.8.2 Forgetting End Station Addresses....................69 175 4.8.3 Shared VLAN Learning................................70 176 4.9 RBridge Ports.........................................71 177 4.9.1 RBridge Port Configuration..........................71 178 4.9.2 RBridge Port Structure..............................72 179 4.9.3 BPDU Handling.......................................74 180 4.9.3.1 Receipt of BPDUs..................................75 181 4.9.3.2 Root Bridge Changes...............................75 182 4.9.3.3 Transmission of BPDUs.............................76 183 4.9.4 Dynamic VLAN Registration...........................76 185 5. RBridge Configuration Parameters.......................77 186 5.1 Per RBridge...........................................77 188 Table of Contents Continued 190 5.2 Per Port..............................................77 191 5.3 Per VLAN..............................................78 193 6. Security Considerations................................80 194 6.1 VLAN Security Considerations..........................80 195 6.2 BPDU/Hello Denial of Service Considerations...........81 197 7. Assignment Considerations..............................83 198 7.1 IANA Considerations...................................83 199 7.2 IEEE Registration Authority Considerations............83 201 8. Normative References...................................84 202 9. Informative References.................................86 204 Appendix A: Incremental Deployment Considerations.........88 205 A.1 Link Cost Determination...............................88 206 A.2 Appointed Forwarders and Bridged LANs.................88 207 A.3 Wiring Closet Topology................................90 208 A.3.1 The RBridge Solution................................91 209 A.3.2 The VLAN Solution...................................91 210 A.3.3 The Spanning Tree Solution..........................91 211 A.3.4 Comparison of Solutions.............................92 213 Appendix B: Trunk and Access Port Configuration...........93 214 Appendix C: Multipathing..................................94 215 Appendix D: Determination of VLAN and Priority............96 217 Appendix E: Support of IEEE 802.1Q-2005 Amendments........97 218 E.1 Completed Amendments..................................97 219 E.2 In-process Amendments.................................98 221 Appendix Z: Revision History..............................99 222 Changes from -03 to -04...................................99 223 Changes from -04 to -05..................................100 224 Changes from -05 to -06..................................101 225 Changes from -06 to -07..................................101 226 Changes from -07 to -08..................................103 227 Changes from -08 to -09..................................104 228 Changes from -09 to -10..................................105 229 Changes from -10 to -11..................................106 230 Changes from -11 to -12..................................106 231 Changes from -12 to -13..................................107 232 Changes from -13 to -14..................................108 233 Changes from -14 to -15..................................110 235 Authors' Addresses.......................................112 236 Copyright and IPR Provisions.............................113 238 Table of Figures 240 Figure 2.1: Interconnected RBridges.......................15 241 Figure 2.2: An Ethernet Encapsulated TRILL Frame..........15 242 Figure 2.3: A PPP Encapsulated TRILL Frame................15 243 Figure 2.4: RBridge Port Model............................20 244 Figure 3.1: TRILL Header..................................22 245 Figure 3.2: Options Area Initial Flags Octet..............24 246 Figure 4.1: TRILL Data Encapsulation over Ethernet........30 247 Figure 4.2: VLAN Tag Information..........................31 248 Figure 4.3: TRILL IS-IS Frame Format......................35 249 Figure 4.4: TRILL ESADI Frame Format......................42 250 Figure 4.5: Detailed RBridge Port Model...................73 251 Figure A.1: Link Cost of a Bridged Link...................88 252 Figure A.2: Wiring Closet Topology........................90 253 Figure C.1: Multi-Destination Multipath...................94 254 Figure C.2: Known Unicast Multipath.......................95 256 1. Introduction 258 In traditional IPv4 and IPv6 networks, each subnet has a unique 259 prefix. Therefore, a node in multiple subnets has multiple IP 260 addresses, typically one per interface. This also means that when an 261 interface moves from one subnet to another, it changes its IP 262 address. Administration of IP networks is complicated because IP 263 routers require per port subnet address configuration. Careful IP 264 address management is required to avoid creating subnets that are 265 sparsely populated, wasting addresses. 267 IEEE 802.1 bridges avoid these problems by transparently gluing many 268 physical links into what appears to IP to be a single LAN [802.1D]. 269 However, 802.1 bridge forwarding using the spanning tree protocol has 270 some disadvantages: 272 o The spanning tree protocol works by blocking ports, limiting the 273 number of forwarding links, and therefore creates bottlenecks by 274 concentrating traffic onto selected links. 276 o Forwarding is not pair-wise shortest path, but is instead whatever 277 path remains after the spanning tree eliminates redundant paths. 279 o The Ethernet header does not contain a hop count (or TTL) field. 280 This is dangerous when there are temporary loops such as when 281 spanning tree messages are lost or components such as repeaters 282 are added. 284 o VLANs can partition when spanning tree reconfigures. 286 This document presents the design for RBridges (Routing Bridges 287 [RBridges]) that implement the TRILL protocol and are poetically 288 summarized below. Rbridges combine the advantages of bridges and 289 routers and, as specified in this document, are the application of 290 link state routing to the VLAN aware customer bridging problem. With 291 the exceptions discussed in this document, RBridges can incrementally 292 replace IEEE [802.1Q-2005] or [802.1D] customer bridges. 294 While RBridges can be applied to a variety of link protocols, this 295 specification focuses on IEEE [802.3] links. Use with other link 296 types is expected to be covered in other documents. 298 For further discussion of the problem domain addressed by RBridges 299 see [RFC5556]. 301 1.1 Algorhyme V2, by Ray Perlner 303 I hope that we shall one day see 304 A graph more lovely than a tree. 306 A graph to boost efficiency 307 While still configuration-free. 309 A network where RBridges can 310 Route packets to their target LAN. 312 The paths they find, to our elation, 313 Are least cost paths to destination! 315 With packet hop counts we now see, 316 The network need not be loop-free! 318 RBridges work transparently, 319 Without a common spanning tree. 321 1.2 Normative Content and Precedence 323 The bulk of the normative material in this specification appears in 324 Sections 1 through 4. In case of conflict between provisions in 325 these four sections, the provision in the higher numbered section 326 prevails. 328 1.3 Terminology and Notation in this document 330 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 331 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 332 document are to be interpreted as described in [RFC2119]. 334 "TRILL" is the protocol specified herein while an "RBridge" is a 335 device that implement that protocol. The second letter in Rbridge is 336 case insensitive. Both Rbridge and RBridge are correct. 338 In this document, the term "link", unless otherwise qualified, means 339 "bridged LAN", that is to say, the combination of one or more [802.3] 340 links with zero or more bridges, hubs, repeaters, or the like. The 341 term "simple link" or the like is used indicate a point-to-point or 342 multi-access link with no included bridges or RBridges. 344 In this document, the term "port", unless otherwise qualified, 345 includes physical, virtual [802.1AE], and pseudo [802.1X] ports. The 346 term "physical port" or the like is used to indicate the physical 347 point of connection between an RBridge and a link. 349 A "campus" is to RBridges as a "bridged LAN" is to bridges. An 350 RBridge campus consists of a network of RBridges, bridges, hubs, 351 repeaters, simple links, and the like and it is bounded by end 352 stations and routers. 354 The term "spanning tree" in this document includes both classic 355 spanning tree and rapid spanning tree (RSTP). 357 This document uses Hexadecimal Notation for MAC addresses. Two 358 hexadecimal digits represent each octet (that is, 8-bit byte), giving 359 the value of the octet as an unsigned integer. A hyphen separates 360 successive octets. This document consistently uses IETF bit ordering 361 although the physical order of bit transmission within an octet on an 362 IEEE [802.3] link is from the lowest order bit to the highest order 363 bit, the reverse. 365 1.4 Categories of Layer 2 Frames 367 In this document, Layer 2 frames are divided into five categories: 369 o layer 2 control frames (such as BPDUs) 370 o native frames (non-TRILL-encapsulated data frames) 371 o TRILL data frames (TRILL-encapsulated data frames) 372 o TRILL control frames 373 o TRILL other frames 375 The way these five types of frames are distinguished is as follows: 377 o Layer 2 control frames are those with a multicast destination 378 address in the range 01-80-C2-00-00-00 to 01-80-C2-00-00-0F or 379 equal to 01-80-C2-00-00-21. RBridges MUST NOT encapsulate and 380 forward such frames, though they MAY, unless otherwise 381 specified in this document, perform the layer 2 function (such 382 as MAC level security) of the control frame. Frames with a 383 destination address of 01-80-C2-00-00-00 (BPDU) or 384 01-80-C2-00-00-21 (VRP) are called "high level control frames" 385 in this document. All other layer 2 control frames are called 386 "low level control frames". 388 o Native frames are those that are not control frames and have an 389 Ethertype other than "TRILL" or "L2-IS-IS" and have a 390 destination MAC address that is not one of the 16 multicast 391 addresses reserved for TRILL. 393 o TRILL data frames have the Ethertype "TRILL". In addition, 394 TRILL data frames, if multicast, have the multicast destination 395 MAC address "All-RBridges". 397 o TRILL control frames have the Ethertype "L2-IS-IS". In 398 addition, TRILL control frames, if multicast, have the 399 multicast destination MAC addresses of "All-IS-IS-RBridges". 400 (Note that ESADI frames look on the outside like TRILL data and 401 are so handled but, when decapsulated, have the L2-IS-IS 402 Ethertype.) 404 o TRILL other frames are those with any of the 16 multicast 405 destination addresses reserved for TRILL other than All- 406 RBridges and All-IS-IS-RBridges. RBridges conformant to this 407 specification MUST discard TRILL other frames. 409 1.5 Acronyms 411 AllL1ISs - All Level 1 Intermediate Systems 413 AllL2ISs - All Level 2 Intermediate Systems 415 BPDU - Bridge PDU 417 CHbH - Critical Hop-by-Hop 419 CItE - Critical Ingress-to-Egress 421 CSNP - Complete Sequence Number PDU 423 DA - Destination Address 425 DR - Designated Router 427 DRB - Designated RBridge 429 EAP - Extensible Authentication Protocol 431 ECMP - Equal Cost Multi-Path 433 EISS - Extended Internal Sublayer Service 435 ESADI - End Station Address Distribution Information 437 FCS - Frame Check Sequence 439 GARP - Generic Attribute Registration Protocol 441 GVRP - GARP VLAN Registration Protocol 442 IEEE - Institute of Electrical and Electronics Engineers 444 IGMP - Internet Group Management Protocol 446 IP - Internet Protocol 448 IS-IS - Intermediate System to Intermediate System 450 ISS - Internal Sublayer Service 452 LAN - Local Area Network 454 LSP - Link State PDU 456 MAC - Media Access Control 458 MLD - Multicast Listener Discovery 460 MRD - Multicast Router Discovery 462 MTU - Maximum Transmission Unit 464 MVRP - Multiple VLAN Registration Protocol 466 NSAP - Network Service Access Point 468 P2P - Point-to-point 470 PDU - Protocol Data Unit 472 PPP - Point-to-Point Protocol 474 RBridge - Routing Bridge 476 RPF - Reverse Path Forwarding 478 SA - Source Address 480 SNMP - Simple Network Management Protocol 482 SPF - Shortest Path First 484 TLV - Type, Length, Value 486 TRILL - TRansparent Interconnection of Lots of Links 488 VLAN - Virtual Local Area Network 490 VRP - VLAN Registration Protocol 492 2. RBridges 494 This section provides a high-level overview of RBridges, which 495 implement the TRILL protocol, omitting some details. Sections 3 and 4 496 below provide more detailed specifications. 498 TRILL, as described in this document and with the exceptions 499 discussed herein, provides [802.1Q-2005] VLAN aware customer bridging 500 service. As described below, TRILL is layered above the ports of an 501 RBridge. 503 The RBridges specified by this document do not supply provider 504 [802.1ad] or provider backbone [802.1ah] bridging or the like. The 505 extension of TRILL to provide such provider services is left for 506 future work that will be separately documented. However, provider or 507 provider backbone bridges may be used to interconnect parts of an 508 RBridge campus. 510 2.1 General Overview 512 RBridges run a link state protocol amongst themselves. This gives 513 them enough information to compute pair-wise optimal paths for 514 unicast, and calculate distribution trees for delivery of frames 515 either to destinations whose location is unknown or to multicast / 516 broadcast groups. [RBridges] [RP1999] 518 To mitigate temporary loop issues, RBridges forward based on a header 519 with a hop count. RBridges also specify the next hop RBridge as the 520 frame destination when forwarding unicast frames across a shared- 521 media link, which avoids spawning additional copies of frames during 522 a temporary loop. A Reverse Path Forwarding Check and other checks 523 are performed on multi-destination frames to further control 524 potentially looping traffic (see Section 4.5.2). 526 The first RBridge that a unicast frame encounters in a campus, RB1, 527 encapsulates the received frame with a TRILL header that specifies 528 the last RBridge, RB2, where the frame is decapsulated. RB1 is known 529 as the "ingress RBridge" and RB2 is known as the "egress RBridge". 530 To save room in the TRILL header and simplify forwarding lookups, a 531 dynamic nickname acquisition protocol is run among the RBridges to 532 select 2-octet nicknames for RBridges, unique within the campus, 533 which are an abbreviation for the 6-octet IS-IS system ID of the 534 RBridge. The 2-octet nicknames are used to specify the ingress and 535 egress RBridges in the TRILL header. 537 Multipathing of multi-destination frames through alternative 538 distribution tree roots and ECMP (Equal Cost MultiPath) of unicast 539 frames are supported (see Appendix C). 541 Networks with a more mesh-like structure will benefit to a greater 542 extent from the multipathing and optimal paths provided by TRILL than 543 will more tree-like networks. 545 RBridges run a protocol on a link to elect a "Designated RBridge" 546 (DRB). The TRILL-IS-IS election protocol on a link is a little 547 different from the IS-IS [ISO10589] election protocol, because in 548 TRILL it is essential that only one RBridge be elected DRB, whereas 549 in layer 3 IS-IS it is possible for multiple routers to be elected 550 Designated Router (also known as Designated Intermediate System). As 551 with an IS-IS router, the DRB may give a pseudonode name to the link, 552 issue an LSP (Link State PDU) on behalf of the pseudonode, and issues 553 CSNPs (Complete Sequence Number PDUs) on the link. Additionally, the 554 DRB has some TRILL-specific duties, including specifying which VLAN 555 will be the Designated VLAN used for communication between RBridges 556 on that link (see Section 4.2.4.2). 558 The DRB either encapsulates / decapsulates all data traffic to/from 559 the link, or, for load splitting, delegates this responsibility, for 560 one or more VLANs, to other RBridges on the link. There must at all 561 times be at most one RBridge on the link that encapsulates / 562 decapsulates traffic for a particular VLAN. We will refer to the 563 RBridge appointed to forward VLAN-x traffic on behalf of the link as 564 the "appointed VLAN-x forwarder" (see Section 4.2.4.3). (Section 2.5 565 discusses VLANs further.) 567 Rbridges SHOULD support SNMPv3 [RFC3411]. The Rbridge MIB will be 568 specified in a separate document. If IP service is available to an 569 RBridge, it SHOULD support SNMPv3 over UDP over IPv4 [RFC3417] and 570 IPv6 [RFC3419]; however, management can be used, within a campus, 571 even for an RBridge that lacks an IP or other Layer 3 transport stack 572 or which does not have a Layer 3 address, by transporting SNMP with 573 Ethernet [RFC4789]. 575 2.2 End Station Addresses 577 An RBridge, RB1, which is the VLAN-x forwarder on any of its links 578 MUST learn the location of VLAN-x end nodes, both on the links for 579 which it is VLAN-x forwarder, and on other links in the campus. RB1 580 learns the port, VLAN, and Layer 2 (MAC) addresses of end nodes on 581 links for which it is VLAN-x forwarder from the source address of 582 frames received, as bridges do (for example, see section 8.7 of 583 [802.1Q-2005]), or through configuration or a Layer 2 explicit 584 registration protocol such as IEEE 802.11 association and 585 authentication. RB1 learns the VLAN and Layer 2 address of distant 586 VLAN-x end nodes, and the corresponding RBridge to which they are 587 attached, by looking at the ingress RBridge nickname in the TRILL 588 header and the VLAN and source MAC address of the inner frame of 589 TRILL data frames that it decapsulates. 591 Additionally, an RBridge that is the appointed VLAN-x forwarder on 592 one or more links MAY use the End Station Address Distribution 593 Information (ESADI) protocol to announce some or all of the attached 594 VLAN-x end nodes on those links. 596 An ESADI could be used to announce end nodes that have been 597 explicitly enrolled. Such information might be more authoritative 598 than that learned from data frames being decapsulated onto the link. 599 Also, the addresses enrolled and distributed in this way can be more 600 secure for two reasons: (1) the enrollment might be authenticated 601 (for example by cryptographically based EAP methods via [802.1X]), 602 and (2) ESADI also supports cryptographic authentication of its 603 messages [RFC5304] for more secure transmission. 605 If an end station is unplugged from one RBridge and plugged into 606 another then, depending on circumstances, frames addressed to that 607 end station can be black holed. This is, they can be sent just to the 608 older RBridge that the end station used to be connected to until 609 cached address information at some remote RBridge(s) times out, 610 possibly for a number of minutes or longer. With ESADI, the link 611 interruption from the unplugging can cause an immediate update to be 612 sent. 614 Even if an ESADI is used to announce or learn attached end nodes, 615 RBridges MUST still learn from received native frames and 616 decapsulated TRILL data frames unless configured not to do so. 617 Advertising end nodes using ESADI is optional, as is learning from 618 these announcements. 620 (See Section 4.8 for further end station address details.) 622 2.3 RBridge Encapsulation Architecture 624 The Layer 2 technology used to connect Rbridges may be either IEEE 625 [802.3] or some other link technology such as PPP [RFC1661]. This is 626 possible since the RBridge relay function is layered on top of the 627 Layer 2 technologies. However, this document specifies only an IEEE 628 802.3 encapsulation. 630 Figure 2.1 shows two RBridges, RB1 and RB2, interconnected through an 631 Ethernet cloud. The Ethernet cloud may include hubs, point-to-point 632 or shared media, IEEE 802.1D bridges, or 802.1Q bridges. 634 ------------ 635 / \ 636 +-----+ / Ethernet \ +-----+ 637 | RB1 |----< >---| RB2 | 638 +-----+ \ Cloud / +-----+ 639 \ / 640 ------------ 642 Figure 2.1: Interconnected RBridges 644 Figure 2.2 shows the format of a TRILL data or ESADI frame traveling 645 through the Ethernet cloud between RB1 and RB2. 647 +--------------------------------+ 648 | Outer Ethernet Header | 649 +--------------------------------+ 650 | TRILL Header | 651 +--------------------------------+ 652 | Inner Ethernet Header | 653 +--------------------------------+ 654 | Ethernet Payload | 655 +--------------------------------+ 656 | Ethernet FCS | 657 +--------------------------------+ 659 Figure 2.2: An Ethernet Encapsulated TRILL Frame 661 In the case of media different from Ethernet, the header specific to 662 that media replaces the outer Ethernet header. For example, Figure 663 2.3 shows a TRILL encapsulation over PPP. 665 +--------------------------------+ 666 | PPP Header | 667 +--------------------------------+ 668 | TRILL Header | 669 +--------------------------------+ 670 | Inner Ethernet Header | 671 +--------------------------------+ 672 | Ethernet Payload | 673 +--------------------------------+ 674 | Ethernet FCS | 675 +--------------------------------+ 677 Figure 2.3: A PPP Encapsulated TRILL Frame 679 The outer header is link-specific and, although this document 680 specifies only [802.3] links, other links are allowed. 682 In both cases the Inner Ethernet Header and the Ethernet Payload come 683 from the original frame and are encapsulated with a TRILL Header as 684 they travel between RBridges. Use of a TRILL header offers the 685 following benefits: 687 1. loop mitigation through use of a hop count field; 689 2. elimination of the need for end station VLAN and MAC address 690 learning in transit RBridges; 692 3. direction of unicast frames towards the egress RBridge (this 693 enables unicast forwarding tables of transit RBridges to be sized 694 with the number of RBridges rather than the total number of end 695 nodes); and, 697 4. provision of a separate VLAN tag for forwarding traffic between 698 RBridges, independent of the VLAN of the native frame. 700 When forwarding unicast frames between RBridges, the outer header has 701 the MAC destination address of the next hop Rbridge, to avoid frame 702 duplication if the inter-RBridge link is multi-access. Having the 703 outer header specify the transmitting RBridge as source address 704 ensures that any bridges inside the Ethernet cloud will not get 705 confused, as they might be if multipathing is in use and they were to 706 see the original source or ingress RBridge in the outer header. 708 2.4 Forwarding Overview 710 RBridges are true routers in the sense that, in the forwarding of a 711 frame by a transit RBridge, the outer layer 2 header is replaced at 712 each hop with an appropriate layer 2 header for the next hop, and a 713 hop count is decreased. Despite these modifications of the outer 714 layer 2 header and the hop count in the TRILL Header, the original 715 encapsulated frame is preserved, including the original frame's VLAN 716 tag. See Section 4.6 for more details. 718 From a forwarding standpoint, transit frames may be classified into 719 two categories: known-unicast and multi-destination. Layer 2 control 720 frames and TRILL control and TRILL other frames are not transit 721 frames, are not forwarded by RBridges, and are not included in these 722 categories. 724 2.4.1 Known-Unicast 726 These frames have a unicast inner MAC destination address 727 (Inner.MacDA) and are those for which ingress RBridge knows the 728 egress RBridge for the destination MAC address in the frame's VLAN. 730 Such frames are forwarded Rbridge hop by Rbridge hop to their egress 731 Rbridge. 733 2.4.2 Multi-destination 735 These are frames that must be delivered to multiple destinations. 737 Multi-destination frames include the following: 739 1. unicast frames for which the location of the destination is 740 unknown: the Inner.MacDA is unicast, but the ingress RBridge does 741 not know its location in the frame's VLAN; 743 2. multicast frames for which the Layer 2 destination address is 744 derived from an IP multicast address: the Inner.MacDA is 745 multicast, from the set of Layer 2 multicast addresses derived 746 from IPv4 [RFC1112] or IPv6 [RFC2464] multicast addresses; these 747 frames are handled somewhat differently in different subcases: 749 2.1 IGMP [RFC3376] and MLD [RFC2710] multicast group membership 750 reports; 752 2.2 IGMP [RFC3376] and MLD [RFC2710] queries and MRD [RFC4286] 753 announcement messages; 755 2.3 other IP derived Layer 2 multicast frames; 757 3. multicast frames for which the Layer 2 destination address is not 758 derived from an IP multicast address: the Inner.MacDA is 759 multicast, and not from the set of Layer 2 multicast addresses 760 derived from IPv4 or IPv6 multicast addresses; 762 4. broadcast frames: the Inner.MacDA is broadcast (FF-FF-FF-FF-FF- 763 FF). 765 RBridges build distribution trees (see Section 4.5) and use these 766 trees for forwarding multi-destination frames. Each distribution tree 767 reaches all RBridges in the campus, is shared across all VLANs, and 768 may be used for the distribution of a native frame that was in any 769 VLAN. However, the distribution of any particular frame on a 770 distribution tree is pruned in different ways for different cases to 771 avoid unnecessary propagation of the frame. 773 2.5 RBridges and VLANs 775 A VLAN is a way to partition end nodes in a campus into different 776 Layer 2 communities [802.1Q-2005]. Use of VLANs requires 777 configuration. By default, the port of receipt determines the VLAN 778 of a frame sent by an end station. End stations can also explicitly 779 insert this information in a frame. 781 IEEE [802.1Q-2005] bridges can be configured to support multiple 782 customer VLANs over a single simple link by inserting / removing a 783 VLAN tag in the frame. VLAN tags used by TRILL have the same format 784 as VLAN tags defined in IEEE [802.1Q-2005]. As shown in Figure 2.2 785 there are two places where such tags may be present in a TRILL- 786 encapsulated frame sent over an IEEE [802.3] link: one in the outer 787 header (Outer.VLAN) and one in the inner header (Inner.VLAN). Inner 788 and outer VLANs are further discussed in Section 4.1. 790 RBridges enforce delivery of a native frame originating in a 791 particular VLAN only to other links in the same VLAN; however, there 792 are a few differences in the handling of VLANs between an RBridge 793 campus and an 802.1 bridged LAN as described below. 795 (See Section 4.2.4 for further discussion of TRILL IS-IS operation on 796 a link.) 798 2.5.1 Link VLAN Assumptions 800 Certain configurations of bridges may cause partitions of a VLAN on a 801 link. In that case, a frame sent by one RBridge to a neighbor on that 802 link, might not arrive, if tagged with a VLAN that is partitioned due 803 to bridge configuration. 805 TRILL requires at least one VLAN per link that gives full 806 connectivity to all the RBridges on that link. The default VLAN is 1, 807 though RBridges may be configured to use a different VLAN. The DRB 808 dictates to the other RBridges which VLAN to use. 810 Since there will be only one appointed forwarder for any VLAN, say 811 VLAN-x, on a link, if bridges are configured to cause VLAN-x to be 812 partitioned on a link, some VLAN-x end nodes on that link may be 813 orphaned (unable to communicate with the rest of the campus). 815 It is possible for bridge and port configuration to cause VLAN 816 mapping on a link (where a VLAN-x frame turns into a VLAN-y frame). 817 TRILL detects this by inserting a copy of the outer VLAN into TRILL- 818 Hello messages and checking it on receipt. If detected, it takes 819 steps to ensure that there is at most a single appointed forwarder on 820 the link, to avoid possible frame duplication or loops (see Section 821 4.4.5). 823 TRILL behaves as conservatively as possible, avoiding loops rather 824 than avoiding partial connectivity. As a result, lack of connectivity 825 may result from bridge or port misconfiguration. 827 2.6 RBridges and IEEE 802.1 Bridges 829 RBridge ports are, except as described below, layered on top of IEEE 830 [802.1Q-2005] port facilities. 832 2.6.1 RBridge Ports and 802.1 Layering 834 RBridge ports make use of [802.1Q-2005] port VLAN and priority 835 processing. In addition, they MAY implement other lower level 802.1 836 protocols as well as protocols for the link in use, such as PAUSE 837 (Annex 31B of [802.3]), port based access control [802.1X], MAC 838 security [802.1AE], or link aggregation [802.1AX]. 840 However, RBridges do not use spanning tree and do not block ports as 841 spanning tree does. Figure 2.4 shows a high-level diagram of an 842 RBridge with one port connected to an IEEE 802.3 link. Single lines 843 represent the flow of control information, double lines the flow of 844 both frames and control information. 846 +----------------------------------------- 847 | RBridge 848 | 849 | Forwarding Engine, IS-IS, Etc. 850 | Processing of native and TRILL frames 851 | 852 +----+---+--------++---------------------- 853 | | || other ports... 854 +-------------+ | || 855 | | || 856 +------------+-------------+ | || 857 | RBridge | | +----++-------+ <- EISS 858 | | | | | 859 | High-level Control Frame | | | 802.1Q-2005 | 860 | Processing (BPDU, VRP) | | | Port VLAN | 861 | | | | & Priority | 862 +-----------++-------------+ | | Processing | 863 || | | | 864 +---------++-----------------+---+-------------+ <-- ISS 865 | | 866 | 802.1/802.3 Low Level Control Frame | 867 | Processing, Port/Link Control Logic | 868 | | 869 +-----------++---------------------------------+ 870 || 871 || +------------+ 872 || | 802.3 PHY | 873 |+--------+ (Physical +--------- 802.3 874 +---------+ Interface) +--------- Link 875 | | 876 +------------+ 878 Figure 2.4: RBridge Port Model 880 The upper interface to the low-level port / link control logic 881 corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005]. 882 In RBridges, high-level control frames are processed above the ISS 883 interface. 885 The upper interface to the port VLAN and priority processing 886 corresponds to the Extended Internal Sublayer Service (EISS) in 887 [802.1Q-2005]. In RBridges, native and TRILL frames are processed 888 above the EISS interface and are subject to port VLAN and priority 889 processing. 891 2.6.2 Incremental Deployment 893 Because RBridges are compatible with IEEE [802.1Q-2005] customer 894 bridges, except as discussed in this document, a bridged LAN can be 895 upgraded by incrementally replacing such bridges with RBridges. 896 Bridges that have not yet been replaced are transparent to RBridge 897 traffic. The physical links directly interconnected by such bridges, 898 together with the bridges themselves, constitute bridged LANs. These 899 bridged LANs appear to RBridges to be multi-access links. 901 If the bridges replaced by RBridges were default configuration 902 bridges, then their RBridge replacements will not require 903 configuration. 905 Because RBridges, as described in this document, only provide 906 customer services, they cannot replace provider bridges or provider 907 backbone bridges, just as a customer bridge can't replace a provider 908 bridge. However, such provider devices can be part of the bridged LAN 909 between RBridges. Extension of TRILL to support provider services is 910 left for future work and will be separately documented. 912 Of course, if the bridges replaced had any port level protocols 913 enabled, such as port based access control [802.1X] or MAC security 914 [802.1AE], replacement RBridges would need the same port level 915 protocols enabled and similarly configured. In addition, the 916 replacement RBridges would have to support the same link type and 917 link level protocols as the replaced bridges. 919 An RBridge campus will work best if all IEEE [802.1D] and 920 [802.1Q-2005] bridges are replaced with RBridges, assuming the 921 RBridges have the same speed and capacity as the bridges. However, 922 there may be intermediate states, where only some bridges have been 923 replaced by RBridges, with inferior performance. 925 See Appendix A for further discussion of incremental deployment. 927 3. Details of the TRILL Header 929 This section specifies the TRILL header. Section 4 below provides 930 other RBridge design details. 932 3.1 TRILL Header Format 934 The TRILL header is shown in Figure 3.1 and is independent of the 935 data link layer used. When that layer is IEEE [802.3], it is prefixed 936 with the 16-bit TRILL Ethertype [RFC5342], making it 64 bit aligned. 938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 939 | V | R |M|Op-Length| Hop Count | 940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 | Egress RBridge Nickname | Ingress RBridge Nickname | 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 Figure 3.1: TRILL Header 946 The header contains the following fields that are described in the 947 sections referenced: 949 o V (Version): 2-bit unsigned integer. See Section 3.2. 951 o R (Reserved): 2 bits. See Section 3.3. 953 o M (Multi-destination): 1 bit. See Section 3.4. 955 o Op-Length (Options Length): 5-bit unsigned integer. See Section 956 3.5. 958 o Hop Count: 6-bit unsigned integer. See Section 3.6. 960 o Egress RBridge Nickname: 16-bit identifier. See Section 3.7.1. 962 o Ingress RBridge Nickname: 16-bit identifier. See Section 3.7.2. 964 3.2 Version (V) 966 Version (V) is a two-bit field. Version zero of TRILL is specified in 967 this document. An RBridge RB1 MUST check the V field in a received 968 TRILL-encapsulated frame. If the V field has a value not recognized 969 by RB1, then RB1 MUST silently discard the frame. 971 3.3 Reserved (R) 973 The two R bits are reserved for future use in extensions to this 974 version zero of the TRILL protocol. They MUST be set to zero when the 975 TRILL header is added by an ingress RBridge, transparently copied but 976 otherwise ignored by transit RBridges, and ignored by egress 977 RBridges. 979 3.4 Multi-destination (M) 981 The Multi-destination bit (see Section 2.4.2) indicates that the 982 frame is to be delivered to a class of destination end stations via a 983 distribution tree and that the egress RBridge nickname field 984 specifies the root for this tree. In particular: 986 o M = 0 (FALSE) - The egress RBridge nickname contains a nickname of 987 the egress Rbridge for a known unicast TRILL data frame; 989 o M = 1 (TRUE) - The egress RBridge nickname field contains a 990 nickname that is the root of a distribution tree. This nickname 991 is selected by the ingress RBridge for a TRILL data frame or by 992 the source RBridge for a TRILL ESADI frame. 994 3.5 TRILL Header Options 996 There are provisions to express in the TRILL Header that a frame is 997 using an optional capability and to encode information into the 998 header in connection with that capability. 1000 The Op-Length header field gives the length of the expressed options 1001 in units of 4 octets, which allows up to 124 octets of options area. 1002 If Op-Length is zero there are no options present. If options are 1003 present, they follow immediately after the Ingress Rbridge Nickname 1004 field. 1006 All Rbridges MUST be able to skip the number of 4-octet chunks 1007 indicated by the Op-Length field in order to find the inner frame, 1008 since RBridges must be able to find the destination MAC address and 1009 VLAN tag in the inner frame. (Transit RBridges need such information 1010 to filter VLANs, IP multicast, and the like. Egress Rbridges need to 1011 find the inner header to correctly decapsulate and handle the inner 1012 frame.) 1014 To ensure backward compatible safe operation, when Op-Length is non- 1015 zero indicating that options are present, the top two bits of the 1016 first octet of the options area are specified as follows: 1018 +------+------+----+----+----+----+----+----+ 1019 | CHbH | CItE | Reserved | 1020 +------+------+----+----+----+----+----+----+ 1022 Figure 3.2: Options Area Initial Flags Octet 1024 If the CHbH (Critical Hop by Hop) bit is one, one or more critical 1025 hop-by-hop options are present. Transit RBridges that do not support 1026 one of the critical hop-by-hop options present, for example an 1027 RBridge that supported no options, MUST drop the frame. If the CHbH 1028 bit is zero, the frame is safe, from the point of view of options 1029 processing, for a transit RBridge to forward, regardless of what 1030 options that RBridge does or does not support. A transit RBridge that 1031 supports none of the options present MUST transparently forward the 1032 options area when it forwards a frame. 1034 If the CItE (Critical Ingress to Egress) bit is a one, one or more 1035 critical ingress-to-egress options are present. If it is zero, no 1036 such options are present. If either CHbH or CItE is non-zero, egress 1037 RBridges that don't support any critical option present, for example 1038 an RBridge that supports no options, MUST drop the frame. If both 1039 CHbH and CItE are zero, the frame is safe, from the point of view of 1040 options, for any egress RBridge to process, regardless of what 1041 options that RBridge does or does not support. 1043 Options, including the meaning of the bits labeled as Reserved in 1044 Figures 3.2, will be further specified in other documents and are 1045 expected to include provisions for hop-by-hop and ingress-to-egress 1046 options as well as critical and non-critical options. 1048 Note: Most RBridge implementations are expected to be optimized for 1049 the simplest and most common cases of frame forwarding and 1050 processing. The inclusion of options may and the inclusion of 1051 complex or lengthy options likely will cause frame processing 1052 using a "slow path" with inferior performance to "fast path" 1053 processing. Limited slow path throughput may cause such frames to 1054 be discarded. 1056 3.6 Hop Count 1058 The Hop Count field is a 6-bit unsigned integer. An Rbridge drops 1059 frames received with a hop count of zero, otherwise it decrements the 1060 hop count. (This behavior is different from IPv4 and IPv6 in order 1061 to support the later addition of a traceroute-like facility that 1062 would be able to get a hop count exceeded from an egress RBridge.) 1064 For known unicast frames, the ingress RBridge SHOULD set the Hop 1065 Count in excess of the number of RBridge hops it expects to the 1066 egress RBridge to allow for alternate routing later in the path. 1068 For multi-destination frames, the Hop Count SHOULD be set by the 1069 ingress RBridge (or source RBridge for a TRILL ESADI frame) to at 1070 least the expected number of hops to the most distant RBridge. To 1071 accomplish this, RBridge RBn calculates, for each branch from RBn of 1072 the specified distribution tree rooted at RBi, the maximum number of 1073 hops in that branch. 1075 Multi-destination frames are of particular danger because a loop 1076 involving one or more distribution tree forks could result in the 1077 rapid generation of multiple copies of the frame, even with the 1078 normal TTL mechanism. It is for this reason that multi-destination 1079 frames are subject to a stringent Reverse Path Forwarding Check and 1080 other checks as described in Section 4.5.2. As an optional additional 1081 traffic control measure, when forwarding a multi-destination frame 1082 onto a distribution tree branch, transit RBridge RBm MAY decrease the 1083 hop count by more than 1 unless decreasing the hop count by more than 1084 1 would result in a Hop Count insufficient to reach all destinations 1085 in that branch of the tree rooted at RBi. Using a Hop Count close or 1086 equal to the minimum needed on multi-destination frames provides 1087 additional protection against problems with temporary loops when 1088 forwarding. 1090 Although the RBridge MAY decrease the hop count of multi-destination 1091 frames by more than 1, under the circumstances described above, the 1092 RBridge forwarding a frame MUST decrease the hop count by at least 1, 1093 and discards the frame if it cannot do so because the hop count is 0. 1094 The option to decrease the hop count by more than 1 under the 1095 circumstances described above applies only to multi-destination 1096 frames, not to known unicast frames. 1098 3.7 RBridge Nicknames 1100 Nicknames are 16-bit dynamically assigned quantities that act as 1101 abbreviations for RBridge's 48-bit IS-IS System ID to achieve a more 1102 compact encoding and can be used to specify potentially different 1103 trees with the same root. This assignment allows specifying up to 1104 2**16 RBridges; however, the value 0x0000 is reserved to indicate 1105 that a nickname is not specified, the values 0xFFC0 through 0xFFFE 1106 are reserved for future specification, and the value 0xFFFF is 1107 permanently reserved. RBridges piggyback a nickname acquisition 1108 protocol on the link state protocol (see Section 3.7.3) to acquire 1109 one or more nicknames unique within the campus. 1111 3.7.1 Egress RBridge Nickname 1113 There are two cases for the contents of the egress RBridge nickname 1114 field, depending on the M-bit (see Section 3.4). The nickname is 1115 filled in by the ingress RBridge for TRILL data frames and by the 1116 source RBridge for TRILL ESADI frames. 1118 o For known unicast TRILL data frames, M == 0 and the egress RBridge 1119 nickname field specifies the egress RBridge, that is, it specifies 1120 the RBridge that needs to remove the TRILL encapsulation and 1121 forward the native frame. Once the egress nickname field is set, 1122 it MUST NOT be changed by any subsequent transit RBridge. 1124 o For multi-destination TRILL data frames and for TRILL ESADI 1125 frames, M == 1. The egress RBridge nickname field contains a 1126 nickname specifying the distribution tree selected to be used to 1127 forward the frame. This root nickname MUST NOT be changed by 1128 transit RBridges. 1130 3.7.2 Ingress RBridge Nickname 1132 The ingress RBridge nickname is set to a nickname of the ingress 1133 RBridge for TRILL data frames and to a nickname of the source RBridge 1134 for TRILL ESADI frames. If the RBridge setting the ingress nickname 1135 has multiple nicknames, it SHOULD use the same nickname in the 1136 ingress field whenever it encapsulates a frame with any particular 1137 Inner.MacSA and Inner.VLAN value. This simplifies end node learning. 1139 Once the ingress nickname field is set, it MUST NOT be changed by any 1140 subsequent transit RBridge. 1142 3.7.3 RBridge Nickname Selection 1144 The nickname selection protocol is piggybacked on TRILL IS-IS as 1145 follows: 1147 o The nickname or nicknames being used by an RBridge are carried in 1148 an IS-IS TLV (type-length-value data element) along with a 1149 priority of use value. Each RBridge chooses its own nickname or 1150 nicknames. 1152 o Nickname values MAY be configured. An RBridge that has been 1153 configured with one or more nickname values will have priority for 1154 those nickname values over all Rbridges with non-configured 1155 nicknames. 1157 o The nickname value 0x0000 and the values from 0xFFC0 through 1158 0xFFFF are reserved and MUST NOT be selected by or configured for 1159 an RBridge. The value 0x0000 is used to indicate that a nickname 1160 is not known. 1162 o The priority of use field reported with a nickname is an unsigned 1163 8-bit value, where the most significant bit (0x80) indicates that 1164 the nickname value was configured. The bottom 7 bits have the 1165 default value 0x40, but MAY be configured to be some other value. 1166 Additionally, an RBridge MAY increase its priority after holding a 1167 nickname for some amount of time. However, the most significant 1168 bit of the priority MUST NOT be set unless the nickname value was 1169 configured. 1171 o Once an RBridge has successfully acquired a nickname it SHOULD 1172 attempt to reuse it in the case of a reboot. 1174 o Each RBridge is responsible for ensuring that its nickname or each 1175 of its nicknames is unique. If RB1 chooses nickname x, and RB1 1176 discovers, through receipt of an LSP for RB2 at any later time, 1177 that RB2 has also chosen x, then the RBridge with the numerically 1178 higher priority keeps the nickname, or if there is a tie in 1179 priority, the RBridge with the numerically higher IS-IS System ID 1180 keeps the nickname, and the other RBridge MUST select a new 1181 nickname. This can require an RBridge with a configured nickname 1182 to select a replacement nickname. 1184 o To minimize the probability of nickname collisions, an RBridge 1185 selects a nickname randomly from the apparently available 1186 nicknames, based on its copy of the link state. This random 1187 selection can be by the RBridge hashing some of its parameters, 1188 e.g., SystemID, time and date, and other entropy sources, such as 1189 those given in [RFC4086], each time or by the RBridge using such 1190 hashing to create a seed and making any selections based on 1191 pseudo-random numbers generated from that seed [RFC4086]. The 1192 random numbers or seed and the algorithm used SHOULD make 1193 uniformly distributed selections over the available nicknames. 1194 Convergence to a nickname-collision free campus is accelerated by 1195 selecting new nicknames only from those that appear to be 1196 available and by having the highest priority nickname involved in 1197 a nickname conflict retain its value. There is no reason for all 1198 Rbridges to use the same algorithm for selecting nicknames. 1200 o If two RBridge campuses merge, then transient nickname collisions 1201 are possible. As soon as each RBridge receives the LSPs from the 1202 other RBridges, the RBridges that need to change nicknames select 1203 new nicknames that do not, to the best of their knowledge, collide 1204 with any existing nicknames. Some RBridges may need to change 1205 nicknames more than once before the situation is resolved. 1207 o To minimize the probability of a new RBridge usurping a nickname 1208 already in use, an RBridge SHOULD wait to acquire the link state 1209 database from a neighbor before it announces any nicknames that 1210 were not configured. 1212 o An RBridge by default has only a single nickname but MAY be 1213 configured to request multiple nicknames. Each such nickname could 1214 be the root of a shortest path tree from the RBridge but, since 1215 the tree number is used in tie breaking when there are multiple 1216 equal cost paths (see Section 4.5.1), the trees for the different 1217 nicknames will likely utilize different links. Because of the 1218 potential tree computation load it imposes, this capability to 1219 request multiple nicknames should be used sparingly, at a few 1220 RBridges that, because of campus topology, are particularly good 1221 places from which to calculate multiple different shortest path 1222 distribution trees. Such trees need separate nicknames so traffic 1223 can be multipathed across them. 1225 If it is desired for a pseudonode to be a tree root, the DRB MAY 1226 request one or more nicknames in the pseudonode LSP. 1228 4. Other RBridge Design Details 1230 Section 3 above specifies the TRILL header, while this Section 1231 specifies other RBridge design details. 1233 4.1 Ethernet Data Encapsulation 1235 TRILL data and ESADI frames in transit on Ethernet links are 1236 encapsulated with an outer Ethernet header (see Figure 2.2). This 1237 outer header looks, to a bridge on the path between two RBridges, 1238 like the header of a regular Ethernet frame and therefore bridges 1239 forward the frame as they normally would. To enable RBridges to 1240 distinguish such TRILL frames, a new TRILL Ethertype (see Section 1241 7.2) is used in the outer header. 1243 Figure 4.1 details a TRILL data frame with an outer VLAN tag 1244 traveling on an Ethernet link as shown at the top of the Figure, that 1245 is, between transit RBridges RB3 and RB4. The native frame originated 1246 at end station ESa, was encapsulated by ingress RBridge RB1 and will 1247 ultimately be decapsulated by egress RBridge RB2 and delivered to 1248 destination end station ESb. The encapsulation shown has the 1249 advantage, in the absence of TRILL options, of aligning the original 1250 Ethernet frame at a 64-bit boundary. 1252 When a TRILL data frame is carried over an Ethernet cloud it has 1253 three pairs of addresses: 1255 o Outer Ethernet Header: Outer Destination MAC Address (Outer.MacDA) 1256 and Outer Source MAC Address (Outer.MacSA): These addresses are 1257 used to specify the next hop RBridge and the transmitting RBridge, 1258 respectively. 1260 o TRILL Header: Egress Nickname and Ingress Nickname. These specify 1261 nickname values of the egress and ingress RBridges, respectively, 1262 unless the frame is multi-destination, in which case the Egress 1263 Nickname specifies the root of the distribution tree on which the 1264 frame is being sent. 1266 o Inner Ethernet Header: Inner Destination MAC Address (Inner.MacDA) 1267 and Inner Source MAC Address (Inner.MacSA): These addresses are as 1268 transmitted by the original end station, specifying, respectively, 1269 the destination and source of the inner frame. 1271 A TRILL data frame also potentially has two VLAN tags, as discussed 1272 in Sections 4.1.2 and 4.1.3 below, that can carry two different VLAN 1273 Identifiers and specify priority. 1275 Flow: 1276 +-----+ +-------+ +-------+ +-------+ +-------+ +----+ 1277 | ESa +--+ RB1 +---+ RB3 +-------+ RB4 +---+ RB2 +--+ESb | 1278 +-----+ |ingress| |transit| ^ |transit| |egress | +----+ 1279 +-------+ +-------+ | +-------+ +-------+ 1280 | 1281 Outer Ethernet Header: | 1282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1283 | Outer Destination MAC Address (RB4) | 1284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 | Outer Destination MAC Address | Outer Source MAC Address | 1286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1287 | Outer Source MAC Address (RB3) | 1288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1289 | Ethertype = C-Tag [802.1Q] | Outer.VLAN Tag Information | 1290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1291 TRILL Header: 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Ethertype = TRILL | V | R |M|Op-Length| Hop Count | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1295 | Egress (RB2) Nickname | Ingress (RB1) Nickname | 1296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 Inner Ethernet Header: 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Inner Destination MAC Address (ESb) | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | Inner Destination MAC Address | Inner Source MAC Address | 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | Inner Source MAC Address (ESa) | 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 Payload: 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Ethertype of Original Payload | | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1311 | Original Ethernet Payload | 1312 | | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 Frame Check Sequence: 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | New FCS (Frame Check Sequence) | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1319 Figure 4.1: TRILL Data Encapsulation over Ethernet 1321 4.1.1 VLAN Tag Information 1323 A "VLAN Tag" (formerly known as a Q-tag), also known as a "C-tag" for 1324 customer tag, includes a VLAN ID and a priority field as shown in 1325 Figure 4.2. The "VLAN ID" may be zero, indicating the no VLAN is 1326 specified, just a priority, although such frames are called "priority 1327 tagged" rather than "VLAN tagged" [802.1Q-2005]. 1329 [802.1Qad] S-tags, also known as service tags, are beyond the scope 1330 of this document. 1332 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1333 | Priority | C | VLAN ID | 1334 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 1336 Figure 4.2: VLAN Tag Information 1338 As recommended in [802.1Q-2005], Rbridges SHOULD be implemented so as 1339 to allow use of the full range of VLAN IDs from 0x001 through 0xFFE. 1340 Rbridges MAY support a smaller number of simultaneously active VLAN 1341 IDs. VLAN ID zero is the null VLAN identifier and indicates that no 1342 VLAN is specified while VLAN ID 0xFFF is reserved. 1344 The VLAN ID 0xFFF MUST NOT be used. Rbridges MUST discard any frame 1345 they receive with an Outer.VLAN ID of 0xFFF. Rbridges MUST discard 1346 any frame for which they examine the Inner.VLAN ID and find it to be 1347 0xFFF; such examination is required at all egress Rbridges which 1348 decapsulate a frame. 1350 The "C" bit shown in Figure 4.2 is not used in TRILL. It MUST be set 1351 to zero and is ignored by receivers. 1353 As specified in [802.1Q-2005], the priority field contains an 1354 unsigned value from 0 through 7 where 1 indicates the lowest 1355 priority, 7 the highest priority, and the default priority zero is 1356 considered to be higher than priority 1 but lower than priority 2. 1357 The [802.1ad] amendment to [802.1Q-2005] permits mapping some 1358 adjacent pairs of priority levels into a single priority level with 1359 and without drop eligibility. Ongoing work in IEEE 802.1 (802.1az, 1360 Appendix E) suggests the ability to configure "priority groups" that 1361 have a certain guaranteed bandwidth. RBridges ports MAY also 1362 implement such options. RBridges are not required to implement any 1363 particular number of distinct priority levels but may treat one or 1364 more adjacent priority levels in the same fashion. 1366 Frames with the same source address, destination address, VLAN, and 1367 priority that are received on the same port as each other and are 1368 transmitted on the same port MUST be transmitted in the order 1369 received unless the RBridge classifies the frames into more fine 1370 grained flows, in which case this ordering requirement applies to 1371 each such flow. (Such frames might not be sent out the same port if 1372 multipath is implemented. See Appendix C.) 1374 The C-Tag Ethertype [RFC5342] is 0x8100. 1376 4.1.2 Inner VLAN Tag 1378 The "Inner VLAN Tag Information" (Inner.VLAN) field contains the VLAN 1379 tag information associated with the native frame when it was 1380 ingressed or the VLAN tag information associated with a TRILL ESADI 1381 frame when that frame was created. When a TRILL frame passes through 1382 a transit RBridge, the Inner.VLAN MUST NOT be changed except when 1383 VLAN mapping is being intentionally performed within that RBridge. 1385 When a native frame arrives at an RBridge, the associated VLAN ID and 1386 priority are determined as specified in [802.1Q-2005] (see Appendix D 1387 and [802.1Q-2005] Section 6.7). If the RBridge is an appointed 1388 forwarder for that VLAN and the delivery of the frame requires 1389 transmission to one or more other links, this ingress RBridge forms a 1390 TRILL data frame with the associated VLAN ID and priority placed in 1391 the Inner.VLAN information. 1393 The VLAN ID is required at the ingress Rbridge as one element in 1394 determining the appropriate egress Rbridge for a known unicast frame 1395 and is needed at the ingress and every transit Rbridge for multi- 1396 destination frames to correctly prune the distribution tree. 1398 4.1.3 Outer VLAN Tag 1400 TRILL frames sent by an RBridge, except for some TRILL-Hello frames, 1401 use an Outer.VLAN ID specified by the Designated RBridge (DRB) for 1402 the link onto which they are being sent, referred to as the 1403 Designated VLAN. For TRILL data and ESADI frames, the priority in the 1404 Outer.VLAN tag SHOULD be set to the priority in the Inner.VLAN tag. 1406 TRILL frames forwarded by a transit RBridge use the priority present 1407 in the Inner.VLAN of the frame as received. TRILL data frames are 1408 sent with the priority associated with the corresponding native frame 1409 when received (see Appendix D). TRILL IS-IS frames SHOULD be sent 1410 with priority 7. 1412 Whether an Outer.VLAN tag actually appears on the wire when a TRILL 1413 frame is sent depends on the configuration of the RBridge port 1414 through which it is sent in the same way as the appearance of a VLAN 1415 tag on a frame sent by an [802.1Q-2005] frame depends on the 1416 configuration of the bridge port (see Section 4.9.2). 1418 4.1.4 Frame Check Sequence (FCS) 1420 Each Ethernet frame has a single Frame Check Sequence (FCS) that is 1421 computed to cover the entire frame, for detecting frame corruption 1422 due to bit errors on a link. Thus, when a frame is encapsulated, the 1423 original FCS is not included but is discarded. Any received frame for 1424 which the FCS check fails SHOULD be discarded (this may not be 1425 possible in the case of cut through forwarding). The FCS normally 1426 changes on encapsulation, decapsulation, and every TRILL hop due to 1427 changes in the outer destination and source addresses, the 1428 decrementing of the hop count, etc. 1430 Although the FCS is normally calculated just before transmission, it 1431 is desirable, when practical, for an FCS to accompany a frame within 1432 an RBridge after receipt. That FCS could then be dynamically updated 1433 to account for changes to the frame during Rbridge processing and 1434 used for transmission or checked against the FCS calculated for frame 1435 transmission. This optional, more continuous use of an FCS would be 1436 helpful in detecting some internal RBridge failures such as memory 1437 errors. 1439 4.2 Link State Protocol (IS-IS) 1441 TRILL uses an extension of IS-IS [ISO10589] [RFC1195] as its routing 1442 protocol. IS-IS has the following advantages: 1444 o it runs directly over Layer 2, so therefore it may be run without 1445 configuration (no IP addresses need to be assigned); 1447 o it is easy to extend by defining new TLV (type-length-value) data 1448 elements and sub-elements for carrying TRILL information; 1450 This section describes TRILL use of IS-IS, except for the TRILL-Hello 1451 protocol, which is described in Section 4.4, and the MTU-probe and 1452 MTU-ack messages that are described in Section 4.3. 1454 4.2.1 IS-IS RBridge Identity 1456 Each RBridge has a unique 48-bit (6-octet) IS-IS System ID. This ID 1457 may be derived from any of the RBridge's unique MAC addresses. 1459 A pseudonode is assigned a 7-octet ID by the DRB that created it, by 1460 taking a 6-octet ID owned by the DRB, and appending another octet. 1461 The 6-octet ID used to form a pseudonode ID SHOULD be the DRB's ID 1462 unless the DRB has to create IDs for pseudonodes for more than 255 1463 links. The only constraint for correct operations is that the 7-octet 1464 ID be unique within the campus, and that the 7th octet be nonzero. An 1465 RBridge has a 7-octet ID consisting of its 6-octet system ID 1466 concatenated with a zero octet. 1468 In this document we use the term "IS-IS ID" to refer to the 7-octet 1469 quantity that can either be the ID of an RBridge or a pseudonode. 1471 4.2.2 IS-IS Instances 1473 TRILL implements a separate IS-IS instance from any used by Layer 3, 1474 that is, different from the one used by routers. Layer 3 IS-IS frames 1475 must be distinguished from TRILL IS-IS frames even when those Layer 3 1476 IS-IS frames are transiting an RBridge campus. 1478 Layer 3 IS-IS native frames have special multicast destination 1479 addresses specified for that purpose, such as AllL1ISs or AllL2ISs. 1480 When they are TRILL encapsulated, these multicast addresses appear as 1481 the Inner.MacDA and the Outer.MacDA will be the All-RBridges 1482 multicast address. 1484 Within TRILL, there is an IS-IS instance across all Rbridges in the 1485 campus as described in Section 4.2.3. This instance uses TRILL IS-IS 1486 frames that are distinguished by having a different Ethertype "L2-IS- 1487 IS". Additionally, for TRILL IS-IS frames that are multicast, there 1488 is a distinct multicast destination address of All-IS-IS-RBridges. 1489 TRILL IS-IS frames do not have a TRILL Header. 1491 ESADI is a separate protocol from the IS-IS instance implemented by 1492 all the RBridges. There is a separate ESADI instance for each VLAN, 1493 and ESADI frames are encapsulated just like TRILL data frames. After 1494 the TRILL header, the ESADI frame has an inner Ethernet header with 1495 the Inner.MacDA of "All-ESADI-RBridges" and the "L2-IS-IS" Ethertype 1496 followed by the ESADI frame. 1498 4.2.3 TRILL IS-IS Frames 1500 All Rbridges must participate in the TRILL IS-IS instance, which 1501 constitutes a single Level 1 IS-IS area using the fixed area-ID zero. 1502 TRILL IS-IS frames are never forwarded by an RBridge but are locally 1503 processed on receipt. (Such processing may cause the RBridge to send 1504 additional TRILL IS-IS frames.) 1506 A TRILL IS-IS frame on an 802.3 link is structured as shown below. 1507 All such frames are Ethertype encoded. The RBridge port out which 1508 such a frame is sent will strip the outer VLAN tag if configured to 1509 do so. 1511 Outer Ethernet Header: 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | All-IS-IS-RBridges Multicast Address | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | All-IS-IS-RBridges continued | Source RBridge MAC Address | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Source RBridge MAC Address continued | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | Ethertype = C-Tag [802.1Q] | Outer.VLAN Tag Information | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | L2-IS-IS Ethertype | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 IS-IS Payload: 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 1527 Frame Check Sequence: 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | FCS (Frame Check Sequence) | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 Figure 4.3: TRILL IS-IS Frame Format 1534 The VLAN specified in the Outer.VLAN information will be the 1535 Designated VLAN for the link on which the frame is sent, except in 1536 the case of some TRILL-Hellos. 1538 4.2.4 TRILL Link Hellos, DRBs, and Appointed Forwarders 1540 RBridges default to using TRILL Hellos unless, on a per port basis, 1541 they are configured to use P2P Hellos. TRILL-Hello frames are 1542 specified in Section 4.4. 1544 RBridges are normally configured to use P2P Hellos only when there 1545 are exactly two of them on a link. However, it can occur that 1546 RBridges are misconfigured as to which type of hello to use. This is 1547 safe but may cause lack of RBridge to RBridge connectivity. An 1548 RBridge port configured to use P2P Hellos ignores TRILL Hellos and an 1549 RBridge port configured to use TRILL Hellos ignores P2P Hellos. 1551 If any of the RBridge ports on a link is configured to use TRILL 1552 Hellos, one of such RBridge ports using TRILL Hellos is elected DRB 1553 (Designated RBridge) for the link. This election is based on 1554 configured priority (most significant field), and source MAC address, 1555 as communicated by TRILL-Hello frames. The DRB, as described in 1556 Section 4.2.4.2, designates the VLAN to be used on the link for 1557 inter-RBridge communication by the non-P2P RBridge ports and appoints 1558 itself or other RBridges on the link as appointed forwarder (see 1559 Section 4.2.4.3) for VLANs on the link. 1561 4.2.4.1 P2P Hello Links 1563 RBridge ports can be configured to use IS-IS P2P Hellos. This implies 1564 that the port is a point-to-point link to another RBridge. An RBridge 1565 MUST NOT provide any end station (native frame) service on a port 1566 configured to use P2P Hellos. 1568 As with Layer 3 IS-IS, such P2P ports do not participate in a DRB 1569 election. They send all frames VLAN tagged as being in the Desired 1570 Designated VLAN configured for the port although this tag may be 1571 stripped if the port is so configured. Since all traffic through the 1572 port should be TRILL frames or layer 2 control frames, such a port 1573 cannot be an appointed forwarder. RBridge P2P ports MUST use the IS- 1574 IS three-way handshake [RFC5303] so that extended circuit IDs are 1575 associated with the link for tie breaking purposes (see Section 1576 4.5.2). 1578 Even if all simple links in a network are physically point-to-point, 1579 if some of the nodes are bridges, the bridged LANs that include those 1580 bridges appear to be multi-access link to attached RBridges. This 1581 would necessitate using TRILL-Hellos for proper operation in many 1582 cases. 1584 While it is safe to erroneously configure ports as P2P, this may 1585 result in lack of connectivity. 1587 4.2.4.2 Designated RBridge 1589 TRILL IS-IS elects one RBridge for each LAN link to be the Designated 1590 RBridge (DRB), that is, to have special duties. The Designated 1591 RBridge: 1593 o Chooses, for the link, and announces in its Hellos, the Designated 1594 VLAN ID to be used for inter-RBridge communication. This VLAN is 1595 used for all TRILL-encapsulated data and ESADI frames and TRILL 1596 IS-IS frames except some TRILL-Hello frames. 1598 o If the link is represented in the IS-IS topology as a pseudonode, 1599 chooses a pseudonode ID and announces that in its Hellos and 1600 issues an LSP on behalf of the pseudonode. 1602 o Issues CSNPs. 1604 o For each VLAN-x appearing on the link, chooses an RBridge on the 1605 link to be the appointed VLAN-x forwarder (the DRB MAY choose 1606 itself to be the appointed VLAN-x forwarder for all or some of the 1607 VLANs). 1609 o Before appointing a VLAN-x forwarder (including appointing 1610 itself), wait at least its Holding Time (to ensure it is DRB). 1612 o If configured to send TRILL-Hello frames, continues to send them 1613 on all its enabled VLANs that have been configured in the 1614 Announcing VLANs set of the DRB, which defaults to all enabled 1615 VLANs. 1617 4.2.4.3 Appointed VLAN-x Forwarder 1619 The appointed VLAN-x forwarder for a link is responsible for the 1620 following points. In connection with the loop avoidance points, when 1621 an appointed forwarder for a port is "inhibited", it drops any native 1622 frames it receives and does not transmit but instead drops any native 1623 frames it decapsulates, in the VLAN for which it is appointed. 1625 o Loop avoidance: 1627 - Inhibiting itself for a time, configurable per port from zero 1628 to 30 seconds, which defaults to 30 seconds, after it sees a 1629 root bridge change on the link (see Section 4.9.3.2). 1631 - Inhibiting itself for VLAN-x, if it has received a Hello in 1632 which the sender asserts that it is appointed forwarder and 1633 that is either 1634 + received on VLAN-x (has VLAN-x as its Outer.VLAN) or 1635 + was originally sent on VLAN-x as indicated inside the body 1636 of the Hello. 1638 - Optionally, not decapsulating a frame from ingress RBridge RBm 1639 unless it has RBm's LSP, and the root bridge on the link it is 1640 about to forward onto is not listed in RBm's list of root 1641 bridges for VLAN-x. This is known as the "decapsulation check" 1642 or "root bridge collision check". 1644 o Unless inhibited (see above), receiving VLAN-x native traffic from 1645 the link and, forwarding it as appropriate. 1647 o Receiving VLAN-x traffic for the link and, unless inhibited, 1648 transmitting it in native form after decapsulating it as 1649 appropriate. 1651 o Learning the MAC address of local VLAN-x nodes by looking at the 1652 source address of VLAN-x frames from the link. 1654 o Optionally learning the port of local VLAN-x nodes based on any 1655 sort of Layer 2 registration protocols, such as IEEE 802.11 1656 association and authentication. 1658 o Keeping track of the { egress RBridge, VLAN, MAC address } of 1659 distant VLAN-x end nodes, learned by looking at the fields { 1660 ingress RBridge, Inner.VLAN ID, Inner.MacSA } from VLAN-x frames 1661 being received for decapsulation onto the link. 1663 o Optionally observe native IGMP [RFC3376], MLD [RFC2710], and MRD 1664 [RFC4286] frames to learn the presence of local multicast 1665 listeners and multicast routers. 1667 o Optionally listening to TRILL ESADI messages for VLAN-x to learn { 1668 egress RBridge, VLAN-x, MAC address } triplets and the confidence 1669 level of such explicitly advertised end nodes. 1671 o Optionally advertising VLAN-x end nodes, on links for which it is 1672 appointed VLAN-x forwarder, in ESADI messages. 1674 o Send TRILL-Hello frames on VLAN-x. 1676 o Listening to BPDUs on the common spanning tree to learn the root 1677 bridge, if any, for that link and to report in its LSP the 1678 complete set of root bridges seen on any of its links for which it 1679 is appointed forwarder for VLAN-x. 1681 When an appointed forwarder observes that the DRB on a link has 1682 changed, it no longer considers itself appointed for that link until 1683 appointed by the new DRB. 1685 4.2.4.4 TRILL LSP Information 1687 The information items in the TRILL IS-IS LSP that are mentioned 1688 elsewhere in this document are listed below. Unless an item is stated 1689 in the list below to be optional, it MUST be included. Other items 1690 MAY be included unless their inclusion is prohibited elsewhere in 1691 this document. The actual encoding of this information and the IS-IS 1692 Type or sub-Type values for any new IS-IS TLV or sub-TLV data 1693 elements are specified in a separate document [layer2]. 1695 1. The IS-IS IDs of neighbors (pseudonodes as well as RBridges) of 1696 RBridge RBn, and the cost of the link to each of those neighbors. 1697 RBridges MUST use the Extended IS Reachability TLV (#22, also 1698 known as "wide metric" [RFC5305]) and MUST NOT use the IS 1699 Reachability TLV (#2, also known as "narrow metric"). To 1700 facilitate efficient operation without configuration and 1701 consistent with [802.1D], RBridges SHOULD, by default, set the 1702 cost of a link to the integer part of twenty trillion 1703 (20,000,000,000,000) divided by the RBridge port's bit rate but 1704 not more than 2**24-2 (16,777,214); for example, the cost for a 1705 link accessed by a 1Gbps port would default to 20,000. (Note that 1706 2**24-1 has a special meaning in IS-IS and would exclude the link 1707 from SPF routes.) However, the link cost MAY, by default, be 1708 decreased for aggregated links and/or increased if the link 1709 appears to be a bridged LAN. The tested MTU for the link (see 1710 Section 4.3) MAY be included via a sub-TLV. 1712 2. The following information in connection with the nickname or each 1713 of the nicknames of RBridge RBn: 1715 2.1 The nickname value (2 octets). 1717 2.2 The unsigned 8-bit priority for RBn to have that nickname (see 1718 Section 3.7.3). 1720 2.3 The 16-bit unsigned priority of that nickname to becoming a 1721 distribution tree root. 1723 3. The maximum TRILL Header Version supported by RBridge RBn. 1725 4. The following information, in addition to the per nickname tree 1726 root priority, in connection with distribution tree determination 1727 and announcement. (See Section 4.5 for further details on how this 1728 information is used.) 1730 4.1 An unsigned 16-bit number that is the number of trees all 1731 RBridges in the campus calculate if RBn has the highest 1732 priority tree root. 1734 4.2 A second unsigned 16-bit number that is the number of trees 1735 RBn would like to use. 1737 4.3 A third unsigned 16-bit number that is the maximum number of 1738 distribution trees that RBn is able to calculate. 1740 4.4 A first list of nicknames that are intended roots of 1741 distribution trees all RBridges in the campus must calculate. 1743 4.5 A second list of nicknames that are roots that RBn would like 1744 to use when ingressing multi-destination frames. 1746 5. The list of VLAN IDs of VLANs directly connected to RBn for links 1747 on which RBn is the appointed forwarder for that VLAN. (Note: an 1748 RBridge may advertise that it is connected to additional VLANs in 1749 order to receive additional frames to support certain VLAN based 1750 features beyond the scope of this specification as mentioned in 1751 Section 4.8.3 and in a separate document concerning VLAN mapping 1752 inside RBridges.) RBridges may associate advertised connectivity 1753 to different groups of VLANs with specific nicknames they hold. In 1754 addition, the LSP contains the following information on a per-VLAN 1755 basis: 1757 5.1 Per VLAN Multicast Router attached flags: This is two bits of 1758 information that indicate whether there is an IPv4 and/or IPv6 1759 multicast router attached to the Rbridge on that VLAN. An 1760 RBridge that does not do IP multicast control snooping MUST 1761 set both of these bits (see Section 4.5.4). This information 1762 is used because IGMP [RFC3376] and MLD [RFC2710] Membership 1763 Reports MUST be transmitted to all links with IP multicast 1764 routers, and SHOULD NOT be transmitted to links without such 1765 routers. Also, all frames for IP-derived multicast addresses 1766 MUST be transmitted to all links with IP multicast routers 1767 (within a VLAN), in addition to links from which an IP node 1768 has explicitly asked to join the group the frame is for, 1769 except for some IP multicast addresses that MUST be treated as 1770 broadcast. 1772 5.2 Per VLAN mandatory announcement of the set of IDs of Root 1773 bridges for any of RBn's links on which RBn is forwarder for 1774 that VLAN. Where MSTP (Multiple Spanning Tree Protocol) is 1775 running on a link, this is the root bridge of the CIST (Common 1776 and Internal Spanning Tree). This is to quickly detect cases 1777 where two Layer 2 clouds accidentally get merged, and where 1778 there might otherwise temporarily be two DRBs for the same 1779 VLAN on the same link. (See Section 4.2.4.3.) 1781 5.3 Optionally, per VLAN Layer 2 multicast addresses derived from 1782 IPv4 IGMP and IPv6 MLD notification messages received from 1783 attached end nodes on that VLAN, indicating the location of 1784 listeners for these multicast addresses (see Section 4.5.5). 1786 5.4 Per VLAN ESADI participation flag, priority, and holding time. 1787 If this flag is one, it indicates that the RBridge wishes to 1788 receive such TRILL ESADI frames (see Section 4.2.5.1). 1790 5.5 Per VLAN appointed forwarder status lost counter (see Section 1791 4.8.2). 1793 6. Optionally, the largest TRILL IS-IS frame that the RBridge can 1794 handle using the originatingLSPBufferSize TLV #14 (see Section 1795 4.3). 1797 7. Optionally, a list of VLAN groups where address learning is shared 1798 across that VLAN group (see Section 4.8.3). Each VLAN group is a 1799 list of VLAN IDs, where the first VLAN ID listed in a group, if 1800 present, is the "primary" and the others are "secondary". This is 1801 to detect misconfiguration of features outside the scope of this 1802 document. RBridges that do not support features such as "shared 1803 VLAN learning" ignore this field. 1805 8. Optionally, the Authentication TLV #10 (see Section 6). 1807 4.2.5 TRILL ESADI 1809 RBridges that are the appointed VLAN-x forwarder for a link MAY 1810 participate in the TRILL end station address distribution information 1811 (ESADI) protocol for that VLAN. But all transit RBridges MUST 1812 properly forward TRILL ESADI frames as if they were multicast TRILL 1813 data frames. TRILL ESADI frames are structured like IS-IS frames but 1814 are always TRILL encapsulated on the wire as if they were TRILL data 1815 frames. 1817 Because of this forwarding, it appears to an ESADI at an RBridge that 1818 it is directly connected by a shared virtual link to all other 1819 RBridges in the campus running ESADI for that VLAN. RBridges that do 1820 not implement that ESADI or are not appointed forwarder for that VLAN 1821 do not decapsulate or locally process any TRILL ESADI frames they 1822 receive for that VLAN. In other words, these frames are transparently 1823 tunneled through transit RBridges. Such transit RBridges treat them 1824 exactly as multicast TRILL data frames and no special processing is 1825 invoked due to such forwarding. 1827 TRILL ESADI frames sent on an IEEE 802.3 link are structured as shown 1828 below. The outer VLAN tag will not be present if it was stripped by 1829 the port out which the frame was sent. 1831 Outer Ethernet Header: 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | Next Hop Destination Address | 1834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1835 | Next Hop Destination Address | Sending RBridge MAC Address | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | Sending RBridge Port MAC Address | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | Ethertype = C-Tag [802.1Q] | Outer.VLAN Tag Information | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1841 TRILL Header: 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1843 | Ethertype = TRILL | V | R |M|Op-Length| Hop Count | 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | Egress (Dist. Tree) Nickname | Ingress (Origin) Nickname | 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 Inner Ethernet Header: 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 | All-ESADI-RBridges Multicast Address | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | All-ESADI-RBridges continued | Origin RBridge MAC Address | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Origin RBridge MAC Address continued | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1855 | Ethertype = C-Tag [802.1Q] | Inner.VLAN Tag Information | 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Ethertype = L2-IS-IS | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 ESADI Payload (formatted as IS-IS): 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | IS-IS Common Header, IS-IS PDU Specific Fields, IS-IS TLVs | 1863 Frame Check Sequence: 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | FCS (Frame Check Sequence) | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 Figure 4.4: TRILL ESADI Frame Format 1870 The Next Hop Destination Address or Outer.MacDA is the All-RBridges 1871 multicast address. The VLAN specified in the Outer.VLAN information 1872 will always be the Designated VLAN for the link on which the frame is 1873 sent. The V and R fields will be zero while the M field will be one. 1874 The VLAN specified in the Inner.VLAN information will be the VLAN to 1875 which the ESADI applies. The Origin RBridge MAC Address or 1876 Inner.MacSA MUST be a globally unique MAC address owned by the 1877 RBridge originating the ESADI frame, for example any of its port MAC 1878 addresses, and each RBridge MUST use the same Inner.MacSA for all of 1879 the ESADI frames that RBridge originates. 1881 4.2.5.1 TRILL ESADI Participation 1883 An RBridge does not send any Hellos because of participation in an 1884 ESADI. The information available in the TRILL IS-IS link state 1885 database is sufficient to determine the ESADI DRB on the virtual link 1886 for each VLAN's ESADI. In particular, the link state database 1887 information for each RBridge includes the VLANs, if any, for which 1888 that RBridge is participating in an ESADI, its priority for being 1889 selected as DRB for each of those ESADIs, its holding time, and its 1890 IS-IS system ID for breaking ties in priority. 1892 An RBridge need not perform any routing calculation because of 1893 participation in an ESADI. Since all RBridges participating in ESADI 1894 for a particular VLAN appear to be connected to the same single 1895 virtual link, there are no routing decisions to be made. A 1896 participating RBridge merely transmits the ESDAI frames it originates 1897 on this virtual link. 1899 The ESADI DRB sends TRILL-ESADI-CSNP frames on the ESADI virtual 1900 link. For robustness, a participating RBridge that determines that 1901 some other RBridge should be ESADI DRB on such a virtual link and has 1902 not received or sent a TRILL-ESADI-CSNP in at least the ESADI DRB 1903 holding time MAY also send a TRILL-ESADI-CSNP on the virtual link. A 1904 participating RBridge that determines that no other RBridges are 1905 participating in an ESADI for a particular VLAN SHOULD NOT send ESADI 1906 information or TRILL-ESADI-CSNPs on the virtual link. 1908 4.2.5.2 TRILL ESADI Information 1910 The information in ESADI is the list of local end station MAC 1911 addresses known to the originating RBridge and, for each such 1912 address, a one octet unsigned "confidence" rating in the range 0-254 1913 (see Section 4.8). 1915 It is intended to optionally provide for VLAN ID translation within 1916 RBridges, as specified in a separate document. This includes 1917 translating TRILL ESADI frames. If TRILL ESADI frames could contain 1918 VLAN IDs in arbitrary internal locations, such translation would be 1919 impractical. Thus, TRILL ESADI frames MUST NOT contain the VLAN ID of 1920 the VLAN to which they apply in the body of the frame after the 1921 Inner.VLAN tag. 1923 4.2.6 SPF, Forwarding, and Ambiguous Destinations 1925 This section describes the logical result desired. Alternative 1926 implementation methods may be used as long as they producing the same 1927 forwarding behavior. 1929 When building a forwarding table, an RBridge RB1 calculates shortest 1930 paths from itself as described in [RFC1195] Appendix C.1. Nicknames 1931 are added into the shortest path calculation as a final step, just as 1932 with an end node. If multiple RBridges , say RBa and RBb, claim the 1933 same nickname, this is a transitory condition and one of RBa or RBb 1934 will defer and choose a new nickname. However, RB1 simply adds that 1935 nickname as if it were attached to both RBa and RBb, and uses its 1936 standard shortest path calculation to choose the next hop 1938 An ingress RBridge RB2 maps a native frame's known unicast 1939 destination MAC address and VLAN into an egress RBridge nickname. If 1940 RB2 learns addresses only from the observation of received and 1941 decapsulated frames, then such MAC addresses cannot be duplicated 1942 within a VLAN in RB2 tables because more recent learned information, 1943 if of a higher or equal confidence, overwrites previous information. 1944 However, duplicates of the same MAC within a VLAN can appear in ESADI 1945 data and between ESADI data and addresses learned from the 1946 observation of received and decapsulated frames, entered by manual 1947 configuration, or learned through layer 2 registration protocols. If 1948 duplicate MAC addresses occur within a VLAN, RB2 sends frames to the 1949 MAC with the highest confidence. If confidences are also tied between 1950 the duplicates, for consistency it is suggested that RB2 direct all 1951 such frames (or all such frames in the same ECMP flow) toward the 1952 same egress RBridge; however, the use of other policies will not 1953 cause a network problem since transit RBridges do not examine the 1954 Inner.MacDA for known unicast frames. 1956 4.3 Inter-RBridge Link MTU Size 1958 There are two reasons why it is important to know what size of frame 1959 each inter-RBridge link in the campus can support: 1961 1. RBridge RB1 must know what size of link state information messages 1962 it can generate, that will be guaranteed to be forwardable across 1963 all inter-RBridge links in the campus. 1965 2. If traffic engineering tools know which links support larger than 1966 minimally acceptable data packet sizes, paths can be computed that 1967 can support large data packets. 1969 4.3.1 Determining Campus-Wide TRILL IS-IS MTU Size 1971 There must be an agreement among all RBridges on the value of "Sz", 1972 the minimum acceptable inter-RBridge link size for the campus for the 1973 proper operation of TRILL IS-IS. Once Sz is known, all RBridges MUST 1974 format their link state information messages to be in chunks of size 1975 at most Sz. Also, every RBridge RB1 SHOULD test each of its RBridge 1976 adjacencies, say to RB2, to ensure that the RB1-RB2 link can forward 1977 packets of at least size Sz. 1979 Sz has no direct effect on end-stations and is not directly related 1980 to any end-station to end-station "path MTU". Methods of using Sz or 1981 any link MTU information gathered by TRILL IS-IS in the traffic 1982 engineering of routes or the determination of any path MTU is beyond 1983 the scope of this document. 1985 Sz is determined by having each RBridge (optionally) advertise, in 1986 its LSP, its assumption of the value of the campus-wide Sz. This LSP 1987 element is known in IS-IS as the originatingLSPBufferSize, TLV #14. 1988 The default and minimum value for Sz, and the implicitly advertised 1989 value of Sz if the TLV is absent, is 1470 octets. This length (which 1990 is also the maximum size of a TRILL-Hello) was chosen to make it 1991 extremely unlikely that a TRILL control frame, even with reasonable 1992 additional headers, tags, and/or encapsulation, would encounter MTU 1993 problems on an inter-RBridge link. 1995 The campus-wide value of Sz is the smallest value of Sz advertised by 1996 any RBridge. 1998 4.3.2 Testing Link MTU Size 2000 There are two new TRILL IS-IS message types for use between pairs of 2001 RBridge neighbors to test the bidirectional packet size capacity of 2002 their connection. These messages are: 2004 -- MTU-probe 2005 -- MTU-ack 2007 Both the MTU-probe and the MTU-ack are padded to the size being 2008 tested. 2010 Sending of MTU-probes is optional; however, an RBridge RB2 that 2011 receives an MTU-probe from RB1 MUST respond with an MTU-ack padded to 2012 the same size as the MTU-probe. The MTU-probe MAY be multicast to 2013 All-RBridges, or unicast to a specific RBridge. The MTU-ack is 2014 normally unicast to the source of the MTU-probe to which it responds 2015 but MAY be multicast to All-RBridges. 2017 If RB1 fails to receive an MTU-ack to a probe of size X from RB2 2018 after k tries (where k is a configurable parameter whose default is 2019 3), then RB1 assumes the RB1-RB2 link cannot support size X. If X is 2020 not greater than Sz, then RB1 sets the "failed minimum MTU test" flag 2021 for RB2 in RB1's Hello. If size X succeeds, and X > Sz, then RB1 2022 advertises the largest tested X for each adjacency in the TRILL 2023 Hellos RB1 sends on that link, and RB1 MAY advertise X as an 2024 attribute of the link to RB2 in RB1's LSP. 2026 4.4 TRILL-Hello Protocol 2028 The TRILL-Hello protocol is a little different from the layer 3 IS-IS 2029 LAN Hello protocol and uses a new type of IS-IS message known as a 2030 TRILL-Hello. 2032 4.4.1 Rationale 2034 The reason for defining this new type of link in TRILL is that in 2035 layer 3 IS-IS, the LAN Hello protocol may elect multiple Designated 2036 Routers (DRs) since, when choosing a DR, routers ignore other routers 2037 with whom they do not have 2-way connectivity. Also, layer 3 IS-IS 2038 LAN Hellos are padded, to avoid forming adjacencies between neighbors 2039 that can't speak the maximum sized packet to each other. This means, 2040 in layer 3 IS-IS, that neighbors that have connectivity to each 2041 other, but with an MTU on that connection less than what they 2042 perceive as maximum sized packets, will not see each other's Hellos. 2043 The result is that routers might form cliques, resulting in the link 2044 turning into multiple pseudonodes. 2046 This behavior is fine for layer 3, but not for layer 2, where loops 2047 may form if there are multiple DRBs. Therefore, the TRILL-Hello 2048 protocol is a little different from layer 3 IS-IS's LAN Hello 2049 protocol. 2051 One other issue with TRILL-Hellos is to ensure that subsets of the 2052 information can appear in any single message, and be processable, in 2053 the spirit of IS-IS LSPs and CSNPs. TRILL-Hello frames, completely 2054 independently of whether they are padded or not, can become very 2055 large. An example where this might be the case is when some sort of 2056 backbone technology interconnects hundreds of TRILL sites over what 2057 would appear to TRILL to be a giant Ethernet, where the RBridges 2058 connected to that cloud will perceive that backbone to be a single 2059 link with hundreds of neighbors. 2061 In TRILL (unlike in layer 3 IS-IS), the DRB is selected based solely 2062 on priority and MAC address. In other words, if RB2 receives a TRILL- 2063 Hello from RB1 with higher (priority, MAC), RB2 defers to RB1 as DRB, 2064 regardless of whether RB1 lists RB2 in RB1's TRILL-Hello. 2066 Although the neighbor list in a TRILL-Hello does not influence the 2067 DRB election, it does determine what is announced in LSPs. RB1 only 2068 reports links to RBridges that it has two-way connectivity with. If 2069 RB1 is DRB on a link, and for whatever reason (MTU mismatch, or one- 2070 way connectivity) RB1 and RB2 do not have two-way connectivity, then 2071 RB2 does not report a link to RB1 (or the pseudonode), and RB1 (or 2072 RB1 on behalf of the pseudonode) does not report a link to RB2. 2074 4.4.2 TRILL-Hello Contents and Timing 2076 The TRILL-Hello has a new IS-IS message type. It starts with the same 2077 fixed header as an IS-IS LAN Hello, which includes the 7-bit priority 2078 for the issuing RBridge to be DRB on that link. TRILL-Hellos are sent 2079 with the same timing as IS-IS LAN Hellos. 2081 TRILL-Hello messages, including their Outer.MacDA and Outer.MacSA, 2082 but excluding any Outer.VLAN or other tags, MUST NOT exceed 1470 2083 octets in length and SHOULD NOT be padded. The following information 2084 MUST appear in every TRILL-Hello. References to "TLV" may actually be 2085 a "sub-TLV" as specified in a separate document [layer2]. 2087 1. The VLAN ID of the Designated VLAN for the link. 2089 2. A copy of the Outer.VLAN ID with which the Hello was tagged on 2090 sending. 2092 3. A 16-bit port ID assigned by the sending RBridge to the port the 2093 TRILL-Hello is sent on such that no two ports of that RBridge have 2094 the same port ID. 2096 4. Two flags as follows: 2098 4.a A flag which, if set, indicates that the sender has detected 2099 VLAN mapping on the link, within the past 2 of its Holding 2100 Times. 2102 4.b A flag which, if set, indicates that the sender believes it is 2103 appointed forwarder for the VLAN and port on which the TRILL- 2104 Hello was sent. 2106 The following information MAY appear 2108 1. The set of VLANs for which end station service is enabled on the 2109 port. 2111 2. Several flags as follows: 2113 2.a A flag which, if set, indicates that the sender's port was 2114 configured as an access port. 2116 2.b A flag which, if set, indicates that the sender's port was 2117 configured as a trunk port. 2119 2.c A bypass pseudonode flag, as described below in this section. 2121 3. If the sender is DRB, the Rbridges (excluding itself) that it 2122 appoints as forwarders for that link and the VLANs for which it 2123 appoints them. As described below, this TLV is designed so that 2124 not all the appointment information need be included in each 2125 Hello. Its absence means that appointed forwarders should 2126 continue as previously assigned. 2128 4. The TRILL neighbor list. This is a new TLV, not the same as the 2129 IS-IS Neighbor TLV, in order to accommodate fragmentation and 2130 reporting MTU on the link (see Section 4.4.2.1). 2132 The appointed forwarders TLV specifies a range of VLANs and, within 2133 that range, specifies which Rbridge, if any, other than the DRB, is 2134 appointed forwarder for the VLANs in that range. Such TLVs sent by 2135 the DRB must eventually cover every possible VLAN. Appointing an 2136 RBridge as forwarder on a port for a VLAN that is not enabled on that 2137 port has no effect. 2139 It is anticipated that many links between RBridges will be point-to- 2140 point, in which case using a pseudonode merely adds to the 2141 complexity. If the DRB specifies the bypass pseudonode bit in its 2142 TRILL-Hellos, the RBridges on the link just report their adjacencies 2143 as point-to-point. This has no effect on how LSPs are flooded on a 2144 link. It only affects what LSPs are generated. 2146 For example, if RB1 and RB2 are the only RBridges on the link and RB1 2147 is DRB, then if RB1 creates a pseudonode that is used, there are 3 2148 LSPs: for, say, RB1.25 (the pseudonode), RB1, and RB2, where RB1.25 2149 reports connectivity to RB1 and RB2, and RB1 and RB2 each just say 2150 they are connected to RB1.25. Whereas if DRB RB1 sets the bypass 2151 pseudonode bit in its Hellos, then there will be only 2 LSPs: RB1 and 2152 RB2 each reporting connectivity to each other. 2154 A DRB SHOULD set the bypass pseudonode bit for its links unless, for 2155 a particular link, it has seen at least two simultaneous adjacencies 2156 on the link at some point since it last re-booted. 2158 4.4.2.1 TRILL Neighbor List 2160 The new TRILL Neighbor TLV includes the following information for 2161 each neighbor it lists: 2163 1. The neighbor's MAC address. 2165 2. MTU size to this neighbor as a two-octet unsigned integer in units 2166 of 4-octet chunks. The value zero indicates that the MTU is 2167 untested. 2169 3. A flag for "failed minimum MTU test". 2171 To allow partial reporting of neighbors, the neighbor IDs MUST be 2172 sorted by ID. If a set of neighbors { X1, X2, X3, ... Xn } are 2173 reported in RB1's Hello, then X1 < X2 < X3, ... < Xn. If RBridge 2174 RB2's ID is between X1 and Xn, and does not appear in RB1's Hello, 2175 then RB2 knows that RB1 has not heard RB2's Hello. 2177 Additionally there are two overall TRILL Neighbor List TLV flags: 2178 "the smallest ID I reported in this Hello is the smallest ID of any 2179 neighbor", and "the largest ID I reported in this Hello is the 2180 largest ID of any neighbor". If all the neighbors fit in RB1's 2181 TRILL-Hello, both flags will be set. 2183 If RB1 reports { X1, ... Xn } in its Hello, with the "smallest" flag 2184 set, and RB2's ID is smaller than X1, then RB2 knows that RB1 has not 2185 heard RB2's Hello. Similarly, if RB2's ID is larger than Xn and the 2186 "largest" flag is set, then RB2 knows that RB1 has not heard RB2's 2187 Hello. 2189 To ensure that any RBridge RB2 can definitively determine whether RB1 2190 can hear RB2, RB1's neighbor list must eventually cover every 2191 possible range of IDs. In other words, if X1 is the smallest reported 2192 in one of RB1's neighbor lists, and the "smallest" flag is not set, 2193 then X1 must appear in a different TRILL-Hello fragment as well, as 2194 the largest ID reported in that fragment. Or, fragments may overlap, 2195 as long as there is no gap, such that some range, say between Xi and 2196 Xj, never appears in any fragment. 2198 4.4.3 TRILL MTU probe and TRILL Hello VLAN Tagging 2200 The MTU probe mechanism is designed to determine the MTU for 2201 transmissions between RBridges. MTU probes and probe acknowledgements 2202 are only sent on the Designated VLAN. 2204 An RBridge RBn maintains for each port the same VLAN information as a 2205 customer IEEE [802.1Q-2005] bridge, including the set of VLANs 2206 enabled for output through that port (see Section 4.9.2). In 2207 addition, RBn maintains the following TRILL specific VLAN parameters 2208 per port: 2210 a) Desired Designated VLAN: the VLAN that RBn, if it is DRB, will 2211 specify in its TRILL-Hellos as the VLAN to be used by all 2212 RBridges on the link to communicate all TRILL frames, except 2213 some TRILL-Hellos. This MUST be a VLAN enabled on RBn's port. 2214 It defaults to the numerically lowest enabled VLAN ID, which is 2215 VLAN 1 for a default configuration RBridge. 2217 b) Designated VLAN: the VLAN being used on the link for all TRILL 2218 frames except some TRILL Hellos. This is RBn's Desired 2219 Designated VLAN if RBn believes it is the DRB or the Designated 2220 VLAN in the DRB's Hellos if RBn is not the DRB. 2222 c) Announcing VLANs set. This defaults to the enabled VLANs set on 2223 the port but may be configured to be a subset of the enabled 2224 VLANs. 2226 d) Forwarding VLANs set: the set of VLANs for which an RBridge 2227 port is appointed VLAN forwarder on the port. This MUST contain 2228 only enabled VLANs for the port, possibly all enabled VLANs. 2230 On each of its ports that is not configured to use P2P Hellos, an 2231 RBridge sends TRILL-Hellos Outer.VLAN tagged with each VLAN in a set 2232 of VLANs. This set depends on the RBridge's DRB status and the above 2233 VLAN parameters. RBridges send TRILL Hellos Outer.VLAN tagged with 2234 the Designated VLAN, unless that VLAN is not enabled on the port. In 2235 addition, the DRB sends TRILL Hellos Outer.VLAN tagged with each 2236 enabled VLAN in its Announcing VLANs set. All non-DRB RBridges send 2237 TRILL-Hellos Outer.VLAN tagged with all enabled VLANs that are in the 2238 intersection of their Forwarding VLANs set and their Announcing VLANs 2239 set. More symbolically, TRILL-Hello frames, when sent, are sent as 2240 follows: 2242 If sender is DRB 2243 intersection ( Enabled VLANs, 2244 union ( Designated VLAN, Announcing VLANs ) ) 2246 If sender is not DRB 2247 intersection ( Enabled VLANs, 2248 union ( Designated VLAN, 2249 intersection ( Forwarding VLANs, Announcing VLANs ) ) ) 2251 Configuring the Announcing VLANs set to be null minimizes the number 2252 of TRILL-Hellos. In that case, TRILL-Hellos are only tagged with the 2253 Designated VLAN. Great care should be taken in configuring an RBridge 2254 to not send TRILL Hellos on any VLAN where that RBridge is appointed 2255 forwarder as, under some circumstances, this can lead to loops. 2257 The number of TRILL-Hellos is maximized, within this specification, 2258 by configuring the Announcing VLANs set to be the set of all enabled 2259 VLAN IDs, which is the default. In that case, the DRB will send 2260 TRILL-Hello frames tagged with all its Enabled VLAN tags; in 2261 addition, any non-DRB RBridge RBn will send TRILL-Hello frames tagged 2262 with the Designated VLAN, if enabled, and tagged with all VLANs for 2263 which RBn is an appointed forwarder. (It is possible to send even 2264 more TRILL-Hellos. In particular, non-DRB RBridges could send TRILL- 2265 Hellos on enabled VLANs for which they are not an appointed forwarder 2266 and which are not the Designated VLAN. This would cause no harm other 2267 than a further communications and processing burden.) 2269 When an RBridge port comes up, until it has heard a TRILL-Hello from 2270 a higher priority RBridge, it considers itself to be DRB on that port 2271 and sends TRILL-Hellos on that basis. Similarly, even if it has at 2272 some time recognized some other RBridge on the link as DRB, if it 2273 receives no TRILL-Hellos on that port from an RBridge with higher 2274 priority as DRB for a long enough time, as specified by IS-IS, it 2275 will revert to believing itself DRB. 2277 4.4.4 Multiple Ports on the Same Link 2279 It is possible for an RBridge RB1 to have multiple ports to the same 2280 link. It is important for RB1 to recognize which of its ports are on 2281 the same link, so, for instance, if RB1 is appointed forwarder for 2282 VLAN A, RB1 knows that only one of its ports acts as appointed 2283 forwarder for VLAN A on that link. 2285 RB1 detects this condition based on receiving TRILL-Hello messages 2286 with the same IS-IS pseudonode ID on multiple ports. RB1 might have 2287 one set of ports, say { p1, p2, p3 } on one link, and another set of 2288 ports { p4, p5 } on a second link, and yet other ports, say p6, p7, 2289 p8, that are each on distinct links. Let us call a set of ports on 2290 the same link as a "port group". 2292 If RB1 detects that a set of ports, say { p1, p2, p3 } are a port 2293 group on a link, then RB1 MUST ensure that it does not cause loops 2294 when it encapsulates and decapsulates traffic from/to that link. If 2295 RB1 is appointed forwarder for VLAN A on that Ethernet link, RB1 MUST 2296 encapsulate / decapsulate VLAN A on only one of the ports. However, 2297 if RB1 is appointed forwarder for more than one VLAN, RB1 MAY choose 2298 to load split among its ports, using one port for some set of VLANs, 2299 and another port for a disjoint set of VLANs. 2301 If RB1 detects VLAN mapping occurring, (see Section 4.4.5), then RB1 2302 MUST NOT load split as appointed forwarder, and instead MUST act as 2303 appointed VLAN forwarder on that link on only one of its ports in the 2304 port group. 2306 When forwarding TRILL-encapsulated multidestination frames to/from a 2307 link on which RB1 has a port group, RB1 MAY choose to load-split 2308 among its ports, provided that it does not duplicate frames, and 2309 provided that it keeps frames for the same flow on the same port. If 2310 RB1's neighbor on that link, RB2, accepts multidestination frames on 2311 that tree on that link from RB1, RB2 MUST accept the frame from any 2312 of RB2's adjacencies to RB1 on that link. 2314 If an RBridge has more than one port connected to a link and those 2315 ports have the same MAC address, they can be distinguished by the 2316 port ID contain in TRILL-Hellos. 2318 4.4.5 VLAN Mapping Within a Link 2320 IEEE [802.1Q-2005] does not provide for bridges changing the C-tag 2321 VLAN ID for a tagged frame they receive, that is, mapping VLANs. 2322 Nevertheless, some bridge products provide this capability and, in 2323 any case, bridged LANs can be configured to display this behavior. 2324 For example, a bridge port can be configured to strip VLAN tags on 2325 output and send the resulting untagged frames onto a link leading to 2326 another bridge's port configured to tag these frames with a different 2327 VLAN. Although each port's configuration is legal under 2328 [802.1Q-2005], in the aggregate they perform manipulations not 2329 permitted to a single customer [802.1Q-2005] bridge. Since RBridge 2330 ports have the same VLAN capabilities as customer [802.1Q-2005] 2331 bridges, this can occur even in the absence of bridges. (VLAN mapping 2332 is referred to in IEEE 802.1 as "VLAN ID translation".) 2334 RBridges include the Outer.VLAN ID inside every TRILL-Hello message. 2335 When a TRILL-Hello is received, RBridges compare this saved copy with 2336 the Outer.VLAN ID information associated with the received frame. If 2337 these differ and the VLAN ID inside the Hello is X and the Outer.VLAN 2338 is Y, it can be assumed that VLAN ID X is being mapped into VLAN ID 2339 Y. 2341 When non-DRB RB2 detects VLAN mapping, based on receiving a TRILL- 2342 Hello where the VLAN tag in the body of the Hello differs from the 2343 one in the outer header, it sets a flag in all of its TRILL-Hellos 2344 for a period of two of its Holding Times since the last time RB2 2345 detected VLAN mapping. When DRB RB1 is informed of VLAN mapping, 2346 either because of receiving a TRILL-Hello that has been VLAN-mapped, 2347 or because of seeing the "VLAN Mapping detected" flag in a neighbor's 2348 TRILL-Hello on the link, RB1 re-assigns VLAN forwarders to ensure 2349 there is only a single forwarder on the link for all VLANs. 2351 4.5 Distribution Trees 2353 RBridges use distribution trees to forward multi-destination frames 2354 (see Section 2.4.2). Distribution Trees are bidirectional. Although 2355 a single tree is logically sufficient for the entire campus, the 2356 computation of additional distribution trees is warranted for the 2357 following reasons: it enables multipathing of multi-destination 2358 frames and enables the choice of a tree root closer to or, in the 2359 limit, identical with the ingress RBridge. Such a closer tree root 2360 improves the efficiency of the delivery of multi-destination frames 2361 that are being delivered to a subset of the links in the campus and 2362 reduces out-of-order delivery when a unicast address transitions 2363 between unknown and known. If applications are in use where 2364 occasional out-of-order unicast frames due to such transitions are a 2365 problem, the RBridge campus should be engineered to make sure they 2366 are of extremely low probability, such as by using ESADI or 2367 configuring addresses to eliminate unknown destination unicast 2368 frames. 2370 An additional level of flexibility is the ability of an RBridge to 2371 acquire multiple nicknames, and therefore have multiple trees rooted 2372 at the same RBridge. Since the tree number is used as a tie breaker 2373 for equal cost paths, the different trees, even if rooted at the same 2374 RBridge, will likely utilize different equal cost paths. 2376 RBridges will precompute all the trees that might be used, and keep 2377 state for Reverse Path Forwarding Check filters (see Section 4.5.2). 2378 Also, since the tree number is used as a tie breaker, it is important 2379 for all RBridges to know: 2381 o how many trees to compute 2382 o which trees to compute 2383 o what the tree number for each tree is 2384 o which trees each ingress RBridge might choose (for building 2385 Reverse Path Forwarding Check filters). 2387 Each RBridge advertises in its LSP a "tree root" priority for its 2388 nickname or for each of its nicknames if it has been configured to 2389 have more than one. This is a 16-bit unsigned integer that defaults, 2390 for an unconfigured RBridge, to 0x8000. Tree roots are ordered with 2391 highest numerical priority being highest priority, then with system 2392 ID of the RBridge (numerically higher = higher priority) as tie 2393 breaker, and if that is equal, by the numerically higher nickname 2394 value having priority. 2396 Each RBridge advertises in its LSP the maximum number of distribution 2397 trees that it can compute and the number of trees that it wants all 2398 RBridges in the campus to compute. The number of trees, k, that are 2399 computed for the campus is the number wanted by the RBridge RB1, 2400 which has the nickname with the highest "tree root" priority, but no 2401 more than the number of trees supported by the RBridge in the campus 2402 which supports the fewest trees. If RB1 does not specify the specific 2403 distribution tree roots as described below, then the k highest 2404 priority trees are the trees that will be computed by all RBridges. 2405 Note that some of these k highest priority trees might be rooted at 2406 the same RBridge, if that RBridge has multiple nicknames. 2408 If an RBridge specifies the number of trees it can compute, or the 2409 number of trees it wants computed for the campus, as 0, it is treated 2410 as specifying them as 1. Thus k defaults to 1. 2412 In addition, the RBridge RB1 having the highest root priority 2413 nickname might explicitly advertise a set of s trees by providing a 2414 list of s nicknames. In that case, the first k of those s trees will 2415 be computed. If s is less than k, or if any of the s nicknames 2416 associated with the trees RB1 is advertising does not exist within 2417 the LSP database, then the RBridges still compute k trees, but the 2418 remaining trees they select are the highest priority trees, such that 2419 k trees are computed. 2421 There are two exceptions to the above, which can cause fewer 2422 distribution trees to be computed, as follows: 2424 o A nickname whose tree root priority is zero is never used as a 2425 tree root except that if all nicknames have priority zero, the 2426 highest priority among them as determined by the tie breakers is 2427 used as a tree root so that there is always guaranteed to be at 2428 least one distribution tree. 2430 o As a transient condition, two or more identical nicknames can 2431 appear in the list of roots for trees to be computed. In such a 2432 case, it is useless to compute a tree for the nickname(s) that are 2433 about to be lost by the RBridges holding them. So a distribution 2434 tree is only computed for the instance of the nickname where the 2435 priority to hold that nickname value is highest, reducing the 2436 total number of trees computed. (It would also be of little use to 2437 go further down the priority ordered list of possible tree root 2438 nicknames to maintain the number of tree as the additional tree 2439 roots found this way would only be valid for a very brief nickname 2440 transition period.) 2442 The k trees calculated for a campus are ordered and numbered from 1 2443 to k. In addition to advertising the number k, RB1 might explicitly 2444 advertise a set of s trees by providing a list of s nicknames that 2445 are the root of the trees. 2447 - If s == k, then the trees are numbered in the order of RB1 2448 advertises them. 2450 - If s == 0, then the trees are numbered in order of decreasing 2451 priority. For example, if RB1 advertises only that k=2, then the 2452 highest priority tree is number 1 and the 2nd highest priority 2453 tree is number 2. 2455 - If s < k, then those advertised by RB1 are numbered from 1 in the 2456 order advertised. Then the remainder are chosen by priority order 2457 from among the remaining possible trees with the numbering 2458 continuing. For example, if RB1 advertises k=4, advertises { Tx, 2459 Ty } as the nicknames of the root of the trees, and the campus 2460 wide priority ordering of trees in decreasing order is Ty > Ta > 2461 Tc > Tb > Tx, the numbering will be as follows: Tx is 1 and Ty is 2462 2 since that is the order they are advertised in by RB1. Then Ta 2463 is 3 and Tc is 4 because they are the highest priority trees that 2464 have not already been numbered. 2466 4.5.1 Distribution Tree Calculation 2468 RBridges do not use spanning tree to calculate distribution trees. 2469 Instead, distribution trees are calculated based on the link state 2470 information, selecting a particular RBridge nickname as the root. 2471 Each RBridge RBn independently calculates a tree rooted at RBi by 2472 performing the SPF (Shortest Path First) calculation with RBi as the 2473 root without requiring any additional exchange of information. 2475 It is important, when building a distribution tree, that all RBridges 2476 choose the same links for that tree. Therefore, when there are equal 2477 cost paths for a particular tree, all RBridges need to use the same 2478 tie-breakers. It is also desirable to allow splitting of traffic on 2479 as many links as possible. For this reason, a simple tie-breaker such 2480 as "always choose the parent with lower ID" would not be desirable. 2481 Instead, TRILL uses the tree number as a parameter in the tie- 2482 breaking algorithm. 2484 When building the tree number j, remember all possible equal cost 2485 parents for node N. After calculating the entire "tree" (actually, 2486 directed graph), for each node N, if N has "p" parents, then order 2487 the parents according to 7-octet IS-IS ID. For tree j, choose N's 2488 parent as choice j mod p. 2490 Note that there might be multiple equal cost links between N and 2491 potential parent P that have no pseudonodes, either because they are 2492 point-to-point links, or pseudonode-suppressed links. Such links will 2493 be treated as a single link for the purpose of tree building, because 2494 they all have the same parent P, whose IS-IS ID is "P.0". 2496 In other words, the set of potential parents for N, for the tree 2497 rooted at R, are those that give equally minimal cost paths from N to 2498 R, and which have distinct IS-IS IDs, based on what is reported in 2499 LSPs. 2501 4.5.2 Multi-destination Frame Checks 2503 When a multi-destination TRILL encapsulated frame is received by an 2504 RBridge, there are four checks performed, each of which may cause the 2505 frame to be discarded: 2507 1. Tree Adjacency Check: Each RBridge RBn keeps a set of adjacencies 2508 ( { port, neighbor } pairs ) for each distribution tree it is 2509 calculating. One of these adjacencies is toward the tree root RBi 2510 and the others are toward the leaves. Once the adjacencies are 2511 chosen, it is irrelevant which ones are towards the root RBi, and 2512 which are away from RBi. RBridges MUST drop a multi-destination 2513 frame that arrives at a port from an RBridge that is not an 2514 adjacency for the tree on which the frame is being distributed. 2515 Let's suppose that RBn has calculated that adjacencies a, c, and f 2516 are in the RBi tree. A multi-destination frame for the 2517 distribution tree RBi is received only from one of the adjacencies 2518 a, c, or f (otherwise it is discarded) and forwarded to the other 2519 two adjacencies. Should RBn have multiple ports on a link, a 2520 multidestination frame it sends on one of these ports will be 2521 received by the others but will be discarded as an RBridge is not 2522 adjacent to itself. 2524 2. RPF Check: Another technique used by RBridges for avoiding 2525 temporary multicast loops during topology changes is the Reverse 2526 Path Forwarding Check. It involves checking that a multi- 2527 destination frame, based on the tree and the ingress RBridge, 2528 arrives from the expected link. RBridges MUST drop multi- 2529 destination frames that fail the RPF check. 2531 To limit the amount of state necessary to perform the RPF check, 2532 each RBridge RB2 MUST announce which trees RB2 may choose when RB2 2533 ingresses a multi-destination packet. When any RBridge, say, RB3, 2534 is computing the tree from nickname X, RB3 computes, for each 2535 RBridge RB2 that might act as ingress for tree X, the link on 2536 which RB3 should receive a packet from ingress RB2 on tree X, and 2537 note for that link that RB2 is a legal ingress RBridge for tree X. 2539 The information to determine which trees RB2 might choose is 2540 included in RB2's LSP. Similarly to how the highest priority 2541 RBridge RB1 specifies the k trees that will be computed by all 2542 RBridges, RB2 specifies a number j "number of ingress trees", can 2543 explicitly specify a set of nicknames of ingress trees in the 2544 field "specified ingress tree nicknames", or a combination of 2545 specified trees and trees selected from the highest priority 2546 trees. If RB2 specifies any trees that are not in the k trees as 2547 specified by RB1, they are ignored. 2549 The j potential ingress trees for RB2 are the ones with nicknames 2550 that RB2 has explicitly specified in "specified ingress tree 2551 nicknames" (and that are included in the k campus-wide trees 2552 selected by highest priority RBridge RB1), with the remainder (up 2553 to the maximum of {j,k}) being the highest priority of the k 2554 campus-wide trees. 2556 The default value for j is 1. The value 0 for j is special and 2557 means that RB2 can pick any of the k trees being computed for the 2558 campus. 2560 3. Parallel Links Check: If the tree-building and tie-breaking for a 2561 particular multi-destination frame distribution tree selects a 2562 non-pseudonode link between RB1 and RB2, that "RB1-RB2 link" might 2563 actually consist of multiple links. These parallel links would be 2564 visible to RB1 and RB2, but not to the rest of the campus (because 2565 the links are not represented by pseudonodes). If this bundle of 2566 parallel links is included in a tree, it is important for RB1 and 2567 RB2 to decide which link to use, but is irrelevant to other 2568 RBridges, and therefore, the tie-breaking algorithm need not be 2569 visible to any RBridges other than RB1 and RB2. In this case, 2570 RB1-RB2 adjacencies are ordered as follows, with the one "most 2571 preferred" adjacency being the one on which RB1 and RB2 transmit 2572 to and receive from each other. 2574 a) Most preferred are those established by P2P Hellos. Tie- 2575 breaking among those is based on preferring the one with the 2576 numerically highest Extended Circuit ID as associated with the 2577 adjacency by the RBridge with the highest System ID. 2579 b) Next considered are those established through TRILL-Hello 2580 frames, with suppressed pseudonodes. Note that the pseudonode 2581 is suppressed in LSPs, but still appears in the TRILL-Hello, 2582 and therefore is available for this tie-breaking. Among these 2583 links, the one with the numerically largest pseudonode ID is 2584 preferred. 2586 4. Port Group Check: If an RBridge has multiple ports attached to the 2587 same link, a multidestination frame it is receiving will arrive on 2588 all of them. All but one received copy of such a frame MUST be 2589 discarded to avoid duplication. All such frames that are part of 2590 the same flow must be accepted on the same port to avoid re- 2591 ordering. 2593 When a topology change occurs (including apparent changes during 2594 start up), an RBridge MUST adjust its input distribution tree filters 2595 no later than it adjusts its output forwarding. 2597 4.5.3 Pruning the Distribution Tree 2599 Each distribution tree SHOULD be pruned per-VLAN, eliminating 2600 branches that have no potential receivers downstream. Multi- 2601 destination TRILL data frames SHOULD only be forwarded on branches 2602 that are not pruned. 2604 Further pruning SHOULD be done in two cases: (1) IGMP [RFC3376], MLD 2605 [RFC2710], and MRD [RFC4286] messages, where these are to be 2606 delivered only to links with IP Multicast routers; and (2) other 2607 multicast frames derived from an IP multicast address that should be 2608 delivered only to links that have registered listeners, plus links 2609 which have IP Multicast routers, except for IP multicast addresses 2610 which must be broadcast. Each of these cases are scoped per-VLAN. 2612 Let's assume that RBridge RBn knows that adjacencies (a, c, and f) 2613 are in the nickname1 distribution tree. RBn marks pruning 2614 information for each of the adjacencies in the nickname1-tree. For 2615 each adjacency and for each tree, RBn marks: 2617 o the set of VLANs reachable downstream, 2619 o for each one of those VLANs, flags indicating whether there are 2620 IPv4 or IPv6 multicast routers downstream, and 2622 o the set of Layer 2 multicast addresses derived from IP multicast 2623 groups for which there are receivers downstream. 2625 4.5.4 Tree Distribution Optimization 2627 RBridges MUST determine the VLAN associated with all native frames 2628 they ingress and properly enforce VLAN rules on the emission of 2629 native frames at egress RBridge ports according to how those ports 2630 are configured and designated as appointed forwarders. RBridges 2631 SHOULD also prune the distribution tree of multi-destination frames 2632 according to VLAN. But, since they are not required to do such 2633 pruning, they may receive TRILL data or ESADI frames that should have 2634 been VLAN pruned earlier in the tree distribution. They silently 2635 discard such frames. A campus may contain some Rbridges that prune on 2636 VLAN and some that do not. 2638 The situation is more complex for multicast. RBridges SHOULD analyze 2639 IP derived native multicast frames, and learn and announce listeners 2640 and IP multicast routers for such frames as discussed in Section 4.7 2641 below. And they SHOULD prune the distribution of IP derived multicast 2642 frames based on such learning and announcements. But, they are not 2643 required to prune based on IP multicast listener and router 2644 attachment state. And, unlike VLANs, where VLAN attachment state of 2645 ports MUST be maintained and honored, RBridges are not required to 2646 maintain IP multicast listener and router attachment state. 2648 An RBridge that does not examine native IGMP [RFC3376], MLD 2649 [RFC2710], and MRD [RFC4286] frames that it ingresses MUST advertise 2650 that it has IPv4 and IPv6 IP multicast routers attached for all the 2651 VLANs for which it is an appointed forwarder. It need not advertise 2652 any IP derived multicast listeners. This will cause all IP derived 2653 multicast traffic to be sent to this RBridge for those VLANs. It then 2654 egresses that traffic onto the links for which it is appointed 2655 forwarder where the VLAN of the traffic matches the VLAN for which it 2656 is appointed forwarder on that link. (This may cause the suppression 2657 of certain IGMP membership report messages from end stations but that 2658 is not significant as any multicast traffic such reports would be 2659 requesting will be sent to such end stations under these 2660 circumstances.) 2662 A campus may contain a mixture of Rbridges with different levels of 2663 IP derived multicast optimization. An RBridge may receive IP derived 2664 multicast frames that should have been pruned earlier in the tree 2665 distribution. It silently discards such frames. 2667 See also "Considerations for Internet Group Management Protocol 2668 (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" 2669 [RFC4541]. 2671 4.5.5 Forwarding Using a Distribution Tree 2673 With full optimization, forwarding a multi-destination data frame is 2674 done as follows. References to adjacencies below do not include the 2675 adjacency on which a frame was received. 2677 o The RBridge RBn receives a multi-destination TRILL data frame with 2678 inner VLAN-x and a TRILL header indicating that the selected tree 2679 is the nickanme1 tree; 2681 o if the source from which the frame was received is not one of the 2682 adjacencies in the nickname1 tree for the specified ingress 2683 RBridge, the frame is dropped (see Section 4.5.1); 2685 o else, if the frame is an IGMP or MLD announcement message or an 2686 MRD query message, then the encapsulated frame is forwarded onto 2687 adjacencies in the nickname1 tree that indicate there are 2688 downstream VLAN-x IPv4 or IPv6 multicast routers as appropriate; 2690 o else, if the frame is for a Layer 2 multicast address derived from 2691 an IP multicast group, but its IP address is not the range of IP 2692 multicast addresses that must be treated as broadcast, the frame 2693 is forwarded onto adjacencies in the nickname1 tree that indicate 2694 there are downstream VLAN-x IP multicast routers of the 2695 corresponding type (IPv4 or IPv6), as well as adjacencies that 2696 indicate there are downstream VLAN-x receivers for that group 2697 address; 2699 o else (the inner frame is for a Layer 2 multicast address not 2700 derived from an IP multicast group or an unknown destination or 2701 broadcast or an IP multicast address which is required to be 2702 treated as broadcast) the frame is forwarded onto an adjacency if 2703 and only if that adjacency is in the nickname1 tree, and marked as 2704 reaching VLAN-x links. 2706 For each link for which RBn is appointed forwarder, RBn additionally 2707 checks to see if it should decapsulate the frame and send it to the 2708 link in native form, or process the frame locally. 2710 TRILL ESADI frames will be delivered only to RBridges that are 2711 appointed forwarders for their VLAN. Such frames will be multicast 2712 throughout the campus, like other non-IP-derived multicast data 2713 frames, on the distribution tree chosen by the RBridge which created 2714 the TRILL ESADI frame, and pruned according to the Inner.VLAN ID. 2715 Thus all the RBridges that are appointed forwarders for a link in 2716 that VLAN receive them. 2718 4.6 Frame Processing Behavior 2720 This section describes RBridge behavior for all varieties of received 2721 frames, including how they are forwarded when appropriate. Section 2722 4.6.1 covers native frames, Section 4.6.2 covers TRILL frames, and 2723 Section 4.6.3 covers layer 2 control frames. Processing may be 2724 organized or sequenced in a different way than described here as long 2725 as the result is the same. See Section 1.4 for frame type 2726 definitions. 2728 Corrupt frames, for example frames that are not a multiple of 8 bits, 2729 are too short or long for the link protocol/hardware in use, or have 2730 a bad FCS are discarded on receipt by an RBridge port as they are 2731 discarded on receipt at an IEEE 802.1 bridge port. 2733 Source address information ( { VLAN, Outer.MacSA, port } ) is learned 2734 by default from any frame with a unicast sources address (see Section 2735 4.8). 2737 4.6.1 Receipt of a Native Frame 2739 If the port is configured as disabled or if end station service is 2740 disabled on the port by configuring it as a trunk port or configuring 2741 it to use P2P Hellos, the frame is discarded. 2743 The ingress Rbridge RB1 determines the VLAN ID for a native frame 2744 according to the same rules as IEEE [802.1Q-2005] bridges do (see 2745 Appendix D and Section 4.9.2). Once the VLAN is determined, if RB1 is 2746 not the appointed forwarder for that VLAN on the port where the frame 2747 was received or is inhibited, the frame is discarded. If it is 2748 appointed forwarder for that VLAN and is not inhibited (see Section 2749 4.2.4.3), then the native frame is forwarded according to 4.6.1.1 if 2750 it is unicast and according to 4.6.1.2 if it is multicast or 2751 broadcast. 2753 4.6.1.1 Native Unicast Case 2755 If the destination MAC address of the native frame is a unicast 2756 address, the following steps are performed. 2758 The Layer 2 destination address and VLAN are looked up in the ingress 2759 RBridge's database of MAC addresses and VLANs to find the egress 2760 RBridge RBm or the local egress port or to discover that the 2761 destination is the receiving RBridge or is unknown. One of the 2762 following four cases will apply: 2764 1. If the destination is the receiving RBridge, the frame is locally 2765 processed. 2767 2. If the destination is known to be on the same link from which the 2768 native frame was received but is not the receiving RBridge, the 2769 RBridge silently discards the frame, since the destination should 2770 already have received it. 2772 3. If the destination is known to be on a different local link for 2773 which RBm is the appointed forwarder, then RB1 converts the native 2774 frame to a TRILL data frame with an Outer.MacDA of the next hop 2775 RBridge towards RBm, a TRILL header with M = 0, an ingress 2776 nickname for RB1, and the egress nickname for RBm. If ingress RB1 2777 has multiple nicknames, it SHOULD use the same nickname in the 2778 ingress field whenever it encapsulates a native frame from any 2779 particular source MAC address and VLAN. This simplifies end node 2780 learning. If RBm is RB1, processing then proceeds as in 4.6.2.4; 2781 otherwise, the Outer.MacSA is set to the MAC address of the RB1 2782 port on the path to the next hop RBridge towards RBm and the frame 2783 is queued for transmission out that port. 2785 4. If a unicast destination MAC is unknown in the frame's VLAN, RB1 2786 handles the frame as described in Section 4.6.1.2 for a broadcast 2787 frame except that the Inner.MacDA is the original native frame's 2788 unicast destination address. 2790 4.6.1.2 Native Multicast and Broadcast Frames 2792 If the RBridge has multiple ports attached to the same link, all but 2793 one received copy of a native multicast or broadcast frame is 2794 discarded to avoid duplication. All such frames that are part of the 2795 same flow must be accepted on the same port to avoid re-ordering. 2797 If the frame is a native IGMP [RFC3376], MLD [RFC2710], or MRD 2798 [RFC4286] frame, then RB1 SHOULD analyze it, learn any group 2799 membership or IP multicast router presence indicated, and announce 2800 that information for the appropriate VLAN in its LSP (see Section 2801 4.7). 2803 For all multi-destination native frames, RB1 forwards the frame in 2804 native form to its links where it is appointed forwarder for the 2805 frame's VLAN, subject to further pruning and inhibition. In addition, 2806 it converts the native frame to a TRILL data frame with the All- 2807 RBridges multicast address as Outer.MacDA, a TRILL header with the 2808 multi-destination bit M = 1, the ingress nickname for RB1, and the 2809 egress nickname for the root of the distribution tree it decides to 2810 use. It then forwards the frame on the pruned distribution tree (see 2811 Section 4.5) setting the Outer.MacSA of each copy sent to the MAC 2812 address of the RB1 port on which it is sent. 2814 The default is for RB1 to write into the egress nickname field one of 2815 the nicknames for a distribution tree, from the set of distribution 2816 trees RB1 has announced it might use, whose root is least cost from 2817 RB1. RB1 MAY choose different distribution trees for different frames 2818 if RB1 has been configured to path-split multicast. In that case RB1 2819 MUST select a tree by specifying a nickname that is a distribution 2820 tree root (see Section 4.5). Also, RB1 MUST select a nickname that 2821 RB1 has announced (in RB1's own LSP) to be one of those that RB1 2822 might use. 2824 4.6.2 Receipt of a TRILL Frame 2826 A TRILL frame has either the TRILL or L2-IS-IS Ethertype or has a 2827 multicast Outer.MacDA allocated to TRILL (see Section 7.2). The 2828 following tests are performed sequentially and the first which 2829 matches controls the handling of the frame: 2831 1. If the Outer.MacDA is All-IS-IS-RBridges and the Ethertype is 2832 L2-IS-IS, the frame is handled as described in Section 4.6.2.1. 2834 2. If the Outer.MacDA is a multicast address allocated to TRILL other 2835 than All-RBridges, the frame is discarded. 2837 3. If the Outer.MacDA is a unicast address other than the address of 2838 the receiving Rbridge, the frame is discarded. (Such discarded 2839 frames are most likely addressed to another RBridge on a multi- 2840 access link and that other Rbridge will handle them.) 2842 4. If the Ethertype is not TRILL, the frame is discarded. 2844 5. If the Version field in the TRILL Header is greater than 0, the 2845 frame is discarded. 2847 6. If the hop count is 0, the frame is discarded. 2849 7. If the Outer.MacDA is multicast and the M bit is zero or if the 2850 Outer.MacDA is unicast and M bit is one, the frame is discarded. 2852 8. By default, an RBridge MUST NOT forward TRILL-encapsulated frames 2853 from a neighbor that it does not have a TRILL IS-IS adjacency 2854 with. RBridges MAY be configured per port to accept these frames 2855 for forwarding in cases where it is known that a non-peering 2856 device (such as an end-station) is configured to originate TRILL- 2857 encapsulated frames that can be safely forwarded. 2859 9. The Inner.MacDA is then tested. If it is the All-ESADI-RBridges 2860 multicast address and RBn implements the ESADI feature, processing 2861 proceeds as in Section 4.6.2.2 below. If it is any other address 2862 or RBn does not implement the ESADI feature, processing proceeds 2863 as in Section 4.6.2.3. 2865 4.6.2.1 TRILL Control Frames 2867 The frame is processed by the TRILL IS-IS instance on RBn and is not 2868 forwarded. 2870 4.6.2.2 TRILL ESADI Frames 2872 If M == 0, the frame is silently discarded. 2874 The egress nickname designates the distribution tree. The frame is 2875 forwarded as described in Section 4.6.2.5. In addition, if the 2876 forwarding Rbridge is an appointed forwarder for a link in the 2877 specified VLAN and implements a TRILL ESADI for that VLAN and ESADI 2878 is enabled, the inner frame is decapsulated and provided to that 2879 local ESADI. 2881 4.6.2.3 TRILL Data Frames 2883 The M flag is then checked. If it is zero, processing continues as 2884 described in Section 4.6.2.4, if it is one, processing continues as 2885 described in Section 4.6.2.5. 2887 4.6.2.4 Known Unicast TRILL Data Frames 2889 The egress nickname in the TRILL header is examined and, if it is 2890 unknown or reserved, the frame is discarded. 2892 If RBn is a transit RBridge the hop count is decremented by one and 2893 the frame forwarded to the next hop RBridge towards the egress 2894 RBridge. (The provision permitting RBridges to decrease the hop count 2895 by more than one under some circumstances (see Section 3.6) applies 2896 only to multi-destination frames, not to the known unicast frames 2897 considered in this subsection.) The Inner.VLAN is not examined by a 2898 transit RBridge when it forwards a known unicast TRILL data frame. 2899 For the forwarded frame, the Outer.MacSA is the MAC address of the 2900 transmitting port, the Outer.MacDA is the unicast address of the next 2901 hop RBridge, and the VLAN is the Designated VLAN on the link onto 2902 which the frame is being transmitted. 2904 If RBn is not a transit RBridge, that is if the egress RBridge 2905 indicated is the RBridge performing the processing, the Inner.MacSA 2906 and Inner.VLAN ID are, by default, learned as associated with the 2907 ingress nickname unless that nickname is unknown or reserved or the 2908 Inner.MacSA is not unicast. Then the frame being forwarded is 2909 decapsulated to native form and the following checks are performed: 2911 o The Inner.MacDA is checked. If it is not unicast, the frame is 2912 discarded. 2914 o If the Inner.MacDA corresponds to the RBridge doing the 2915 processing, the frame is locally delivered. 2917 o The Inner.VLAN ID is checked. If it is 0x0 or 0xFFF, the frame is 2918 discarded. 2920 o The Inner.MacDA and Inner.VLAN ID are looked up in RBn's local 2921 address cache and the frame is then either sent onto the link 2922 containing the destination, if the RBridge is appointed forwarder 2923 for that link for the frame's VLAN and is not inhibited (or 2924 discarded if it is inhibited), or processed as in one of the 2925 following two paragraphs. 2927 A known unicast TRILL data frame can arrive at the egress Rbridge 2928 only to find that the combination of Inner.MacDA and Inner.VLAN is 2929 not actually known by that RBridge. One way this can happen is that 2930 the address information may have timed out in the egress RBridge MAC 2931 address cache. In this case, the egress RBridge sends the native 2932 frame out on all links that are in the frame's VLAN for which the 2933 RBridge is appointed forwarder and has not been inhibited, except 2934 that it MAY refrain from sending the frame on links where it knows 2935 there cannot be an end station with the destination MAC address, for 2936 example the link port is configured as a trunk (see Section 4.9.1). 2938 If, due to manual configuration or learning from layer 2 registration 2939 or ESADI, the destination MAC and VLAN appear in RBn's local address 2940 cache for two or more links for which RBn is an uninhibited appointed 2941 forwarder for the frame's VLAN, RBn sends the frame on all such 2942 links. 2944 4.6.2.5 Multi-Destination TRILL Data Frames 2946 The egress and ingress nicknames in the TRILL header are examined 2947 and, if either is unknown or reserved, the frame is discarded. 2949 The Outer.MacSA is checked and the frame discarded if it is not a 2950 tree adjacency for the tree indicated by the egress RBridge nickname 2951 on the port where the frame was received. The Reverse Path 2952 Forwarding Check is performed on the ingress and egress nicknames and 2953 the frame discarded if it fails. If there are multiple TRILL-Hello 2954 pseudonode suppressed parallel links to the previous hop RBridge, the 2955 frame is discarded if it has been received on the wrong one. If the 2956 RBridge has multiple ports connected to the link, the frame is 2957 discarded unless it was received on the right one. For more 2958 information on the checks in this paragraph, see Section 4.5.2. 2960 If the Inner.VLAN ID of the frame is 0x0 or 0xFFF, the frame is 2961 discarded. 2963 If the RBridge is an appointed forwarder for the Inner.VLAN ID of the 2964 frame, the Inner.MacSA and Inner.VLAN ID are, by default, learned as 2965 associated with the ingress nickname unless that nickname is unknown 2966 or reserved or the Inner.MacSA is not unicast. A copy of the frame is 2967 then decapsulated, sent in native form on those links in its VLAN for 2968 which the RBridge is appointed forwarder subject to additional 2969 pruning and inhibition as described in Section 4.2.4.3, and/or 2970 locally processed as appropriate. 2972 The hop count is decreased (possibly by more than one, see Section 2973 3.6) and the frame is forwarded down the tree specified by the egress 2974 RBridge nickname pruned as described in Section 4.5. 2976 For the forwarded frame, the Outer.MacSA is set to that of the port 2977 on which the frame is being transmitted, the Outer.MacDA is the All- 2978 RBridges multicast address, and the VLAN is the Designated VLAN of 2979 the link on which the frame is being transmitted. 2981 4.6.3 Receipt of a Layer 2 Control Frame 2983 Low-level control frames received by an RBridge are handled within 2984 the port where they are received as described in Section 4.9. 2986 There are two types of high-level control frames, distinguished by 2987 their destination address, which are handled as described in the 2988 sections referenced below. 2990 Name Section Destination Address 2992 BPDU 4.9.3 01-80-C2-00-00-00 2993 VRP 4.9.4 01-80-C2-00-00-21 2995 4.7 IGMP, MLD, and MRD Learning 2997 Ingress RBridges SHOULD learn, based on native IGMP [RFC3376], MLD 2998 [RFC2710], and MRD [RFC4286] frames they receive in VLANs for which 2999 they are an uninhibited appointed forwarder, which IP derived 3000 multicast messages should be forwarded onto which links. Such frames 3001 are also, in general, encapsulated as TRILL data frames and 3002 distributed as described below and in Section 4.5. 3004 An IGMP or MLD membership report received in native form from a link 3005 indicates a multicast group listener for that group on that link. An 3006 IGMP or MLD query or an MRD advertisement received in native form 3007 from a link indicates the presence of an IP multicast router on that 3008 link. 3010 IP multicast group membership reports have to be sent throughout the 3011 campus and delivered to all IP multicast routers, distinguishing IPv4 3012 and IPv6. All IP-derived multicast traffic must also be sent to all 3013 IP multicast routers for the same version of IP. 3015 IP multicast data SHOULD only be sent on links where there is either 3016 an IP multicast router for that IP type (IPv4 or IPv6) or an IP 3017 multicast group listener for that IP multicast derived MAC address, 3018 unless the IP multicast address is in the range required to be 3019 treated as broadcast. 3021 RBridges do not need to announce themselves as listeners to the IPv4 3022 All-Snoopers multicast group (the group used for MRD reports 3023 [RFC4286]), because the IPv4 multicast address for that group is in 3024 the range where all frames sent to that IP multicast addresses must 3025 be broadcast (see [RFC4541], Section 2.1.2). However, RBridges that 3026 are performing IPv6 derived multicast optimization MUST announce 3027 themselves as listeners to the IPv6 All-Snoopers multicast group. 3029 See also "Considerations for Internet Group Management Protocol 3030 (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches" 3031 [RFC4541]. 3033 4.8 End Station Address Details 3035 RBridges have to learn the MAC addresses and VLANs of their locally 3036 attached end stations for link/VLAN pairs for which they are the 3037 appointed forwarder so they can 3039 o forward the native form of incoming known unicast TRILL data 3040 frames onto the correct link and 3042 o decide, for an incoming native unicast frame from a link, where 3043 the RBridge is the appointed forwarder for the frame's VLAN, 3044 whether the frame is 3046 - known to have been destined for another end station on the same 3047 link, so the RBridge need do nothing, or 3049 - has to be converted to a TRILL data frame and forwarded. 3051 RBridges need to learn the MAC addresses, VLANs, and remote RBridges 3052 of remotely attached end stations for VLANs for which they and the 3053 remote RBridge are an appointed forwarder, so they can efficiently 3054 direct native frames they receive that are unicast to those addresses 3055 and VLANs. 3057 4.8.1 Learning End Station Addresses 3059 There are five independent ways an RBridge can learn end station 3060 addresses as follows: 3062 1. From the observation of VLAN-x frames received on ports where it 3063 is appointed VLAN-x forwarder, learning the { source MAC, VLAN, 3064 port } triplet of received frames. 3066 2. The { source MAC, VLAN, ingress RBridge nickname } triplet of any 3067 native frames that it decapsulates. 3069 3. By Layer 2 registration protocols learning the { source MAC, VLAN, 3070 port } of end stations registering at a local port. 3072 4. By running one or more TRILL ESADIs that receive remote address 3073 information and/or transmit local address information. 3075 5. By management configuration. 3077 RBridges MUST implement capabilities 1 and 2 above. RBridges use 3078 these capabilities unless configured, for one or more particular 3079 VLANs and/or ports, not to learn from either received frames or from 3080 decapsulating native frames to be transmitted or both. 3082 RBridges MAY implement capabilities 3 and 4 above. If capability 4 is 3083 implemented, such ESADIs are run only when the RBridge is configured 3084 to do so on a per-VLAN basis. 3086 RBridges SHOULD implement capability 5. 3088 Entries in the table of learned MAC and VLAN addresses and associated 3089 information also have a one octet unsigned confidence level 3090 associated with each entry. Such information learned from the 3091 observation of data has a confidence of 0x20 unless configured to 3092 have a different confidence. This confidence level can be configured 3093 on a per RBridge basis separately for information learned from local 3094 native frames and that learned from remotely originated encapsulated 3095 frames. Such information received via TRILL ESADI is accompanied by 3096 a confidence level in the range 0 to 254. Such information configured 3097 by management defaults to a confidence level of 255 but may be 3098 configured to have another value. 3100 The table of learned MAC addresses includes (1) { confidence, VLAN, 3101 MAC address, local port } for addresses learned from local native 3102 frames and local registration protocols, (2) { confidence, VLAN, MAC 3103 address, egress RBridge nickname } for addresses learned from remote 3104 encapsulated frames and ESADI link state databases, and (3) 3105 additional information to implement timeout of learned addresses, 3106 statically configured addresses, and the like. 3108 When a new address and related information learned from observing 3109 data frames are to be entered into the local database there are three 3110 possibilities: 3112 A. If this is a new { address, VLAN } pair, the information is 3113 entered accompanied by the confidence level. 3115 B. If there is already an entry for this { address, VLAN } pair with 3116 the same accompanying delivery information, the confidence level 3117 in the local database is set to the maximum of its existing 3118 confidence level and the confidence level with which it is being 3119 learned. In addition, if the information is being learned with the 3120 same or a higher confidence level than its existing confidence 3121 level, timer information is reset. 3123 C. If there is already an entry for this { address, VLAN } pair with 3124 different information, the learned information replaces the older 3125 information only if it is being learned with higher or equal 3126 confidence than that in the database entry. If it replaces older 3127 information, timer information is also reset. 3129 4.8.2 Forgetting End Station Addresses 3131 While RBridges need to learn end station addresses as described 3132 above, it is equally important that they be able to forget such 3133 information. Otherwise, frames for end stations that have moved to a 3134 different part of the campus could be indefinitely black holed by 3135 RBridges with stale information as to the link to which the end 3136 station is attached. 3138 For end station address information locally learned from frames 3139 received, the time out from the last time a native frame was received 3140 or decapsulated with the information conforms to the recommendations 3141 of [802.1D]. It is referred to as the "Ageing Time" and is 3142 configurable per RBridge with a range of from 10 seconds to 1,000,000 3143 seconds and a default value of 300 seconds. 3145 The situation is different for end station address information 3146 acquired via TRILL ESADI. It is up to the originating RBridge to 3147 decide when to remove such information from the ESADI LSP (or up to 3148 ESADI timeouts if the originating RBridge becomes inaccessible). 3150 When an RBridge ceases to be appointed forwarder for VLAN-x on a 3151 port, it forgets all end station address information learned from the 3152 observation of VLAN-x native frames received on that port. It also 3153 increments a per VLAN counter of the number of times it lost 3154 appointed forwarder status on one of its ports for that VLAN. 3156 When, for all of its ports, RBridge RBn is no longer appointed 3157 forwarder for VLAN-x, it forgets all end station address information 3158 learned from decapsulating VLAN-x native frames. Also, if RBn is 3159 participating in TRILL ESADI for VLAN-x, it ceases to so participate 3160 after sending a final LSP nulling out the end station address 3161 information for that VLAN which it had been originating. In addition, 3162 all other RBridges that are VLAN-x forwarder on at least one of their 3163 ports notice that the link state data for RBn has changed to show 3164 that it no longer has a link on VLAN-x. In response, they forget all 3165 end station address information they have learned from decapsulating 3166 VLAN-x frames that show RBn as the ingress RBridge. 3168 When the appointed forwarder lost counter for RBridge RBn for VLAN-x 3169 is observed to increase via the TRILL IS-IS link state database but 3170 RBn continues to be an appointed forwarder for VLAN-x on at least one 3171 of its ports, every other RBridge that is an appointed forwarder for 3172 VLAN-x modifies the aging of all the addresses it has learned by 3173 decapsulating native frames in VLAN-x from ingress RBridge RBn as 3174 follows: The time remaining for each entry is adjusted to be no 3175 larger than a per RBridge configuration parameter called (to 3176 correspond to [802.1D]) "Forward Delay". This parameter is in the 3177 range of 4 to 30 seconds with a default value of 15 seconds. 3179 4.8.3 Shared VLAN Learning 3181 RBridges can map VLAN IDs into a smaller number of identifiers for 3182 purposes of address learning, as [802.1Q-2005] bridges can. Then, 3183 when a lookup is done in learned address information, this identifier 3184 is used for matching in place of the VLAN ID. If the ID of the VLAN 3185 on which the address was learned is not retained, then there are the 3186 following consequences: 3188 o The RBridge no longer has the information needed to participate in 3189 TRILL ESADI for the VLANs who's ID is not being retained. 3191 o In cases where 4.8.2 above requires the discarding of learned 3192 address information based on a particular VLAN, when the VLAN ID 3193 is not available for entries under a shared VLAN identifier, 3194 instead the time remaining for each entry under that shared VLAN 3195 identifier is adjusted to be no longer than the RBridge's "Forward 3196 Delay". 3198 Although outside the scope of this specification, there are some 3199 Layer 2 features in which a set of VLANs has shared learning, where 3200 one of the VLANs is the "primary" and the other VLANs in the group 3201 are "secondaries". An example of this is where traffic from different 3202 communities are separated using VLAN tags, and yet some resource 3203 (such as an IP router or DHCP server) is to be shared by all the 3204 communities. A method of implementing this feature is to give a VLAN 3205 tag, say Z, to a link containing the shared resource, and have the 3206 other VLANs, say A, C, and D, be part of the group { primary = Z, 3207 secondaries = A, C, D }. An RBridge, aware of this grouping, attached 3208 to one of the secondary VLANs in the group also claims to be attached 3209 to the primary VLAN. So an RBridge attached to A would claim to also 3210 be attached to Z. An RBridge attached to the primary would claim to 3211 be attached to all the VLANs in the group. 3213 This document does not specify how VLAN groups might be used. Only 3214 RBridges that participate in a VLAN group will be configured to know 3215 about the VLAN group. However, to detect misconfiguration, an RBridge 3216 configured to know about a VLAN group SHOULD report the VLAN group in 3217 its LSP. 3219 4.9 RBridge Ports 3221 Section 4.9.1 below describes the several RBridge port configuration 3222 bits, Section 4.9.2 gives a logical port structure in terms of frame 3223 processing, and Sections 4.9.3 and 4.9.4 describe the handling of 3224 high-level control frames. 3226 4.9.1 RBridge Port Configuration 3228 There are four per port configuration bits as follows: 3230 o Disable port bit. When this bit is set, all frames received or to 3231 be transmitted are discarded, with the possible exception of some 3232 layer 2 control frames that may be generated and transmitted or 3233 received and processed within the port. By default, ports are 3234 enabled. 3236 o End station service disable (trunk port) bit. When this bit is 3237 set, all native frames received on the port and all native frames 3238 that would have been sent on the port are discarded. (See Appendix 3239 B.) (Note that, for this document, "native frames" does not 3240 include layer 2 control frames.) By default, ports are not 3241 restricted to being trunk ports. 3243 If a port with end station service disabled reports, in a TRILL- 3244 Hello frame it sends out that port, which VLANs it provides end 3245 station support for, it reports that there are none. 3247 o TRILL traffic disable (access port) bit. If this bit is set, the 3248 goal is to avoid sending any TRILL frames, except TRILL-Hello 3249 frames, on the port since it is intended only for native end 3250 station traffic. By default, ports are not restricted to being 3251 access ports. This bit is reported in TRILL-Hello frames. If RB1 3252 is the DRB and has this bit set in its TRILL-Hello, the DRB still 3253 appoints VLAN forwarders. However, usually no pseudonode is 3254 reported, and none of the inter-RBridge links associated with that 3255 link are reported in LSPs. 3257 If the DRB RB1 does not have this bit set, but neighbor RB2 on the 3258 link does have the bit set, then RB1 does not appoint RB2 as 3259 appointed forwarder for any VLAN, and none of the RBridges 3260 (including the pseudonode) report RB2 as a neighbor in LSPs. 3262 In some cases even though the DRB has the "access port" flag set, 3263 the DRB MAY choose to create a pseudonode for the access port. In 3264 this case, the other RBridges report connectivity to the 3265 pseudonode in their LSP, but the DRB sets the "overload" flag in 3266 the pseudonode LSP. 3268 o Use P2P Hellos bit. If this bit is set, Hellos sent on this port 3269 are IS-IS P2P Hellos. By default TRILL-Hellos are used. See 3270 Section 4.2.4.1 for more information on P2P links. 3272 The dominance relationship of these four configuration bits is as 3273 follows, where configuration bits to the left dominate those to the 3274 right. That is to say, when any pair of bits are asserted, 3275 inconsistencies in behavior they mandate are resolved in favor of 3276 behavior mandated by the bit to the left in the this list. 3278 Disable > P2P > Access > Trunk 3280 4.9.2 RBridge Port Structure 3282 An RBridge port can be modeled as having a lower level structure 3283 similar to that of an [802.1Q-2005] bridge port as shown in Figure 3284 4.5. In this figure, the double lines represent the general flow of 3285 the frames and information while single lines represent information 3286 flow only. The dashed lines in connection with VRP (GVRP/MVRP) are to 3287 show that VRP support is optional. An actual RBridge port 3288 implementation may be structured in any way that provides the correct 3289 behavior. 3291 +---------------------------------------------- 3292 | RBridge 3293 | 3294 | Interport Forwarding, IS-IS. Management, ... 3295 | 3296 +----++----------------------+-------------++-- 3297 || | || 3298 Trill || Data | || 3299 || +--+---------+ || 3300 +-------------++-----+ | TRILL | || 3301 | Encapsulation | +------+ IS-IS Hello| || 3302 | Decapsulation | | | Processing | || 3303 | Processing | | +-----++-----+ || 3304 +--------------------+ | || || 3305 | RBridge Appointed +------+ || || 3306 +---+ Forwarder and | || || 3307 | | Inhibition Logic +==============\\ || //====++ 3308 | +---------+--------+-+ Native \\ ++ // 3309 | | | Frames \++/ 3310 | | | || 3311 +----+-----+ +- - + - - + | || 3312 | RBridge | | RBridge | | || All TRILL and 3313 | BPDU | | VRP | | || Native Frames 3314 |Processing| |Processing| | || 3315 +-----++---+ + - - -+- -+ | +--------++--+ <- EISS 3316 || | | | 802.1Q | 3317 || | | | Port VLAN | 3318 || | | |and priority| 3319 || | | | Processing | 3320 +---++------------++------+------------+------------+ <-- ISS 3321 | 802.1/802.3 Low Level Control Frame | 3322 | Processing, Port/Link Control Logic | 3323 +------------++-------------------------------------+ 3324 || 3325 || +------------+ 3326 || | 802.3 PHY | 3327 ++========+ (Physical +======== 802.3 3328 | Interface) | Link 3329 +------------+ 3331 Figure 4.5: Detailed RBridge Port Model 3333 Low-level control frames are handled in the lower level port / link 3334 control logic in the same way as in an [802.1Q-2005] bridge port. 3335 This can optionally include a variety of 802.1 or link specific 3336 protocols such as PAUSE (Annex 31B of [802.3]), link layer discovery 3337 [802.1AB], link aggregation [802.1AX], MAC security [802.1AE], or 3338 port based access control [802.1X]. While handled at a low level, 3339 these frames may affect higher level processing. For example, a Layer 3340 2 registration protocol may affect the confidence in learned 3341 addresses. The upper interface to this lower level port control logic 3342 corresponds to the Internal Sublayer Service (ISS) in [802.1Q-2005]. 3344 High-level control frames (BPDUs and, if supported, VRP frames) are 3345 not VLAN tagged. Although they extend through the ISS interface, they 3346 are not subject to port VLAN processing. Behavior on receipt of a 3347 VLAN tagged BPDU or VLAN tagged VRP frame, is unspecified. If a VRP 3348 is not implemented, then all VRP frames are discarded. Handling of 3349 BPDUs is described in Section 4.9.3. Handling of VRP frames is 3350 described in Section 4.9.4. 3352 Frames other than layer 2 control frames, that is, all TRILL and 3353 native frames, are subject to Port VLAN and priority processing which 3354 is the same as for an [802.1Q-2005] bridge. The upper interface to 3355 the port VLAN and priority processing corresponds to the Extended 3356 Internal Sublayer Service (EISS) in [802.1Q-2005]. 3358 In this model, RBridge port processing below the EISS layer is 3359 identical to an [802.1Q-2005] bridge except for (1) the handling of 3360 high-level control frames and (2) that the discard of frames that 3361 have exceeded the Maximum Transit Delay is not mandatory but MAY be 3362 done. 3364 As described in more detail elsewhere in this document, incoming 3365 native frames are only accepted if the RBridge is an uninhibited 3366 appointed forwarder for the frame's VLAN, after which they are 3367 normally encapsulated and forwarded; outgoing native frames are 3368 usually obtained by decapsulation and are only output if the RBridge 3369 is an uninhibited appointed forwarder for the frame's VLAN. 3371 TRILL-Hellos, MTU-probes, and MTU-acks are handled per port and, like 3372 all TRILL IS-IS frames, are never forwarded. They can affect the 3373 appointed forwarder and inhibition logic as well as the RBridge's 3374 LSP. 3376 Except TRILL-Hellos, MTU-probes, and MTU-acks, all TRILL control as 3377 well as TRILL data and ESADI frames are passed up to higher level 3378 RBridge processing on receipt and passed down for transmission on 3379 creation or forwarding. Note that these frames are never blocked due 3380 to the appointed forwarder and inhibition logic, which affects only 3381 native frames, but there are additional filters on some of them such 3382 as the Reverse Path Forwarding Check. 3384 4.9.3 BPDU Handling 3386 If RBridge campus topology were static, RBridges would simply be end 3387 stations from a bridging perspective, terminating but not otherwise 3388 interacting with spanning tree. However, there are reasons for 3389 RBridges to listen to and sometimes to transmit BPDUs as described 3390 below. Even when RBridges listen to and transmit BPDUs, this is a 3391 local RBridge port activity. The ports of a particular RBridge never 3392 interact so as to make the RBridge as a whole a spanning tree node. 3394 4.9.3.1 Receipt of BPDUs 3396 Rbridges MUST listen to spanning tree BPDUs received on a port and 3397 keep track of the root bridge, if any, on that link. If MSTP is 3398 running on the link, this is the CIST root. This information is 3399 reported per VLAN by the RBridge in its LSP and may be used as 3400 described in Section 4.2.4.3. In addition, the receipt of spanning 3401 tree BPDUs is used as an indication that a link is a bridged LAN, 3402 which can affect the RBridge transmission of BPDUs. 3404 An RBridge MUST NOT encapsulate or forward any BPDU frame it 3405 receives. 3407 RBridges discard any topology change BPDUs they receive, but note 3408 Section 4.9.3.3. 3410 4.9.3.2 Root Bridge Changes 3412 A change in the root bridge seen in the spanning tree BPDUs received 3413 at an RBridge port may indicate a change in bridged LAN topology, 3414 including the possibility of the merger of two bridged LANs or the 3415 like, without any physical indication at the port. During topology 3416 transients, bridges may go into pre-forwarding states that block 3417 TRILL-Hello frames. For these reasons, when an RBridge sees a root 3418 bridge change on a port for which it is appointed forwarder for one 3419 or more VLANs, it is inhibited (discards all native frames received 3420 from or which it would otherwise have sent to the link) for a period 3421 of time between zero and 30 seconds. This time period is configurable 3422 per port and defaults to 30 seconds. 3424 For example, consider two bridged LANs carrying multiple VLANs, each 3425 with various RBridge appointed forwarders. Should they become merged, 3426 due to a cable being plugged in or the like, those RBridges attached 3427 to the original bridged LAN with the lower priority root will see a 3428 root bridge change while those attached to the other original bridged 3429 LAN will not. Thus all appointed forwarders in the first set will be 3430 inhibited for a time period while things are sorted out by BPDUs 3431 within the merged bridged LAN and TRILL-Hello frames between the 3432 RBridges involved. 3434 4.9.3.3 Transmission of BPDUs 3436 When an RBridge ceases to be appointed forwarder for one or more 3437 VLANs out a particular port it SHOULD, as long as it continues to 3438 receive spanning tree BPDUs on that port, send topology change BPDUs 3439 until it sees the topology change acknowledged in a spanning tree 3440 BPDU. 3442 RBridges MAY support a capability for sending spanning tree BPDUs for 3443 the purpose of attempting to force a bridged LAN to partition as 3444 discussed in Section A.3.3. 3446 4.9.4 Dynamic VLAN Registration 3448 Dynamic VLAN registration provides a means for bridges (and less 3449 commonly end stations) to request that VLANs be enabled or disabled 3450 on ports leading to the requestor. This is done by VLAN registration 3451 protocol (VRP) frames: GVRP or MVRP. RBridges MAY implement GVRP 3452 and/or MVRP as described below. 3454 VRP frames are never encapsulated as TRILL frames between RBridges or 3455 forwarded in native form by an RBridge. If an RBridge does not 3456 implement a VRP, it discards any VRP frames received and sends none. 3458 RBridge ports may have dynamically enabled VLANs. If an RBridge 3459 supports a VRP, the actual enablement of dynamic VLANs is determined 3460 by GVRP/MVRP frames received at the port as it would be for an 3461 [802.1Q-2005] / [802.1ak] bridge. 3463 An RBridge that supports a VRP sends GVRP/MVRP frames as an 3464 [802.1Q-2005] / [802.1ak] bridge would send on each port that is not 3465 configured as an RBridge trunk port or P2P port. For this purpose, it 3466 sends VRP frames to request traffic in the VLANs for which it is 3467 appointed forwarder and in the Designated VLAN, unless the Designated 3468 VLAN is disabled on the port, and to not request traffic in any other 3469 VLAN. 3471 5. RBridge Configuration Parameters 3473 This section lists configuration parameters for RBridges. It would be 3474 expected that the TRILL MIB will include the items listed in this 3475 section plus additional Rbridge status and data including traffic and 3476 error counts. 3478 5.1 Per RBridge 3480 The following per RBridge parameters may be configured: 3482 o Number of nicknames and, for each nickname, its nickname 3483 priority, priority to be selected as a distribution tree root, 3484 and the nickname value. (The nickname is configured if and only 3485 if the top bit of the nickname priority is a one (see Section 3486 3.7.3).) 3488 o The desired number of distribution trees for the campus, a 3489 desired number of distribution tree to use, the maximum number 3490 of distribution trees the RBridge can compute, and two lists of 3491 RBridge nicknames, as discussed in Section 4.5. 3493 o The per RBridge parameters Ageing Timer, Forward Delay, and 3494 Maximum Transit Delay. 3496 o Two octets that are, respectively, the confidence in { MAC, 3497 VLAN, local port } triples learned from locally received native 3498 frames and the confidence in { MAC, VLAN, remote RBridge } 3499 triples learned from decapsulating frames. 3501 o The desired minimum acceptable inter-RBridge link MTU for the 3502 campus, that is, originatingLSPBufferSize. 3504 o The number of failed MTU-probes before the RBridge concludes 3505 that a particular MTU is not supported. 3507 Static end station address information and priority of such end 3508 station information statically configured and learned in various ways 3509 can also be configured. 3511 5.2 Per Port 3513 An RBridge has the following per port configuration parameters: 3515 o The same parameters as an [802.1Q-2005] port in terms of C-VLAN 3516 IDs and, in addition, an Announcing VLANs set (see Section 3517 4.4.3). 3519 o The same parameters as an [802.1Q-2005] port in terms of frame 3520 priority code point mapping. 3522 o The inhibition time for the port when it observed a change in 3523 the root bridge of an attached bridged LAN. 3525 o The desired designated VLAN that the RBridge will advertise in 3526 its TRILL Hellos if it is DRB for the link via that port. 3528 o Four per-port configuration bits: disable port, disable end 3529 station service (trunk), access port, and use P2P Hellos (see 3530 Section 4.9.1). 3532 o Two bits per port such that (1) if the first is set, it disable 3533 learning { MAC address, VLAN, port } triples from locally 3534 received native frames on the port and (2) if the second is 3535 set, it disables learning { MAC address, VLAN, remote RBridge } 3536 triples from frames decapsulated for output on the port. (Such 3537 learning is disabled if either the per port or per VLAN bit 3538 mentioned below is set.) 3540 o The priority of the RBridge to be DRB and its Holding Time via 3541 that port. 3543 o A bit which, when set, enables the receipt of TRILL- 3544 encapsulated frames from a source with which the RBridges does 3545 not have an IS-IS adjacency. 3547 o Configuration for the optional send-BPDUs solution to the 3548 wiring closet topology problem (see Section A.3.3) consists of 3549 Bridge Address of the RBridge with lowest System ID. If RB1 and 3550 RB2 are part of a wiring closet topology, both need to be 3551 configured to know about this, and know the ID that should be 3552 used in the spanning tree protocol on the specified port. 3554 5.3 Per VLAN 3556 An RBridge has the following per VLAN configuration parameters: 3558 o Per VLAN ESADI participation flag, 7-bit priority, and Holding 3559 Time. 3561 o RBridges may be configured to send and/or learn end station 3562 address information via ESADI on a per VLAN basis. 3564 o Two bits per VLAN which, (1) if the first is set disable 3565 learning { MAC address, VLAN, port } triples from locally 3566 received native frames in the VLAN and (2) if the second is set 3567 disable learning { MAC address, VLAN, remote RBridge } triples 3568 from frames decapsulated for output in the VLAN. (Such learning 3569 is disabled if either the per VLAN or per port bit mentioned 3570 above is set.) 3572 6. Security Considerations 3574 Layer 2 bridging is not inherently secure. It is, for example, 3575 subject to spoofing of source addresses and bridging control 3576 messages. A goal for TRILL is that RBridges do not add new issues 3577 beyond those existing in current bridging technology. 3579 Countermeasures are available such as to configure the TRILL IS-IS 3580 and ESADI instances to use IS-IS security [RFC5304] and ignore 3581 unauthenticated TRILL control and ESADI frames received. RBridges 3582 using IS-IS security will need configuration. 3584 IEEE 802.1 port admission and link security mechanisms, such as 3585 [802.1X] and [802.1AE], can also be used. These are best thought of 3586 as being implemented below TRILL (see Section 4.9.2) and are outside 3587 the scope of TRILL (just as they are generally out of scope for 3588 bridging standards [802.1D] and 802.1Q); however, TRILL can make use 3589 of secure registration through the confidence level communicated in 3590 optional TRILL ESADI (see Section 4.8). 3592 TRILL encapsulates native frames inside the RBridge campus while they 3593 are in transit between ingress RBridge and egress RBridge(s) as 3594 described in Sections 2.3 and 4.1. Thus, TRILL ignorant devices with 3595 firewall features that cannot be detected by RBridges as end stations 3596 will generally not be able to inspect the content of such frames for 3597 security checking purposes. This may render them ineffective. Layer 3598 3 routers and hosts appear to RBridges to be end stations and native 3599 frames will be decapsulated before being sent to such devices. Thus 3600 they will not see the TRILL Ethertype. Firewall devices that do not 3601 appear to an RBridge to be an end station, for example bridges with 3602 co-located firewalls, should be modified to understand TRILL 3603 encapsulation. 3605 RBridges do not prevent nodes from impersonating other nodes, for 3606 instance, by issuing bogus ARP/ND replies. However, RBridges do not 3607 interfere with any schemes that would secure neighbor discovery. 3609 6.1 VLAN Security Considerations 3611 TRILL supports VLANs. These provide logical separation of traffic but 3612 care should be taken in using VLANs for security purposes. To have 3613 reasonable assurance of such separation, all the RBridges and links 3614 (including bridged LANs) in a campus must be secured and configured 3615 so as to prohibit end stations from using dynamic VLAN registration 3616 frames or otherwise gaining access to any VLAN carrying traffic for 3617 which they are not authorized to read and/or inject. 3619 Furthermore, if VLANs were used to keep some information off links 3620 where it might be observed in a bridged LAN, this will no longer 3621 work, in general, when bridges are replaced with RBridges; with 3622 encapsulation and a different outer VLAN tag, the data will travel 3623 the least cost transit path regardless of VLAN. Appropriate counter 3624 measures are to use end-to-end encryption or an appropriate TRILL 3625 security option should one be specified. 3627 6.2 BPDU/Hello Denial of Service Considerations 3629 The TRILL protocol requires that an appointed forwarder at an RBridge 3630 port be temporarily inhibited if it sees a TRILL-Hello from another 3631 RBridge claiming to be the appointed forwarder for the same VLAN or 3632 sees a root bridge change out that port. Thus it would seem that 3633 forged BPDUs showing repeated root bridge changes and forged TRILL- 3634 Hello frames with the Appointed Forwarder flag set could represent a 3635 significant denial of service attack. However, the situation is not 3636 as bad as it seems. 3638 The best defense against forged TRILL-Hello frames or other IS-IS 3639 messages is the use of IS-IS security [RFC5304]. Rogue end-stations 3640 would not normally have access to the required IS-IS keying material 3641 needed to forge authenticatible messages. 3643 Authentication similar to IS-IS security is usually unavailable for 3644 BPDUs. However, it is also the case that in typical modern wired 3645 LANs, all the links are point-to-point. If you have an all-RBridged 3646 point-to-point campus, then the worst that an end-station can do by 3647 forging BPDUs or TRILL-Hello frames is to deny itself service. This 3648 could be either through falsely inhibiting the forwarding of native 3649 frames by the RBridge to which it is connected or by falsely 3650 activating the optional decapsulation check (see Section 4.2.4.3). 3652 However, when an RBridge campus contains bridged LANs, those bridged 3653 LANs appear to any connected RBridges to be multi-access links. The 3654 forging of BPDUs by an end-station attached to such a bridged LAN 3655 could affect service to other end-stations attached to the same 3656 bridged LAN. Note that bridges never forward BPDUs but process them, 3657 although this processing may result in the issuance of further BPDUs. 3658 Thus, for an end-station to forge BPDUs to cause continuing changes 3659 in the root bridge as seen by an RBridge through intervening bridges 3660 would typically require it to cause root bridge thrashing throughout 3661 the bridged LAN that would be disruptive even in the absence of 3662 RBridges. 3664 Some bridges can be configured to not send BPDUs and/or to ignore 3665 BPDUs on particular ports and RBridges can be configured not to 3666 inhibit appointed forwarding on a port due to root bridge changes; 3667 however, such configuration should be used with caution as it can be 3668 unsafe. 3670 7. Assignment Considerations 3672 This section discuses IANA and IEEE 802 assignment considerations. 3673 See [RFC5226]. 3675 7.1 IANA Considerations 3677 A new IANA registry is created for TRILL Parameters with two 3678 subregistries as below. 3680 The initial contents of the TRILL Nicknames subregistry is as 3681 follows: 3683 0x0000 Reserved to indicate no nickname specified 3684 0x0001-0xFFBF Dynamically allocated by the RBridges within each 3685 RBridge campus 3686 0xFFC0-0xFFFE Available for allocation by RFC Required (single 3687 value) or IETF Review (single or multiple values) 3688 0xFFFF Permanently reserved 3690 The initial contents of the TRILL Multicast Address subregistry is as 3691 follows: 3693 01-80-C2-XX-XX-X0 Assigned as All-RBridges 3694 01-80-C2-XX-XX-X1 Assigned as All-IS-IS-RBridges 3695 01-80-C2-XX-XX-X2 Assigned as All-ESADI-RBridges 3696 01-80-C2-XX-XX-X3 to 01-80-C2-XX-XX-XF Available for allocation 3697 by IETF Review 3699 7.2 IEEE Registration Authority Considerations 3701 The Ethertype is assigned by the IEEE Registration Authority to 3702 the TRILL Protocol. 3704 The Ethertype is assigned by the IEEE Registration Authority 3705 for L2-IS-IS. 3707 The block of 16 multicast MAC addresses from <01-80-C2-XX-XX-X0> to 3708 <01-80-C2-XX-XX-XF> are assigned by the IEEE Registration Authority 3709 for IETF TRILL protocol use. 3711 8. Normative References 3713 [802.1ak] "IEEE Standard for Local and metropolitan area networks / 3714 Virtual Bridged Local Area Networks / Multiple Registration 3715 Protocol", IEEE Standard 802.1ak-2007, 22 June 2007. 3717 [802.1D] "IEEE Standard for Local and metropolitan area networks / 3718 Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004. 3720 [802.1Q-2005] "IEEE Standard for Local and metropolitan area networks 3721 / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006. 3723 [802.3] "IEEE Standard for Information technology / 3724 Telecommunications and information exchange between systems / 3725 Local and metropolitan area networks / Specific requirements Part 3726 3: Carrier sense multiple access with collision detection 3727 (CSMA/CD) access method and physical layer specifications", 3728 802.3-2008, 26 December 2008. 3730 [ISO10589] ISO/IEC 10589:2002, "Intermediate system to Intermediate 3731 system routeing information exchange protocol for use in 3732 conjunction with the Protocol for providing the Connectionless- 3733 mode Network Service (ISO 8473)," ISO/IEC 10589:2002. 3735 [layer2] Banerjee, A., et al., "Extensions to IS-IS for Layer-2 3736 Systems", draft-ietf-isis-layer2, work in progress. 3738 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", STD 5, 3739 RFC 1112, Stanford University, August 1989. 3741 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 3742 dual environments", RFC 1195, December 1990. 3744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3745 Requirement Levels", BCP 14, RFC 2119, March 1997. 3747 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 3748 Networks", RFC 2464, December 1998. 3750 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 3751 Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 3753 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 3754 Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3755 3376, October 2002. 3757 [RFC3417] Presuhn, R., Ed., "Transport Mappings for the Simple 3758 Network Management Protocol (SNMP)", STD 62, RFC 3417, December 3759 2002. 3761 [RFC3419] Daniele, M. and J. Schoenwaelder, "Textual Conventions for 3762 Transport Addresses", RFC 3419, December 2002. 3764 [RFC4286] Haberman, B., Martin, J., "Multicast Router Discovery", RFC 3765 4286, December 2005. 3767 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3768 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 3770 [RFC5303] Katz, D., Saluja, R., and D. Eastlake 3rd, "Three-Way 3771 Handshake for IS-IS Point-to-Point Adjacencies", RFC 5303, October 3772 2008. 3774 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 3775 Engineering", RFC 5305, October 2008. 3777 9. Informative References 3779 [802.1ad] "IEEE Standard for and metropolitan area networks / Virtual 3780 Bridged Local Area Networks / Provider Bridges", 802.1ad-2005, 26 3781 May 2005. 3783 [802.1ah] "IEEE Standard for Local and Metropolitan Area Networks / 3784 Virtual Bridged Local Area Networks / Provider Backbone Bridges", 3785 802.1ah-2008, 1 January 2008. 3787 [802.1aj] Virtual Bridged Local Area Networks / Two-Port Media Access 3788 Control (MAC) Relay, 802.1aj Draft 4.2, 24 September 2009. 3790 [802.1AE] "IEEE Standard for Local and metropolitan area networks / 3791 Media Access Control (MAC) Security", 802.1AE-2006, 18 August 3792 2006. 3794 [802.1AX] "IEEE Standard for Local and metropolitan area networks / 3795 Link Aggregation", 802.1AX-2008, 1 January 2008. 3797 [802.1X] "IEEE Standard for Local and metropolitan area networks / 3798 Port Based Network Access Control", 802.1X-REV Draft 2.9, 3 3799 September 2008. 3801 [RBridges] Perlman, R., "RBridges: Transparent Routing", Proc. 3802 Infocom 2005, March 2004. 3804 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 3805 RFC 1661, July 1994. 3807 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 3808 Architecture for Describing Simple Network Management Protocol 3809 (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002. 3811 [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, 3812 "Randomness Requirements for Security", BCP 106, RFC 4086, June 3813 2005. 3815 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 3816 "Considerations for Internet Group Management Protocol (IGMP) and 3817 Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, 3818 May 2006. 3820 [RFC4789] Schoenwaelder, J. and T. Jeffree, "Simple Network 3821 Management Protocol (SNMP) over IEEE 802 Networks", RFC 4789, 3822 November 2006. 3824 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 3825 Authentication", RFC 5304, October 2008. 3827 [RFC5342] Eastlake 3rd., D., "IANA Considerations and IETF Protocol 3828 Usage for IEEE 802 Parameters", BCP 141, RFC 5342, September 2008. 3830 [RFC5556] Touch, J. and R. Perlman, "Transparent Interconnection of 3831 Lots of Links (TRILL): Problem and Applicability Statement", RFC 3832 5556, May 2009. 3834 [RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches, 3835 and Internetworking Protocols, 2nd Edition", Addison Wesley 3836 Longman, Chapter 3, 1999. 3838 Appendix A: Incremental Deployment Considerations 3840 Some aspects of partial RBridge deployment are described below for 3841 link cost determination (Section A.1) and possible congestion due to 3842 appointed forwarder bottlenecks (Section A.2). A particular example 3843 of a problem related to the TRILL use of a single appointed forwarder 3844 per link per VLAN (the "wiring closet topology") is explored in 3845 detail in Section A.3. 3847 A.1 Link Cost Determination 3849 With an RBridged campus having no bridges or repeaters on the links 3850 between RBridges, the RBridges can accurately determine the number of 3851 physical hops involved in a path and the line speed of each hop, 3852 assuming this is reported by their port logic. With intervening 3853 devices, this is no longer possible. For example, as shown in Figure 3854 A.1, the two bridges B1 and B2 can completely hide a slow link so 3855 that both Rbridges RB1 and RB2 incorrectly believe the link is 3856 faster. 3858 +-----+ +----+ +----+ +-----+ 3859 | | Fast | | Slow | | Fast | | 3860 | RB1 +--------+ B1 +--------+ B2 +--------+ RB2 | 3861 | | Link | | Link | | Link | | 3862 +-----+ +----+ +----+ +-----+ 3864 Figure A.1: Link Cost of a Bridged Link 3866 Even in the case of a single intervening bridge, two RBridges may 3867 know they are connected but each see the link as a different speed 3868 from how it is seen by the other. 3870 However, this problem is not unique to RBridges. Bridges can 3871 encounter similar situations due to links hidden by repeaters and 3872 routers can encounter similar situations due to links hidden by 3873 bridges, repeaters or Rbridges. 3875 A.2 Appointed Forwarders and Bridged LANs 3877 With partial RBridge deployment, the RBridges may partition a bridged 3878 LAN into a relatively small number of relatively large remnant 3879 bridged LANs, or possibly not partition it at all so a single bridged 3880 LAN remains. Such configuration can result in the following problem: 3882 The requirement that native frames enter and leave a link via the 3883 link's appointed forwarder for the VLAN of the frame can cause 3884 congestion or suboptimal routing. (Similar problems can occur within 3885 a bridged LAN due to the spanning tree algorithm.) The extent to 3886 which such a problem will occur is highly dependent on the network 3887 topology. For example, if a bridged LAN had a star-like structure 3888 with core bridges that connected only to other bridges and peripheral 3889 bridges that connected to end stations and are connected to core 3890 bridges, the replacement of all of the core bridges by RBridges 3891 without replacing the peripheral bridges would generally improve 3892 performance without inducing appointed forwarder congestion. 3894 Solutions to this problem are discussed below and a particular 3895 example explored in Section A.3. 3897 Inserting RBridges so that all the bridged portions of the LAN stay 3898 connected to each other and have multiple RBridge connections is 3899 generally the least efficient arrangement. 3901 There are four techniques that may help if the problem above occurs 3902 and which can, to some extent, be used in combination: 3904 1. Replace more IEEE 802.1 customer bridges with RBridges so as to 3905 minimize the size of the remnant bridged LANs between RBridges. 3906 This requires no configuration of the RBridges unless the bridges 3907 they replace required configuration. 3909 2. Re-arrange network topology to minimize the problem. If the 3910 bridges and RBridges involved are configured, this may require 3911 changes in their configuration. 3913 3. Configure the RBridges and bridges so that end stations on a 3914 remnant bridged LAN are separated into different VLANs that have 3915 different appointed forwarders. If the end stations were already 3916 assigned to different VLANs, this is straightforward (see Section 3917 4.2.4.2). If the end stations were on the same VLAN and have to be 3918 split into different VLANs, this technique may lead to 3919 connectivity problems between end stations. 3921 4. Configure the RBridges such that their ports which are connected 3922 to the bridged LAN send spanning tree BPDUs (see Section A.3.3) in 3923 such a way as to force the partition of the bridged LAN. (Note: A 3924 spanning tree is never formed through an RBridge but always 3925 terminates at RBridge ports.) To use this technique, the RBridges 3926 must support this optional feature, and would need to be 3927 configured to use it, but the bridges involved would rarely have 3928 to be configured. This technique makes the bridged LAN unavailable 3929 for TRILL through traffic because the bridged LAN partitions. 3931 Conversely to item 3 above, there may be bridged LANs which use 3932 VLANs, or use more VLANs than would otherwise be necessary, to 3933 support the Multiple Spanning Tree Protocol or otherwise reduce the 3934 congestion that can be caused by a single spanning tree. Replacing 3935 the IEEE 802.1 bridges in such LANs with RBridges may enable a 3936 reduction in or elimination of VLANs and configuration complexity. 3938 A.3 Wiring Closet Topology 3940 If 802.1 bridges are present and RBridges are not properly 3941 configured, the bridge spanning tree or the DRB may make 3942 inappropriate decisions. Below is a specific example of the more 3943 general problem that can occur when a bridged LAN is connected to 3944 multiple RBridges. 3946 In cases where there are two (or more) groups of end nodes, each 3947 attached to a bridge (say B1 and B2), and each bridge is attached to 3948 an RBridge (say RB1 and RB2 respectively), with an additional link 3949 connecting B1 and B2 (see Figure A.2), it may be desirable to have 3950 the B1-B2 link only as a backup in case one of RB1 or RB2 or one of 3951 the links B1-RB1 or B2-RB2 fail. 3953 +-------------------------------+ 3954 | | | | 3955 | Data +-----+ +-----+ | 3956 | Center -| RB1 |----| RB2 |- | 3957 | +-----+ +-----+ | 3958 | | | | 3959 +-------------------------------+ 3960 | | 3961 | | 3962 +-------------------------------+ 3963 | | | | 3964 | +----+ +----+ | 3965 | Wiring | B1 |-----| B2 | | 3966 | Closet +----+ +----+ | 3967 | Bridged | 3968 | LAN | 3969 +-------------------------------+ 3971 Figure A.2: Wiring Closet Topology 3973 For example, B1 and B2 may be in a wiring closet and it may be easy 3974 to provide a short, high bandwidth, low cost link between them while 3975 RB1 and RB2 are at a distant data center such that the RB1-B1 and 3976 RB2-B2 links are slower and more expensive. 3978 Default behavior might be that one of RB1 or RB2 (say RB1) would 3979 become DRB for the bridged LAN including B1 and B2 and appoint itself 3980 forwarder for the VLANs on that bridged LAN. As a result, RB1 would 3981 forward all traffic to/from the link, so end nodes attached to B2 3982 would be connected to the campus via the path B2-B1-RB1, rather than 3983 the desired B2-RB2. This wastes the bandwidth of the B2-RB2 path and 3984 cuts available bandwidth between the end stations and the data center 3985 in half. The desired behavior would be to make use of both the RB1-B1 3986 and RB2-B2 links. 3988 Three solutions to this problem are described below. 3990 A.3.1 The RBridge Solution 3992 Of course, if B1 and B2 are replaced with RBridges, the right thing 3993 will happen without configuration (other than VLAN support), but this 3994 may not be immediately practical if bridges are being incrementally 3995 replaced by RBridges. 3997 A.3.2 The VLAN Solution 3999 If the end stations attached to B1 and B2 are already divided among a 4000 number of VLANs, RB1 and RB2 could be configured so that which ever 4001 becomes DRB for this link will appoint itself forwarder for some of 4002 these VLANs and appoint the other RBridge for the remaining VLANs. 4003 Should either of the RBridges fail or become disconnected, the other 4004 will have only itself to appoint as forwarder for all the VLANs. 4006 If the end stations are all on a single VLAN, then it would be 4007 necessary to assign them between at least two VLANs to use this 4008 solution. This may lead to connectivity problems that might require 4009 further measures to rectify. 4011 A.3.3 The Spanning Tree Solution 4013 Another solution is to configure the relevant ports on RB1 and RB2 to 4014 be part of a "wiring closet group", with a configured per RBridge 4015 port "Bridge Address" Bx (which may be RB1 or RB2's System ID). Both 4016 RB1 and RB2 emit spanning tree BPDUs on their configured ports as 4017 highest priority root Bx. This causes the spanning tree to logically 4018 partition the bridged LAN as desired by blocking the B1-B2 link at 4019 one end or the other (unless one of the bridges is configured to also 4020 have highest priority and has a lower ID, which we consider to be a 4021 misconfiguration). With the B1-B2 link blocked, RB1 and RB2 cannot 4022 see each other's TRILL-Hellos via that link and each acts as 4023 Designated RBridge and appointed forwarder for its respective 4024 partition. Of course, with this partition, no TRILL through traffic 4025 can flow through the RB1-B1-B2-RB2 path. 4027 In the spanning tree BPDU, the Root is "Bx" with highest priority, 4028 cost to Root is 0, Designated Bridge ID is "RB1" when RB1 transmits 4029 and "RB2" when RB2 transmits, and port ID is a value chosen 4030 independently by each of RB1 and RB2 to distinguish each of its own 4031 ports. (If RB1 and RB2 were actually bridges on the same shared 4032 medium with no bridges between them, the result would be that the one 4033 with the larger ID sees "better" BPDUs (because of the tie breaker on 4034 the third field: the ID of the transmitting bridge), and would turn 4035 off its port.) 4037 Should either RB1 or the RB1-B1 link or RB2 or the RB2-B2 link fail, 4038 the spanning tree algorithm will stop seeing one of the RBx roots and 4039 will unblock the B1-B2 link maintaining connectivity of all the end 4040 stations with the data center. 4042 If the link RB1-B1-B2-RB2 is on the cut set of the campus and RB2 and 4043 RB1 have been configured to believe they are part of a wiring closet 4044 group, the campus becomes partitioned as the link is blocked. 4046 A.3.4 Comparison of Solutions 4048 Replacing all 802.1 customer bridges with RBridges is usually the 4049 best solution with the least amount of configuration required, 4050 possibly none. 4052 The VLAN solution works well with a relatively small amount of 4053 configuration if the end stations are already divided among a number 4054 of VLANs. If they are not, it becomes more complex and problematic. 4056 The spanning tree solution does quite well in this particular case. 4057 But it depends on both RB1 and RB2 having implemented the optional 4058 feature of being able to configure a port to emit spanning tree BPDUs 4059 as described in Section A.3.3 above. It also makes the bridged LAN 4060 whose partition is being forced unavailable for through traffic. 4061 Finally, while in this specific example it neatly breaks the link 4062 between the two bridges B1 and B2, if there were a more complex 4063 bridged LAN, instead of exactly two bridges, there is no guarantee 4064 that it would partition into roughly equal pieces. In such a case, 4065 you might end up with a highly unbalanced load on the RB1-B1 link and 4066 the RB2-B2 link although this is still better than using only one of 4067 these links exclusively. 4069 Appendix B: Trunk and Access Port Configuration 4071 Many modern bridged LANs are organized into a core and access model, 4072 The core bridges have only point-to-point links to other bridges 4073 while the access bridges connect to end stations, core bridges, and 4074 possibly other access bridges. It seems likely that some RBridge 4075 campuses will be organized in a similar fashion. 4077 An RBridge port can be configured as a trunk port, that is, a link to 4078 another RBridge or RBridges, by configuring it to disable end station 4079 support. There is no reason for such a port to have more than one 4080 VLAN enabled and in its Announcing Set on the port. Of course, the 4081 RBridge (or RBridges) to which it is connected must have the same 4082 VLAN enabled. There is no reason for this VLAN to be other than the 4083 default VLAN 1 unless the link is actually over carrier Ethernet or 4084 other facilities that only provide some other specific VLAN or the 4085 like. Such configuration minimizes wasted TRILL-Hellos and eliminates 4086 useless decapsulation and transmission of multi-destination traffic 4087 in native form onto the link. (see Sections 4.2.4 and 4.9.1) 4089 An RBridge access port would be expected to lead to a link with end 4090 stations and possibly one or more bridges. Such a link might also 4091 have more than one RBridge connected to it to provide more reliable 4092 service to the end stations. It would be a goal to minimize or 4093 eliminate transit traffic on such a link as it is intended for end 4094 station native traffic. This can be accomplished by turning on the 4095 access port configuration bit for the RBridge port or ports connected 4096 to the link as further detailed in Section 4.9.1. 4098 When designing RBridge configuration user interfaces, consideration 4099 should be given to making it convenient to configure ports as trunk 4100 and access ports. 4102 Appendix C: Multipathing 4104 Rbridges support multipathing of both known unicast and multi- 4105 destination traffic. Implementation of multipathing is optional. 4107 Multi-destination traffic can be multipathed by using different 4108 distribution tree roots for different frames. For example, assume 4109 that in Figure C.1 end stations attached to RBy are the source of 4110 various multicast streams each of which has multiple listeners 4111 attached to various of RB1 through RB9. Assuming equal bandwidth 4112 links, a distribution tree rooted at RBy will predominantly use the 4113 vertical links among RB1 through RB9 while one rooted at RBz will 4114 predominantly use the horizontal. If RBy chooses its nickname as the 4115 distribution tree root for half of this traffic and an RBz nickname 4116 as the root for the other half, it may be able to substantially 4117 increase the aggregate bandwidth by making use of both the vertical 4118 and horizontal links among RB1 through RB9. 4120 Since the distribution trees an RBridge must calculate are the same 4121 for all RBridges and transit RBridges MUST respect the tree root 4122 specified by the ingress RBridge, a campus will operate correctly 4123 with a mix of RBridges some of which use different roots for 4124 different multi-destination frames they ingress and some of which use 4125 a single root for all such frames. 4127 +---+ 4128 |RBy|---------------+ 4129 +---+ | 4130 / | \ | 4131 / | \ | 4132 / | \ | 4133 +---+ +---+ +---+ | 4134 |RB1|---|RB2|---|RB3| | 4135 +---+ +---+ +---+\ | 4136 | | | \ | 4137 +---+ +---+ +---+ \+---+ 4138 |RB4|---|RB5|---|RB6|-----|RBz| 4139 +---+ +---+ +---+ /+---+ 4140 | | | / 4141 +---+ +---+ +---+/ 4142 |RB7|---|RB8|---|RB9| 4143 +---+ +---+ +---+ 4145 Figure C.1: Multi-Destination Multipath 4147 Known unicast equal cost multipathing (ECMP) can occur if, instead of 4148 using a tie-breaker criterion when building an SPF path between 4149 ingress and egress RBridges, information about equal cost paths is 4150 retained. Different unicast frames can then be sent via different 4151 equal cost paths. For example, in Figure C.2, which shows only 4152 RBridges and omits any bridges present, there are three equal cost 4153 paths between RB1 and RB2 and two equal cost paths between RB2 and 4154 RB5. 4156 A transit RBridge receiving a known unicast frame forwards it towards 4157 the egress RBridge and is not concerned with whether it believes 4158 itself to be on any particular path from the ingress RBridge or a 4159 previous transit RBridge. Thus a campus will operate correctly with 4160 a mix of RBridges some of which implement ECMP and some of which do 4161 not. 4163 There are actually three possibilities for the parallel paths between 4164 RB1 and RB2 as follows: 4166 1. If two or three of these paths have pseudonodes, then all three 4167 will be distinctly visible in the campus wide link state and ECMP 4168 as described above is applicable. 4169 2. If the paths use P2P Hellos or otherwise do not have pseudonodes, 4170 these three paths would appear as a single adjacency in the link 4171 state. In this case, multipathing across them would be an entirely 4172 local matter for RB1 and RB2. It can be freely done for known 4173 unicast frames but not for multi-destination frames as described 4174 in Section 4.5.2. 4175 3. If and only if the three paths between RB1 and RB2 are single hop 4176 equal bandwidth links with no intervening bridges, then it would 4177 be permissible to combine them into one logical link through the 4178 [802.1AX] "link aggregation" feature. Rbridges MAY implement link 4179 aggregation since that feature operates below TRILL (see Section 4180 4.9.2). 4182 +---+ double line = 10 Gbps 4183 ----- ===|RB3|--- single line = 1 Gbps 4184 / \ // +---+ \ 4185 +---+ +---+ +---+ 4186 ===|RB1|-----|RB2| |RB5|=== 4187 +---+ +---+ +---+ 4188 \ / \ +---+ // 4189 ----- ----|RB4|=== 4190 +---+ 4192 Figure C.2: Known Unicast Multipath 4194 When multipathing is used, frames that follow different paths will be 4195 subject to different delays and may be re-ordered. While some 4196 traffic may be order/delay insensitive, typically most traffic 4197 consists of flows of frames where re-ordering within a flow is 4198 damaging. How to determine flows or what granularity flows should 4199 have is beyond the scope of this document. (This issue is discussed 4200 in [802.1AX].) 4202 Appendix D: Determination of VLAN and Priority 4204 A high-level, informative summary of how VLAN ID and priority are 4205 determined for incoming native frames, omitting some details, is 4206 given in the bulleted items below. For more detailed information, see 4207 [802.1Q-2005]. 4209 o When an untagged native frame arrives, an unconfigured RBridge 4210 associates the default priority zero and the VLAN ID 1 with it. It 4211 actually sets the VLAN for the untagged frame to be the "port VLAN 4212 ID" associated with that port. The port VLAN ID defaults to VLAN 4213 ID 1 but may be configured to be any other VLAN ID. An Rbridge may 4214 also be configured on a per port basis to discard such frames or 4215 to associate a different priority code point with them. 4216 Determination of the VLAN ID associated with an incoming untagged 4217 non-control frame may also be made dependent on the Ethertype or 4218 NSAP (referred to in 802.1 as the Protocol) of the arriving frame, 4219 the source MAC address, or other local rules. 4221 o When a priority tagged native frame arrives, an unconfigured 4222 RBridge associates with it both the port VLAN ID, which defaults 4223 to 1, and the priority code point provided in the priority tag in 4224 the frame. An Rbridge may be configured on a per port basis to 4225 discard such frames or to associate them with a different VLAN ID 4226 as described in the point immediately above. It may also be 4227 configured to map the priority code point provided in the frame by 4228 specifying, for each of the eight possible values that might be in 4229 the frame, what actual priority code point will be associated with 4230 the frame by the RBridge. 4232 o When a C-tagged (formerly called Q-tagged) native frame arrives, 4233 an unconfigured RBridge associates with it the VLAN ID and 4234 priority in the C-tag. An RBridge may be configured on a per port 4235 per VLAN basis to discard such frames. It may also be configured 4236 on a per port basis to map the priority value as specified above 4237 for priority tagged frames. 4239 In 802.1, the process of associating a priority code point with a 4240 frame, including mapping a priority provided in the frame to another 4241 priority, is referred to as priority "regeneration". 4243 Appendix E: Support of IEEE 802.1Q-2005 Amendments 4245 This informational appendix briefly comments on RBridge support for 4246 completed and in-process amendments to IEEE [802.1Q-2005]. There is 4247 no assurance that existing RBridge protocol specifications or 4248 existing bridges will support not yet specified future [802.1Q-2005] 4249 amendments just as there is no assurance that existing bridge 4250 protocol specifications or existing RBridges will support not yet 4251 specified future TRILL amendments. 4253 The information below is frozen as of 25 October 2009. For the latest 4254 status, see the IEEE 802.1 working group ( 4255 http://grouper.ieee.org/groups/802/1/ ). 4257 E.1 Completed Amendments 4259 802.1ad-2005 Provider Bridges - Sometimes called "Q-in-Q", because 4260 VLAN tags used to be called "Q-tags", 802.1ad specifies 4261 Provider Bridges that tunnel customer bridge traffic within 4262 service VLAN tags (S-tags). If the customer LAN is an RBridge 4263 campus, that traffic will be bridged by Provider Bridges. 4264 Customer bridge features involving Provider Bridge awareness, 4265 such as the ability to configure a customer bridge port to add 4266 an S-tag to a frame before sending it to a Provider Bridge, are 4267 below the EISS layer and can be supported in RBridge ports 4268 without modification to the TRILL protocol. 4269 802.1ag-2007 Connectivity Fault Management (CFM) - This 802.1 feature 4270 is at least in part dependent on the symmetric path and other 4271 characteristics of spanning tree. The comments provided to the 4272 IETF TRILL working group by the IEEE 802.1 working group stated 4273 that "TRILL weakens the applicability of CFM.". 4274 802.1ak-2007 Multiple Registration Protocol - Supported to the extent 4275 described in Section 4.9.4. 4276 802.1ah-2008 Provider Backbone Bridges - Sometimes called "MAC-in- 4277 MAC", 802.1ah provides for Provider Backbone Bridges that 4278 tunnel customer bridge traffic within different outer MAC 4279 addresses and using a tag (the "I-tag") to preserve the 4280 original MAC addresses and signal other information. If the 4281 customer LAN is an RBridge campus, that traffic will be bridged 4282 by Provider Backbone Bridges. Customer bridge features 4283 involving Provider Backbone Bridge awareness, such as the 4284 ability to configure a customer bridge port to add an I-tag to 4285 a frame before sending it to a Provider Backbone Bridge, are 4286 below the EISS layer and can be supported in RBridge ports 4287 without modification to the TRILL protocol. 4288 802.1Qaw-2009 Management of Data-Driven and Data-Dependent 4289 Connectivity Fault - Amendment building on 802.1ag. See 4290 comments on 802.1ag-2007 above. 4292 802.1Qay-2009 Provider Backbone Bridge Traffic Engineering - 4293 Amendment building on 802.1ah to configure traffic engineered 4294 routing. See comments on 802.1ah-2008 above. 4296 E.2 In-process Amendments 4298 The following are amendments to IEEE [802.1Q-2005] that are in 4299 process. As such, the brief comments below are based on drafts and 4300 may be incorrect for later versions or any final amendment. 4302 802.1aj Two-port MAC Relay - This amendment specifies a MAC relay 4303 that will be transparent to RBridges. RBridges are compatible 4304 with IEEE 802.1aj devices as currently specified, in the same 4305 sense that IEEE 802.1Q-2005 bridges are compatible with such 4306 devices. 4307 802.1aq Shortest Path Bridging - This amendment provides for improved 4308 routing in bridged LANs. 4309 802.1Qat Stream Reservation Protocol - Modification to 802.1Q to 4310 support the 802.1 Timing and Synchronization. This protocol 4311 reserves resources for streams at supporting bridges. 4312 802.1Qau Congestion Notification - It currently appears that 4313 modifications to RBridge behavior above the EISS level would be 4314 needed to support this amendment. Such modifications are beyond 4315 the scope of this document. 4316 802.1Qav Forwarding and Queuing Enhancements for Time-Sensitive 4317 Streams - Modification to 802.1Q to support the 802.1 Timing 4318 and Synchronization protocol. This amendment specifies methods 4319 to support the resource reservations made through the 802.1Qat 4320 protocol (see above). 4321 802.1Qaz Enhanced Transmission Selection - It appears that this 4322 amendment will be below the EISS layer and can be supported in 4323 RBridge ports without modification to the TRILL protocol. 4324 802.1Qbb Priority-based Flow Control - Commonly called "per priority 4325 pause", it appears that this amendment will be below the EISS 4326 layer and can be supported in RBridge ports without 4327 modification to the TRILL protocol. 4328 802.1bc Remote Customer Service Interfaces. This is an extension to 4329 802.1Q provider bridging. See 802.1ad-2005 above. 4330 802.1Qbe Multiple Backbone Service Instance Identifier (I-SID) 4331 Registration Protocol (MIRP). This is an extension to 802.1Q 4332 provider backbone bridging. See 802.1ah-2008 above. 4333 802.1Qbf Provider Backbone Bridge Traffic Engineering (PBB-TE) 4334 Infrastructure Segment Protection. This amendment extends 4335 802.1Q to support certain types of failover between provider 4336 backbone bridges. See 802.1ah-2008 above. 4338 Appendix Z: Revision History 4340 RFC Editor: Please delete this Appendix Z before publication. In 4341 addition, please replace the string "" where it 4342 occurs in this document with "RFC xxxx" where xxxx is the RFC number 4343 assigned to this document. 4345 Changes from -03 to -04 4347 1. Divide IANA Considerations section into IANA and IEEE parts. Add 4348 IANA considerations for TRILL Header variations and reserved bit 4349 and normative references to RFCs 2434 and 4020. 4351 2. Add note on the terms Rbridge and TRILL to section 1.2. 4353 3. Remove IS-IS marketing text. 4355 4. Split Section 3 into Sections 3 and 4. Add a new top level 4356 section "5. Pseudo Code", renumbering following sections. Move 4357 pseudo code that was in old Section 3 into Section 5 and make 4358 section 3 more textural. This idea is that Section 3 and 4 have 4359 more readable text descriptions with some corner cases left out 4360 for simplicity while section 5 has more structured and complete 4361 coverage. 4363 5. Revised and extended Security Considerations section. 4365 6. Move multicast router attachment bit and IGMP membership report 4366 information from the per-VLAN IS-IS instance to the core IS-IS 4367 instance so the information can be used by core RBridges to prune 4368 distribution trees. 4370 7. Remove ARP/ND optimization. 4372 8. Change TRILL Header to add option feature. Add option section. 4374 9. Change TRILL Header to expand Version field to the Variation 4375 field. Add TRILL message variations (8 bits) supported to the per 4376 RBridge link state information. 4378 10. Distinguish TRILL data and IS-IS messages by using Variation = 0 4379 and 1. 4381 11. Consistently state that VLAN pruning and IP derived multicast 4382 pruning of distribution trees are SHOULD. 4384 12. Add text and pseudo code to discard TRILL Ethertype data frames 4385 received on a port that does not have an IS-IS adjacency on it. 4387 13. Add end station address learning section. Specify end station 4388 address learning from decapsulated native frames. 4390 14. Add nickname allocation priority and optional nickname 4391 configuration. Reserve nickname values zero and 0xFFFF. 4393 15. Explain about multiple Designated RBridges because of multiple 4394 VLANS. 4396 16. Add Incremental Deployment Considerations Section incorporating 4397 expanded Wiring Closet Topology Section. 4399 17. Add more detail on VLAN tag information and material on frame 4400 priority. 4402 18. Miscellaneous minor editing and terminology updates. 4404 Changes from -04 to -05 4406 NOTE: Section 5 was NOT updated as indicated below but the remainder 4407 of the draft was so updated. 4409 1. Mention optional VLAN and multicast optimization in Abstract. 4411 2. Change to distinguish TRILL IS-IS from TRILL data frames based on 4412 the Inner.MacDA instead of a TRILL Header bit. 4414 3. Split IP multicast router attached bit in two so you can 4415 separately indicate attachment of IPv4 and IPv6 routers. Provide 4416 that these bits must be set if an RBridge does not actually do 4417 multicast control snooping on ingressed traffic. 4419 4. Add the term "port VLAN ID" (PVID). 4421 5. Drop references to PIM. Improve discussions of IGMP, MLD, and MRD 4422 messages. 4424 6. Move M bit over one and create two-bit pruning field at the 4425 bottom of the "V" combined field. 4427 7. Add pruning control values of V and discussion of same. 4429 8. Permit optional unicast transmission of multi-destination frames 4430 when there is only one received out a port. 4432 9. Miscellaneous minor editing and terminology updates. 4434 Changes from -05 to -06 4436 1. Revise Section 2 discussion of DRB determination in the presence 4437 of VLANs and move it to Section 2.2. Adjust VLAN handling 4438 description. 4440 2. Change "V" field to be a 2-bit version fields followed by 2 4441 reserved bits. Make corresponding changes to eliminate the 4442 inclusion in the header of frame analysis indicating type of 4443 multi-destination pruning which is proper for frame. Thus all 4444 non-ingress RBridges that wish to perform such pruning are forced 4445 to do full frame analysis. Make further corresponding changes in 4446 IANA Considerations. 4448 3. The Inner.MacDA for TRILL IS-IS frames is changed to a second 4449 multicast address: All-IS-IS-RBridges. IEEE Allocation 4450 Considerations, etc., are correspondingly changed. 4452 4. Note in Section 6 that bridges can hide slow links and generally 4453 make it harder from RBridges to determine the cost of an RBridge 4454 to RBridge hop that is a bridged LAN. 4456 5. Add material noting that replacement of bridges by RBridges can 4457 cause connectivity between previously isolated islands of the 4458 same VLAN. 4460 6. Expand Security Considerations by mentioning RFC 3567 and 4461 indicating that TRILL enveloping may reduce the effectively of 4462 TRILL-ignorant firewall functionality. 4464 7. Extensive updates to pseudo code. 4466 8. Change to one DRB per physical link that dictates the inter- 4467 RBridge VLAN for the link, appoints forwarders per-VLAN, can be 4468 configured to send Hellos on multiple VLANs, etc. 4470 9. Add a minimal management by SNMP statement to Section 2. 4472 10. Delete explicit requirement to process TRILL frames arriving on a 4473 port even if the port implements spanning tree and is in spanning 4474 tree blocked state. 4476 11. Miscellaneous minor editing and terminology updates. 4478 Changes from -06 to -07 4480 [WARNING: Section 5 of draft -07 was not fully updated to incorporate 4481 the changes below.] 4482 1. Drop recommendation to set "bridge" flags in some 802.1AB frame 4483 fields. 4485 2. Add Section 2.5 giving an informative description of zero 4486 configuration behavior for 802.1D and 802.1Q-2005 bridges and 4487 RBridges. 4489 3. Add Section 4.7 (renumbering the former 4.7 to be 4.9) on the 4490 receipt, handing, and transmission of MVRP and other MRP frames 4491 by RBridges. Add references to 802.1ak. 4493 4. Add Section 4.8 on Multipathing. 4495 5. Partial changes to Section 5 to correspond with changes elsewhere 4496 in the draft. 4498 6. Addition of frame category definitions in Section 1.2. 4500 7. Addition of Section 10, Acronyms. 4502 8. Add note in Section 6.2 that difficult in link cost determination 4503 due to intervening devices is not confined to RBridges. 4505 9. Re-ordered some sections in Section 6. 4507 10. Added a paragraph about taking care if trying to use VLANs for 4508 security to Security Considerations Section and re-ordered 4509 paragraphs in that section. 4511 11. Added mention of being able to configure a port so that native 4512 frames are not send and are dropped on receipt. Probably need to 4513 say more about this. 4515 12. Remove material about pseudo node suppression. 4517 13. Fix a few cases where hop count was off by one. 4519 14. Add option critical bits when option area length non-zero. 4521 15. Replace some remaining references to Q-tag with C-tag. 4523 16. Miscellaneous minor editing and terminology updates. Changed 4524 Figure numbers to be relative to major section. Added Table 4525 captions. 4527 Changes from -07 to -08 4529 1. Add "low" and "high" level control frame definitions to Section 4530 1.2 and note concerning frames that would qualify as both "TRILL" 4531 and "control" frames. Utilize these defined frame types more 4532 consistently through the document. 4534 2. Move substantial areas of tutorial, motivational, and 4535 informational text to Appendices, or a separate document, 4536 including Sections numbered 2.5, 4.8, 6.3, and 6.4 in version 4537 -07. Remove pseudo-code (Section 5 in version -07). 4539 3. Move link Hellos / VLAN specification and discussion to a new 4540 subsection of Section 4. 4542 4. Replace distribution tree root flag per RBridge with new logic 4543 which orders all RBridges in a campus as to their priority to be 4544 a distribution tree root and provides for the highest priority 4545 distribution tree root to dictate the numbers of trees in the 4546 campus. RBridges use the tree with least cost from themselves to 4547 the tree root for multi-destination frame distribution, or the n 4548 such trees if they multi-path multi-destination traffic. 4550 5. Add "Access" port configuration bit and Appendix on Trunk and 4551 Access Links. 4553 6. Add statement that use of S-tags in TRILL is outside the scope of 4554 this document. 4556 7. Add new section on RBridge port structure (Section 4.7) which 4557 includes discussion of RBridge interactions with BPDUs and 4558 revised interactions with VRP frames. Make provisions for dynamic 4559 VLAN registration a "MAY" implement and agnostic between GVRP and 4560 MVRP. Remove references to 802.1ak. Simplify text related to VRP. 4561 Remove related configuration option. 4563 8. Add requirement to adjust input filters no later than output 4564 forwarding. 4566 9. Add requirement for configurable (default 30 second) inhibition 4567 on RBridge decapsulation out a port if a root bridge change has 4568 just been observed on that port. 4570 10. Add provisions for propagating topology change to attached 4571 bridged LAN when an RBridge is de-appointed forwarder. Also other 4572 end station addressing forgetting details including per VLAN 4573 forwarding status dropped counter. 4575 11. Delete requirement that appointed forwarder wait until it has 4576 received all the LSPs listed in the first CSNP (if any) it has 4577 received from its neighbors before forwarding frames off a link. 4579 12. Add explicit criterion for when an RBridge port defers to the DRB 4580 indicated in a Hello it receives even if that Hello is not from 4581 the DRB or even from an RBridge in direct communication with the 4582 DRB. 4584 13. Add provisions for pseudonode minimization. 4586 14. Update reference to RFC 2434 to be to RFC 5226. 4588 15. Miscellaneous minor editing and terminology updates. Add Figures 4589 index after Table of Contents. 4591 Changes from -08 to -09 4593 1. Specify SHOULD as the implementation requirement for SNMPv3 4594 management. 4596 2. Change default confidence level to 0x20 for addresses learned 4597 from observing locally received native frames and from 4598 decapsulating TRILL data frames. This provides more space for 4599 lower confidence levels. 4601 3. Add security consideration for observation of traffic no longer 4602 constrained to links in its Inner.VLAN due to TRILL 4603 encapsulation. 4605 4. Updated bridge configuration assumptions in Section 2.3.1. 4607 5. Use "inhibited" to describe the status of an appointed forwarder 4608 when it is temporarily discarding all received native frames and 4609 not sending any native frames. 4611 6. In Section 4.4, there was an implication that the priority to be 4612 a tree root and the number of trees to be computed had not only 4613 default values for a zero configuration RBridge but could also be 4614 individually present or absent in the LSP for the RBridge. This 4615 tends to lead to a variable-length sub-TLV or multiple sub-TLVs 4616 in the LSP that leads to additional code paths to test. So 4617 various "if advertised" conditional clauses have been removed. 4619 7. Reserve nicknames 0xFFC0 through 0xFFFE as well as 0x0000 and 4620 0xFFFF and provide IANA Considerations for their allocation. 4622 8. Improve Figure 4.1, "TRILL Data Encapsulation over Ethernet" by 4623 generalizing it and adding an RBridge diagram. 4625 9. Add "access port" bit to Hello. Extend and clarify behavior for 4626 access ports and for the occurrence of the IS Neighbor TLV in 4627 TRILL Hellos. 4629 10. Miscellaneous minor editing. 4631 Changes from -09 to -10 4633 1. Split Section 2.4 into two subsections inserting 2.4.1 with a 4634 simplified RBridge port diagram and discussion of how RBridges 4635 mostly use the mechanisms of IEEE 802.1Q-2005 bridges below the 4636 EISS layer. 4638 2. Remove the "SHOULD" requirement that the hop count for multi- 4639 destination frames not be set by the ingress RBridge in excess of 4640 the distance through the distribution tree to the most remote 4641 RBridge. 4643 3. Remove any implication that addresses received by ESADI are 4644 always better than those learned from the data plane. 4646 4. Rephrase language concerning the case where a known unicast 4647 native frame in receive by an RBridge to be output in native form 4648 on another link of that RBridge so that instead of describing 4649 this as logically forwarding the frame in native form it is 4650 described as logically encapsulating and then decapsulating the 4651 frame. 4653 5. Remove language saying that a TRILL Ethertype frame with a 4654 broadcast outer destination address MAY be treated as if its 4655 outer destination address was All-RBridges. 4657 6. Clarify that all TRILL data frames with unknown or reserved 4658 egress nicknames are discarded. 4660 7. Substantially expand Figure 4.5 at the upper port layers and 4661 correspondingly expand the accompanying text that is now Section 4662 4.7.2. 4664 8. Change TRILL IS-IS frames so they are no longer encapsulated but 4665 have the All-IS-IS-RBridges Outer.MacDA. Change the Inner.MacDA 4666 of ESADI frames to be the new All-ESADI-RBridges multicast 4667 address. 4669 9. Update reference to RFC 3567 to be to RFC 5304. 4671 10. Miscellaneous minor editing changes. 4673 Changes from -10 to -11 4675 1. Add BPDU/Hello denial of service section to Security 4676 Considerations. 4678 2. Remove general prohibition on RBridges sending spanning tree 4679 BPDUs. 4681 3. Change ESADI from "End Station Address Distribution Instance" to 4682 "End Station Address Distribution Information". 4684 4. Delete redundant requirement that TRILL IS-IS Hellos contain an 4685 extra field distinguishing the port from which they are sent. 4686 This need is met by the source MAC address. 4688 5. Add Maximum Transit Delay for RBridges with enforcement a MAY. 4690 6. Confused note re DRB deferral deleted. 4692 7. Update boilerplate and make miscellaneous minor editing changes. 4694 Changes from -11 to -12 4696 1. Changes in the determination of the distribution trees to allow 4697 the highest priority RBridge to explicitly list some or all of 4698 the tree roots. Change the listing of distribution trees an 4699 RBridge can use in encapsulating multi-destination frames to 4700 allow the RBridge to not explicitly list all the roots it can 4701 use. 4703 2. Add figures and a little text illustrating the structure of TRILL 4704 IS-IS and TRILL ESADI frames. 4706 3. Add brief discussion of Hello size limitations. 4708 4. Extend appointed forwarder inhibition to also occur on receiving 4709 a Hello sent on VLAN-x as well as received on VLAN-x in cases of 4710 VLAN translation. 4712 5. Provide for the allocation of a block of 16 multicast addresses 4713 for TRILL use by the IETF Registration Authority. RBridges 4714 conforming to this specification discard frames sent to any of 4715 these addresses other than All-RBridges and All-IS-IS-RBridges. 4716 (All-ESADI-RBridges is only allowed as an Inner.MacDA.) 4718 6. Add text on MTU and add Protection Hellos so there are now two 4719 kinds of Hellos, Adjacency and Protection. 4721 7. Add text mandating the RBridges with the Extended IS Adjacency 4722 TLV (#22) and do not use the IS Adjacency TLV (#2). 4724 8. Add text requiring and specifying "tie breaking" to select only 4725 one when sending multi-destination frames between RBridges 4726 connected by multiple parallel links. Mandate three-way handshake 4727 on links configured to use P2P Hellos to provide Extended Circuit 4728 ID. 4730 9. Add section and material on using P2P Hellos. 4732 10. Miscellaneous minor editing changes. 4734 Changes from -12 to -13 4736 1. Eliminate all references to "Hello time", replacing with 4737 appropriate references to Holding Time. 4739 2. Response to IEEE 802.1 comments: Replace all occurrences to 4740 "[802.1Q]" with "[802.1Q-2005]" to make it absolutely, positively 4741 clear that we don't claim to support the "current" 802.1Q as 4742 amended. Add Appendix E to summarize the current state of support 4743 by this draft for the current 802.1Q adopted and in-process 4744 amendments. 4746 3. Improve wording on frame types terminology in Section 1.3. 4748 4. Permit multiple nicknames per Rbridge. 4750 5. Make tie breaker on building distribution trees be the "tree 4751 number" which counts trees rooted at different nicknames at the 4752 same Rbridge as different trees. 4754 6. Renumber 4.3 through 4.7 to be 4.5 through 4.9 and add new 4755 sections 4.3 on MTU-probe and MTU-probe-ack and 4.4 on the TRILL- 4756 Hello protocol that approximately corresponds to the previous 4757 Section 4.2.4. 4759 7. Change TRILL control (IS-IS) messages to be indicated by the 4760 L2-IS-IS Ethertype. Add that Ethertype to Section 5 and Section 4761 7.2. 4763 8. Eliminate references to TRILL IS-IS instance as "core". 4765 9. Eliminate feature whereby encapsulated multi-destination frames 4766 being sent to only one next hop RBridge of interest could be sent 4767 unicast. 4769 10. Update references to Problem and Applicability Statement draft to 4770 be to RFC 5556. 4772 11. Change how the Hop Count is handled so it is tested on receipt of 4773 an encapsulated frame and discarded if it is zero and then not 4774 tested when decremented on forwarding. 4776 12. Clarify and correct handling of multiple parallel links between 4777 adjacent RBridges providing tie-breaking. 4779 13. Correct DRB election to specify MAC address as tie breaker, not 4780 System ID. 4782 14. Change default number of multi-destination frames to be 4783 calculated for the campus from 2 to 1. Provide for RBridges to 4784 advertise how many trees they can calculate and limit number of 4785 trees to the minimum such number across all RBridges in the 4786 campus. 4788 15. Provide that when an appointed forwarder observes that the DRB on 4789 a link has changed, it no longer considers itself appointed for 4790 that link until appointed by the new DRB. 4792 16. Add new section 4.4.4 and material in 4.5.2 and other spots on 4793 port groups, renumbering the former 4.4.4 as 4.4.5. 4795 17. Miscellaneous editing changes. 4797 Changes from -13 to -14 4799 1. Clarify Section 4.5.2 and specify that the extended circuit ID 4800 specified by the RBridge with the highest System ID is the one 4801 use for tie breaking. 4803 2. Specify a maximum size for TRILL-Hello messages (1470 bytes) and 4804 that they SHOULD NOT be padded. 4806 3. Note in 4.2.4.4 that the measured MTU for a link may be 4807 advertised in a sub-TLV of wide metric. 4809 4. Add default link cost specification to 4.2.4.4 item 1. 4811 5. Add note that the VLANs an RBridge is advertising connectivity to 4812 may be associated with particular nicknames of that RBridge as 4813 per draft-ietf-isis-layer2-01.txt. 4815 6. Update 802.3 reference to 802.3-2008. 4817 7. Parts of Section 5 that duplicated Section 7 were eliminated from 4818 Section 5 and the RBridge configuration parameters description in 4819 Section 5 was made more complete. 4821 8. Add references to RFC 3417 and 3419 in connection with SNMP 4822 support. 4824 9. Update Appendix E. 4826 10. Update references to Clause 43 of 802.3 to be to 802.1AX-2008 and 4827 add a couple of references to Annex 31B of 802.3. 4829 11. Clarify that the ways in which RBridges differ in behavior from 4830 802.1Q-2005 bridges are specified in this document. 4832 12. Define "port" to clarify that it includes virtual and pseudo 4833 ports. 4835 13. Clarify that RBridges, as defined in this document, do *not* 4836 offer services equivalent to provider or provider backbone 4837 bridges and that extensions of TRILL in that direction are left 4838 for future work. However, provider and/or provider backbone 4839 bridges may be used to connect parts of an RBridge campus. 4841 14. Add a statement that the optimal and multipath features of TRILL 4842 are of more benefit to more mesh-like networks. 4844 15. Add rapid updating of MAC attachment location as a motivation for 4845 ESADI. 4847 16. Add explanation and motivation for optional decrease of hop 4848 count, for multi-destination frames only, by more than one. 4850 17. Clarify that an RBridge selecting a new nickname does so only 4851 from the nicknames which appear free, based on its copy of the 4852 link state database, which accelerates convergence to stable 4853 nicknames. 4855 18. Provide that priority to be tree root is per nickname, not per 4856 Rbridge, and recommend the sparing use of multiple-nicknames at 4857 an Rbridge. 4859 19. Specify that an RBridge campus is a single Level 1 IS-IS area 4860 with area-ID zero. 4862 20. Add material on ambiguous destinations to new section 4.2.6, 4863 4.6.2.4 and elsewhere: duplicate nicknames or VLAN/MAC addresses. 4865 21. Clarify that the link MTU testing and campus wide inter-RBridge 4866 MTU determination are to support proper TRILL IS-IS operation, do 4867 not relate directly to end station traffic, and do not provide 4868 and end-to-end path MTU service or determination. 4870 22. Specify that TRILL-Hellos are sent with the same timing as IS-IS 4871 LAN Hellos. 4873 23. Add brief statement on how to avoid re-ordering of frames when a 4874 VLAN/MAC address changes between known and unknown. 4876 24. Permit ports to be configured to accept TRILL-encapsulated frames 4877 from devices with which the RBridge does not have an IS-IS 4878 adjacency. 4880 25. Expand ECMP discussion in Appendix C to account for various cases 4881 under this current draft. 4883 26. Specify the default state for the port disable, trunk, access, 4884 and P2P configuration bits. 4886 27. Add definition of "campus". 4888 28. Add "SHOULD" requirement for an RBridge with multiple nicknames 4889 to use the same one as ingress when encapsulating native frames 4890 from the same MAC and VLAN. 4892 29. Many miscellaneous editing changes. 4894 Changes from -14 to -15 4896 There were only two technical changes from -14 to -15, as listed in 4897 items 1 and 9 below. 4899 1. Add port ID to TRILL-Hello by adding one sentence each to section 4900 4.4.2 and 4.4.4. 4902 2. Change name of IANA registry to "TRILL Parameter Registry". 4904 3. Clarify in Section 4.1.4 that the TRILL encapsulated frames have 4905 only one FCS, that is, the encapsulated payload does not include 4906 an FCS. 4908 4. Clarify description of tree numbering at the end of 4.5 4910 5. Clarify in Section 4.5.5 that multi-destionation frames are not 4911 sent back out the port they are received on. 4913 6. Clarify that the meaning of the Reserved bits in Figure 3.2 will 4914 be specified in other documents. Improve wording of description 4915 of critial bits. 4917 7. Add normative references in Section 4.2 to draft-ietf-isis-layer2 4918 and add it to the normative references list. 4920 8. Clarify the TRILL IS-IS frames are always Ethertype encoded. 4922 9. Fix next to last paragraph of Section 4.7 so an RBridge doing 4923 IPv6 multicast optimization does have to announce it is in the 4924 IPv6 All-Snoopers Group. 4926 10. Fix about a dozen typos, mostly one character changes. 4928 Authors' Addresses 4930 Radia Perlman 4931 Sun Microsystems 4932 16 Network Circle 4933 Menlo Park, CA 94025 4935 Phone: +1-650-960-1300 4936 Email: Radia.Perlman@sun.com 4938 Donald E. Eastlake, 3rd 4939 Stellar Switches 4940 155 Beaver Street 4941 Milford, MA 01757 USA 4943 Phone: +1-508-634-2066 4944 Email: d3e3e3@gmail.com 4946 Dinesh G. Dutt 4947 Cisco Systems 4948 170 Tasman Drive 4949 San Jose, CA 95134-1706 USA 4951 Phone: +1-408-527-0955 4952 Email: ddutt@cisco.com 4954 Silvano Gai 4955 Cisco Systems 4956 2600 San Tomas Expressway 4957 Santa Clara, CA 95051 USA 4959 Phone: +1-408-387-6123 4960 Email: sgai@cisco.com 4962 Anoop Ghanwani 4963 Brocade Communications Systems 4964 1745 Technology Drive 4965 San Jose, CA 95110 USA 4967 Phone: +1-408-333-7149 4968 Email: anoop@brocade.com 4970 Copyright and IPR Provisions 4972 Copyright (c) 2010 IETF Trust and the persons identified as the 4973 document authors. All rights reserved. 4975 This document is subject to BCP 78 and the IETF Trust's Legal 4976 Provisions Relating to IETF Documents 4977 (http://trustee.ietf.org/license-info) in effect on the date of 4978 publication of this document. Please review these documents 4979 carefully, as they describe your rights and restrictions with respect 4980 to this document. Code Components extracted from this document must 4981 include Simplified BSD License text as described in Section 4.e of 4982 the Trust Legal Provisions and are provided without warranty as 4983 described in the BSD License. The definitive version of an IETF 4984 Document is that published by, or under the auspices of, the IETF. 4985 Versions of IETF Documents that are published by third parties, 4986 including those that are translated into other languages, should not 4987 be considered to be definitive versions of IETF Documents. The 4988 definitive version of these Legal Provisions is that published by, or 4989 under the auspices of, the IETF. Versions of these Legal Provisions 4990 that are published by third parties, including those that are 4991 translated into other languages, should not be considered to be 4992 definitive versions of these Legal Provisions. For the avoidance of 4993 doubt, each Contributor to the IETF Standards Process licenses each 4994 Contribution that he or she makes as part of the IETF Standards 4995 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 4996 language to the contrary, or terms, conditions or rights that differ 4997 from or are inconsistent with the rights and licenses granted under 4998 RFC 5378, shall have any effect and shall be null and void, whether 4999 published or posted by such Contributor, or included with or in such 5000 Contribution.