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]