doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc5556.txt b/doc/rfc/rfc5556.txt
new file mode 100644
index 0000000..5ca296f
--- /dev/null
+++ b/doc/rfc/rfc5556.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group                                           J. Touch
+Request for Comments: 5556                                       USC/ISI
+Category: Informational                                       R. Perlman
+                                                                     Sun
+                                                                May 2009
+
+
+         Transparent Interconnection of Lots of Links (TRILL):
+                  Problem and Applicability Statement
+
+Status of This Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+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 (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+Abstract
+
+   Current IEEE 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 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.
+
+
+
+
+
+
+
+
+
+
+Touch & Perlman              Informational                      [Page 1]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. The TRILL Problem ...............................................3
+      2.1. Inefficient Paths ..........................................3
+      2.2. Multipath Forwarding .......................................5
+      2.3. Convergence and Safety .....................................6
+      2.4. Stability of IP Multicast Optimization .....................6
+      2.5. IEEE 802.1 Bridging Protocols ..............................7
+      2.6. Problems Not Addressed .....................................8
+   3. Desired Properties of Solutions to TRILL ........................9
+      3.1. No Change to Link Capabilities .............................9
+      3.2. Zero Configuration and Zero Assumption ....................10
+      3.3. Forwarding Loop Mitigation ................................10
+      3.4. Spanning Tree Management ..................................11
+      3.5. Multiple Attachments ......................................11
+      3.6. VLAN Issues ...............................................11
+      3.7. Operational Equivalence ...................................12
+      3.8. Optimizations .............................................12
+      3.9. Internet Architecture Issues ..............................13
+   4. Applicability ..................................................13
+   5. Security Considerations ........................................14
+   6. Acknowledgments ................................................15
+   7. Informative References .........................................15
+
+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 supporting automatic configuration.  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.,
+
+
+
+
+Touch & Perlman              Informational                      [Page 2]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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.
+
+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 pairwise along a ring, a
+   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
+
+
+
+Touch & Perlman              Informational                      [Page 3]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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.
+
+                              [A]
+                             // \    [C]
+                            //   \   / \\  [D]
+                           //     \ /   \\ //
+                          [B]=====[H]=====[E]
+                            \     //      ||
+                             \   //       ||
+                              \ //        ||
+                               [G]--------[F]
+
+           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.
+
+                                  [A]
+                                  1           [C]
+                                 1              1
+                                1                1
+                              [B]1111111[H]121212[E]
+                                     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
+
+
+
+Touch & Perlman              Informational                      [Page 4]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   H-F link carries only A-C traffic ('1's) and the G-F traffic ('2's)
+   is more direct.
+
+                                  [A]
+                                  1           [C]
+                                 1              1
+                                1                1
+                              [B]1111111[H]111111[E]
+
+
+
+                                  [G]2222222[F]
+
+       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.  Using spanning trees 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
+   endpoint to another to be sent over multiple, typically equal-cost,
+   paths.  (Traffic sent over different paths will generally encounter
+   different delays and may be reordered with respect to traffic on
+   another path.  Thus, traffic must be divided into flows, such that
+   reordering of traffic between flows is not significant, and those
+   flows are 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
+   number 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              Informational                      [Page 5]
+
+RFC 5556            TRILL: Problem and Applicability            May 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 STP.
+
+   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.
+
+                   [R]----[A]----[B]----[C]----[D]----[E]
+                           |                           |
+                           +--------[F]-----[G]--------+
+
+         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
+   in order 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              Informational                      [Page 6]
+
+RFC 5556            TRILL: Problem and Applicability            May 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 relearn the correct multicast forwarding from
+   the receipt of multicast control messages on new ports.  Such control
+   messages are sent to establish multicast distribution state and then
+   to refresh it, sometimes at intervals of seconds.  If a bridging
+   topology change has occurred during such intervals, 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.  IEEE 802.1 Bridging Protocols
+
+   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
+      [IEEE06].
+
+   o  802.1s - added support for multiple spanning trees, up to a
+      maximum of 65, one per non-overlapping group of VLANs (Multiple
+      STP) [IEEE06].
+
+   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
+   Ethernet services.  The TRILL problem as described in this document
+
+
+
+Touch & Perlman              Informational                      [Page 7]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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 renamed 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  security of the Ethernet link subnet management protocol
+
+   o  flooding attacks on a Ethernet link subnet
+
+   o  support for "provider" services such as Provider Bridges
+      (802.1ad), Provider Backbone Bridges (802.1ah), or Provider
+      Backbone Bridge Traffic Engineering (802.1Qay)
+
+
+
+Touch & Perlman              Informational                      [Page 8]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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 Address Resolution Protocol (ARP),
+   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-layer 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].  So called "zero configuration protocols" (also known as
+   "zeroconf", e.g., as used to configure link-local addresses
+   [RFC3927]), as well as existing bridge autoconfiguration, are also
+   dependent on broadcast.
+
+   Current Ethernet ensures in-order delivery for frames of the same
+   priority and no duplicated frames, under normal operation (excepting
+   transients during reconfiguration).  These criteria apply in varying
+   degrees to the different types of Ethernet, e.g., basic Ethernet up
+   through basic VLAN (802.1Q) ensures that all frames with the same
+
+
+
+Touch & Perlman              Informational                      [Page 9]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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
+   the 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 a 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 Internet Group Management Protocol (IGMP) snooping,
+   broadcast support via serial copy, and support of multiple VLANs.
+
+3.3.  Forwarding Loop Mitigation
+
+   Using spanning trees 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
+   that may introduce transient loops during routing convergence.  A
+   TRILL solution thus needs to provide support for mitigating the
+   effect of such routing loops.
+
+
+
+
+
+Touch & Perlman              Informational                     [Page 10]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   In the Internet, loop mitigation is provided by decrementing hop
+   counts (Time To Live (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 is received on an unexpected
+   interface, which indicates that routing is in flux and that 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
+   segments.
+
+   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
+   Protocol)).
+
+3.5.  Multiple Attachments
+
+   In STP, a single node with multiple attachments to a single spanning
+   tree segment will always get and send traffic over only 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
+   as many bridge devices do not participate in the VLAN protocols.  A
+   TRILL solution 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.
+
+
+
+Touch & Perlman              Informational                     [Page 11]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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.
+
+   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
+
+
+
+Touch & Perlman              Informational                     [Page 12]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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 as for IPv4 [RFC826].
+
+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
+   solutions.
+
+
+
+Touch & Perlman              Informational                     [Page 13]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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
+   solution.
+
+   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.
+
+   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.
+
+
+
+
+Touch & Perlman              Informational                     [Page 14]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   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.  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 2-Word-v2.0.template.dot.
+
+7.  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.
+
+   [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,
+             1999.
+
+   [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.
+
+
+
+
+
+
+
+Touch & Perlman              Informational                     [Page 15]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+   [RFC826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
+             Converting Network Protocol Addresses to 48.bit Ethernet
+             Address for Transmission on Ethernet Hardware", STD 37, RFC
+             826, November 1982.
+
+   [RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers",
+             RFC 1812, June 1995.
+
+   [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
+             Thyagarajan, "Internet Group Management Protocol, Version
+             3", RFC 3376, October 2002.
+
+   [RFC3819] Karn, P., Ed., Bormann, C., Fairhurst, G., Grossman, D.,
+             Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
+             Wood, "Advice for Internet Subnetwork Designers", BCP 89,
+             RFC 3819, July 2004.
+
+   [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+             Configuration of IPv4 Link-Local Addresses", RFC 3927, May
+             2005.
+
+   [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+             "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+   [RFC4286] Rosenberg, J., "Extensible Markup Language (XML) Formats
+             for Representing Resource Lists", RFC 4826, May 2007.
+
+   [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.
+
+   [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+             "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+             September 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.
+
+
+
+
+
+
+
+
+
+
+
+Touch & Perlman              Informational                     [Page 16]
+
+RFC 5556            TRILL: Problem and Applicability            May 2009
+
+
+Authors' Addresses
+
+   Joe Touch
+   USC/ISI
+   4676 Admiralty Way
+   Marina del Rey, CA 90292-6695
+   U.S.A.
+
+   Phone: +1 (310) 448-9151
+   EMail: touch@isi.edu
+   URL:   http://www.isi.edu/touch
+
+
+   Radia Perlman
+   Sun Microsystems
+   16 Network Circle
+   umpk16-161
+   Menlo Park, CA 94025
+   U.S.A.
+
+   EMail: Radia.Perlman@sun.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Touch & Perlman              Informational                     [Page 17]
+