Internet DRAFT - draft-gray-rbridge-routing-reqs
draft-gray-rbridge-routing-reqs
Network Working Group E. Gray
Internet Draft Editor
Expires: April, 2006 Marconi
October, 2005
Routing Requirements in Support of R-Bridges
draft-gray-rbridge-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 April 15, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Gray Expires April 15, 2006 [Page 1]
Internet-Draft R-Bridge Routing Requirements August 2005
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 a campus, optimal pair-wise
routing, safe forwarding even during periods of temporary loops, and
the ability to cut down on ARP/ND traffic. The design supports VLANs,
allows forwarding tables to be based on RBridge destinations (rather
than endnode destinations, allowing internal forwarding tables to be
smaller than in conventional bridge systems) and re-uses existing
routing protocols (for - at least - distribution of reachability of
destinations and shortest path computation within a campus).
In order to accomplish this, the design may impose requirements for
extensions to 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...................................................2
2. Link State Protocol Requirements...............................4
3. Issues.........................................................5
3.1. Interactions with Spanning Tree Forwarding................5
3.1.1. Per-ingress Spanning Tree............................5
3.1.2. Per VLAN.............................................5
3.1.3. Single Spanning Tree.................................5
3.2. Interactions with Spanning Tree Protocol Operation........5
3.3. R-Bridge Interactions with Routing........................6
4. Security Considerations........................................6
5. Conclusions....................................................6
6. Acknowledgments................................................6
7. References.....................................................6
7.1. Normative References......................................6
7.2. Informative References....................................7
8. Author's Address(es)...........................................7
9. Intellectual Property Statement................................7
10. Disclaimer of Validity........................................7
11. Copyright Statement...........................................8
12. Acknowledgment................................................8
1. Introduction
The current dominant approach to segregating network traffic relies
on a hierarchical arrangement of bridges and routers. Hierarchical
network structure is thus based on a determined trade-off between
limitations of IP routing and similar disadvantages of 802 bridging.
Gray Expires April 15, 2006 [Page 2]
Internet-Draft R-Bridge Routing Requirements August 2005
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. Considerations of consequences
of looping traffic - and the potential for exponentially increasing
load in the case of looping broadcast or flooded data - impose a set
of disciplines on the use of bridge interconnections that:
1) Result in inefficient use of inter-bridge connections and
2) Delays in forwarding traffic as a result of changes in the
network topology.
The combined effect of broadcast/flooding, and loop avoidance, sets
practical limits on bridged network size in the network hierarchy.
Inefficient use of inter-bridge connections similarly sets limits
on the usefulness of bridging with high-speed (and consequent high
cost) interfaces.
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.
R-Bridges are intended to incorporate the efficient bandwidth use of
IP routing with the simplicity of Ethernet/802 bridging for networks
possibly larger - and with greater forwarding capacity - than is the
case with current Ethernet/802 bridged networks.
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.
Gray Expires April 15, 2006 [Page 3]
Internet-Draft R-Bridge Routing Requirements August 2005
RBridges are fully compatible with current bridges as well as current
IPv4 and IPv6 routers and endnodes. They are as invisible to current
IP routers as bridges are, and like routers, they terminate a bridged
spanning tree.
2. Link State Protocol
Running a link state protocol among RBridges is straightforward. It
is the same as running a level 1 routing protocol in an area. IS-IS
is a more appropriate choice than OSPF in this case because it is
easy in IS-IS to define new TLVs for carrying new information. This
document, however, does not mandate use of any specific link-state
routing protocol. Instead, it sets forth the requirements that will
apply to any link-state routing protocol that may be used.
To keep R-Bridge and Routing instances separate (assuming both are
colocated), RBridge routing messages should be sent to a different
Ethernet/802 multicast address than the link-state routing protocol
messages used for IP routing - or (as an IS-IS example) they may be
differentiated by use of different "area address", where, in order
to keep RBridges configuration-free, the RBridge area address would
be a constant for all RBridges, and would not be one that would ever
appear as a real IS-IS area address.
Information that RBridge link state information will carry includes:
o layer 2 addresses of nodes within the campus which have
transmitted packets 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
packet, then E's location need only be delivered to other RBridges
that are attached to VLAN A links.
Gray Expires April 15, 2006 [Page 4]
Internet-Draft R-Bridge Routing Requirements August 2005
Given that RBridges must support delivery only to links within a VLAN
(for multicast or unknown packets marked with the VLAN's tag), this
mechanism can be used to advertise endnode information solely to
RBridges within 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 might be
preferable to design a special case mechanism where each DR
advertises its attached endnodes, and receives explicit acks from the
other RBridges.
3. Issues
3.1. Interactions with Spanning Tree Forwarding
3.1.1. Per-ingress Spanning Tree
TBD
3.1.2. Per VLAN
TBD
3.1.3. Single Spanning Tree
TBD
3.2. Interactions with Spanning Tree Protocol Operation
RBridges MUST calculate a spanning tree for each broadcast domain. In
a campus without VLANs, this means a single spanning tree could be
used for delivery of packets with unknown or group address layer 2
destination.
While it is possible to support VLANs with a single spanning tree, and
just avoid forwarding the decapsulated packet onto links that do not
support that VLAN, the solution will allow for more optimal delivery
if a different spanning tree is calculated for each broadcast domain.
It is neither necessary, nor desirable, to use the bridge spanning tree
algorithm to calculate spanning trees. Instead, spanning trees SHOULD
be calculated based on the link state information. Using the link state
protocol to calculate spanning trees makes the design very flexible and
efficient. The link state database gives sufficient information so
that RBridges can calculate a single spanning tree, spanning trees
Gray Expires April 15, 2006 [Page 5]
Internet-Draft R-Bridge Routing Requirements August 2005
per VLAN, or per-ingress RBridge spanning trees without requiring any
additional exchange of information between RBridges.
3.3. R-Bridge Interactions with Routing
Because R-Bridges will need to participate in flooding, and will have
other significant differentiations in forwarding behavior, it may be
necessary 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.
4. 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 a requirement that RBridges need no configuration.
5. Conclusions
TBD
6. Acknowledgments
TBD
7. References
7.1. Normative References
[1] Touch, J., "Dynamic Internet overlay deployment and management
using the X-Bone", Computer Networks Vol. 36, No. 2-3, July
2001.
[2] Touch, J., Wang, Y., Eggert, L. and G. Finn, "A Virtual
Internet Architecture", ISI Technical Report ISI-TR-570,
Presented at the Workshop on Future Directions in Network
Architecture (FDNA) 2003 at Sigcomm 2003, March 2003.
Gray Expires April 15, 2006 [Page 6]
Internet-Draft R-Bridge Routing Requirements August 2005
7.2. Informative References
TBD
8. Author's Addresses
Eric Gray
Marconi Corporation, plc
900 Chelmsford Street,
Lowell, MA - 01851
Email: Eric.Gray@marconi.com
9. 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
10. 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.
Gray Expires April 15, 2006 [Page 7]
Internet-Draft R-Bridge Routing Requirements August 2005
11. Copyright Statement
Copyright (C) The Internet Society (2005).
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.
12. Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Gray Expires April 15, 2006 [Page 8]
