Network Working Group E. Gray
Internet Draft Editor
Expires: July, 2007 Ericsson
January, 2007
TRILL Routing Requirements in Support of RBridges
draft-ietf-trill-routing-reqs-02.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 July 31, 2007.
Abstract
RBridges provide the ability to have an entire domain, with multiple
physical links, look to IP like a single subnet. The design allows
for zero configuration of switches within an RBridge domain, optimal
pair-wise routing, safe forwarding even during periods of temporary
loops, and potential additional advantages as well. The design also
supports VLANs, allows forwarding tables to be based on destinations
within the RBridge domain (rather than station destinations, allowing
internal forwarding tables to be smaller than in conventional bridge
systems).
Gray Expires July, 2007 [Page 1]
Internet-Draft TRILL Routing Requirements January, 2007
The intent is to re-uses one or more existing routing protocols to
accomplish these goals.
This document lays out the background and specific requirements of
potential routing protocols to be considered for use in this design.
In particular, this document defines what is needed to accomodate
this design using IS-IS (or OSPF) as a basis for RBridge protocols.
Table of Contents
1. Introduction....................................................3
1.1. Terminology................................................4
1.2. Specific TRILL Goals.......................................5
2. General Requirements Potentially Affecting Routing..............6
3. Link State Protocol Specific Requirements.......................6
4. Potential Issues................................................7
4.1. Interactions with Spanning Tree Forwarding.................7
4.2. Computing Routes...........................................8
4.3. RBridge Interactions with Routing..........................8
5. Security Considerations.........................................8
6. Conclusions.....................................................9
7. IANA Considerations.............................................9
8. Acknowledgments.................................................9
9. References.....................................................10
9.1. Normative References......................................10
9.2. Informative References....................................10
10. Author's Address(es)..........................................10
11. Intellectual Property Statement...............................10
12. Disclaimer of Validity........................................11
13. Copyright Statement...........................................11
14. Acknowledgment................................................11
Gray Expires July, 2007 [Page 2]
Internet-Draft TRILL Routing Requirements January, 2007
1. Introduction
The current dominant approach to segregating network traffic relies
on a hierarchical arrangement of bridges and routers. Hierarchy is
further extended - both within routing protocols (such as IS-IS and
OSPF) and between routing protocols (for example, between IGPs and
BGP). At least part of the current network structure is based on a
determined trade-off between limitations of IP routing and similar
disadvantages of 802 bridging.
Bridging Limitations
For example, bridged networks consist of single broadcast/flooding
domains. Ethernet/802 encapsulation (on which bridging is based)
does not provide mechanisms for reducing the impact of looping data
traffic that may result from a transient change in network topology
and the existence of multiple paths.
The impact of looping traffic is far worse with flooded or broadcast
traffic as this results in exponentially increasing traffic load.
Consideration of the impacts of looping data lead to the use of
STP/RSTP to establish a connected - loop free - tree by disabling
forwarding on a subset of links that might create a loop. This has
also the effect of eliminating redundant paths, reducing aggregate
throughput and increasing latency through the network.
Because of the potential for severe impact from looping traffic,
many (if not most) current bridge implementations stop forwarding of
traffic frames following a topology change event and restart only
after STP/RSTP is complete.
As a result, the process of eliminating potential loops in existing
bridging deployments:
1) Results in inefficient use of inter-bridge connections
and
2) May cause delays in forwarding traffic as a result of
changes in the network topology.
The combined effect of broadcast/flooding traffic, and the use of
spanning trees for loop avoidance, sets practical limits on bridged
network size in the network hierarchy and results in inefficient
bandwidth use of inter-bridge connections. Inefficient inter-bridge
connection usage similarly limits the usefulness of bridging with
high-speed (and consequently high cost) interfaces.
Gray Expires July, 2007 [Page 3]
Internet-Draft TRILL Routing Requirements January, 2007
IP Routing Issues
For IP routed networks, any link (or subnet) must have at least one
unique prefix. This means that a node that moves from one IP subnet
to another must change its IP address. Also, nodes with multiple IP
subnet attachments must have multiple IP addresses. In IP routed
networks, there are frequent trade-off considerations between using
smaller subnets (longer prefix length) to minimize wasted IP address
space (as a result of unused addresses in the fixed address range
defined by the prefix and length) and using larger subnets (shorter
prefix length) to minimize the need for (changes in) configuration.
In any case - with current IP routing technology - subnets must be
configured for each routed interface.
Proposed Solution
Using a hybrid of routing and bridging - an RBridge - we hope to
gain the benefits of both technologies, in particular, gaining the
bandwidth advantages of shortest path routing while retaining the
simplified configuration associated with bridging.
1.1. Terminology
The following terms are used in this document in the way that
they are defined in "TRILL RBridge Architecture" [TARCH]:
ARP (Address Resolution Protocol)
Bridge Learning
Broadcast Domain
Broadcast Traffic
Cooperating RBridges
Egress RBridge
Ethernet
Flooded Traffic
Flooding
Frame
IGP (Interior Gateway Protocol)
Ingress RBridge
Ingress RBridge Tree
IS-IS (Intermediate System to Intermediate System)
ND (Neighbor Discovery)
OSPF (Open Shortest Path First)
RBridge
SPF (Shortest Path First)
Station
STP/RSTP (Spanning Tree Protocol/Rapid Spanning Tree Protocol)
TRILL (TRansport Interconnect over Lots of Links)
Unknown Destination
VLAN (Virtual Local Area Network)
Gray Expires July, 2007 [Page 4]
Internet-Draft TRILL Routing Requirements January, 2007
1.2. Specific TRILL Goals
(Near) Zero Configuration
It is a TRILL requirement that it must be possible to deploy RBridges
in at least a nominal set of potential deployment scenarios without a
need to perform any configuration at each RBridge. It is possible to
meet this goal for a sub-set of all possible deployment scenarios by
making realistic restrictions on deployment - such as restricting the
deployment scenarios to exclude those involving a "trust model" that
imposes a need for configuration of some form of "shared secret" or
other configuration required to restrict access to "trusted" devices.
It is also conceivable that a minimal configuration may be required
for deployment of an initial (set of) device(s) - with subsequently
deployed devices deriving that configuration information during the
process of - for example - peer discovery. This would constitute a
mechanism for "near zero configuration".
Efficient Unicast Bandwidth Usage
For unicast, non-flooded traffic, RBridges are intended to merge the
efficient bandwidth use of IP routing with the simplicity of Ethernet
(or 802.1) bridging for networks possibly larger - and with greater
forwarding capacity - than is the case with these networks presently.
The approach that we will use in accomplishing this is based on the
idea of extending (one or more) link state routing protocol(s) to
include distribution of Ethernet/802 reachability information between
RBridges. In addition, there may be specific requirements imposed on
the interactions between these extensions and Spanning Tree Protocol
(STP) and between RBridges and (potentially co-located) IP routing
instances.
Potentially More Efficient Multicast and Broadcast Usage
There are clear advantages to incorporating mechanisms for improved
efficiency in forwarding (layer 2) multicast frames and - possibly
in reducing the amount of broadcast traffic as well. To the extent
that these efficiency improvements may be considered "optimizations"
and may be defined orthogonally to the process of specifying basic
RBridge functionality, the potential to include these optimizations
is (highly) desirable, but not mandatory.
Examples of this type of optimization include use of any intrinsic
multicast routing capabilities and optimizations of ARP/ND.
Gray Expires July, 2007 [Page 5]
Internet-Draft TRILL Routing Requirements January, 2007
Backward Compatibility
RBridges must be fully compatible with current bridges, IPv4 and
IPv6 routers and stations. They should be invisible to current IP
routers (just as bridges are), and like routers, they terminate a
bridged spanning tree, (i.e. - they do not forward BPDUs). Unlike
Routers, RBridges do not terminate a broadcast domain.
2. General Requirements Potentially Affecting Routing
Candidate IGP Routing protocols - IS-IS or OSPF - must be evaluated
for compatibility with the above goals.
For example, since IS-IS requires a unique System ID for each IS-IS
instance (at least within a "scoped" deployment), a requirement for
"(near) zero configuration" implies a need for mechanisms that allow
auto-configuration and/or negotiation of these (scoped) unique IDs.
Similar requirement must apply for OSPF as well, if selected.
In addition, forwarding of protocol messages must be compatible with
(or reasonably adaptable to) use of forwarding at layer 2, or there
must be a means for deriving suitable higher layer addresses for the
purpose of protocol exchanges - without imposing the need to manually
configure higher-layer addresses.
3. Link State Protocol Specific Requirements
Assuming that link state routing protocols meet above requirements,
running a link state protocol among RBridges is straightforward. It
is the same as running a level 1 routing protocol in an area. This
would be theoretically true for either IS-IS or OSPF, assuming that
both of these meet the general requiremenst above.
From the perspective of simply extending existing routing protocols,
IS-IS is a more appropriate choice than OSPF because it is easy in
IS-IS to define new TLVs for use in carrying a new information type.
This document, however, does not mandate a specific link-state, IGP,
routing protocol. Instead, it sets forth the requirements that will
apply to any link-state routing protocol that may be used.
For implementations providing co-located Router/RBridge function,
it is necessary to have mechanisms for distinguishing any protocol
interactions in Routing instances from protocol interactions in the
co-located RBridge instance. Specific mechanisms we will use are
very likely to be determined by the Link State Routing Protocol that
Gray Expires July, 2007 [Page 6]
Internet-Draft TRILL Routing Requirements January, 2007
we select. Potential distinguishing mechanisms include use of a new
well-known Ethernet/802 multicast address, higher-layer protocol ID
or other - routing protocol specific - approaches.
The mechanism chosen should be consistent with the TRILL goals. If,
for example, a routing protocol specific approach required use of a
unique "area" identifier, the RBridge area identifier should be a
constant, well-known, value for all RBridges, and would not be one
that would ever appear as a real routing area identifer - in order
to allow for a potential for configuration-free operation.
Information that RBridge link state information will carry includes:
o layer 2 addresses of nodes within the domain which have
transmitted frames but have not transmitted ARP or ND replies
o layer 3, layer 2 addresses of IP nodes within the domain. For
data compression, perhaps only the portion of the address
following the domain-wide prefix need be carried. This will be
more of an issue for IPv6 than for IPv4.
o VLANs directly connected to this RBridge
Station information need only be delivered to RBridges supporting
the VLAN in which the station resides. So, for instance, if station
E is discovered through a VLAN A frame, then E's location need only
be delivered to other RBridges that are attached to VLAN A links.
Given that RBridges must support delivery only to links within a VLAN
(for multicast or unknown frames marked with the VLAN's tag), this
mechanism can be used to advertise station information solely to the
RBridges "within" a VLAN (i.e. - having connectivity or configuration
that associates them with a VLAN). Although a separate instance of
the link state protocol could be run for this purpose, the topology
is so restricted (just a single broadcast domain), that it may be
preferable to define special case mechanisms whereby each Designated
RBridge advertises attached stations, and receives explicit
acknowledgments from other RBridges.
4. Potential Issues
4.1. Interactions with Spanning Tree Forwarding and Bridge Learning
Spanning tree forwarding applies within parts of the RBridge domain,
where two or more RBridges are connected by a link that includes
multiple 802.1 bridges.
Gray Expires July, 2007 [Page 7]
Internet-Draft TRILL Routing Requirements January, 2007
In order to simplify the interactions between RBridges and bridges -
in particular, relative to spanning tree forwarding - RBridges block
BPDUs in spanning tree protocol with attached 802.1 bridges.
Hence, from the Link State Routing protocol perspective, the protocol
will be able to treat spanning tree links as indistinguishable from
any other Ethernet/802.1 link, in the same way that routing protocols
do today.
However, support for multi-pathing is potentially problematic and is
assumed - in this document - to be a non-goal. Multi-path forwarding
has the potential to confound the bridge learning process.
4.2. Computing Routes
RBridges must calculate an L2 "route table" consisting of Next Hop
information for each known L2 unicast destination address within a
(possibly VLAN scoped) broadcast domain. This is computed using a
routing protocol's SPF algorithm and based on destination layer 2
address reachability advertisements.
4.3. RBridge Interactions with Routing
The fact that RBridges participate in flooding, and will have other
significant differences in forwarding behavior, provides additional
reasons to maintain separate routing instances if an RBridge and
Router are co-located. Otherwise, interactions between routers and
RBridges should be identical to interactions between routers and
bridges.
One of the potential interactions to consider in evaluating specific
routing protocols is how a specific routing protocol advertises on a
shared media. For instance, if a "pseudo-node" is used as a target
for such advertisements, how does this interact with the advertising
requirements for RBridges?
We expect this to be routing and RBridge protocol specific, and a
subject for further study.
5. Security Considerations
The goal is not to add additional security issues over what would be
present with traditional bridges and routers. RBridge Interactions
with Routers must be defined such that there is no "leaking" of info
used in authentication and/or encryption between router and r-bridge
instances.
Gray Expires July, 2007 [Page 8]
Internet-Draft TRILL Routing Requirements January, 2007
As with routing schemes, authentication of RBridge messages would be
a simple addition to protocol (and it could be accomplished the same
way as it would be in existing routing protocol). However, any sort
of authentication requires additional configuration, which might
interfere with the requirement that RBridges need no configuration.
The essential requirement that RBridges do not require configuration
provides a forceful argument that most RBridge components are likely
to be physically separate (verses logically separate instances within
a single physical device) from routers. However, implementers may
choose to provide devices with both Routing and RBridge instancing
capabilities.
Implementers should consider the differences in trust models implied
in Routing and Bridging domains and apply appropriate trust boundary
safeguards in addition to instance isolation in general.
6. Conclusions
Routing protocols must be evaluated using the criteria in sections
2 and 3 above, with a clear objective of satisfying the TRILL goals
outlined in section 1.2. In addition, specific protocol solutions
should use discussion in section 4 above in making a determination
as to what approaches TRILL should use, for that (or those) routing
protocols that is determined to be useful for RBridge implementation.
Because of the requirement to be able to extend the routing protocol
to carry new information, and potentially support new types of peer
negotiation, the selected routing protocol must include mechanisms
to allow simple routing protocol extensions, new message formats and
potentially new types of message exchanges.
For reasons stated in above sections, we believe it is clear that the
IS-IS routing protocol may easily be adapted to satisfy TRILL routing
protocol requirements.
7. IANA Considerations
There is no action required of IANA by this document.
8. Acknowledgments
Thanks and appreciation are due Radia Perlman and Erik Nordmark for
their efforts in reviewing this document. Also appreciated are the
review efforts of Joel Halpern and Russ White.
Gray Expires July, 2007 [Page 9]
Internet-Draft TRILL Routing Requirements January, 2007
9. References
9.1. Normative References
[TARCH] "TRILL RBridge Architecture", Gray, E. Editor - Work in
Progress.
9.2. Informative References
None.
10. Author's Addresses
Eric Gray
Ericsson
900 Chelmsford Street,
Lowell, MA - 01851
Email: Eric.Gray@Ericsson.com
11. 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.
Gray Expires July, 2007 [Page 10]
Internet-Draft TRILL Routing Requirements January, 2007
12. 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.
13. Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
14. Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gray Expires July, 2007 [Page 11]
