TRILL R.Perlman Internet Draft Sun Microsystems Intended status: Proposed Standard Silvano Gai Nuova Systems Dinesh G. Dutt Cisco Systems Expires: August 2007 March 2007 RBridges: Base Protocol Specification draft-ietf-trill-rbridge-protocol-03.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Distribution of this document is unlimited. Comments should be sent to the TRILL working group mailing list. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire September 2007. Abstract RBridges allow for optimal pair-wise forwarding with zero configuration, safe forwarding even during periods of temporary loops, and the ability to cut down on ARP/ND and IP multicast Perlman, Gai, Dutt Expires September 2007 [Page 1] Internet-Draft RBridge Protocol March 2007 traffic. They achieve these goals by replacing the Spanning Tree protocol with IS-IS. The design also supports VLANs, and allows forwarding tables to be based on RBridge destinations (rather than endnode destinations), which allows internal forwarding tables to be substantially smaller than in conventional bridge systems. Acknowledgements Many people have contributed to this design, including the working group co-chairs Donald Eastlake 3rd and Erik Nordmark, and many other members of the working group including, in alphabetic order, Alia Atlas, Stewart Bryant, Dino Farinacci, Don Fedyk, Eric Gray, Sanjay Sane, and Joe Touch. We invite you to join the mailing list at http://www.postel.org/rbridge. Table of Contents 1. Introduction...................................................3 1.1. Algorhyme V2..............................................4 1.2. Conventions used in this document ........................5 2. RBridges.......................................................5 2.1. RBridge Architecture......................................6 2.2. RBridges and VLAN.........................................8 2.3. Forwarding of Different Frame Types.......................9 2.3.1. Known-Unicast........................................9 2.3.2. Multi-destination....................................9 2.4. Advantages of RBridges...................................10 3. Detailed RBridge Design.......................................10 3.1. TRILL Header Format......................................10 3.1.1. Version (V).........................................11 3.1.2. Multi-destination (M)...............................11 3.1.3. Hop Limit...........................................11 3.1.4. RBridge addresses...................................12 3.1.4.1. Egress RBridge Address.........................12 3.1.4.2. Ingress RBridge Address........................12 3.2. Ethernet Encapsulation...................................12 3.2.1. Outer VLAN Tag......................................14 3.2.2. Inner VLAN Tag......................................14 3.2.3. FCS.................................................15 3.2.4. Point-to-point links................................15 3.3. Link State Protocol (IS-IS)..............................15 3.3.1. IS-IS RBridge Identity..............................16 3.3.2. Separate Instances..................................16 3.3.3. Multiple RBridge IS-IS Instances....................16 3.3.3.1. The IS-IS core instance........................16 Perlman, Gai, Dutt Expires September 2007 [Page 2] Internet-Draft RBridge Protocol March 2007 3.3.3.2. The IS-IS VLAN instance........................17 3.3.4. Designated RBridge..................................18 3.4. Distribution Trees.......................................20 3.4.1. Distribution Tree Calculation.......................21 3.5. Pruning the Distribution Tree............................22 3.6. Forwarding using a Distribution Tree.....................22 3.7. Wiring Closet Topology...................................23 3.8. Learning Endnode Location................................24 3.9. Forwarding Behavior......................................25 3.9.1. Receipt of a Native Frame...........................25 3.9.1.1. Unicast case...................................25 3.9.1.2. Other multi-destination frames.................26 3.9.1.3. IS-IS frames...................................26 3.9.2. Receipt of an In-transit Frame......................27 3.9.2.1. Flooded Frame..................................27 3.9.2.2. Unicast Frame..................................28 3.9.2.3. IS-IS Frame....................................28 3.10. IGMP Learning...........................................28 3.11. RBridge Addresses.......................................29 3.12. Handling ARP/ND Queries.................................29 3.13. Discovering IP Multicast Routers........................31 3.14. Assuring Freshness of Endnode Information...............31 4. RBridge Addresses, Parameters, and Constants..................32 5. Security Considerations.......................................32 6. IANA Considerations...........................................33 7. References....................................................33 7.1. Normative References.....................................33 7.2. Informative References...................................34 Intellectual Property Statement..................................35 Disclaimer of Liability..........................................36 Copyright Statement..............................................36 Acknowledgment...................................................36 1. Introduction In traditional IPv4 and IPv6 networks, each subnet has a unique prefix. Therefore, a node in multiple subnets has multiple IP addresses, typically one per interface. This also means that when an interface moves from one subnet to another, it changes its IP address. Administration of IP networks is complicated because IP routers require significant configuration and careful IP address management is required to avoid creating subnets that are not fully populated and waste addresses. IEEE 802.1 bridges avoid these problems by transparently gluing many physical links into what appears to IP to be a single LAN. Perlman, Gai, Dutt Expires September 2007 [Page 3] Internet-Draft RBridge Protocol March 2007 Bridge forwarding via the spanning tree has some disadvantages: o The spanning tree blocks ports limiting the number of forwarding links and therefore creates bottleneck by concentrating traffic onto selected links. o The Ethernet header does not contain a TTL field and this is dangerous when there are temporary loops such as when spanning tree messages are lost or components such as repeaters are added. o Forwarding is not pair-wise shortest path, but is instead whatever path remains after the spanning tree eliminates redundant paths. This document presents the design for RBridges (Routing Bridges), which combines the advantages of bridges and routers [RBridges] and which is poetically summarized below. While RBridge technology can be applied to a variety of link protocols, this specification, where relevant, concentrates on 802.3 links. 1.1. Algorhyme V2 I hope that we shall one day see A graph more lovely than a tree. A graph to boost efficiency While still configuration-free. A network where RBridges can Route packets to their target LAN. The paths they find, to our elation, Are least cost paths to destination! With packet hop limits we now see, The network need not be loop-free! RBridges work transparently. Without a common spanning tree. Ray Perlner Perlman, Gai, Dutt Expires September 2007 [Page 4] Internet-Draft RBridge Protocol March 2007 1.2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2. RBridges The main idea is to have RBridges run a link state protocol amongst themselves. This enables them to have enough information to compute pairwise optimal paths for unicast, and to calculate distribution trees for delivery of frames either to unknown destinations, or to multicast/broadcast groups. ECMP (Equal Cost MultiPath) may be supported, but it may introduce frame reordering. To mitigate the temporary loop issues, RBridges forward based on a header with a hop limit (AKA TTL or hop count). Although the hop limit discards looping frames, it is also desirable not to spawn additional copies of frames by having RBridges specify the next RBridge recipient, while forwarding across a shared-media link. RBridges MUST learn the location of endnodes. They learn the location and layer 2 addresses of attached nodes from the source address of frames, as bridges do (for example, see section 8.7 of [802.1Q]). RBridges also learn the IP addresses of directly attached nodes and their association with MAC addresses from ARP/ND requests/replies. Once an RBridge learns the location of a directly attached endnode, it advertises this information to the other RBridges in its link state information. Perlman, Gai, Dutt Expires September 2007 [Page 5] Internet-Draft RBridge Protocol March 2007 2.1. RBridge Architecture +----------------------------------------------------------+ | Higher Layer Entities | +--+--------------+----------------------+--------------+--+ | \ Trill Layer | RBridge Relay Entity | Trill Layer / | +----+------------+----------------------+------------+----+ | Data Link Layer | | Data Link Layer | +-----------------+ +-----------------+ | Physical Layer | | Physical Layer | +-------+---------+ +-------+---------+ | | P1 P2 Figure 1 Architecture of an RBridge Figure 1 shows an RBridge that contains: o An Rbridge Relay Entity that interconnects two Rbridge ports; o At least one port (two in the example); o Higher Layer Entities, including at least the IS-IS protocol. o The TRILL Layer. An RBridge encapsulates incoming IEEE 802.3 frames (in this document also referred to as Ethernet frames) with a TRILL header to forward them to other Rbridges. The layer 2 technology used to connect Rbridges may be either IEEE 802.3 or some other technology such as PPP. This is possible since the functionality of an RBridge relay entity is layered on top of the layer 2 technologies. However, in accordance with the TRILL WG charter, the first edition of this document specifies only an IEEE 802.3 encapsulation. Figure 2 shows two RBridges R1 and R2 interconnected through an Ethernet cloud. There are no restrictions on what may compose the Ethernet cloud: point-to-point or shared media, hubs and bridges. The Ethernet cloud may support VLAN tagging or not. Perlman, Gai, Dutt Expires September 2007 [Page 6] Internet-Draft RBridge Protocol March 2007 ------------ / \ +----+ / Ethernet \ +----+ | R1 |----< >---| R2 | +----+ \ Cloud / +----+ \ / ------------ Figure 2 Interconnected RBridges Figure 3 shows the format of a TRILL frame traveling through the Ethernet cloud from R1 to R2. +--------------------------------+ | Outer Ethernet Header | +--------------------------------+ | TRILL Header | +--------------------------------+ | Inner Ethernet Header | +--------------------------------+ | Ethernet Payload | +--------------------------------+ | Ethernet FCS | +--------------------------------+ Figure 3 An Ethernet Encapsulated TRILL Frame In the case of other media different from Ethernet, the outer Ethernet header is replaced by the header specific to that media. For example, figure 4 shows a TRILL encapsulation over PPP. +--------------------------------+ | PPP Header | +--------------------------------+ | TRILL Header | +--------------------------------+ | Inner Ethernet Header | +--------------------------------+ | Ethernet Payload | +--------------------------------+ | Ethernet FCS | +--------------------------------+ Figure 4 A PPP Encapsulated TRILL Frame Perlman, Gai, Dutt Expires September 2007 [Page 7] Internet-Draft RBridge Protocol March 2007 The outer header is link-specific, and although this document specifies only Ethernet links, other links are allowed. In both cases the Inner Ethernet Header and the Ethernet Payload are those of the original frame. Frames are encapsulated with a TRILL header as they travel between RBridges for several reasons: 1. to mitigates the loop issues with bridges a hop limit field is included; 2. to prevent source MAC learning in the core from frames in transit; 3. to direct frames towards the egress RBridge. This enables forwarding tables of RBridges to be sized with the number of RBridges rather than the total number of endnodes. When forwarding between RBridges across a shared-media, the data link layer header contains the address of the next hop Rbridge, to avoid frame duplication and, in the case of loops, to avoid spawning additional copies of frames. 2.2. RBridges and VLAN A VLAN is a way to partition endnodes into different communities [802.1Q]. The usual method of determining which community a frame belongs to is based on the port from which it is received. IEEE 802.1Q compliant bridges support VLANs and the same support is present in RBridges. IEEE 802.1Q bridges have the capability of supporting multiple VLANs over a single link by inserting/removing a VLAN tag into the frame. Some endnodes have the same capability. The VLAN tag is structured according to IEEE 802.1Q. As shown in figure 3, there are two places where such tags may be present in a TRILL-encapsulated frame: one in the outer header (outer VLAN) and one in the inner header (inner VLAN). Inners and Outer VLANs are further discussed in section 3.2. RBridges enforce that a frame originating in a particular inner VLAN gets delivered only to other links in the same inner VLAN. Perlman, Gai, Dutt Expires September 2007 [Page 8] Internet-Draft RBridge Protocol March 2007 A side-effect of inner VLANs is that it makes RBridges more scalable, since endnode membership in an inner VLAN is only of interest to RBridges that have an attached port configured to be in that inner VLAN. 2.3. Forwarding of Different Frame Types There are several types of frames which RBridges forward slightly differently. They are here classified into two main categories: known-unicast and multi-destination. 2.3.1. Known-Unicast These frames have an inner MAC Destination Address (Inner.MacDa) that is unicast and the MAC address location is known to the ingress RBridge (the RBridge that performs the TRILL encapsulation). 2.3.2. Multi-destination These are frames that must be delivered to multiple destinations, because either they have a group address or the location of the destination is unknown. They are: 1. frames for unknown unicast destinations: the Inner.MacDa is unicast, but the ingress RBridge does not know its location; 2. frames for layer 2 multicast addresses derived from IP multicast addresses: the Inner.MacDa is multicast; 3. frames for layer 2 multicast addresses not derived from IP multicast addresses: the Inner.MacDa is multicast; 4. frames for the layer 2 broadcast addresses: the Inner.MacDa is broadcast; 5. ARP queries: the Inner.MacDa is broadcast; 6. ND queries: the Inner.MacDa is multicast; Perlman, Gai, Dutt Expires September 2007 [Page 9] Internet-Draft RBridge Protocol March 2007 7. IGMP membership reports: the Inner.MacDa is multicast. RBridges build distribution trees (see Section 3.4. ) and use these trees for forwarding multi-destination frames. 2.4. Advantages of RBridges Like bridges, RBridges are zero configuration and transparent to IP nodes. Like routers, RBridges forward on pair-wise shortest paths, and do not create broadcast storms during temporary loops. RBridges have the additional advantage that they may optimize IP multicast traffic, and ARP (IPv4) [RFC826] and ND (IPv6) [RFC2461] by avoiding the broadcast/multicast behavior of the queries. RBridges are fully compatible with current 802.1D and 802.1Q bridges as well as current IPv4 and IPv6 routers and endnodes. They are as invisible to current IP routers as bridges are, and like routers, they terminate the spanning tree protocol. 3. Detailed RBridge Design 3.1. TRILL Header Format The TRILL header is shown in Figure 5 and it is independent of the data link layer used. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V | Hop Limit |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ingress RBridge Address | Egress RBridge Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 TRILL Encapsulation o V (Version): 2-bit. See Section 3.1.1. o Hop Limit: 6-bit unsigned integer. See Section 3.1.3. o M (Multi-destination): 1-bit. See Section 3.1.2. o Reserved: 7-bit. Perlman, Gai, Dutt Expires September 2007 [Page 10] Internet-Draft RBridge Protocol March 2007 o Ingress RBridge Address: 16-bit address. See Section 3.1.4.2. o Egress RBridge Address: 16-bit address. See Section 3.1.4.1. 3.1.1. Version (V) According to IEEE's Ethertype format guidelines, a single Ethertype is granted to a protocol and it is the protocol's responsibility to structure the format of the protocol header so as to support future revisions to the protocol. In adhering to this guideline, a two bit field called version is used to identify the format in use. It is set to 0 by default. If it is set to 1, 2, 3 the header format is undefined by this version of the standard. 3.1.2. Multi-destination (M) The Multi-destination bit (see Section 2.3.2. ) specifies the content of the egress RBridge address: o M = 0 (FALSE) - the egress RBridge address contains the address of the egress Rbridge; o M = 1 (TRUE) - the egress RBridge address contains the address of the RBridge that is the root of the distribution tree. 3.1.3. Hop Limit A 6-bit unsigned integer. Each RBridge MUST check this field before forwarding the frame to another RBridge. If this field is zero, the frame MUST be discarded. If this field is non-zero, it MUST be decremented by one in the forwarded frame. This field was previously referred to as TTL (Time To Live) or hop count. In IPv6 the IETF has replaced the concept of TTL with Hop Limit. TRILL aligns with this newer definition. Perlman, Gai, Dutt Expires September 2007 [Page 11] Internet-Draft RBridge Protocol March 2007 3.1.4. RBridge addresses 16-bit address. This is the TRILL address of the RBridge. This assignment allows addressing up to 64K RBridges. This was also referred to in the past as "RBridge nickname" or "shim nickname". The simplest encoding of an RBridge address would be a 48-bits MAC address. However, to achieve a more compact encoding, RBridges piggyback a address acquisition protocol on the link state protocol (see Section 3.11. ), to acquire a unique 16-bit addresses (within the campus). 3.1.4.1. Egress RBridge Address This field contains two types of information, depending on M-bit (see Section 3.1.2. ): o For known-unicast frames, it contains the egress RBridge Address i.e. the RBridge that needs to remove the TRILL header from the frame. o For multi-destination frames, it contains the address of the root RBridge of the distribution tree to be used to forward the frame. 3.1.4.2. Ingress RBridge Address The ingress RBridge address always contains the identifier of the ingress RBridge, i.e. the RBridge that added the TRILL header to the frame. 3.2. Ethernet Encapsulation TRILL frames in transit on Ethernet links are encapsulated with an additional outer Ethernet header (see figure 3). This outer header looks, to an Ethernet bridge on the path between two RBridges, like the header of a regular Ethernet frame and therefore bridges forward the frame without requiring any modification. To enable RBridges to distinguish encapsulated frames, a new Ethertype = TRILL (to be assigned) is used in the outer header. Perlman, Gai, Dutt Expires September 2007 [Page 12] Internet-Draft RBridge Protocol March 2007 Figure 6 details a frame traveling on the Ethernet cloud of Figure 2 from R1 to R2. This encapsulation has the advantage of aligning the original Ethernet frame at 64 bit boundaries. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Destination MAC Address | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Outer VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = TRILL | V | Hop Limit |M| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Egress RBridge Address | Ingress RBridge Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Destination MAC Address | InnerSource MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Source MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype = IEEE 802.1Q | UP |C| Inner VID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original Ethernet Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New FCS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 TRILL Encapsulation over Ethernet When a TRILL frame is carried over an Ethernet cloud it has three sets of addresses: o Outer MAC Addresses. These addresses are used to address the next hop RBridge over a shared Ethernet Cloud. o TRILL Addresses. These are the end-to-end addresses of the RBridges doing the encapsulation/decapsulation (at least for the known unicast case, see Section 3.1.4. ). o Inner MAC Addresses. These are the addresses of the endnodes, as originally inserted in the frames by the transmitting endnode. Perlman, Gai, Dutt Expires September 2007 [Page 13] Internet-Draft RBridge Protocol March 2007 It also potentially has two IEEE 802.1Q tags that carries two different VLAN Identifier (VID). 3.2.1. Outer VLAN Tag The Outer VLAN Tag: MAY or MAY NOT be present. If present, it is used to enable connectivity between two RBridges through an Ethernet cloud that support VLANs. Once two RBridges have established connectivity on an outer VLAN, they become adjacent and they start to operate as if connected by a direct link. For example, a network manager may configure VLAN 4 for RBridges RB1 and RB2 to communicate (the outer VID contains the value 4). VLAN 3 may be assigned for RB2 and RB3 to communicate (the outer VID contains the value 3). In this case RB2 becomes adjacent to both RB1 (on VLAN 4) and RB3 (on VLAN 3), but RB1 and RB3 are not adjacent (since they have no common VLAN). There is no additional discussion of this field in the rest of the document. 3.2.2. Inner VLAN Tag The Inner VLAN Tag: contains the VLAN information associated with the original frame. Each Ethernet port of an RBridge uses the "ingress rule" specified in Section 6.7 of IEEE 802.1Q. This rule always associates a VID (VLAN Identifier) with any frame, independently of whether the frame came in tagged, untagged or priority tagged. Since the most common default value for the parameter PVID (Port VLAN Identifier) is 1, an Rbridge MAY suppress the inner VLAN tag for frames with VID = 1. The Inner VID is extremely important for TRILL (see section 2.2. ). In the rest of this document, any reference to the term VLAN should be interpreted as inner VLAN. Perlman, Gai, Dutt Expires September 2007 [Page 14] Internet-Draft RBridge Protocol March 2007 3.2.3. FCS The frame has a single FCS that is computed to cover the entire frame. This has become standard practice in IEEE 802.1: the tagging structure effectively requires FCS recomputation at the boundaries of the network. Additionally, the IETF (with diffserv, ECN, routing) have also effectively required FCS recomputation at all boundaries of the network. 3.2.4. Point-to-point links If there is a direct RBridge-to-RBridge point-to-point link, there is no real need for the outer header. Therefore if the link is a point- to-point Ethernet link, it is acceptable to set the fields in the outer header to predefined values on transmission and ignore them on reception. 3.3. Link State Protocol (IS-IS) In recent years, the IS-IS routing protocol [ISO10589] has become increasingly popular, with widespread usage among Service Providers. It is a link state protocol, which enables very fast convergence with large scalability. It is also a very flexible protocol and has been extended to incorporate leading edge features such as MPLS Traffic Engineering. TRILL uses IS-IS, since it also provides the following advantages: o it runs directly over the layer 2; o it is easy to extend by defining new TLVs for carrying the TRILL information; o it may be run with zero configuration. IS-IS exchanges information by exchanging LSPs (Link State PDUs). Perlman, Gai, Dutt Expires September 2007 [Page 15] Internet-Draft RBridge Protocol March 2007 3.3.1. IS-IS RBridge Identity Each RBridge has a unique 6-byte System ID, which may be derived from any of the RBridge universal MAC addresses. 3.3.2. Separate Instances RBridge implements a separate IS-IS instance from the one used by any routing protocol, e.g. the ones used by IP routers. This instance is identified by a combination of Outer.Mac.DA, Outer.Ethertpe and Inner.Ethertype (see 3.9.1.3. ). The RBridge IS-IS instance is also differentiated by defaulting to a distinct, constant "area address" (the value 0) that would never appear as a real IS-IS area address. 3.3.3. Multiple RBridge IS-IS Instances Each RBridge runs multiple IS-IS instances: o One IS-IS core instance; o IS-IS VLAN instances, one per each inner VLAN the RBridge is connected to. In theory this information could all be contained in one instance of RBridge IS-IS. However, since endnode information for a particular VLAN needs to be known only to RBridges that are connected to links configured to be in that VLAN, and since the core instance is global to all RBridges, it is appropriate to have multiple instances. 3.3.3.1. The IS-IS core instance The information contained in the LSP of RBridge Rn core is: 1. the TRILL address of RBridge Rn; 2. the list of VIDs of VLANs directly connected to Rn; 3. a flag RequestTree indicating whether RBridges MUST calculate a tree rooted at Rn (default RequestTree = TRUE); Perlman, Gai, Dutt Expires September 2007 [Page 16] Internet-Draft RBridge Protocol March 2007 4. the System IDs of RBridges which are neighbors of RBridge Rn, and the cost of the link to each of those neighbors. Using the previous information each RBridge can compute the optimal pair-wise forwarding for know-unicast traffic and the distribution trees for multi-destination traffic. The distribution trees (see Section 3.4. ) may also be pruned according to the list of VIDs connected to each RBridge (see Section 3.5. ). In fact, if Rn is forwarding a multi-destination frame tagged with VLAN A, Rn need not forward it onto branches of the distribution tree that have no downstream VLAN A links. 3.3.3.2. The IS-IS VLAN instance The endnode information for VLAN A, which is carried in the LSP injected by Rn in VLAN A, contains: 1. L2INFO: layer 2 addresses of nodes on a VLAN A link attached to Rn which have transmitted frames, but have not transmitted ARP/ND requests/replies (i.e., these are not known to be IP nodes). 2. L3and2INFO: layer 3, layer 2 addresses of IP nodes attached Rn on VLAN A, which Rn has learned through ARP/ND requests/replies. In the case of IPv6, for data compression, only the portion of the address following the campus-wide prefix is carried. 3. Multicast Router attached: This is one bit of information that indicates whether there is an IP multicast router attached on VLAN A. This information is used because IGMP [RFC3376] Membership Reports MUST be transmitted to all links with IGMP routers, and SHOULD NOT be transmitted to links without IGMP routers. Also, all frames for IP-derived multicast addresses MUST be transmitted to all links with IGMP routers (within the VLAN), in addition to links from which an IP node has explicitly asked to join the group which the frame is for. 4. Layer 2 addresses derived from IPv4 or IPv6 IGMP notification messages received from attached endnodes on VLAN A, indicating the location of listeners for these multicast addresses. If Rn has learned endnode E's location first from a data frame (and therefore has included E's layer 2 address in the L2INFO), and later E transmits an ARP/ND request/reply, Rn MUST include E in the L3andL2INFO, and SHOULD remove E from L2INFO. Perlman, Gai, Dutt Expires September 2007 [Page 17] Internet-Draft RBridge Protocol March 2007 The way that RBridges distinguish which IS-IS instance the VLAN link state information is for is based on the VLAN tag in the inner header i.e. the inner VLAN. Given that RBridges already support distribution trees pruned by VID (see Section 3.3.3.1. ), the same mechanism is used by the per-VLAN instance of IS-IS to distribute endnode information solely to RBridges within a VLAN. Each per-VLAN instance of IS-IS appears to the RBridges as a single link with all the RBridges with endnodes in that VLAN as neighbor. When an RBridge originates an IS-S frame for the VLAN A instance, all RBridges forward it as an ordinary frame in VLAN A, along the specified distribution tree, even if they nave no endnodes connected to VLAN A. RBridges with endnodes in VLAN A also receive and process the frame in their VLAN-A IS-IS instance. 3.3.4. Designated RBridge IS-IS elects one RBridge on each link to be the Designated RBridge, i.e. to have special duties. The Designated RBridge: o learns and advertises the identities of attached endnodes; o encapsulates and forwards frames that originate on that link to the rest of the campus; o decapsulates and forwards frames onto that link received from other RBridges; o initiates a distributed ARP/ND when an ARP/ND query is received for an unknown destination; o answers ARP/ND queries when the target node is known. It is incorrect to have multiple RBridges being Designated RBridge on the same link at the same time. This could temporarily happen if a partitioned bridged LAN became connected with a bridge or repeater. The situation resolves once the better priority RBridge's IS-IS Hello is received by the other RBridges on the link. Perlman, Gai, Dutt Expires September 2007 [Page 18] Internet-Draft RBridge Protocol March 2007 BPDUs are messages that are transmitted and received even in preforwarding state (listening and learning states). If RBridges listen to BPDUs, and if the LANs for which R1 was Designated RBridge, and for which R2 was Designated RBridge get joined, then either R1 or R2 detect that the bridge Root has changed identity. A conservative solution would be to invoke something like a preforwarding state, in which the RBridge that detects the change stops forwarding anything to or from the link until it is sure the IS-IS link election would have completed. But the IS-IS election could get slowed down due to bridges in preforwarding state, and it would be undesirable to disrupt traffic to and from the link just because the root ID has changed. An alternative solution is to have RBridges participate in the spanning tree election, with higher priority for becoming root (actually, lowest numerical priority value) than any of the bridges, and with the same priority as for becoming Designated RBridge on the link. Then an RBridge is Designated RBridge if and only if it is the spanning tree Root. Note that RBridges MUST NOT merge spanning trees from different ports. If two ports of R1 are connected to the same bridged LAN, then the regular bridge spanning tree algorithm partitions the LAN into distinct LANs for each of R1's ports. However, if two of R1's ports are connected to the same shared medium (without any bridges between the ports), then the regular bridge spanning tree algorithm turns off one of R1's redundant ports. So for example, R1 sends BPDUs on each of its ports, with itself as Root (with highest, i.e., numerically lowest priority), 0 cost from Root, and the port ID. There are several possible cases: o R1 is the highest priority RBridge on the bridged LAN, in which case it becomes spanning tree Root and Designated RBridge. o R1 receives a BPDU from itself (because two of its ports are on the same shared medium without any bridges between). In this case, the numerically lowest port remains in ST forwarding state, and the other port(s) go into ST blocking state. R1 receives a BPDU from someone else with higher priority (numerically lower priority|ID), in which case R1 is not Root, and not Designated RBridge. It is possible this is due to a bridge being configured with the lowest priority, and then if R1 declines being Designated RBridge, the LAN becomes orphaned from the campus. We must treat this case as a misconfiguration of bridges, and the LAN becomes orphaned until the misconfiguration is corrected, but an RBridge could in theory eventually discover it is not receiving Perlman, Gai, Dutt Expires September 2007 [Page 19] Internet-Draft RBridge Protocol March 2007 any IS-IS Hellos, and become Designated RBridge even though it is not spanning tree Root. 3.4. Distribution Trees RBridges use distribution trees to forward multi-destination frames (see Section 2.3.2. ). Distribution Trees are bidirectional. A single distribution tree is enough for the entire campus. The TRILL WG decided that the computation of additional distribution trees was warranted because: 1. using a tree rooted at the ingress RBridge optimizes the distribution path and (almost always) the cost of delivery when the number of destination links is a subset of the total number of links, as is the case with VLANs and IP multicasts; 2. for unknown unicast destinations, using a tree rooted at the ingress RBridge minimizes out-of-order delivery because in the case where a flow starts before the location of the destination is known by the RBridges, the path to the destination is the same as the shortest path to the destination. A distribution tree rooted in the ingress RBridge is not always the best choice: 1. In some cases, a different tradeoff might be wanted in terms of expense of computation vs. optimality of traffic distribution (so fewer trees would be desired) 2. It might be desirable to allow choosing a different distribution tree than the one rooted at the ingress RBridge, in order to allow multipathing of multicast traffic injected by a particular Bridge. RBridges MUST calculate at least one distribution tree, and by default SHOULD compute one distribution tree for every Rbridge. However, to scale in the presence of a large number of RBridges in a campus, some RBridges MAY be configured to not be the root of distribution tree. Each RBridge Ri announces whether RBridges MUST compute a tree rooted at Ri via the RequestTree flag in its IS-IS core instance LSP. The default is RequestTree == TRUE, but management configuration MAY reduce the number of trees. If all RBridges have their RequestTree == FALSE, then each RBridge MUST calculate a tree rooted at the RBridge with lowest ID. Perlman, Gai, Dutt Expires September 2007 [Page 20] Internet-Draft RBridge Protocol March 2007 If Ri is a tree root, then any RBridge Rn that needs to send multi- destination traffic MAY select the Ri-tree. Rn does so by specifying in the TRILL header: Trill.EgressRbridgeAddress = Ri; Trill.M = TRUE; All the other RBridges MUST comply with the decision of Rn. In IS-IS a shared link is modeled as a pseudonode. Pseudonodes MUST set RequestTree = FALSE. 3.4.1. Distribution Tree Calculation RBridges do not use the spanning tree protocol to calculate distribution trees. Instead, distribution trees are calculated based on the link state information, selecting a particular RBridge as the root. Calculation of a tree rooted at Ri is done independently by each RBridge Rn by performing the SPF (Shortest Path First) calculation with Ri as the root without requiring any additional exchange of information. In the case a node Rn has two or more minimal equal cost path toward the root Ri a deterministic tie-breaker is needed to guarantee that all RBridges calculate the same distribution tree. This is obtained by selecting the path that goes to the parent that has the lower IS- IS System ID. Each RBridge Rn keeps a set of adjacencies (port, neighbor pair) for each distribution tree. One of these adjacencies is toward the root Ri and the others are toward the leaves. Once the adjacencies are chosen, it is irrelevant which ones are towards the root Ri, and which are away from Ri. Let's suppose that Rn has calculated that adjacencies a, c, and f are in the Ri tree. A multi-destination frame for the distribution tree Ri is received only from one of the adjacencies a, c, or f (otherwise is discarded) and forwarded to the other two adjacencies. Perlman, Gai, Dutt Expires September 2007 [Page 21] Internet-Draft RBridge Protocol March 2007 3.5. Pruning the Distribution Tree Each distribution tree is pruned per VLAN eliminating branches that have no potential receivers downstream. Multi-destination frames are forwarded only on branches that are not pruned. Further pruning is done in the case of IGMP Notification Messages [RFC3376], where these are to be delivered only to ports with IP Multicast Routers. In the case of a multicast derived from an IP multicast, these multicast data frames are delivered only to links that have registered listeners, plus links which have IP Multicast routers. Let's assume that RBridge Rn knows that adjacencies (a, c, and f) are in the Ri-distribution tree. Rn marks pruning information for each of the adjacencies in the Ri-tree. For each adjacency and for each tree, Rn marks: o the set of VLANs reachable downstream, and for each one of those, a flag indicating whether there are IP multicast routers downstream, and o the set of layer 2 multicast addresses derived from IP multicast group for which there are receivers downstream. 3.6. Forwarding using a Distribution Tree Forwarding a multi-destination frame is done as follows: o The RBridge Rn receives a multi-destination frame on VLAN A and the TRILL header indicates the selected tree is the Ri-tree; o if the adjacency from which the frame was received is not one of the adjacencies in the Ri-tree, the frame is dropped; o else if the frame is an IGMP Notification message then the frame is forwarded onto adjacencies in the Ri-tree that indicate there are downstream VLAN-A IP multicast routers; o else if the frame is for a layer 2 multicast address derived from IP multicast groups then the frame is forward onto adjacencies in the Ri-tree that indicate there are downstream VLAN-A IP multicast routers, as well as adjacencies that indicate there are downstream VLAN-A receives for that group address; Perlman, Gai, Dutt Expires September 2007 [Page 22] Internet-Draft RBridge Protocol March 2007 o else if the inner frame is for an unknown destination or layer 2 multicast not derived from IP multicast, or distributed ARP/ND, or broadcast, the frame is forwarded onto an adjacency if and only if that adjacency is in the Ri-tree, and marked as reaching VLAN-A links. For each link for which Rn is Designated RBridge, Rn additionally checks to see if it should decapsulate the frame and send it to the link (e.g., if it is a distributed ARP/ND in the specified VLAN for that link), or process the frame (e.g., if it is a per-VLAN IS-IS instance link state announcement for a VLAN that Rn is attached to). 3.7. Wiring Closet Topology In cases where there are two (or more) groups of endnodes, each attached to a bridge (say B1 and B2 respectively), and each bridge is attached to an RBridge (say R1 and R2 respectively), with a link connecting B1 and B2 (see Figure 7), it may be desirable to have the B1-B2 link only as a backup in case one of R1 and R2, or the links B1-R1 or B2-R2 fail. +----+ +----+ | R1 |-----| R2 | +----+ +----+ | | +-------------------------------+ | | | | | +----+ +----+ | | Closet | B1 |-----| B2 | | | +----+ +----+ | | | +-------------------------------+ Figure 7 Wiring Closet Topology For example, B1 and B2 may be in a wiring closet and it may be easy to provide a very short very high bandwidth link between them while R1 and R2 are at a distant data center such that the R1-B1 and R2-B2 links are slower and more expensive. Default behavior would be that one of R1 or R2 (say R1) would become Designated RBridge, and forward traffic to/from the link, so endnodes attached to B2 would be connected to the campus via the path B2-B1- Perlman, Gai, Dutt Expires September 2007 [Page 23] Internet-Draft RBridge Protocol March 2007 R1, rather than the desired B2-R2. The desired behavior would probably be to make maximum use of both the R1-B1 and R2-B2 links. The solution is to configure R1 and R2 to be part of a "wiring closet group", with a configured System ID Rx (which may be R1 or R2's System ID). Both R1 and R2 participate in the bridge spanning tree on the configured ports as root Rx, which causes the spanning tree to break the B1-B2 link as desired, and both R1 and R2 act as Designated RBridge on each of their respective partitions. In the BPDU, the Root is "Rx", cost to Root is 0, Designated Bridge ID is "R1" when R1 transmits and "R2 when R2 transmits, and port ID is a value chosen independently by each of R1 and R2 to distinguish each of its own ports. If R1 and R2 were actually on the same shared medium with no bridges between them, the result is that the one with the larger ID sees "better" BPDUs (because of the tie-breaker on the third field; the ID of the transmitting RBridge), and turns off the port. The only misconfiguration that may occur is if the link R1-R2 is on the cut set of the campus, and R2 and/or R1 have been configured to believe they are part of a wiring closet group. In that case, the link becomes partitioned. 3.8. Learning Endnode Location RBridges learn endnode location from native frames (similar to 802.1D bridges, see in section 7.0 of [802.1Q]). They learn (layer 3, layer 2) pairs, for the purpose of supporting ARP/ND optimization, from listening to ARP/ND request/replies. This endnode information is learned by the Designated RBridge, and distributed to other RBridges through the link state protocol. RBridges need not remember endnode information for a VLAN unless there are endnodes for that VLAN on one of their directly connected links. Perlman, Gai, Dutt Expires September 2007 [Page 24] Internet-Draft RBridge Protocol March 2007 3.9. Forwarding Behavior 3.9.1. Receipt of a Native Frame 3.9.1.1. Unicast case Let's assume that Rn receives a unicast frame with Mac.Da = D, Mac.Sa = S and Ethertype != TRILL. Rn knows this is a native frame from the Ethertype value. Rn determines the VID according to the same rules as bridges do. Once the VLAN is established, the layer 2 address of D is looked up in the destination table for that VLAN to find the egress RBridge Rm, or discover that D is unknown. If D is known, with egress Rm, then Rn encapsulates the frame, in the following way: Outer.MacDa = next hop RBridge (in the path to Rm); Outer.MacSa = Rn; Outer.Ethertype = TRILL; Trill.v = 0; Trill.Reserved = 0; Trill.M = FALSE; // this is not a multi-destination frame Trill.HopLimit = default or configured hop limit; Trill.EgressRBridgesAddress = Rm; Trill.IngressRBridgesAddress = Rn; Followed by the received frame; If D is unknown, Rn encapsulates the frame, in the following way: Outer.MacDa = ALL-RBRIDGES; Outer.MacSa = Rn; Outer.Ethertype = TRILL; Trill.v = 0; Trill.Reserved = 0; Trill.M = TRUE; // this is a multi-destination frame Trill.HopLimit = default or configured hop limit; Trill.EgressRBridgesAddress = Ri // Distribution Tree, see below Trill.IngressRBridgesAddress = Rn; Followed by the received frame; In the latter case, the egress RBridge address indicates the chosen distribution tree Ri. The default is for Rn to put its own address there. However, if Rn is configured to decline to be a tree root, Perlman, Gai, Dutt Expires September 2007 [Page 25] Internet-Draft RBridge Protocol March 2007 then Rn MUST select some other RBridge Ri which has elected to be a tree root or the RBridge with the lowest ID if none have elected to be a tree root. 3.9.1.2. Other multi-destination frames If the frame is an IGMP announcement, then Rn learns the group membership, and announces a receiver for that layer 2 group address in its per-VLAN link state instance. If the frame is a PIM or MRD [RFC4286] message, Rn learns that there is an IP multicast router (for the specified VLAN) on its link, and adds that information into its per-VLAN IS-IS link state information. If the frame is an ARP/ND reply, then Rn learns the (layer 3, layer 2) correspondence, and adds that information into its per-VLAN link state information. 3.9.1.3. IS-IS frames If the frame is from the IS-IS core instance of Rn, then there is no need for the TRILL Ethertype and inner headers. The outer header contains: Outer.MacDa = ALL-RBRIDGES; Outer.MacSa = Rn; Outer.Ethertype = IS-IS; In this case the IS-IS frame is never forwarded by the RBridge as a layer 2 frame, but instead is delivered to the RBridge IS-IS process for processing. The situation is different in the per-VLAN instances of IS-IS, since there is the need to carry the VID. The encapsulation is as follow: Outer.MacDa = ALL-RBRIDGES; Outer.MacSa = Rn; Outer.Ethertype = TRILL; Trill.v = 0; Trill.Reserved = 0; Trill.M = TRUE; // this is a multi-destination frame Trill.HopLimit = MAX-HOP-LIMIT; Trill.EgressRBridgesAddress = Ri; // Distribution Tree, see above Trill.IngressRBridgesAddress = Rn; Perlman, Gai, Dutt Expires September 2007 [Page 26] Internet-Draft RBridge Protocol March 2007 Followed by a VLAN-tagged IS-IS packet (same as for core instance, but with VLAN tag). In this case the frames are forwarded like a non- IP-multicast flooded frame, as well as processed, if the RBridge belongs to the specified VLAN. 3.9.2. Receipt of an In-transit Frame Let's suppose RBridge Rn receives a TRILL encapsulated frame (as indicated by Outer.Ethertype = TRILL). 3.9.2.1. Flooded Frame if (Outer.MacDa == ALL-RBRIDGES) { if (Outer.MacSa != a tree adjacency for the tree indicated) { Discard the frame } else { Rn forwards along the tree indicated by Trill.EgressRBridgesAddress, pruned as specified in section 3.5. It also removes the TRILL encapsulation and forwards the frame to the appropriate ports where it is a Designated RBridge. } } Perlman, Gai, Dutt Expires September 2007 [Page 27] Internet-Draft RBridge Protocol March 2007 3.9.2.2. Unicast Frame if (Outer.MacDa != Rn) { R1 Drops the frame // the destination in the outer header // is not R1 } else { if (Trill.EgressRBridgesAddress == Rn) { Rn process the frame, i.e. it removes the TRILL encapsulation, extracts the inner frame and forwards it onto the link containing the destination, or processes the frame if the Inner.MacDa == Rn. } else { // The frame needs to be forwarded to another RBridge // Outer.MacDa = lookup (Trill.EgressRBridgesAddress); Outer.MACSa = Rn; Trill.HopLimit -= 1; forward_frame(); } } 3.9.2.3. IS-IS Frame If the protocol type in the outer header indicates this is an IS-IS frame, then Rn processes the frame accordingly. 3.10. IGMP Learning RBridges learn, based on seeing IGMP [RFC3376] frames, which multicast addresses should be forwarded onto which links. IGMP messages have to be forwarded throughout the campus, since IP routers in the broadcast domain also need to see these messages. IGMP messages are forwarded by RBridges throughout the campus like any layer 2 multicast. They are recognized by having an IP message type=2 in the IP header. In addition, they are processed by RBridges Perlman, Gai, Dutt Expires September 2007 [Page 28] Internet-Draft RBridge Protocol March 2007 in order to extract, from announcements, what egress RBridges have receivers for which groups. 3.11. RBridge Addresses To make the TRILL header smaller, RBridges dynamically acquire 2-byte addresses that are unique within the campus. The address allocation protocol is piggybacked on the core IS-IS RBridge instance as follows: o The address requested by the RBridge is carried in a new TLV. Each RBridge chooses its own address. o Each RBridge is also responsible for ensuring that its address is unique. If R1 chooses address x, and R1 discovers, through receipt of R2's LSP, that R2 has also chosen x, then the RBridge with the lower System ID keeps the address, and the other RBridge MUST choose a new address. o If two RBridge domains merge then transient address collisions are possible. As soon as each RBridge receives the link state frames from the other RBridges, the RBridges that need to change addresses choose new addresses that do not, to the best of their knowledge, collide with any existing addresses. To minimize the probability of address collisions, each RBridge chooses its address randomly hashing some of its parameters. There is no reason for all RBridges to use the same algorithm for choosing addresses. Once an RBridge has successfully acquired an address it SHOULD store it in non-volatile memory and reuse it in the case of a reboot. To minimize the probability of a new RBridge usurping a address already in use, an RBridge SHOULD wait to acquire the link state database from a neighbor before it announces its own address. 3.12. Handling ARP/ND Queries IEEE 802.1 bridges forward an ARP/ND query as an ordinary broadcast/multicast frame to all links belonging to the same VLAN. Rbridges SHOULD implement an "optimized ARP/ND response" Perlman, Gai, Dutt Expires September 2007 [Page 29] Internet-Draft RBridge Protocol March 2007 When the target's location is assumed to be known by the first RBridge, it needs not flood the query. Alternative behaviors of the first Designated RBridge that receives the ARP/ND query would be to: 1. send a response directly to the querier, with the layer 2 address of the target, as believed by the RBridge 2. encapsulate the ARP/ND query to the target's Designated RBridge, and have the Designated RBridge at the target forward the query to the target. This behavior has the advantage that a response to the query is authoritative. If the query does not reach the target, then the querier does not get a response 3. block ARP/ND queries that occur for some time after a query to the same target has been launched, and then respond to the querier when the response to the recently-launched query to that target is received The reason not to do the most optimized behavior all the time is for timeliness of detecting a stale cache. Also, in the case of scure neighbor discovery (SEND) [RFC3971], cryptography might prevent behavior 1, since the RBridge would not be able to sign the response with the target's private key. It is not essential that all RBridges use the same strategy for which option to select for a particular query. However, once the first Designated RBridge decides on a strategy for a particular query, the other RBridges MUST carry that through. If the first RBridge responds directly to the querier, or blocks the query, then no other RBridges are involved. If the first Designated RBridge R1 decides to unicast the query to the target's Designated RBridge R2, then R2 decapsulates the query, and initiate an ARP/ND query on the target's link. When/if the target responds, R2 encapsulates and unicast the response to R1, which decapsulates the response and send it to the querier. If the first Designated RBridge R1 decides to flood the query (which it MUST do if the target is unknown, but MAY do if it wants to assure freshness of the information), the query is encapsulated to be flooded through the indicated VLAN. The distributed ARP/ND query is carried by RBridges through the RBridge distribution tree. Each Designated RBridge, in addition to forwarding the query through the distribution tree, initiates an ARP/ND query on its link(s). If a reply is received from the target by Designated RBridge R2, R2 initiates a link state update to inform Perlman, Gai, Dutt Expires September 2007 [Page 30] Internet-Draft RBridge Protocol March 2007 all the other RBridges of D's location, layer 3 address, and layer 2 address, in addition to forwarding the reply to the querier. It is the querier's Designated RBridge R1 that chooses which strategy to employ when seeing an ARP/ND query. Some mix of these strategies (responding directly, unicasting the query to the target's Designated RBridge, or flooding the query) might be the best solution. For instance, even if the target's location and (layer 3, layer 2) correspondence is in the link state information R1 received from R2, if the target's location has not been recently verified by R1 through a broadcast ARP/ND or unicast query to the target, then R1 MAY broadcast or unicast the query or respond directly. So for instance, RBridges could keep track of the last time a broadcast ARP/ND occurred for each endnode E (by any source, and injected by any RBridge). Let's say the parameter is 20 seconds. If a source S on RBridge R1's link does an ARP/ND for D, if R1 has not seen an ARP/ND for D within the last 20 seconds, R1 unicasts the query to force a reply from the target; otherwise it proxies the reply. When R2 forwards a unicast ARP/ND query, if the target does not respond, then R2 MAY replay the query, and if the target still does not respond, R2 SHOULD remove the target from its link state information. 3.13. Discovering IP Multicast Routers Until Multicast Router Discovery [RFC4286] is universally deployed, RBridges discover IP multicast routers through their transmission of PIM messages. So an RBridge concludes there is an IP multicast router on its port if it either receives an MRD message or a PIM message on that port. A PIM message is recognized because the protocol type in the IP header is decimal 103. 3.14. Assuring Freshness of Endnode Information A Designate RBridge MUST be capable of ensuring freshness of its endnode information using periodic ARP/ND queries. Because this may be a problem if the endnodes are in power-saver mode, there MUST be a configuration option to disable or control the frequency of these queries. These queries SHOULD be enabled by default. Perlman, Gai, Dutt Expires September 2007 [Page 31] Internet-Draft RBridge Protocol March 2007 4. RBridge Addresses, Parameters, and Constants Each RBridge needs a unique System ID. The simplest such address is a unique 6-byte ID, since such an ID is easily obtainable as any of the EUI-48's owned by that RBridge. IS-IS already requires each router to have such an address. The parameter DEFAULT-HOP-LIMIT (suggested value 20). It is the value used to initialize Trill.HopLimit when an RBridge encapsulates a frame if some other value has not been configured. A new Ethertype must be assigned to indicate a TRILL encapsulated frame. A layer 2 multicast address for ALL-RBRIDGES must be assigned for use as the destination address in flooded frames. To support VLANs, RBridges (like bridges today), must be configured, for each port, with the PVID (Port VLAN ID) in which that port belongs. A parameter to determine whether an RBridge should periodically do queries to ensure that the endnode information is fresh, and if so, with what frequency. The parameter RequestTree that indicates whether an RBridge wants to be the root of a distribution tree. Configuration for wiring closet topology consists of System ID of the RBridge with lowest System ID. If R1 and R2 are part of a wiring closet topology, only R2 needs to be configured to know about this, and that R1 is the ID it should use in the spanning tree protocol on the specified port. 5. Security Considerations The goal is for RBridges to not add additional security issues over what would be present with traditional bridges. RBridges do not prevent nodes from impersonating other nodes, for instance, by issuing bogus ARP/ND replies. However, RBridges do not interfere with any schemes that would secure neighbor discovery. As with routing schemes, authentication of RBridge messages would be a simple addition to the design (and it would be accomplished the same way as it would be in IS-IS). However, any sort of Perlman, Gai, Dutt Expires September 2007 [Page 32] Internet-Draft RBridge Protocol March 2007 authentication requires additional configuration, which might interfere with the perception that RBridges, like bridges, are zero configuration. 6. IANA Considerations A new Ethertype must be assigned to indicate an TRILL encapsulated frame. A layer 2 multicast address for "All RBridges" must be assigned for use as the destination address in flooded frames. 7. References 7.1. Normative References [802.1D] "IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Bridges", 802.1D-2004, 9 June 2004. [802.1Q] "IEEE Standard for Local and metropolitan area networks / Virtual Bridged Local Area Networks", 802.1Q-2005, 19 May 2006. [ISO10589] ISO/IEC 10589:2002, "Intermediate system to Intermediate system routeing information exchange protocol for use in conjunction with the Protocol for providing the Connectionless-mode Network Service (ISO 8473)," ISO/IEC 10589:2002. [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", RFC 826, November 1982. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461 (Standards Track), December 1998. [RFC3376] Cain, B., "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC4286] Haberman, B., Martin, J., "Multicast Router Discovery", RFC 4286, December 2005. Perlman, Gai, Dutt Expires September 2007 [Page 33] Internet-Draft RBridge Protocol March 2007 [SNOOP] Christensen, M., Kimball, K, Solensky, F., "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12.txt 7.2. Informative References [Arch] Gray, E., "The Architecture of an RBridge Solution to TRILL", draft-ietf-trill-rbridge-arch-01.txt, October 2006, work in progress. [PAS} Touch, J., & R. Perlman "Transparent Interconnection of Lots of Links (TRILL) / Problem and Applicability Statement", draft-ietf- trill-prob-01.txt, Octover 2006, work in progress. [RBridges] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 2005, March 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RP1999] Perlman, R., "Interconnection: Bridges, Routers, Switches, and Internetworking Protocols", Addison Wesley Chapter 3, 1999. Perlman, Gai, Dutt Expires September 2007 [Page 34] Internet-Draft RBridge Protocol March 2007 Author's Address Radia Perlman Sun Microsystems Email: Radia.Perlman@sun.com Silvano Gai Nuova Systems Email: sgai@nuovasystems.com Dinesh G. Dutt Cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134-1706 Phone: 1-408-527-0955 EMail: ddutt@cisco.com Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Perlman, Gai, Dutt Expires September 2007 [Page 35] Internet-Draft RBridge Protocol March 2007 Disclaimer of Liability This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Perlman, Gai, Dutt Expires September 2007 [Page 36]