< draft-ietf-trill-prob-05.txt   draft-ietf-trill-prob-06.txt >
TRILL WG J. Touch TRILL WG J. Touch
Internet Draft USC/ISI Internet Draft USC/ISI
Intended status: Informational R. Perlman Intended status: Informational R. Perlman
Expires: March 2009 Sun Expires: September 2009 Sun
September 29, 2008 March 5, 2009
Transparent Interconnection of Lots of Links (TRILL): Transparent Interconnection of Lots of Links (TRILL):
Problem and Applicability Statement Problem and Applicability Statement
draft-ietf-trill-prob-05.txt draft-ietf-trill-prob-06.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that This Internet-Draft is submitted to IETF in full conformance with the
any applicable patent or other IPR claims of which he or she is provisions of BCP 78 and BCP 79.
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 This document may contain material from IETF Documents or IETF
BCP 79. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on March 29, 2009. This Internet-Draft will expire on September 5, 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 (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
Current Ethernet (802.1) link layers use spanning tree protocols that Current IEE 802.1 LANs use spanning tree protocols that have a number
have a number of challenges. These protocols need to strictly avoid of challenges. These protocols need to strictly avoid loops, even
loops, even temporary ones, during route propagation, because of the temporary ones, during route propagation, because of the lack of
lack of header loop detection support. Routing tends not to take full header loop detection support. Routing tends not to take full
advantage of alternate paths, or even non-overlapping pairwise paths advantage of alternate paths, or even non-overlapping pairwise paths
(in the case of spanning trees). This document addresses these (in the case of spanning trees). This document addresses these
concerns and suggests that they can be addressed by applying modern concerns and suggests that they can be addressed by applying modern
network layer routing protocols at the link layer. This document network layer routing protocols at the link layer. This document
assumes that solutions would not address issues of scalability beyond assumes that solutions would not address issues of scalability beyond
that of existing bridged (802.1) links, but that a solution would be that of existing IEEE 802.1 bridged links, but that a solution would
backward compatible with 802.1, including hubs, bridges, and their be backward compatible with 802.1, including hubs, bridges, and their
existing plug-and-play capabilities. existing plug-and-play capabilities.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................3
2. The TRILL Problem..............................................3 2. The TRILL Problem..............................................4
2.1. Inefficient Paths.........................................4 2.1. Inefficient Paths.........................................4
2.2. Multipath Forwarding......................................5 2.2. Multipath Forwarding......................................6
2.3. Convergence and Safety....................................6 2.3. Convergence and Safety....................................7
2.4. Stability of IP Multicast Optimization....................7 2.4. Stability of IP Multicast Optimization....................7
2.5. Other Ethernet Protocol Extensions........................7 2.5. Other Ethernet Protocol Extensions........................8
2.6. Problems Not Addressed....................................8 2.6. Problems Not Addressed....................................9
3. Desired Properties of Solutions to TRILL.......................9 3. Desired Properties of Solutions to TRILL......................10
3.1. No Change to Link Capabilities............................9 3.1. No Change to Link Capabilities...........................10
3.2. Zero Configuration and Zero Assumption....................9 3.2. Zero Configuration and Zero Assumption...................11
3.3. Forwarding Loop Mitigation...............................10 3.3. Forwarding Loop Mitigation...............................11
3.4. Spanning Tree Management.................................10 3.4. Spanning Tree Management.................................12
3.5. Multiple Attachments.....................................11 3.5. Multiple Attachments.....................................12
3.6. VLAN Issues..............................................11 3.6. VLAN Issues..............................................12
3.7. Operational Equivalence..................................11 3.7. Operational Equivalence..................................13
3.8. Optimizations............................................12 3.8. Optimizations............................................13
3.9. Internet Architecture Issues.............................12 3.9. Internet Architecture Issues.............................14
4. Applicability.................................................13
5. Security Considerations.......................................14 4. Applicability.................................................15
6. IANA Considerations...........................................14 5. Security Considerations.......................................15
7. Acknowledgments...............................................14 6. IANA Considerations...........................................16
8. References....................................................15 7. Acknowledgments...............................................16
8.1. Normative References.....................................15 8. References....................................................16
8.2. Informative References...................................15 8.1. Normative References.....................................16
8.2. Informative References...................................16
1. Introduction 1. Introduction
Conventional Ethernet networks - known in the Internet as Ethernet Conventional Ethernet networks - known in the Internet as Ethernet
link subnets - have a number of attractive features, allowing hosts link subnets - have a number of attractive features, allowing hosts
and routers to relocate within the subnet without requiring and routers to relocate within the subnet without requiring
renumbering and are automatically configuring. The basis of the renumbering and are automatically configuring. The basis of the
simplicity of these subnets is the spanning tree, which although simplicity of these subnets is the spanning tree, which although
simple and elegant, can have substantial limitations. With spanning simple and elegant, can have substantial limitations. With spanning
trees, the bandwidth across the subnet is limited because traffic trees, the bandwidth across the subnet is limited because traffic
flows over a subset of links forming a single tree - or, with the flows over a subset of links forming a single tree - or, with the
latest version of the protocol and significant additional latest version of the protocol and significant additional
configuration, over a small number of superimposed trees. The oldest configuration, over a small number of superimposed trees. The oldest
version of the spanning tree protocol can converge slowly when version of the spanning tree protocol can converge slowly when there
bridges are frequently relocated. are frequent topology changes.
The alternative to an Ethernet link subnet is often a network subnet. The alternative to an Ethernet link subnet is often a network subnet.
Network subnets can use link-state routing protocols that allow Network subnets can use link-state routing protocols that allow
traffic to traverse least-cost paths rather than being aggregated on traffic to traverse least-cost paths rather than being aggregated on
a spanning tree backbone, providing higher aggregate capacity and a spanning tree backbone, providing higher aggregate capacity and
more resistance to link failures. Unfortunately, IP - the dominant more resistance to link failures. Unfortunately, IP - the dominant
network layer technology - requires that hosts be renumbered when network layer technology - requires that hosts be renumbered when
relocated in different network subnets, interrupting network (e.g., relocated in different network subnets, interrupting network (e.g.,
tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are tunnels, IPsec) and transport (e.g., TCP, UDP) associations that are
in progress during the transition. in progress during the transition.
skipping to change at page 3, line 36 skipping to change at page 4, line 12
Links" or "TRILL". The remainder of this document makes minimal Links" or "TRILL". The remainder of this document makes minimal
assumptions about a solution to TRILL. assumptions about a solution to TRILL.
2. The TRILL Problem 2. The TRILL Problem
Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted Ethernet subnets have evolved from 'thicknet' to 'thinnet' to twisted
pair with hubs to twisted pair with switches, becoming increasingly pair with hubs to twisted pair with switches, becoming increasingly
simple to wire and manage. Each level has corresponding topology simple to wire and manage. Each level has corresponding topology
restrictions; thicknet is inherently linear, whereas thinnet and hub- restrictions; thicknet is inherently linear, whereas thinnet and hub-
connected twisted pair have to be wired as a tree. Switches, added in 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 IEEE 802.1D, allow network managers to avoid thinking in trees, where
spanning tree protocol finds a valid tree automatically; the spanning tree protocol finds a valid tree automatically;
unfortunately, this additional simplicity comes with a number of unfortunately, this additional simplicity comes with a number of
associated penalties [12]. associated penalties [Pe99].
The spanning tree often results in inefficient use of the link The spanning tree often results in inefficient use of the link
topology; traffic is concentrated on the spanning tree path, and all topology; traffic is concentrated on the spanning tree path, and all
traffic follows that path even when other more direct paths are traffic follows that path even when other more direct paths are
available. The addition in 802.1Q of support for multiple spanning available. The addition in IEEE 802.1Q of support for multiple
trees helps a little, but the use of multiple spanning trees requires spanning trees helps a little, but the use of multiple spanning trees
additional configuration, the number of trees is limited, and these requires additional configuration, the number of trees is limited,
defects apply within each tree regardless. The spanning tree protocol and these defects apply within each tree regardless. The spanning
reacts to certain small topology changes with large effects on the tree protocol reacts to certain small topology changes with large
reconfiguration of links in use. Each of these aspects of the effects on the reconfiguration of links in use. Each of these aspects
spanning tree protocol can cause problems for current link layer of the spanning tree protocol can cause problems for current link
deployments. layer deployments.
2.1. Inefficient Paths 2.1. Inefficient Paths
The Spanning Tree Protocol (STP) helps break cycles in a set of The Spanning Tree Protocol (STP) helps break cycles in a set of
interconnected bridges, but it also can limit the bandwidth among interconnected bridges, but it also can limit the bandwidth among
that set and cause traffic to take circuitous paths. For example, in 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, a set of N nodes that are interconnected pair-wise along a ring,
spanning tree will, in effect, disable one physical link so that spanning tree will disable one physical link so that connectivity is
connectivity is loop free. This will cause traffic between the pair loop free. This will cause traffic between the pair of nodes
of nodes connected by that disabled link to have to go N-1 physical connected by that disabled link to have to go N-1 physical hops
hops around the entire remainder of the ring rather than take the around the entire remainder of the ring rather than take the most
most efficient single hop path. Using modern routing protocols with efficient single hop path. Using modern routing protocols with such a
such a topology, no traffic should have to go more than N/2 hops. topology, no traffic should have to go more than N/2 hops.
For another example, consider the network shown in Figure 1, which For another example, consider the network shown in Figure 1, which
shows a number of bridges and their interconnecting links. End hosts shows a number of bridges and their interconnecting links. End hosts
and routers are not shown; they would connect to the bridges that are 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 shown, labeled A-H. Note that the network shown has cycles that would
cause packet storms if hubs (repeaters) were used instead of cause packet storms if hubs (repeaters) were used instead of
spanning-tree-capable bridges. One possible spanning tree is shown by spanning-tree-capable bridges. One possible spanning tree is shown by
double lines. double lines.
A A
skipping to change at page 5, line 45 skipping to change at page 6, line 27
practically be integrated into the spanning tree system such as practically be integrated into the spanning tree system such as
multipath routing discussed in Section 2.2 below. Layer 3 routing multipath routing discussed in Section 2.2 below. Layer 3 routing
typically optimizes paths between pairs of endpoints based on a cost typically optimizes paths between pairs of endpoints based on a cost
metric, conventionally based on bandwidth, hop count, latency, and/or metric, conventionally based on bandwidth, hop count, latency, and/or
policy measures. policy measures.
2.2. Multipath Forwarding 2.2. Multipath Forwarding
The discussion above assumes that all traffic flowing from one point The discussion above assumes that all traffic flowing from one point
to another follows a single path. Spanning tree reduces aggregate to another follows a single path. Spanning tree reduces aggregate
bandwidth by forcing all such paths onto one tree, while link state bandwidth by forcing all such paths onto one tree, while modern
routing causes such paths to be cost metric optimal. However, routing causes such paths to be selected based on a cost metric.
extensions to modern routing protocols enable even greater aggregate However, extensions to modern routing protocols enable even greater
bandwidth by permitting traffic flowing from one end point to another aggregate bandwidth by permitting traffic flowing from one end point
to be sent over multiple, typically equal cost, paths. (Traffic sent to another to be sent over multiple, typically equal cost, paths.
over different paths will generally encounter different delays and (Traffic sent over different paths will generally encounter different
may be re-ordered with respect to traffic on another path. Thus delays and may be re-ordered with respect to traffic on another path.
traffic must be divided into flows, such that re-ordering of traffic Thus traffic must be divided into flows, such that re-ordering of
between flows is not significant, and those flows allocated to traffic between flows is not significant, and those flows allocated
paths.) to paths.)
Multipathing typically spreads the traffic more evenly over the Multipathing typically spreads the traffic more evenly over the
available physical links. The addition of multipathing to a link- available physical links. The addition of multipathing to a routed
state routed network would typically result in only a small network would typically result in only a small improvement in
improvement in capacity for a network with roughly equal traffic capacity for a network with roughly equal traffic between all pairs
between all pairs of nodes, because in that situation traffic is of nodes, because in that situation traffic is already fairly well
already fairly well dispersed. Conversely, multipathing can produce a dispersed. Conversely, multipathing can produce a dramatic
dramatic improvement in a link-state routed network where the traffic improvement in a routed network where the traffic between a small
between a small numbers of pairs of nodes dominates, because such numbers of pairs of nodes dominates, because such traffic can - under
traffic can - under the right circumstances - be spread over multiple the right circumstances - be spread over multiple paths that might
paths that might otherwise be lightly loaded. otherwise be lightly loaded.
2.3. Convergence and Safety 2.3. Convergence and Safety
The spanning tree is dependent on the way a set of bridges are The spanning tree is dependent on the way a set of bridges are
interconnected, i.e., the link layer topology. Small changes in this interconnected, i.e., the link layer topology. Small changes in this
topology can cause large changes in the spanning tree. Changes in the topology can cause large changes in the spanning tree. Changes in the
spanning tree can take time to propagate and converge, especially for spanning tree can take time to propagate and converge, especially for
non-RSTP protocols. older versions of the STP protocol.
One possible case occurs when one of the branches connected to the One possible case occurs when one of the branches connected to the
root bridge fails, causing a large number of ports to block and root bridge fails, causing a large number of ports to block and
unblock before the network reconverges [9]. Consider a ring with a unblock before the network reconverges [Me04]. Consider a ring with a
stub as shown in Figure 4. stub as shown in Figure 4.
R----A----B----C----D----E R----A----B----C----D----E
| | | |
+-----F-----G-------+ +-----F-----G-------+
Figure 4 Ring with poor convergence under reconfiguration 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 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 the two open paths, while the D->E link is blocked. If the A->B link
directions. If the A->B link fails, then E must unblock its port to D fails, then E must unblock its port to D for traffic to flow again,
for traffic to flow again, but it may require recomputation of the but it may require recomputation of the entire tree through BPDUs
entire tree through BPDUs (Bridge PDUs). Even worse, if R is root and (Bridge PDUs). Even worse, if R is root and R or the A-R connection
R or the A-R connection fails, BPDU updates related to the old and fails, BPDU updates related to the old and new root can lead to a
new root can lead to a brief count-to-infinity event, and, if RSTP is brief count-to-infinity event, and, if RSTP (Rapid Spanning Tree
in use, can delay convergence for a few seconds. The original 802.1 Protocol) is in use, can delay convergence for a few seconds. The
spanning tree protocol can impose 30-second delays in re-establishing original IEEE 802.1 spanning tree protocol can impose 30-second
data connectivity after a topology change to be sure a new topology delays in re-establishing data connectivity after a topology change
has stabilized and been fully propagated. to be sure a new topology has stabilized and been fully propagated.
The spanning tree protocol is inherently global to an entire layer 2 The spanning tree protocol is inherently global to an entire layer 2
subnet; there is no current way to contain, partition, or otherwise subnet; there is no current way to contain, partition, or otherwise
factor the protocol into a number of smaller, more stable subsets factor the protocol into a number of smaller, more stable subsets
that interact as groups. Contrast this with Internet routing, which that interact as groups. Contrast this with Internet routing, which
includes both intradomain and interdomain variants, split to provide includes both intradomain and interdomain variants, split to provide
exactly that containment and scalability within a domain while exactly that containment and scalability within a domain while
allowing domains to interact freely independent of what happens allowing domains to interact freely independent of what happens
within a domain. within a domain.
2.4. Stability of IP Multicast Optimization 2.4. Stability of IP Multicast Optimization
Although it is a layer violation, it is common for high end bridges Although it is a layer violation, it is common for high end bridges
to snoop on IP multicast control messages for the purpose of to snoop on IP multicast control messages for the purpose of
optimizing the distribution of IP multicast data and of those control optimizing the distribution of IP multicast data and of those control
messages [4]. messages [RFC4541].
When such snooping and optimization is performed by spanning tree- When such snooping and optimization is performed by spanning tree-
based bridges, it done at each bridge based on the traffic observed based bridges, it done at each bridge based on the traffic observed
on that bridge's ports. Changes in topology may reverse or otherwise on that bridge's ports. Changes in topology may reverse or otherwise
change the required forwarding ports of messages for a multicast change the required forwarding ports of messages for a multicast
group. Bridges must re-learn the correct multicast forwarding from group. Bridges must re-learn the correct multicast forwarding from
the receipt of multicast control messages on new ports. Such control the receipt of multicast control messages on new ports. Such control
messages, after their initial issuance to establish multicast messages, after their initial issuance to establish multicast
distribution state, are sent only to refresh such state, sometimes at distribution state, are sent only to refresh such state, sometimes at
intervals of seconds, during which, if a bridging topology change has intervals of seconds, during which, if a bridging topology change has
occurred, multicast data may be misdirected and lost. occurred, multicast data may be misdirected and lost.
A solution based on link state routing, however, can form and However, a solution based on link state routing, for example, can
maintain a global view of the multicast group membership and form and maintain a global view of the multicast group membership and
multicast router situation in a similar fashion to that in which it 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 maintains a global view of the status of links. Thus such a solution
can adjust the forwarding of multicast data and control traffic can adjust the forwarding of multicast data and control traffic
immediately as it sees the link topology change. immediately as it sees the LAN topology change.
2.5. Other Ethernet Protocol Extensions 2.5. Other Ethernet Protocol Extensions
There have been a variety of 802.1 protocols beyond the initial There have been a variety of IEEE protocols beyond the initial
shared-media Ethernet variant, including: shared-media Ethernet variant, including:
o 802.1D - added bridges (i.e., switches) and a spanning tree o 802.1D - added bridges (i.e., switches) and a spanning tree
protocol (STP) (incorporates 802.1w, below) [6] protocol (STP) (incorporates 802.1w, below) [IEEE04].
o 802.1w - extension for rapid reconvergence of the spanning tree o 802.1w - extension for rapid reconvergence of the spanning tree
protocol (RTSP) [6] protocol (RTSP) [IEEE04].
o 802.1Q - added VLAN and priority support, where each link address o 802.1Q - added VLAN and priority support, where each link address
maps to one VLAN (incorporates 802.1v and 802.1s, below) [7] 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 o 802.1v - added VLANs where segments map to VLANs based on link
address together with network protocol and transport port [7] address together with network protocol and transport port
[IEEE06].
o 802.1s - added support for multiple spanning trees, up to a o 802.1s - added support for multiple spanning trees, up to a
maximum of 65, one per non-overlapping group of VLANs (MSTP) [7] maximum of 65, one per non-overlapping group of VLANs (MSTP)
[IEEE06].
It is useful to note that these extensions do not address the issue This document presumes the above variants are supported on the
of independent, localized routing in a single spanning tree - which Ethernet subnet, i.e., that a TRILL solution would not interfere with
is the focus of TRILL. This document presumes the above variants are (i.e., would not affect) any of the above.
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 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 2.6. Problems Not Addressed
There are other challenges to deploying Ethernet subnets that are not There are other challenges to deploying Ethernet subnets that are not
addressed in this document. These include: 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 Ethernet link subnet scale
o increased node relocation o increased node relocation
o Ethernet link subnet management protocol security o Ethernet link subnet management protocol security
o flooding attacks on a Ethernet link subnet o flooding attacks on a Ethernet link subnet
o support for "provider" services such as Provider Bridges
o support for "provider" services such as Provider Bridges (802.1ad) (802.1ad), Provider Backbone Bridges (802.1ah), or Provider
or Provider Backbone Bridges (802.1ah) Backbone Bridge Traffic Engineering (802.1Qay)
Solutions to TRILL need not support deployment of larger scales of Solutions to TRILL need not support deployment of larger scales of
Ethernet link subnets than current broadcast domains can support Ethernet link subnets than current broadcast domains can support
(e.g., around 1,000 end-hosts in a single bridged LAN of 100 bridges, (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). or 100,000 end-hosts inside 1,000 VLANs served by 10,000 bridges).
Similarly, solutions to TRILL need not address link layer node Similarly, solutions to TRILL need not address link layer node
migration, which can complicate the caches in learning bridges. migration, which can complicate the caches in learning bridges.
Similar challenges exist in the ARP protocol, where link layer Similar challenges exist in the ARP protocol, where link layer
forwarding is not updated appropriately when nodes move to ports on forwarding is not updated appropriately when nodes move to ports on
skipping to change at page 9, line 23 skipping to change at page 10, line 46
useful properties of bridges, or maintaining those properties while useful properties of bridges, or maintaining those properties while
solving the problems listed in Section 2. solving the problems listed in Section 2.
3.1. No Change to Link Capabilities 3.1. No Change to Link Capabilities
There must be no change to the service that Ethernet subnets already There must be no change to the service that Ethernet subnets already
provide as a result of deploying a TRILL solution. Ethernet supports provide as a result of deploying a TRILL solution. Ethernet supports
unicast, broadcast, and multicast natively. Although network unicast, broadcast, and multicast natively. Although network
protocols, notably IP, can tolerate link layers that do not provide protocols, notably IP, can tolerate link layers that do not provide
all three, it would be useful to retain the support already in place all three, it would be useful to retain the support already in place
[8]. Zeroconf, as well as existing bridge autoconfiguration, are [RFC3819]. Zeroconf, as well as existing bridge autoconfiguration,
dependent on broadcast as well. are dependent on broadcast as well.
Current Ethernet ensures in-order delivery for frames of the same Current Ethernet ensures in-order delivery for frames of the same
priority and no duplicated frames, under normal operation (excepting priority and no duplicated frames, under normal operation (excepting
transients during reconfiguration). These criteria apply in varying transients during reconfiguration). These criteria apply in varying
degrees to the different variants of Ethernet, e.g., basic Ethernet degrees to the different variants of Ethernet, e.g., basic Ethernet
up through basic VLAN (802.1Q) ensures that all frames between two up through basic VLAN (802.1Q) ensures that all frames with the same
link addresses have both properties, but protocol/port VLAN (802.1v) priority between two link addresses have both properties, but
ensures this only for packets with the same protocol and port. There protocol/port VLAN (802.1v) ensures this only for packets with the
are subtle implications to such a requirement. Bridge autolearning same protocol and port. There are subtle implications to such a
already is susceptible to moving nodes between ports, because requirement. Bridge autolearning already is susceptible to moving
previously learned associations between port and link address change. nodes between ports, because previously learned associations between
A TRILL solution could be similarly susceptible to such changes. port and link address change. A TRILL solution could be similarly
susceptible to such changes.
3.2. Zero Configuration and Zero Assumption 3.2. Zero Configuration and Zero Assumption
Both bridges and hubs are zero configuration devices; hubs having no Both bridges and hubs are zero configuration devices; hubs having no
configuration at all, and bridges being automatically self- configuration at all, and bridges being automatically self-
configured. Bridges are further zero-assumption devices, unlike hubs. configured. Bridges are further zero-assumption devices, unlike hubs.
Bridges can be interconnected in arbitrary topologies, without regard Bridges can be interconnected in arbitrary topologies, without regard
for cycles or even self-attachment. Spanning tree protocols (STPs) for cycles or even self-attachment. Spanning tree protocols (STPs)
remove the impact of cycles automatically, and port autolearning remove the impact of cycles automatically, and port autolearning
reduces unnecessary broadcast of unicast traffic. reduces unnecessary broadcast of unicast traffic.
skipping to change at page 10, line 26 skipping to change at page 11, line 50
support via IGMP snooping, broadcast support via serial copy, and support via IGMP snooping, broadcast support via serial copy, and
supporting multiple VLANs. supporting multiple VLANs.
3.3. Forwarding Loop Mitigation 3.3. Forwarding Loop Mitigation
Spanning tree avoids forwarding loops by construction, although Spanning tree avoids forwarding loops by construction, although
transient loops can occur, e.g., via the temporarily undetected transient loops can occur, e.g., via the temporarily undetected
appearance of new link connectivity or the loss of a sufficient appearance of new link connectivity or the loss of a sufficient
number of spanning tree control frames. Solutions to TRILL are number of spanning tree control frames. Solutions to TRILL are
intended to use adapted network layer routing protocols which may intended to use adapted network layer routing protocols which may
introduce transient loops during routing convergence. TRILL solutions introduce transient loops during routing convergence. A TRILL
thus need support for mitigating the effect of such routing loops. 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 In the Internet, loop mitigation is provided by a decrementing hop
counts (TTL); in other networks, packets include a trace (sometimes counts (TTL); in other networks, packets include a trace (sometimes
referred to as 'serialized' or 'unioned') of visited nodes [2]. In referred to as 'serialized' or 'unioned') of visited nodes [RFC1812].
addition, there may be localized consistency checks, such as whether In addition, there may be localized consistency checks, such as
traffic in received on an unexpected interface, which indicates that whether traffic in received on an unexpected interface, which
routing is in flux and such traffic should probably be discarded for indicates that routing is in flux and such traffic should probably be
safety. These types of mechanisms limit the impact of loops or detect discarded for safety. These types of mechanisms limit the impact of
them explicitly. Mechanisms with similar effect should be included in loops or detect them explicitly. Mechanisms with similar effect
TRILL solutions. should be included in TRILL solutions.
3.4. Spanning Tree Management 3.4. Spanning Tree Management
In order to address convergence under reconfiguration and robustness In order to address convergence under reconfiguration and robustness
to link interruption (Section 2.2), participation in the spanning to link interruption (Section 2.2), participation in the spanning
tree (STP) must be carefully managed. The goal is to provide the tree (STP) must be carefully managed. The goal is to provide the
desired stability of the TRILL solution and of the entire Ethernet desired stability of the TRILL solution and of the entire Ethernet
link subnet, which may include bridges using STP. This may involve link subnet, which may include bridges using STP. This may involve a
TRILL solutions participating in the STP, where the protocol is used TRILL solution participating in the STP, where the protocol used for
for TRILL might dampen interactions with STP, or it may involve TRILL might dampen interactions with STP, or it may involve severing
severing the STP into separate STPs on 'stub' external Ethernet link the STP into separate STPs on 'stub' external Ethernet link subnet
subnet segments. segments.
A requirement is that a TRILL solution must not require modifications A requirement is that a TRILL solution must not require modifications
or exceptions to the existing spanning tree protocols (e.g., STP, or exceptions to the existing spanning tree protocols (e.g., STP,
RSTP, MSTP). RSTP (Rapid Spanning Tree Protocol), MSTP (Multiple Spanning Tree
Protocol)).
3.5. Multiple Attachments 3.5. Multiple Attachments
In STP, a single node with multiple attachments to a single spanning 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 tree segment will always only get and send traffic over one of the
those attachment points. TRILL must manage all traffic, including those attachment points. TRILL must manage all traffic, including
multicast and broadcast traffic, so as not to create feedback loops multicast and broadcast traffic, so as not to create traffic loops
on Ethernet segments with multiple TRILL attachment points. This involving Ethernet segments with multiple TRILL attachment points.
includes multiple attachments to a single TRILL node and attachments This includes multiple attachments to a single TRILL node and
to multiple TRILL nodes. 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 3.6. VLAN Issues
A TRILL solution should support multiple VLANs (802.1Q, which A TRILL solution should support multiple customer VLANs (802.1Q,
includes 802.1v and 802.1s). This may involve ignorance, just as many which includes 802.1v and 802.1s). This may involve ignorance, just
bridge devices do not participate in the VLAN protocols. It may as many bridge devices do not participate in the VLAN protocols. It
alternately furnish direct VLAN support, e.g., by providing may alternately furnish direct VLAN support, e.g., by providing
configurable support for VLAN ignorant end stations equivalent to configurable support for VLAN ignorant end stations equivalent to
that provided by 802.1Q non-provider bridges. 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 3.7. Operational Equivalence
As with any extension to an existing architecture, it would be useful As with any extension to an existing architecture, it would be useful
- though not strictly necessary - to be able to describe or consider - though not strictly necessary - to be able to describe or consider
a TRILL solution as equivalent to an existing link layer component. a TRILL solution as equivalent to an existing link layer component.
Such equivalence provides a validation model for the architecture and 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 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 on a deployed Ethernet. In this case, 'user' refers to users of the
Ethernet protocol, whether at the host (data segments), bridge (ST Ethernet protocol, whether at the host (data segments), bridge (ST
control segments), or VLAN (VLAN control). control segments), or VLAN (VLAN control).
This provides a sanity check, i.e., "we got it right if we can 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 exchange a TRILL solution component or components with an X" (where
bridge, a hub, or some other link layer abstraction). It does not "X" might be a single bridge, a hub, or some other link layer
matter whether "X" can be implemented on the same scale as the abstraction). It does not matter whether "X" can be implemented on
corresponding TRILL solution. It also does not matter if it can - the same scale as the corresponding TRILL solution. It also does not
there may be utility to deploying the TRILL solution components matter if it can - there may be utility to deploying the TRILL
incrementally, in ways that a single "X" could not be installed. 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 For example, if a TRILL solution's components were equivalent to a
bridge, it would mean that the TRILL solution would - as a whole - 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 - 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- components would propagate STP, any more than a bridge need do so in
board control. It would mean that the solution would interact with its on-board control. It would mean that the solution would interact
BPDUs at the edge, where the solution would - again, as a whole - 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 - participate as if a single node in the spanning tree. Note that
equivalence is not required; a solution may act as if an 802.1 hub, this equivalence is not required; a solution may act as if an IEEE
or may not have a corresponding equivalent link layer component at 802.1 hub, or may not have a corresponding equivalent link layer
all. component at all.
3.8. Optimizations 3.8. Optimizations
There are a number of optimizations that may be applied to TRILL There are a number of optimizations that may be applied to TRILL
solutions. These must be applied in a way that does not affect solutions. These must be applied in a way that does not affect
functionality as a tradeoff for increased performance. Such functionality as a tradeoff for increased performance. Such
optimizations may address broadcast and multicast frame distribution, optimizations may address broadcast and multicast frame distribution,
VLAN support, and snooping of ARP and IPv6 neighbor discovery. VLAN support, and snooping of ARP and IPv6 neighbor discovery.
In addition, there may be optimizations which make the implementation In addition, there may be optimizations which make the implementation
skipping to change at page 12, line 36 skipping to change at page 14, line 23
might require large high speed content addressable memory making might require large high speed content addressable memory making
implementation of such core bridges difficult. Although a TRILL implementation of such core bridges difficult. Although a TRILL
solution need not provide such optimizations, it may reduce the need solution need not provide such optimizations, it may reduce the need
for such large, high speed content addressable memories or provide for such large, high speed content addressable memories or provide
other similar optimizations. other similar optimizations.
3.9. Internet Architecture Issues 3.9. Internet Architecture Issues
TRILL solutions are intended to have no impact on the Internet TRILL solutions are intended to have no impact on the Internet
network layer architecture. In particular, the Internet and higher network layer architecture. In particular, the Internet and higher
layer headers should remain intact when traversing a TRILL solution, layer headers should remain intact when traversing a deployed TRILL
just as they do when traversing any other link subnet technologies. solution, just as they do when traversing any other link subnet
This means that the IP TTL field cannot be co-opted for forwarding technologies. This means that the IP TTL field cannot be co-opted for
loop mitigation, as it would interfere with the Internet layer forwarding loop mitigation, as it would interfere with the Internet
assuming that the link subnet was reachable with no changes in TTL layer assuming that the link subnet was reachable with no changes in
(Internet TTLs are changed only at routers, as per RFC 1812, and even TTL (Internet TTLs are changed only at routers, as per RFC 1812, and
if IP TTL were considered, TRILL is expected to support non-IP even if IP TTL were considered, TRILL is expected to support non-IP
payloads, and so requires a separate solution anyway) [2]. payloads, and so requires a separate solution anyway) [RFC1812].
TRILL solutions should also have no impact on Internet routing or TRILL solutions should also have no impact on Internet routing or
signaling, which also means that broadcast and multicast, both of signaling, which also means that broadcast and multicast, both of
which can pervade an entire Ethernet link subnet, must be able to which can pervade an entire Ethernet link subnet, must be able to
transparently pervade a TRILL solution. Changing how either of these transparently pervade a deployed TRILL solution. Changing how either
capabilities behaves would have significant effects on a variety of of these capabilities behaves would have significant effects on a
protocols, including RIP (broadcast), RIPv2 (multicast), ARP variety of protocols, including RIP (broadcast), RIPv2 (multicast),
(broadcast), IPv6 neighbor discovery (multicast), etc. ARP (broadcast), IPv6 neighbor discovery (multicast), etc.
Note that snooping of network layer packets may be useful, especially Note that snooping of network layer packets may be useful, especially
for certain optimizations. These include snooping multicast control for certain optimizations. These include snooping multicast control
plane packets (IGMP) to tune link multicast to match the network plane packets (IGMP) to tune link multicast to match the network
multicast topology, as is already done in existing smart switches multicast topology, as is already done in existing smart switches
[3][5]. This also includes snooping IPv6 neighbor discovery messages [RFC3376][RFC4286]. This also includes snooping IPv6 neighbor
to assist with governing TRILL solution edge configuration, as is the discovery messages to assist with governing TRILL solution edge
case in some smart learning bridges [10]. Other layers may similarly configuration, as is the case in some smart learning bridges
be snooped, notably ARP packets, for similar reasons for IPv4 [14]. [RFC4861]. Other layers may similarly be snooped, notably ARP
packets, for similar reasons for IPv4 [RFC826].
4. Applicability 4. Applicability
As might be expected, TRILL solutions are intended to be used to As might be expected, TRILL solutions are intended to be used to
solve the problems described in Section 2. However, not all such solve the problems described in Section 2. However, not all such
installations are appropriate environments for such solutions. This installations are appropriate environments for such solutions. This
section outlines the issues in the appropriate use of these section outlines the issues in the appropriate use of these
solutions. solutions.
TRILL solutions are intended to address problems of path efficiency TRILL solutions are intended to address problems of path efficiency
skipping to change at page 13, line 37 skipping to change at page 15, line 26
solution components may find other TRILL solution components within a solution components may find other TRILL solution components within a
single Ethernet link subnet and aggregate into a single TRILL single Ethernet link subnet and aggregate into a single TRILL
solution. solution.
TRILL solutions are not intended to span separate Ethernet link TRILL solutions are not intended to span separate Ethernet link
subnets interconnected by network layer (e.g., router) devices, subnets interconnected by network layer (e.g., router) devices,
except via link layer tunnels, where such tunnels render the distinct except via link layer tunnels, where such tunnels render the distinct
subnet undetectably equivalent from a single Ethernet link subnet. subnet undetectably equivalent from a single Ethernet link subnet.
A currently open question is whether 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 should contain components of only one TRILL solution, either of
of architecture or utility. Multiple TRILL solutions, like Internet necessity of architecture or utility. Multiple TRILL solutions, like
ASes, may allow TRILL routing protocols to be partitioned in ways Internet ASes, may allow TRILL routing protocols to be partitioned in
that help their stability, but this may come at the price of needing ways that help their stability, but this may come at the price of
the TRILL solutions to participate more fully as nodes (each modeling needing the TRILL solutions to participate more fully as nodes (each
a bridge) in the Ethernet link subnet STP. Each architecture solution modeling a bridge) in the Ethernet link subnet STP. Each architecture
should decide whether multiple TRILL solutions are supported within a solution should decide whether multiple TRILL solutions are supported
single Ethernet link subnet and mechanisms should be included to within a single Ethernet link subnet and mechanisms should be
enforce whatever decision is made. included to enforce whatever decision is made.
TRILL solutions need not address scalability limitations in bridged TRILL solutions need not address scalability limitations in bridged
subnets. Although there may be scale benefits of other aspects of subnets. Although there may be scale benefits of other aspects of
solving TRILL problems, e.g., of using network layer routing to solving TRILL problems, e.g., of using network layer routing to
provide stability under link changes or intermittent outages, this is provide stability under link changes or intermittent outages, this is
not a focus of this work. not a focus of this work.
As also noted earlier, TRILL solutions are not intended to address As also noted earlier, TRILL solutions are not intended to address
security vulnerabilities in either the data plane or control plane of security vulnerabilities in either the data plane or control plane of
the link layer. This means that TRILL solutions should not limit the link layer. This means that TRILL solutions should not limit
skipping to change at page 14, line 32 skipping to change at page 16, line 19
intended to provide more stable routing than STP, this stability is intended to provide more stable routing than STP, this stability is
limited to performance, and the subsequent robustness is intended to limited to performance, and the subsequent robustness is intended to
address non-malicious events. address non-malicious events.
There may be some side-effects to the use of TRILL solutions that can There may be some side-effects to the use of TRILL solutions that can
provide more robust operation under certain attacks, such as those provide more robust operation under certain attacks, such as those
interrupting or adding link service, but TRILL solutions should not interrupting or adding link service, but TRILL solutions should not
be relied upon for such capabilities. be relied upon for such capabilities.
Finally, TRILL solutions should not interfere with other protocols Finally, TRILL solutions should not interfere with other protocols
intended to address these vulnerabilities, such as those under intended to address these vulnerabilities, such as those to secure
development to secure IPv6 neighbor discovery [1]. IPv6 neighbor discovery [RFC3971].
6. IANA Considerations 6. IANA Considerations
This document requires no IANA actions. This document requires no IANA actions.
This section should be removed by the RFC Editor prior to final This section should be removed by the RFC Editor prior to final
publication. publication.
7. Acknowledgments 7. Acknowledgments
Portions of this document are based on documents that describe a Portions of this document are based on documents that describe a
preliminary solution, and on a related network layer solution preliminary solution, and on a related network layer solution
[11][13][15]. Donald Eastlake III provided substantial text and [Pe04][Pe05][To03]. Donald Eastlake III provided substantial text and
comments. Additional comments and feedback were provided by the comments. Additional comments and feedback were provided by the
members of the IETF TRILL WG, in which this document was developed. 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. This document was prepared using 2-Word-v2.0.template.dot.
8. References 8. References
8.1. Normative References 8.1. Normative References
None. None.
8.2. Informative References 8.2. Informative References
[1] Arkko, J., J. Kempf, B. Sommerfield, B. Zill, P. Nikander, [IEEE04] IEEE 802.1D bridging standard, "IEEE Standard for Local and
"Secure Neighbor Discovery (SeND)", RFC 3971 (Proposed metropolitan area networks: Media Access Control (MAC)
Standard), Mar. 2005. Bridges", (incorporates 802.1w), Jun. 2004.
[2] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812 [IEEE06] IEEE 802.1Q VLAN standard, "IEEE Standards for Local and
(Proposed Standard), Jun. 1995. metropolitan area networks: Virtual Bridged Local Area
Networks", (incorporates 802.1v and 802.1s), May 2006.
[3] Cain, B., S. Deering, I. Kouvelas, B. Fenner, A. Thyagarajan, [Me04] Myers, A., T.E. Ng, H. Zhang, "Rethinking the Service
"Internet Group Management Protocol, Version 3", RFC 3376 Model: Scaling Ethernet to a Million Nodes", Proc. ACM
(Proposed Standard), Oct. 2002. Third Workshop on Hot Topics in Networks (HotNets-III),
Mar. 2004.
[4] Christensen, M., Kimball, K., and F. Solensky, "Considerations [Pe99] Perlman, R., "Interconnection: Bridges, Routers, Switches,
for Internet Group Management Protocol (IGMP) and Multicast and Internetworking Protocols", Addison Wesley, Chapter 3,
Listener Discovery (MLD) Snooping Switches", RFC 4541, May 1999.
2006.
[5] Haberman, B., J. Martin, "Multicast Router Discovery", RFC 4286 [Pe04] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom
(Proposed Standard), Dec. 2005. 2005, Mar. 2004.
[6] IEEE 802.1D bridging standard, "IEEE Standard for Local and [Pe05] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent
metropolitan area networks: Media Access Control (MAC) Routing," (expired work in progress), Apr. 2004 - May 2005.
Bridges", (incorporates 802.1w), Jun. 2004.
[7] IEEE 802.1Q VLAN standard, "IEEE Standards for Local and [RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or
metropolitan area networks: Virtual Bridged Local Area converting network protocol addresses to 48.bit Ethernet
Networks", (incorporates 802.1v and 802.1s), May 2006. address for transmission on Ethernet hardware", RFC-826 /
STD-37 (Standard), Nov. 1982.
[8] Karn, P., (ed.), C. Bormann, G. Fairhurst, D. Grossman, R. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers",
Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood, "Advice RFC-1812 (Proposed Standard), Jun. 1995.
for Internet Subnetwork Designers", RFC-3819 / BCP 89 (Best
Current Practice), Jul. 2004.
[9] Myers, A., T.E. Ng, H. Zhang, "Rethinking the Service Model: [RFC3819] Karn, P., (ed.), C. Bormann, G. Fairhurst, D. Grossman, R.
Scaling Ethernet to a Million Nodes", Proc. ACM Third Workshop Ludwig, J. Mahdavi, G. Montenegro, J. Touch, L. Wood,
on Hot Topics in Networks (HotNets-III), Mar. 2004. "Advice for Internet Subnetwork Designers", RFC-3819 / BCP
89 (Best Current Practice), Jul. 2004.
[10] Narten, T., E. Nordmark, W. Simpson, H. Soliman, "Neighbor [RFC3376] Cain, B., S. Deering, I. Kouvelas, B. Fenner, A.
Discovery for IP version 6 (IPv6)", RFC 4861 (Draft Standard), Thyagarajan, "Internet Group Management Protocol, Version
Sep. 2007. 3", RFC-3376 (Proposed Standard), Oct. 2002.
[11] Perlman, R., "RBridges: Transparent Routing", Proc. Infocom [RFC3971] Arkko, J., J. Kempf, B. Sommerfield, B. Zill, P. Nikander,
2005, Mar. 2004. "Secure Neighbor Discovery (SeND)", RFC-3971 (Proposed
Standard), Mar. 2005.
[12] Perlman, R., "Interconnection: Bridges, Routers, Switches, and [RFC4286] Haberman, B., J. Martin, "Multicast Router Discovery",
Internetworking Protocols", Addison Wesley, Chapter 3, 1999. RFC-4286 (Proposed Standard), Dec. 2005.
[13] Perlman, R., J. Touch, A. Yegin, "RBridges: Transparent [RFC4541] Christensen, M., Kimball, K., and F. Solensky,
Routing," (expired work in progress), Apr. 2004 - May 2005. "Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches", RFC-4541, May 2006.
[14] Plummer, D., "Ethernet Address Resolution Protocol: Or [RFC4861] Narten, T., E. Nordmark, W. Simpson, H. Soliman, "Neighbor
converting network protocol addresses to 48.bit Ethernet Discovery for IP version 6 (IPv6)", RFC-4861 (Draft
address for transmission on Ethernet hardware", RFC 826 / STD Standard), Sep. 2007.
37 (Standard), Nov. 1982.
[15] Touch, J., Y. Wang, L. Eggert, G. Finn, "A Virtual Internet [To03] Touch, J., Y. Wang, L. Eggert, G. Finn, "A Virtual Internet
Architecture", ISI Technical Report ISI-TR-570, Presented at Architecture", ISI Technical Report ISI-TR-570, Presented
the Workshop on Future Directions in Network Architecture at the Workshop on Future Directions in Network
(FDNA) 2003 at Sigcomm 2003, March 2003. Architecture (FDNA) 2003 at Sigcomm 2003, March 2003.
Author's Addresses Author's Addresses
Joe Touch Joe Touch
USC/ISI USC/ISI
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292-6695 Marina del Rey, CA 90292-6695
U.S.A. U.S.A.
Phone: +1 (310) 448-9151 Phone: +1 (310) 448-9151
skipping to change at page 16, line 44 skipping to change at line 810
URL: http://www.isi.edu/touch URL: http://www.isi.edu/touch
Radia Perlman Radia Perlman
Sun Microsystems Sun Microsystems
16 Network Circle 16 Network Circle
umpk16-161 umpk16-161
Menlo Park, CA 94025 Menlo Park, CA 94025
U.S.A. U.S.A.
Email: Radia.Perlman@sun.com Email: Radia.Perlman@sun.com
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.
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.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 65 change blocks. 
228 lines changed or deleted 300 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/