Skip to main content

Transparent Interconnection of Lots of Links (TRILL): Problem and Applicability Statement

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5556.
Authors Radia Perlman , Dr. Joseph D. Touch
Last updated 2015-10-14 (Latest revision 2009-03-05)
Replaces draft-touch-trill-prob
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Informational
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5556 (Informational)
Action Holders
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Mark Townsley
Send notices to (None)
TRILL WG                                                       J. Touch 
Internet Draft                                                  USC/ISI 
Intended status: Informational                               R. Perlman 
Expires: September 2009                                             Sun 
                                                          March 5, 2009 
           Transparent Interconnection of Lots of Links (TRILL):  
                    Problem and Applicability Statement 

Status of this Memo 

   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and BCP 79.  

   This document may contain material from IETF Documents or IETF 
   Contributions published or made publicly available before November 
   10, 2008. The person(s) controlling the copyright in some of this 
   material may not have granted the IETF Trust the right to allow 
   modifications of such material outside the IETF Standards Process.  
   Without obtaining an adequate license from the person(s) controlling 
   the copyright in such materials, this document may not be modified 
   outside the IETF Standards Process, and derivative works of it may 
   not be created outside the IETF Standards Process, except to format 
   it for publication as an RFC or to translate it into languages other 
   than English. 

   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-

   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 

   The list of Internet-Draft Shadow Directories can be accessed at 

   This Internet-Draft will expire on September 5, 2009. 

Touch & Perlman       Expires September 5, 2009                [Page 1] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

