TRILL WG J. Touch
Internet Draft USC/ISI
Intended status: Informational R. Perlman
Expires: December 2008 Sun
June 16, 2008
Transparent Interconnection of Lots of Links (TRILL):
Problem and Applicability Statement
draft-ietf-trill-prob-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.
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 on December 16, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Current Ethernet (802.1) link layers use custom routing protocols
that have a number of challenges. These routing protocols need to
strictly avoid loops, even temporary loops during route propagation,
Touch & Perlman Expires December 16, 2008 [Page 1]
Internet-Draft TRILL: Problem and Applicability June 2008
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). The
convergence of these routing protocols and stability under link
changes and failures is also of concern. This document addresses
these concerns and suggests that they are related to the need to be
able to apply modern network layer routing protocols at the link
layer. This document assumes that solutions would not address issues
of scalability beyond that of existing bridged (802.1) links, but
that a solution would be backward compatible with 802.1, including
hubs, bridges, and their existing plug-and-play capabilities.
This document is a work in progress; we invite you to participate on
the mailing list at http://www.postel.org/rbridge
Table of Contents
1. Introduction...................................................3
2. The TRILL Problem..............................................3
2.1. Inefficient Paths.........................................4
2.2. Multipath Forwarding......................................6
2.3. Convergence and Safety....................................6
2.4. Stability of IP Multicast Optimization....................7
2.5. Other Ethernet Extensions.................................8
2.6. Problems Not Addressed....................................9
3. Desired Properties of Solutions to TRILL.......................9
3.1. No Change to Link Capabilities...........................10
3.2. Zero Configuration and Zero Assumption...................10
3.3. Forwarding Loop Mitigation...............................11
3.4. Spanning Tree Management.................................11
3.5. Multiple Attachments.....................................11
3.6. VLAN Issues..............................................12
3.7. Operational Equivalence..................................12
3.8. Optimizations............................................12
3.9. Internet Architecture Issues.............................13
4. Applicability.................................................14
5. Security Considerations.......................................14
6. IANA Considerations...........................................15
7. Acknowledgments...............................................15
8. References....................................................15
8.1. Normative References.....................................15
8.2. Informative References...................................15
9. Author's Addresses............................................17
Intellectual Property Statement..................................17
Disclaimer of Validity...........................................18
Touch & Perlman Expires December 16, 2008 [Page 2]
Internet-Draft TRILL: Problem and Applicability June 2008
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. Unfortunately, the
basis of the simplicity of these subnets is the spanning tree, which
although simple and elegant, can have substantial limitations. In
subnets where bridges are also frequently relocated, convergence of
the spanning tree protocol can be slow. Because all traffic flows
over a single tree, all traffic is concentrated on a subset of links,
increasing susceptibility to the effects of link failures and
limiting the bandwidth across the subnet.
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.
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
802.1D, allow network managers to avoid thinking in trees, where the
spanning tree protocol finds a valid tree automatically;
Touch & Perlman Expires December 16, 2008 [Page 3]
Internet-Draft TRILL: Problem and Applicability June 2008
unfortunately, this additional simplicity comes with a number of
associated penalties [13].
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 may be
available. (The addition in 802.1Q of support for multiple spanning
trees helps a little but the number of trees is limited and these
defects apply to each tree.) The spanning tree configuration is
affected by even small topology changes, and small changes can have
large effects. Each of these inefficiencies 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, in effect, 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 which
would cause packet storms if hubs (repeaters) were used instead of
STP-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
Touch & Perlman Expires December 16, 2008 [Page 4]
Internet-Draft TRILL: Problem and Applicability June 2008
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
B1111111H121212E
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.
A
1 C
1 1
1 1
B1111111H111111E
G2222222222F
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
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.
Touch & Perlman Expires December 16, 2008 [Page 5]
Internet-Draft TRILL: Problem and Applicability June 2008
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 link state
routing causes such paths to be cost metric optimal. 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.)
Such multipathing of single destination traffic is not possible with
spanning tree. Spanning tree provides only a single path and the
address learning in spanning tree requires symmetric paths. But such
multipathing is enabled by link state routing, at least for equal
cost paths.
Multipathing would typically result in only a small improvement in
capacity for a network with roughly equal traffic between all pairs
of nodes. It would typically spread the traffic more evenly over the
available physical links. But it can produce dramatic improvement in
a network where the traffic between a small numbers of pairs of nodes
dominates, because such traffic can be spread over multiple paths
which might otherwise be lightly loaded.
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.
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 [5][10]. Consider a ring with
a stub as shown in Figure 4.
Touch & Perlman Expires December 16, 2008 [Page 6]
Internet-Draft TRILL: Problem and Applicability June 2008
A----B----C----D----E
| |
+-----F-----G-------+
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 in both
directions. 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 a new
root can race each other around the ring and, if RSTP is in use,
produce persistent loops lasting for tens of seconds due to BPDU
traffic throttling [5]. The original spanning tree protocol can
impose 45 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.
All variants of spanning tree are inherently unsafe in the
fundamental sense that, by default, ports are enabled for the
forwarding or flooding of data and it requires the receipt of control
messages to disable them. Thus, although this is a very rare
occurrence, if enough control messages are dropped or not processed,
loops can appear. In contrast, with link state routing, forwarding or
flooding is disabled by default and only enabled for a port on
receipt and process of proper routing control messages.
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 [4].
Touch & Perlman Expires December 16, 2008 [Page 7]
Internet-Draft TRILL: Problem and Applicability June 2008
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 send 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.
A solution based on link state routing, however, 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 link topology change.
2.5. Other Ethernet Extensions
There have been a variety of 802.1 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) [7]
o 802.1w - extension for rapid reconvergence of the spanning tree
protocol (RTSP) [7]
o 802.1Q - added VLAN and priority support, where each link address
maps to one VLAN (incorporates 802.1v and 802.1s, below) [8]
o 802.1v - added VLANs where segments map to VLANs based on link
address together with network protocol and transport port [8]
o 802.1s - added support for multiple spanning trees, up to a
maximum of 64, one per group of VLANs (MSTP) [8]
These variants are further complicated by different versions updated
periodically.
It is useful to note that these extensions do not address the issue
of independent, localized routing in a single spanning tree - which
is the focus of TRILL. This document presumes the above variants are
supported on the Ethernet subnet, i.e., that a TRILL solution would
support all of the above.
Touch & Perlman Expires December 16, 2008 [Page 8]
Internet-Draft TRILL: Problem and Applicability June 2008
2.6. Problems Not Addressed
There are other challenges to deploying Ethernet subnets that are not
addressed in this document. 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
o support for "provider" services such as Provider Bridges (802.1ad)
or Provider Backbone Bridges (802.1ah)
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 (STP) 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.
Touch & Perlman Expires December 16, 2008 [Page 9]
Internet-Draft TRILL: Problem and Applicability June 2008
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
[9]. 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
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 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. STP removes 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 STP.
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.
Touch & Perlman Expires December 16, 2008 [Page 10]
Internet-Draft TRILL: Problem and Applicability June 2008
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 appearance of a new link 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. TRILL solutions thus need 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 [2]. 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 (Sections 2.2 and 1.1), participation in the 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 TRILL
solutions participating in the STP, where the protocol is 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, MSTP).
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 feedback loops
on Ethernet segments with multiple TRILL attachment points. This
Touch & Perlman Expires December 16, 2008 [Page 11]
Internet-Draft TRILL: Problem and Applicability June 2008
includes multiple attachments to a single TRILL node and attachments
to multiple TRILL nodes.
3.6. VLAN Issues
A TRILL solution should support multiple VLANs (802.1Q, 802.1V, and
802.1S). This may involve ignorance, just 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.
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 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 were equivalent to a single 802.1D
bridge, it would mean that the TRILL solution would - as a whole -
participate in the STP. This need not require that TRILL solution
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 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
Touch & Perlman Expires December 16, 2008 [Page 12]
Internet-Draft TRILL: Problem and Applicability June 2008
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 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 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) [2].
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 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
[3][6]. 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 [11]. Other layers may similarly
be snooped, notably ARP packets, for similar reasons for IPv4 [15].
Touch & Perlman Expires December 16, 2008 [Page 13]
Internet-Draft TRILL: Problem and Applicability June 2008
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.
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 only one TRILL solution instance, 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 December 16, 2008 [Page 14]
Internet-Draft TRILL: Problem and Applicability June 2008
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 under
development to secure IPv6 neighbor discovery [1].
6. IANA Considerations
This document requires no IANA actions.
This section should be removed by the RFC Editor prior to final
publication.
7. Acknowledgments
Portions of this document are based on documents that describe a
preliminary solution, and on a related network layer solution
[12][14][16]. Donald Eastlake III provided substantial text and
comments.
This document was prepared using 2-Word-v2.0.template.dot.
8. References
8.1. Normative References
None.
8.2. Informative References
[1] Arkko, J., J. Kempf, B. Sommerfield, B. Zill, P. Nikander,
"Secure Neighbor Discovery (SeND)", RFC 3971 (Proposed
Standard), Mar. 2005.
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812
(Proposed Standard), Jun. 1995.
Touch & Perlman Expires December 16, 2008 [Page 15]
Internet-Draft TRILL: Problem and Applicability June 2008
[3] Cain, B., S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan,
"Internet Group Management Protocol, Version 3", RFC 3376
(Proposed Standard), Oct. 2002.
[4] 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.
[5] Elmeleegy, K., A.L. Cox, T.E. Ng, "On Count-to-Infinity Induced
Forwarding Loops in Ethernet Networks", Proc. Infocom 2006,
Apr. 2006.
[6] Haberman, B., J. Martin, "Multicast Router Discovery", RFC 4286
(Proposed Standard), Dec. 2005.
[7] IEEE 802.1D bridging standard, "IEEE Standard for Local and
metropolitan area networks: Media Access Control (MAC)
Bridges", (incorporates 802.1w), Jun. 2004.
[8] 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.
[9] 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.
[10] 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 Nnetworks (HotNets-III), Mar. 2004.
[11] Narten, T., E. Nordmark, W. Simpson, H. Soliman, "Neighbor
Discovery for IP version 6 (IPv6)", RFC 4861 (Draft Standard),
Sep. 2007.
[12] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom
2005, Mar. 2004.
[13] Perlman, R., "Interconnection: Bridges, Routers, Switches, and
Internetworking Protocols", Addison Wesley, Chapter 3, 1999.
[14] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent
Routing," (expired work in progress), Apr. 2004 - May 2005.
Touch & Perlman Expires December 16, 2008 [Page 16]
Internet-Draft TRILL: Problem and Applicability June 2008
[15] 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.
[16] 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.
9. Author's 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
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
Touch & Perlman Expires December 16, 2008 [Page 17]
Internet-Draft TRILL: Problem and Applicability June 2008
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.
Disclaimer of Validity
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 (2008).
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.
Touch & Perlman Expires December 16, 2008 [Page 18]