One document matched: draft-gray-trill-routing-reqs-00.txt
Network Working Group E. Gray
Internet Draft Editor
Expires: July, 2006 Ericsson
January, 2006
TRILL Routing Requirements in Support of RBridges
draft-gray-trill-routing-reqs-00.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.
This document may not be modified, and derivative works of it may
not be created, except to publish it as an RFC and to translate it
into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
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 30, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Gray Expires July 2006 [Page 1]
Internet-Draft TRILL Routing Requirements January, 2006
Abstract
RBridges provide the ability to have an entire campus, with multiple
physical links, look to IP like a single subnet. The design allows
for zero configuration of switches within an RBridge campus, optimal
pair-wise routing, safe forwarding even during periods of temporary
loops, and the potential ability to cut down on Address Resolution
Protocol (ARP) and/or Neighbor Discovery (ND) traffic. The design
supports VLANs, allows forwarding tables to be based on destinations
within the RBridge campus (rather than endnode destinations, allowing
internal forwarding tables to be smaller than in conventional bridge
systems) and re-uses existing routing protocols (for distribution of
reachability of destinations and shortest path computation within an
RBridge campus, and potentially for peer/topology discovery).
In order to accomplish this, the design may impose requirements for
extensions to one or more existing routing protocols necessary to
accomplish the distribution and computation processes, as well as
specific limits on interactions between bridge, R-Bridge and Router
instances.
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..........................9
5. Security Considerations.........................................9
6. Conclusions....................................................10
7. Acknowledgments................................................10
8. References.....................................................10
8.1. Normative References......................................10
8.2. Informative References....................................10
9. Author's Address(es)...........................................11
10. Intellectual Property Statement...............................11
11. Disclaimer of Validity........................................11
12. Copyright Statement...........................................11
13. Acknowledgment................................................12
Gray Expires July 2006 [Page 2]
Internet-Draft TRILL Routing Requirements January, 2006
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.
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) Causes 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 2006 [Page 3]
Internet-Draft TRILL Routing Requirements January, 2006
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.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [TERM].
The following additional 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
Filtering Database
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)
Packet
RBridge
RBridge Campus
SPF (Shortest Path First)
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 2006 [Page 4]
Internet-Draft TRILL Routing Requirements January, 2006
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
R-Bridge instances. In addition, there may be specific requirements
imposed on the interactions between these extensions and the Spanning
Tree Protocol (STP) and between R-Bridge instances and (potentially
colocated) 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 2006 [Page 5]
Internet-Draft TRILL Routing Requirements January, 2006
Backward Compatibility
RBridges MUST be fully compatible with current bridges, current Pv4
and IPv6 routers and endnodes. They SHOULD be invisible to current
IP routers (just as bridges are), and like routers, they terminate
a bridged spanning tree. 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 colocated Router and RBridge function,
it is necessary to have mechanisms for distinguishing any protocol
interactions in Routing instances from protocol interactions in the
colocated RBridge instance. The specific mechanisms we will use are
very likely to be determined by the Link State Routing Protocol that
Gray Expires July 2006 [Page 6]
Internet-Draft TRILL Routing Requirements January, 2006
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 campus which have
transmitted frames but have not transmitted ARP or ND replies
o layer 3, layer 2 addresses of IP nodes within the campus. For
data compression, perhaps only the portion of the address
following the campus-wide prefix need be carried. This will be
more of an issue for IPv6 than for IPv4.
o VLANs directly connected to this RBridge
The endnode information (the endnode information) need only be
delivered to RBridges supporting the VLAN in which the endnode
resides. So, for instance, if endnode 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 endnode information solely to the
RBridges "within" a VLAN (i.e. - having connectivity or configuration
that assoicates 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 DR advertises attached
endnodes, and receives explicit acknolegments from other RBridges.
4. Potential Issues
4.1. Interactions with Spanning Tree Forwarding and Bridge Learning
Spanning tree forwarding applies within the RBridge Campus, where two
or more RBridges are connected by a link that includes multiple 802.1
bridges.
Gray Expires July 2006 [Page 7]
Internet-Draft TRILL Routing Requirements January, 2006
In order to simplify the interactions between RBridges and bridges -
in particular, relative to spanning tree forwarding - RBridges do not
actively participate in spanning tree protocol with 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
Computing Unicast Forwarding
RBridges MUST calculate an L2 "route table" consisting of Next Hop
information for each L2 unicast destination address within each
(possibly VLAN scoped) broadcast domain. This is computed using a
routing protocol's SPF algorithm and based on destination layer 2
address reachability advertisements.
Computing the Ingress RBridge Tree
In addition, RBridges MUST calculate a similar table for multicast
and broadcast frame forwarding as follows:
1) RBridges compute next hop information for multicast/broadcast
delivery - for each VLAN scoped broadcast domain - to be used
for frames not received from another RBridge (as determined by
the combination of interface and layer 2 source address) using
the routing protocol's SPF algorithm. The next hop information
in this case includes appropriate encapsulation information for
use in forwarding to other RBridges.
2) RBridges then compute next hop information for multicast and
broadcast delivery - for each VLAN scoped broadcast domain - to
be used for frames received from each specific Ingress RBridge
(as determined by the encapsulated layer 2 source address).
Again, the computation uses a routing protocol's SPF algorithm.
Any RBridge implementation MAY differentiate multicast route tables
from broadcast route tables if doing so is required to support the
multicast forwarding optimization.
Gray Expires July 2006 [Page 8]
Internet-Draft TRILL Routing Requirements January, 2006
Broadcast route tables - per VLAN - are used to flood frames with
destinations unknown to the Ingress RBridge (the only RBridge that
did not receive the frame from another RBridge). Subsequent RBridges
MAY "peek" at the encapsulated frame to determine if the destination
address is known at the local RBridge. If the destination address is
known, the local RBridge MAY elect to choose an appropriate next hop
for forwarding to that destination only.
In a campus without VLANs, or one having a single VLAN, this means
a single "route table" could be computed and used for delivery of
frames with unknown or group address layer 2 destinations.
While it is possible to support VLANs with a single spanning tree, and
just avoid forwarding the decapsulated frame onto links that do not
support that VLAN, the multi-VLAN approach allows for more efficient
delivery by avoiding transmission of frames on those paths that do not
lead to participants in a specific VLAN.
4.3. R-Bridge Interactions with Routing
The fact that R-Bridges participate in flooding, and will have other
significant differences in forwarding behavior, provides additional
reasons to maintain separate routing instances if an R-Bridge and
Router are colocated. Otherwise, interactions between routers and
R-Bridges SHOULD be identical to interactions with bridges.
5. Security Considerations
The goal is not to add additional security issues over what would be
present with traditional bridges and routers. R-Bridge 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.
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.
Gray Expires July 2006 [Page 9]
Internet-Draft TRILL Routing Requirements January, 2006
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. Acknowledgments
Thanks and appreciation are due Radia Perlman and Erik Nordmark for
their efforts in reviewing this document.
8. References
8.1. Normative References
[TERM] "Key words for use in RFCs to Indicate Requirement Levels",
Bradner, S., RFC 2119/BCP 14, March 1997.
[TARCH] "TRILL RBridge Architecture", Gray, E. Editor - Work in
Progress.
8.2. Informative References
None.
Gray Expires July 2006 [Page 10]
Internet-Draft TRILL Routing Requirements January, 2006
9. Author's Addresses
Eric Gray
Ericsson
900 Chelmsford Street,
Lowell, MA - 01851
Email: Eric.Gray@marconi.com
10. 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
11. 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 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.
12. Copyright Statement
Copyright (C) The Internet Society (2006).
Gray Expires July 2006 [Page 11]
Internet-Draft TRILL Routing Requirements January, 2006
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.
13. Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gray Expires July 2006 [Page 12]| PAFTECH AB 2003-2026 | 2026-04-24 02:10:02 |