Copyright Notice 

   Copyright (c) 2009 IETF Trust and the persons identified as the 
   document authors. All rights reserved. 

   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents in effect on the date of 
   publication of this document ( 
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 


   Current IEE 802.1 LANs use spanning tree protocols that have a number 
   of challenges. These protocols need to strictly avoid loops, even 
   temporary ones, during route propagation, because of the lack of 
   header loop detection support. Routing tends not to take full 
   advantage of alternate paths, or even non-overlapping pairwise paths 
   (in the case of spanning trees). This document addresses these 
   concerns and suggests that they can be addressed by applying modern 
   network layer routing protocols at the link layer. This document 
   assumes that solutions would not address issues of scalability beyond 
   that of existing IEEE 802.1 bridged links, but that a solution would 
   be backward compatible with 802.1, including hubs, bridges, and their 
   existing plug-and-play capabilities. 

Table of Contents 

   1. Introduction...................................................3 
   2. The TRILL Problem..............................................4 
      2.1. Inefficient Paths.........................................4 
      2.2. Multipath Forwarding......................................6 
      2.3. Convergence and Safety....................................7 
      2.4. Stability of IP Multicast Optimization....................7 
      2.5. Other Ethernet Protocol Extensions........................8 
      2.6. Problems Not Addressed....................................9 
   3. Desired Properties of Solutions to TRILL......................10 
      3.1. No Change to Link Capabilities...........................10 
      3.2. Zero Configuration and Zero Assumption...................11 
      3.3. Forwarding Loop Mitigation...............................11 
      3.4. Spanning Tree Management.................................12 
      3.5. Multiple Attachments.....................................12 
      3.6. VLAN Issues..............................................12 
      3.7. Operational Equivalence..................................13 
      3.8. Optimizations............................................13 
      3.9. Internet Architecture Issues.............................14 
Touch & Perlman       Expires September 5, 2009                [Page 2] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   4. Applicability.................................................15 
   5. Security Considerations.......................................15 
   6. IANA Considerations...........................................16 
   7. Acknowledgments...............................................16 
   8. References....................................................16 
      8.1. Normative References.....................................16 
      8.2. Informative References...................................16 
1. Introduction 

   Conventional Ethernet networks - known in the Internet as Ethernet 
   link subnets - have a number of attractive features, allowing hosts 
   and routers to relocate within the subnet without requiring 
   renumbering and are automatically configuring. The basis of the 
   simplicity of these subnets is the spanning tree, which although 
   simple and elegant, can have substantial limitations. With spanning 
   trees, the bandwidth across the subnet is limited because traffic 
   flows over a subset of links forming a single tree - or, with the 
   latest version of the protocol and significant additional 
   configuration, over a small number of superimposed trees. The oldest 
   version of the spanning tree protocol can converge slowly when there 
   are frequent topology changes. 

   The alternative to an Ethernet link subnet is often a network subnet. 
   Network subnets can use link-state routing protocols that allow 
   traffic to traverse least-cost paths rather than being aggregated on 
   a spanning tree backbone, providing higher aggregate capacity and 
   more resistance to link failures. Unfortunately, IP - the dominant 
   network layer technology - requires that hosts be renumbered when 
   relocated in different network subnets, interrupting network (e.g., 
   tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are 
   in progress during the transition.  

   It is thus useful to consider a new approach that combines the 
   features of these two existing solutions, hopefully retaining the 
   desirable properties of each. Such an approach would develop a new 
   kind of bridge system that was capable of using network-style 
   routing, while still providing Ethernet service. It allows reuse of 
   well-understood network routing protocols to benefit the link layer. 

   This document describes the challenge of such a combined approach. 
   This problem is known as "Transparent Interconnection of Lots of 
   Links" or "TRILL". The remainder of this document makes minimal 
   assumptions about a solution to TRILL. 

Touch & Perlman       Expires September 5, 2009                [Page 3] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

2. The TRILL Problem 

   Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted 
   pair with hubs to twisted pair with switches, becoming increasingly 
   simple to wire and manage. Each level has corresponding topology 
   restrictions; thicknet is inherently linear, whereas thinnet and hub-
   connected twisted pair have to be wired as a tree. Switches, added in 
   IEEE 802.1D, allow network managers to avoid thinking in trees, where 
   the spanning tree protocol finds a valid tree automatically; 
   unfortunately, this additional simplicity comes with a number of 
   associated penalties [Pe99]. 

   The spanning tree often results in inefficient use of the link 
   topology; traffic is concentrated on the spanning tree path, and all 
   traffic follows that path even when other more direct paths are 
   available. The addition in IEEE 802.1Q of support for multiple 
   spanning trees helps a little, but the use of multiple spanning trees 
   requires additional configuration, the number of trees is limited, 
   and these defects apply within each tree regardless. The spanning 
   tree protocol reacts to certain small topology changes with large 
   effects on the reconfiguration of links in use. Each of these aspects 
   of the spanning tree protocol can cause problems for current link 
   layer deployments. 

2.1. Inefficient Paths 

   The Spanning Tree Protocol (STP) helps break cycles in a set of 
   interconnected bridges, but it also can limit the bandwidth among 
   that set and cause traffic to take circuitous paths. For example, in 
   a set of N nodes that are interconnected pair-wise along a ring, 
   spanning tree will disable one physical link so that connectivity is 
   loop free. This will cause traffic between the pair of nodes 
   connected by that disabled link to have to go N-1 physical hops 
   around the entire remainder of the ring rather than take the most 
   efficient single hop path. Using modern routing protocols with such a 
   topology, no traffic should have to go more than N/2 hops. 

   For another example, consider the network shown in Figure 1, which 
   shows a number of bridges and their interconnecting links. End hosts 
   and routers are not shown; they would connect to the bridges that are 
   shown, labeled A-H. Note that the network shown has cycles that would 
   cause packet storms if hubs (repeaters) were used instead of 
   spanning-tree-capable bridges. One possible spanning tree is shown by 
   double lines. 

Touch & Perlman       Expires September 5, 2009                [Page 4] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

                                // \     C                                 
                               //   \   / \\   D                          
                              //     \ /   \\ //                          
                              B=======H===== E                             
                               \     //     || 
                                \   //      ||                             
                                 \ //       ||                             
             Figure 1 Bridged subnet with spanning tree shown 

   The spanning tree limits the capacity of the resulting subnet. Assume 
   that the links are 100 Mbps. Figure 2 shows how traffic from hosts on 
   A to hosts on C goes via the spanning tree path A-B-H-E-C (links 
   replaced with '1' in the figure); traffic from hosts on G to F go via 
   the spanning three path G-H-E-F (links replaced by '2' in the 
   figure). The link H-E is shared by both paths (alternating '1's and 
   '2's), resulting in an aggregate capacity for both A..C and G..F 
   paths of a total of 100 Mbps.  

                                 1        C                                 
                                1          1                              
                               1            1                            
                                     2       2 
                                    2        2                             
                                   2         2                             
                                  G          F                             
         Figure 2 Traffic from A..C (1) and G..F (2) share a link 

   If traffic from G to F were to go directly using full routing, e.g., 
   from G-F, both paths could have 100 Mbps each, and the total 
   aggregate capacity could be 200 Mbps (Figure 3). In this case, the H-
   F link carries only A-C traffic ('1's) and the G-F traffic ('2's) is 
   more direct. 

Touch & Perlman       Expires September 5, 2009                [Page 5] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

                                 1        C                                
                                1          1                              
                               1            1                            
       Figure 3 Traffic from A..C (1) and G..F (2) with full routing 

   There are a number of features of modern layer 3 routing protocols 
   which would be beneficial if available at layer 2, but which cannot 
   practically be integrated into the spanning tree system such as 
   multipath routing discussed in Section 2.2 below. Layer 3 routing 
   typically optimizes paths between pairs of endpoints based on a cost 
   metric, conventionally based on bandwidth, hop count, latency, and/or 
   policy measures. 

2.2. Multipath Forwarding 

   The discussion above assumes that all traffic flowing from one point 
   to another follows a single path. Spanning tree reduces aggregate 
   bandwidth by forcing all such paths onto one tree, while modern 
   routing causes such paths to be selected based on a cost metric. 
   However, extensions to modern routing protocols enable even greater 
   aggregate bandwidth by permitting traffic flowing from one end point 
   to another to be sent over multiple, typically equal cost, paths. 
   (Traffic sent over different paths will generally encounter different 
   delays and may be re-ordered with respect to traffic on another path. 
   Thus traffic must be divided into flows, such that re-ordering of 
   traffic between flows is not significant, and those flows allocated 
   to paths.) 

   Multipathing typically spreads the traffic more evenly over the 
   available physical links. The addition of multipathing to a routed 
   network would typically result in only a small improvement in 
   capacity for a network with roughly equal traffic between all pairs 
   of nodes, because in that situation traffic is already fairly well 
   dispersed. Conversely, multipathing can produce a dramatic 
   improvement in a routed network where the traffic between a small 
   numbers of pairs of nodes dominates, because such traffic can - under 
   the right circumstances - be spread over multiple paths that might 
   otherwise be lightly loaded. 

Touch & Perlman       Expires September 5, 2009                [Page 6] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

2.3. Convergence and Safety  

   The spanning tree is dependent on the way a set of bridges are 
   interconnected, i.e., the link layer topology. Small changes in this 
   topology can cause large changes in the spanning tree. Changes in the 
   spanning tree can take time to propagate and converge, especially for 
   older versions of the STP protocol. 

   One possible case occurs when one of the branches connected to the 
   root bridge fails, causing a large number of ports to block and 
   unblock before the network reconverges [Me04]. Consider a ring with a 
   stub as shown in Figure 4. 

                        |                   | 
         Figure 4 Ring with poor convergence under reconfiguration 

   If A is the root bridge, then the paths A->B->C->D and A->F->G->E are 
   the two open paths, while the D->E link is blocked. If the A->B link 
   fails, then E must unblock its port to D for traffic to flow again, 
   but it may require recomputation of the entire tree through BPDUs 
   (Bridge PDUs). Even worse, if R is root and R or the A-R connection 
   fails, BPDU updates related to the old and new root can lead to a 
   brief count-to-infinity event, and, if RSTP (Rapid Spanning Tree 
   Protocol) is in use, can delay convergence for a few seconds. The 
   original IEEE 802.1 spanning tree protocol can impose 30-second 
   delays in re-establishing data connectivity after a topology change 
   to be sure a new topology has stabilized and been fully propagated. 

   The spanning tree protocol is inherently global to an entire layer 2 
   subnet; there is no current way to contain, partition, or otherwise 
   factor the protocol into a number of smaller, more stable subsets 
   that interact as groups. Contrast this with Internet routing, which 
   includes both intradomain and interdomain variants, split to provide 
   exactly that containment and scalability within a domain while 
   allowing domains to interact freely independent of what happens 
   within a domain.  

2.4. Stability of IP Multicast Optimization 

   Although it is a layer violation, it is common for high end bridges 
   to snoop on IP multicast control messages for the purpose of 
   optimizing the distribution of IP multicast data and of those control 
   messages [RFC4541].  

Touch & Perlman       Expires September 5, 2009                [Page 7] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   When such snooping and optimization is performed by spanning tree-
   based bridges, it done at each bridge based on the traffic observed 
   on that bridge's ports. Changes in topology may reverse or otherwise 
   change the required forwarding ports of messages for a multicast 
   group. Bridges must re-learn the correct multicast forwarding from 
   the receipt of multicast control messages on new ports. Such control 
   messages, after their initial issuance to establish multicast 
   distribution state, are sent only to refresh such state, sometimes at 
   intervals of seconds, during which, if a bridging topology change has 
   occurred, multicast data may be misdirected and lost. 

   However, a solution based on link state routing, for example, can 
   form and maintain a global view of the multicast group membership and 
   multicast router situation in a similar fashion to that in which it 
   maintains a global view of the status of links. Thus such a solution 
   can adjust the forwarding of multicast data and control traffic 
   immediately as it sees the LAN topology change. 

2.5. Other Ethernet Protocol Extensions 

   There have been a variety of IEEE protocols beyond the initial 
   shared-media Ethernet variant, including: 

   o  802.1D - added bridges (i.e., switches) and a spanning tree 
      protocol (STP) (incorporates 802.1w, below) [IEEE04]. 

   o  802.1w - extension for rapid reconvergence of the spanning tree 
      protocol (RTSP) [IEEE04]. 

   o  802.1Q - added VLAN and priority support, where each link address 
      maps to one VLAN (incorporates 802.1v and 802.1s, below) [IEEE06]. 

   o  802.1v - added VLANs where segments map to VLANs based on link 
      address together with network protocol and transport port 

   o  802.1s - added support for multiple spanning trees, up to a 
      maximum of 65, one per non-overlapping group of VLANs (MSTP) 

   This document presumes the above variants are supported on the 
   Ethernet subnet, i.e., that a TRILL solution would not interfere with 
   (i.e., would not affect) any of the above. 

   In addition, the following more recent extensions have been 
   standardized to specify provider/carrier Ethernet services that can 
   be effectively transparent to the previously specified customer 
Touch & Perlman       Expires September 5, 2009                [Page 8] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   Ethernet services. The TRILL Problem as described in this document is 
   limited to customer Ethernet services; however, there is no reason 
   that a TRILL solution might not be easily applicable to both customer 
   and provider Ethernet. 

   o  802.1ad (Provider Bridges) - added support for a second level of 
      VLAN tag, called a "service tag", and re-named the original 802.1Q 
      tag a "customer tag". Also known as Q-in-Q because of the stacking 
      of 802.1Q VLAN tags. 

   o  802.1ah (Provider Backbone Bridges) - added support for stacking 
      of MAC addresses by providing a tag to contain the original source 
      and destination MAC addresses. Also know as MAC-in-MAC. 

   It is useful to note that no extension listed above in this section 
   addresses the issue of independent, localized routing in a single LAN 
   - which is the focus of TRILL. 

   The TRILL problem and a sketch of a possible solution [Pe04] were 
   presented to both the IETF (via a BoF) and IEEE 802 (via an IEEE 802 
   Plenary meeting Tutorial). The IEEE, in response, approved a project 
   called Shortest Path Bridging (IEEE Project P802.1aq), taking a 
   different approach than that presented in [Pe04]. The current Draft 
   of P802.1aq appears to describe two different techniques. One, which 
   does not use encapsulation, is, according to the IEEE Draft, limited 
   in applicability to small networks of no more than 100 shortest path 
   bridges. The other, which uses 802.1ah, is, according to the IEEE 
   Draft, limited in applicability to networks of no more than 1,000 
   shortest path bridges. 

2.6. Problems Not Addressed 

   There are other challenges to deploying Ethernet subnets that are not 
   addressed in this document other than, in some cases, to mention 
   relevant IEEE 802.1 documents, although it is possible for a solution 
   to address one or more of these in addition to the TRILL problem. 
   These include: 

   o  increased Ethernet link subnet scale 

   o  increased node relocation 

   o  Ethernet link subnet management protocol security 

   o  flooding attacks on a Ethernet link subnet 

Touch & Perlman       Expires September 5, 2009                [Page 9] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   o  support for "provider" services such as Provider Bridges 
      (802.1ad), Provider Backbone Bridges (802.1ah), or Provider 
      Backbone Bridge Traffic Engineering (802.1Qay) 

   Solutions to TRILL need not support deployment of larger scales of 
   Ethernet link subnets than current broadcast domains can support 
   (e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges, 
   or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges). 

   Similarly, solutions to TRILL need not address link layer node 
   migration, which can complicate the caches in learning bridges. 
   Similar challenges exist in the ARP protocol, where link layer 
   forwarding is not updated appropriately when nodes move to ports on 
   other bridges. Again, the compartmentalization available in network 
   routing, like that of network layer Autonomous Systems (ASes), can 
   help hide the effect of migration. That is a side effect, however, 
   and not a primary focus of this work. 

   Current link control plane protocols, including Ethernet link subnet 
   management (spanning tree) and link/network integration (ARP), are 
   vulnerable to a variety of attacks. Solutions to TRILL need not 
   address these insecurities. Similar attacks exist in the data plane, 
   e.g., source address spoofing, single address traffic attacks, 
   traffic snooping, and broadcast flooding. TRILL solutions need not 
   address any of these issues, although it is critical that they do not 
   introduce new vulnerabilities in the process (see Section 5). 

3. Desired Properties of Solutions to TRILL 

   This section describes some of the desirable or required properties 
   of any system that would solve the TRILL problems, independent of the 
   details of such a solution. Most of these are based on retaining 
   useful properties of bridges, or maintaining those properties while 
   solving the problems listed in Section 2. 

3.1. No Change to Link Capabilities 

   There must be no change to the service that Ethernet subnets already 
   provide as a result of deploying a TRILL solution. Ethernet supports 
   unicast, broadcast, and multicast natively. Although network 
   protocols, notably IP, can tolerate link layers that do not provide 
   all three, it would be useful to retain the support already in place 
   [RFC3819]. Zeroconf, as well as existing bridge autoconfiguration, 
   are dependent on broadcast as well. 

   Current Ethernet ensures in-order delivery for frames of the same 
   priority and no duplicated frames, under normal operation (excepting 
Touch & Perlman       Expires September 5, 2009               [Page 10] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   transients during reconfiguration). These criteria apply in varying 
   degrees to the different variants of Ethernet, e.g., basic Ethernet 
   up through basic VLAN (802.1Q) ensures that all frames with the same 
   priority between two link addresses have both properties, but 
   protocol/port VLAN (802.1v) ensures this only for packets with the 
   same protocol and port. There are subtle implications to such a 
   requirement. Bridge autolearning already is susceptible to moving 
   nodes between ports, because previously learned associations between 
   port and link address change. A TRILL solution could be similarly 
   susceptible to such changes. 

3.2. Zero Configuration and Zero Assumption 

   Both bridges and hubs are zero configuration devices; hubs having no 
   configuration at all, and bridges being automatically self-
   configured. Bridges are further zero-assumption devices, unlike hubs. 
   Bridges can be interconnected in arbitrary topologies, without regard 
   for cycles or even self-attachment. Spanning tree protocols (STPs) 
   remove the impact of cycles automatically, and port autolearning 
   reduces unnecessary broadcast of unicast traffic.  

   A TRILL solution should strive to have similar zero configuration, 
   zero assumption operation. This includes having TRILL solution 
   components automatically discover other TRILL solution components and 
   organize themselves, as well as to configure that organization for 
   proper operation (plug-and-play). It also includes zero configuration 
   backward compatibility with existing bridges and hubs, which may 
   include interacting with some of the bridge protocols, such as 
   spanning tree. 

   VLANs add a caveat to zero configuration; a TRILL solution should 
   support automatic use of a default VLAN (like non-VLAN bridges), but 
   would undoubtedly require explicit configuration for VLANs where 
   bridges require such configuration. 

   Autoconfiguration extends to optional services, such as multicast 
   support via IGMP snooping, broadcast support via serial copy, and 
   supporting multiple VLANs.  

3.3. Forwarding Loop Mitigation 

   Spanning tree avoids forwarding loops by construction, although 
   transient loops can occur, e.g., via the temporarily undetected 
   appearance of new link connectivity or the loss of a sufficient 
   number of spanning tree control frames. Solutions to TRILL are 
   intended to use adapted network layer routing protocols which may 
   introduce transient loops during routing convergence. A TRILL 
Touch & Perlman       Expires September 5, 2009               [Page 11] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   solution thus needs to provide support for mitigating the effect of 
   such routing loops. 

   In the Internet, loop mitigation is provided by a decrementing hop 
   counts (TTL); in other networks, packets include a trace (sometimes 
   referred to as 'serialized' or 'unioned') of visited nodes [RFC1812]. 
   In addition, there may be localized consistency checks, such as 
   whether traffic in received on an unexpected interface, which 
   indicates that routing is in flux and such traffic should probably be 
   discarded for safety. These types of mechanisms limit the impact of 
   loops or detect them explicitly. Mechanisms with similar effect 
   should be included in TRILL solutions. 

3.4. Spanning Tree Management 

   In order to address convergence under reconfiguration and robustness 
   to link interruption (Section 2.2), participation in the spanning 
   tree (STP) must be carefully managed. The goal is to provide the 
   desired stability of the TRILL solution and of the entire Ethernet 
   link subnet, which may include bridges using STP. This may involve a 
   TRILL solution participating in the STP, where the protocol used for 
   TRILL might dampen interactions with STP, or it may involve severing 
   the STP into separate STPs on 'stub' external Ethernet link subnet 

   A requirement is that a TRILL solution must not require modifications 
   or exceptions to the existing spanning tree protocols (e.g., STP, 
   RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree 

3.5. Multiple Attachments 

   In STP, a single node with multiple attachments to a single spanning 
   tree segment will always only get and send traffic over one of the 
   those attachment points. TRILL must manage all traffic, including 
   multicast and broadcast traffic, so as not to create traffic loops 
   involving Ethernet segments with multiple TRILL attachment points. 
   This includes multiple attachments to a single TRILL node and 
   attachments to multiple TRILL nodes. Support for multiple attachments 
   can improve support for forms of mobility that induce topology 
   changes, such as "make before break", although this is not a major 
   goal of TRILL. 

3.6. VLAN Issues 

   A TRILL solution should support multiple customer VLANs (802.1Q, 
   which includes 802.1v and 802.1s). This may involve ignorance, just 
Touch & Perlman       Expires September 5, 2009               [Page 12] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   as many bridge devices do not participate in the VLAN protocols. It 
   may alternately furnish direct VLAN support, e.g., by providing 
   configurable support for VLAN ignorant end stations equivalent to 
   that provided by 802.1Q non-provider bridges. 

   Provider VLANs (802.1ad) are outside of the scope of this document. A 
   TRILL solution might or might not be easily adaptable to handling 
   provider VLANs. 

3.7. Operational Equivalence 

   As with any extension to an existing architecture, it would be useful 
   - though not strictly necessary - to be able to describe or consider 
   a TRILL solution as equivalent to an existing link layer component. 
   Such equivalence provides a validation model for the architecture and 
   a way for users to predict the effect of the use of a TRILL solution 
   on a deployed Ethernet. In this case, 'user' refers to users of the 
   Ethernet protocol, whether at the host (data segments), bridge (ST 
   control segments), or VLAN (VLAN control). 

   This provides a sanity check, i.e., "we got it right if we can 
   exchange a TRILL solution component or components with an X" (where 
   "X" might be a single bridge, a hub, or some other link layer 
   abstraction). It does not matter whether "X" can be implemented on 
   the same scale as the corresponding TRILL solution. It also does not 
   matter if it can - there may be utility to deploying the TRILL 
   solution components incrementally, in ways that a single "X" could 
   not be installed. 

   For example, if a TRILL solution's components were equivalent to a 
   single IEEE 802.1D bridge, it would mean that they would - as a whole 
   - participate in the STP. This need not require that TRILL solution 
   components would propagate STP, any more than a bridge need do so in 
   its on-board control. It would mean that the solution would interact 
   with BPDUs at the edge, where the solution would - again, as a whole 
   - participate as if a single node in the spanning tree. Note that 
   this equivalence is not required; a solution may act as if an IEEE 
   802.1 hub, or may not have a corresponding equivalent link layer 
   component at all. 

3.8. Optimizations 

   There are a number of optimizations that may be applied to TRILL 
   solutions. These must be applied in a way that does not affect 
   functionality as a tradeoff for increased performance. Such 
   optimizations may address broadcast and multicast frame distribution, 
   VLAN support, and snooping of ARP and IPv6 neighbor discovery. 
Touch & Perlman       Expires September 5, 2009               [Page 13] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   In addition, there may be optimizations which make the implementation 
   of a TRILL solution easier than roughly equivalent existing bridge 
   devices. For example, in many bridged LANs, there are topologies such 
   that central ("core") bridges which have both a greater volume of 
   traffic flowing through them as well as traffic to and from a larger 
   variety of end station than do non-core bridges. Thus means that such 
   core bridges need to learn a large number of end station addresses 
   and need to do lookups based on such addresses very rapidly. This 
   might require large high speed content addressable memory making 
   implementation of such core bridges difficult. Although a TRILL 
   solution need not provide such optimizations, it may reduce the need 
   for such large, high speed content addressable memories or provide 
   other similar optimizations. 

3.9. Internet Architecture Issues 

   TRILL solutions are intended to have no impact on the Internet 
   network layer architecture. In particular, the Internet and higher 
   layer headers should remain intact when traversing a deployed TRILL 
   solution, just as they do when traversing any other link subnet 
   technologies. This means that the IP TTL field cannot be co-opted for 
   forwarding loop mitigation, as it would interfere with the Internet 
   layer assuming that the link subnet was reachable with no changes in 
   TTL (Internet TTLs are changed only at routers, as per RFC 1812, and 
   even if IP TTL were considered, TRILL is expected to support non-IP 
   payloads, and so requires a separate solution anyway) [RFC1812]. 

   TRILL solutions should also have no impact on Internet routing or 
   signaling, which also means that broadcast and multicast, both of 
   which can pervade an entire Ethernet link subnet, must be able to 
   transparently pervade a deployed TRILL solution. Changing how either 
   of these capabilities behaves would have significant effects on a 
   variety of protocols, including RIP (broadcast), RIPv2 (multicast), 
   ARP (broadcast), IPv6 neighbor discovery (multicast), etc. 

   Note that snooping of network layer packets may be useful, especially 
   for certain optimizations. These include snooping multicast control 
   plane packets (IGMP) to tune link multicast to match the network 
   multicast topology, as is already done in existing smart switches 
   [RFC3376][RFC4286]. This also includes snooping IPv6 neighbor 
   discovery messages to assist with governing TRILL solution edge 
   configuration, as is the case in some smart learning bridges 
   [RFC4861]. Other layers may similarly be snooped, notably ARP 
   packets, for similar reasons for IPv4 [RFC826]. 

Touch & Perlman       Expires September 5, 2009               [Page 14] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

4. Applicability 

   As might be expected, TRILL solutions are intended to be used to 
   solve the problems described in Section 2. However, not all such 
   installations are appropriate environments for such solutions. This 
   section outlines the issues in the appropriate use of these 

   TRILL solutions are intended to address problems of path efficiency 
   and concentration, inability to multipath, and path stability within 
   a single Ethernet link subnet. Like bridges, individual TRILL 
   solution components may find other TRILL solution components within a 
   single Ethernet link subnet and aggregate into a single TRILL 

   TRILL solutions are not intended to span separate Ethernet link 
   subnets interconnected by network layer (e.g., router) devices, 
   except via link layer tunnels, where such tunnels render the distinct 
   subnet undetectably equivalent from a single Ethernet link subnet. 

   A currently open question is whether a single Ethernet link subnet 
   should contain components of only one TRILL solution, either of 
   necessity of architecture or utility. Multiple TRILL solutions, like 
   Internet ASes, may allow TRILL routing protocols to be partitioned in 
   ways that help their stability, but this may come at the price of 
   needing the TRILL solutions to participate more fully as nodes (each 
   modeling a bridge) in the Ethernet link subnet STP. Each architecture 
   solution should decide whether multiple TRILL solutions are supported 
   within a single Ethernet link subnet and mechanisms should be 
   included to enforce whatever decision is made. 

   TRILL solutions need not address scalability limitations in bridged 
   subnets. Although there may be scale benefits of other aspects of 
   solving TRILL problems, e.g., of using network layer routing to 
   provide stability under link changes or intermittent outages, this is 
   not a focus of this work. 

   As also noted earlier, TRILL solutions are not intended to address 
   security vulnerabilities in either the data plane or control plane of 
   the link layer. This means that TRILL solutions should not limit 
   broadcast frames, ARP requests, or spanning tree protocol messages 
   (if such are interpreted by the TRILL solution or solution edge). 

5. Security Considerations 

   TRILL solutions should not introduce new vulnerabilities compared to 
   traditional bridged subnets.  
Touch & Perlman       Expires September 5, 2009               [Page 15] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   TRILL solutions are not intended to be a solution to Ethernet link 
   subnet vulnerabilities, including spoofing, flooding, snooping, and 
   attacks on the link control plane (STP, flooding the learning cache) 
   and link-network control plane (ARP). Although TRILL solutions are 
   intended to provide more stable routing than STP, this stability is 
   limited to performance, and the subsequent robustness is intended to 
   address non-malicious events. 

   There may be some side-effects to the use of TRILL solutions that can 
   provide more robust operation under certain attacks, such as those 
   interrupting or adding link service, but TRILL solutions should not 
   be relied upon for such capabilities. 

   Finally, TRILL solutions should not interfere with other protocols 
   intended to address these vulnerabilities, such as those to secure 
   IPv6 neighbor discovery [RFC3971].  

6. IANA Considerations 

   This document requires no IANA actions.  

   This section should be removed by the RFC Editor prior to final 

7. Acknowledgments 

   Portions of this document are based on documents that describe a 
   preliminary solution, and on a related network layer solution 
   [Pe04][Pe05][To03]. Donald Eastlake III provided substantial text and 
   comments. Additional comments and feedback were provided by the 
   members of the IETF TRILL WG, in which this document was developed, 
   and by the IESG. 

   This document was prepared using 

8. References 

8.1. Normative References 


8.2. Informative References 

   [IEEE04] IEEE 802.1D bridging standard, "IEEE Standard for Local and 
             metropolitan area networks: Media Access Control (MAC) 
             Bridges", (incorporates 802.1w), Jun. 2004. 

Touch & Perlman       Expires September 5, 2009               [Page 16] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   [IEEE06] IEEE 802.1Q VLAN standard, "IEEE Standards for Local and 
             metropolitan area networks: Virtual Bridged Local Area 
             Networks", (incorporates 802.1v and 802.1s), May 2006. 

   [Me04]    Myers, A., T.E. Ng, H. Zhang, "Rethinking the Service 
             Model: Scaling Ethernet to a Million Nodes", Proc. ACM 
             Third Workshop on Hot Topics in Networks (HotNets-III), 
             Mar. 2004. 

   [Pe99]    Perlman, R., "Interconnection: Bridges, Routers, Switches, 
             and Internetworking Protocols", Addison Wesley, Chapter 3, 

   [Pe04]    Perlman, R., "RBridges: Transparent Routing", Proc. Infocom 
             2005, Mar. 2004. 

   [Pe05]    Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent 
             Routing," (expired work in progress), Apr. 2004 - May 2005. 

   [RFC826]  Plummer, D., "Ethernet Address Resolution Protocol: Or 
             converting network protocol addresses to 48.bit Ethernet 
             address for transmission on Ethernet hardware", RFC-826 / 
             STD-37 (Standard), Nov. 1982. 

   [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 
             RFC-1812 (Proposed Standard), Jun. 1995. 

   [RFC3819] Karn, P., (ed.), C. Bormann, G. Fairhurst, D. Grossman, R. 
             Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood, 
             "Advice for Internet Subnetwork Designers", RFC-3819 / BCP 
             89 (Best Current Practice), Jul. 2004. 

   [RFC3376]  Cain, B., S. Deering, I. Kouvelas, B. Fenner, A. 
             Thyagarajan, "Internet Group Management Protocol, Version 
             3", RFC-3376 (Proposed Standard), Oct. 2002. 

   [RFC3971] Arkko, J., J. Kempf, B. Sommerfield, B. Zill, P. Nikander, 
             "Secure Neighbor Discovery (SeND)", RFC-3971 (Proposed 
             Standard), Mar. 2005. 

   [RFC4286] Haberman, B., J. Martin, "Multicast Router Discovery", 
             RFC-4286 (Proposed Standard), Dec. 2005. 

   [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 
             "Considerations for Internet Group Management Protocol 
             (IGMP) and Multicast Listener Discovery (MLD) Snooping 
             Switches", RFC-4541, May 2006. 
Touch & Perlman       Expires September 5, 2009               [Page 17] 

Internet-Draft     TRILL: Problem and Applicability          March 2009 

   [RFC4861] Narten, T., E. Nordmark, W. Simpson, H. Soliman, "Neighbor 
             Discovery for IP version 6 (IPv6)", RFC-4861 (Draft 
             Standard), Sep. 2007. 

   [To03]    Touch, J., Y. Wang, L. Eggert, G. Finn, "A Virtual Internet 
             Architecture", ISI Technical Report ISI-TR-570, Presented 
             at the Workshop on Future Directions in Network 
             Architecture (FDNA) 2003 at Sigcomm 2003, March 2003. 

Author's Addresses 

   Joe Touch 
   4676 Admiralty Way 
   Marina del Rey, CA 90292-6695 
   Phone: +1 (310) 448-9151 
   Radia Perlman 
   Sun Microsystems  
   16 Network Circle  
   Menlo Park, CA 94025  

Touch & Perlman       Expires September 5, 2009               [Page 18]