ATM Forum/96-0352 PROJECT: ATM Forum Technical Committee **************************************************************************** SOURCE: Ross Callon Bay Networks 3 Federal Street Billerica, MA 01821 phone: +1-508-436-3936 email: rcallon@baynetworks.com George Swallow Cisco Systems 1100 Technology Park Drive Billerica, MA 01821 phone: +1-508-262-1143 email: swallow@cisco.com Loa Andersson Ericsson Telecon Business Unit Broadband S-126 25 Stockholm phone: +46 8 719 52 67 email: etxlooa@kk.ericsson.se Joel M. Halpern Newbridge Networks Corp. 593 Herndon Parkway Herndon, VA 22070-5241 phone: +1-703-708-5954 email: jhalpern@Newbridge.COM Bryan Gleeson Adaptec 691 South Milpitas Blvd Milpitas, CA 95035 phone: +1-408-945-8600 x3228 email: bryang@eng.adaptec.com Jason Jeffords Cabletron Technology Drive Durham, NH 03824 phone: +1-603-337-7019 email: jeffords@ctron.com Allwyn Sequeira First Virtual Corporation 3393 Octavius Drive Suite 102 Santa Clara, CA 95054 phone: +1-408-988-7070 fax: +1-408-988-7077 email: sequeira@fvc.com John Drake Fore Systems, Inc Research Park 5800 Corporate Park Pittsburgh, PA 15237 phone: +1-412-635-3356 email: drake@fore.com Andre Fredette IBM Corporation Research Triangle Park, NC phone: +1-919-254-7121 email: fredette@vnet.ibm.com Ed Sullivan Interphase Corporation 13800 Senlac Drive Dallas, Texas 75234 phone: +1-214-654-5264 email: sullivan@iphase.com **************************************************************************** Title: The Relationship between MPOA and Integrated PNNI **************************************************************************** DATE: April 15-19, 1996 -- Anchorage, Alaska, USA **************************************************************************** DISTRIBUTION: MPOA Subworking Group, PNNI Subworking Group **************************************************************************** ABSTRACT: This contribution discusses the relationship between MPOA and Integrated PNNI (I-PNNI). Specifically, we discuss the role that each protocol may play in a multiprotocol over ATM network. We note that MPOA and I-PNNI solve different aspects of this problem, and that MPOA and I-PNNI are compatible but independent protocols. It is expected that some multiprotocol over ATM network environments may make use of MPOA only, some may make use of I-PNNI only and still others may choose to use both together. This contribution is offered for informational purposes. **************************************************************************** NOTICE: This contribution has been prepared to assist the ATM Forum. This document is offered to the Forum as a basis for discussion, and is not a binding proposal on the contributors, nor on any other company. The statements contained herein are subject to change in form and content after further study. Specifically, we reserve the right to add to, amend, or modify the statements contained herein. **************************************************************************** 1. INTRODUCTION There is some confusion regarding the relationship between MPOA and Integrated PNNI. In some places it has been erroneously been suggested that MPOA and I-PNNI are contradictory or are alternative solutions to the same problem. This contribution attempts to clarify this confusion. We discuss the roles that MPOA and I-PNNI may play in a multiprotocol over ATM environment. We also point out possible alternatives to MPOA, as well as possible alternatives to I-PNNI. We conclude that MPOA and I-PNNI are compatible, although independent protocols. In some cases it is possible that MPOA may be used without I-PNNI. In other cases it is possible that I-PNNI may be used without MPOA. Finally, in some cases it is possible that MPOA and I- PNNI may be used together. MPOA defines methods for a Host to interact with routers or route servers over an ATM subnet, and for distributing routes from a route server to an edge device forwarder. However, MPOA is not a routing protocol. MPOA is compatible with a wide choice of routing protools, including I-PNNI and other routing protocols. I-PNNI is a routing protocol for ATM, for IP, and potentially for other internet level protocols. However, I-PNNI does not define host behavior, and is compatible with a range of host behaviors. Similarly, I-PNNI does not require, but is compatible with the separation of route server and edge device forwarding functions between different physical devices. Our conclusion is that MPOA and I-PNNI are fully compatible, and that they may be used together. Thus it is perfectly reasonable and sensible for the ATM Forum to be working on specifications for both simultaneously. Note that in the following text, the term "IP over ATM" is used as an example of a multiprotocol over ATM environment and is not intended to apply only to use of the Internet Protocol. 2. MPOA and INTEGRATED PNNI This section presents brief overviews of MPOA and Integrated PNNI. It is intended here only to provide the shortest possible overviews. More complete descriptions of MPOA and I-PNNI, as well as options for routing in an IP over ATM environment, are provided by the references [1-6]. 2.1 A Very Brief Outline of MPOA The MPOA working group in the ATM Forum [1,2] is defining a set of behaviors and protocol usage for ATM hosts, route servers and edge devices to interoperate over an ATM fabric. It defines a single unified host behavior for ATM-attached hosts (compatible with, and based on LAN Emulation, NHRP, and other relevant standards). The MPOA group is also defining techniques for the operation of a "virtual router", in which route computation functions may be performed in separate physical boxes (route servers) from the packet forwarding functions (edge devices). MPOA makes use of and clarifies the relationship between a number of existing techniques developed by the ATM Forum and IETF. This includes how LAN Emulation fits in to provide emulation and virtualization of individual "subnets", how to set up shortcut virtual circuits between members of different subnets, and how NHRP-capable hosts fit in to the environment. To support layer 3 multicast, the MPOA group is adopting the multicast address resolution server (MARS) developed by the IETF. ATM Hosts These make use of the NHRP protocol defined by IETFÕs routing-over- large-clouds group: Rules are defined regarding how to use this protocol to resolve destination addresses both on the same and on different subnets. LAN Emulation may be used to reach destinations on the same subnet. Configuration protocols for these hosts are also defined. Virtual Routers Mechanisms are being defined to allow the various functions required in an IP over ATM router to be logically separated. For example, route server functions, consisting of running one (or more) IP-level routing protocol(s) in order to build and maintain a forwarding table, are logically (and may be physically) separated from the IP packet forwarding functions. The term "virtual router" refers to the case where these two logical functions are implemented in separate physical devices. Again, the NHRP protocol is used, with enhancements to ensure "safe" forwarding of data without persistent loops. As such, the virtual router aspects of MPOA allows some of the physical devices which take part in IP forwarding to avoid running a routing protocol. One implementation choice of MPOA would be to put the route server functions (i.e. operation of some IP-level routing protocol) into each physical IP forwarding device. We will call these devices conventional routers. Through the use of MPOA-defined virtual routers, it is possible that *some* of the devices which take part in IP forwarding (specifically MPOA edge devices) will not run an IP level routing protocol. However, MPOA assumes that a routing protocol will be running between route servers for each layer 3 protocol supported. MPOA does not specify any particular routing protocol. It is designed to run with any routing protocol. As an example, if you have multiple route servers, you need to run a routing protocol between them: Each route server needs to tell the other route servers which IP addresses it can reach, whether directly or indirectly. If you have a route server and one or more conventional routers (whether ATM- attached or not), then again you need an IP level routing protocol between the route servers and the routers. Evaluation of the relative advantages of virtual routers versus conventional routers is outside of the scope of this contribution. However, we expect that each will be used in some cases. 2.2 A Very Brief Outline of I-PNNI. I-PNNI [3] is a routing protocol which can compute paths for IP packets as well as for ATM SVCs. I-PNNI may be used by routers and by route servers. I- PNNI is also compatible with ATM switches which are running ATM Forum PNNI phase 1 for SVC routing. This implies that the routers and route servers can make their routing decisions with a knowledge of the combined router/route server/edge-device/ATM topology. I-PNNI also allows a single routing protocol to be used for ATM and IP simultaneously. I-PNNI allows QoS-based routes to be calculated for ATM, and allows Type of Service (ToS) and Quality of Service (QoS) routes to be calculated for IP packets over a combination of ATM and legacy links (for more details see [5]). Note that ToS based routes refers to routing of different IP packets based on the TOS bits included in the IP header. QoS based routes refers to more general quality of service routing, such as intentionally routing two different IP flows, each requiring a certain dedicated bandwidth, via different routes in order to avoid interference between the flows. The issue of mapping specific IP packets to QoS-sensitive routes needs to be addressed by a combination of I-PNNI and other efforts. I-PNNI is basically PNNI plus IP-level reachability information. It does what a routing protocol does, i.e. it calculates routes between devices advertised in the routing protocol. An alternative to I-PNNI is to run separate routing protocols for ATM and for IP. This is known as "layered routing". For example, in an IP over ATM environment, it is possible to run OSPF for IP routing and to simultaneously run PNNI Phase 1 for ATM SVC routing. This would, of course, require that the capabilities of the ATM subnet be modeled for the purpose of allowing OSPF to consider the possibility of forwarding IP packets over ATM. Evaluation of the relative advantages of integrated PNNI versus layered routing is outside of the scope of this paper. However, we expect that each will be used in some cases. In general, the vast majority of hosts should not be involved in the operation of routing protocols (neither IP-level nor ATM-level routing protocols). ATM-attached hosts will make use of standards such as RFC 1577, LAN Emulation, NHRP, and/or the MPOA host behavior in order to define how hosts interact with routers and route servers. This is independent of whether I-PNNI or layerred routing is used in the network. 3. CONCLUSION Whether you put any IP-level routing protocol on each edge devices is pretty much independent of which IP routing protocol you use. Possible questions to be answered for any particular IP over ATM Network environment include: (1) What routing protocol to use for ATM SVCs? If you want a multi-vendor standard, then the only available answer in a private ATM network is PNNI. (2) What devices in the network run an IP-level routing protocol? There are two possible answers: (a) "All things that act as intermediate systems forwarding IP packets". This means that conventional routers are used. (b) "Route servers and some (but not necessarily all), of the things which act as intermediate systems forwarding IP packets". This means that virtual routers are used. Note that virtual routers and conventional routers may be used simultaneously in the same network if desired. In fact, it is to be expected that in some cases a single physical device will serve as both a conventional router as well as a route server. (3) What routing protocol do you use for IP? Possible answers include "none", "I-PNNI", "OSPF layered over ATM" or "some other protocol layered over ATM". The answer of "none" only makes sense in a very small network. The first of these three questions only has one answer if you want an open standard. The other two questions allows multiple reasonable answers. The precise tradeoffs between the alternatives is outside of the scope of this contribution. However, we note that the possible solutions of "use MPOA virtual routers" and "use Integrated PNNI" are reasonable and compatible. We also note that the choice of routing protocol and of conventional versus virtual routers is independent of the protocols used for host to router and host to route server interaction. 4. REFERENCES [1] "Requirements for the MPOA protocol", ed. C.Brown, ATM Forum 95-0004R2, April 19, 1995. [2] MPOA Subworking group, "Baseline Text for MPOA", ed. C.Brown, ATM Forum 95-0824R6, February 1996. [3] PNNI Subworking group, "PNNI Draft Specification", ed. Cherukuri and Dykeman, ATM Forum 94-0471R15, January 1996. [4] "Methods for Routing of Internetwork Level Protocols over ATM", Callon et al., ATM Forum 96-0353, April 1996. [5] "Issues and Approaches for Integrated PNNI", R.Callon et al., ATM Forum 96-0355, April 1996. [6] "Routing in a Multiprotocol over ATM Environment", R.Callon, J.Halpern, J.Drake, H.Sandick, J.Jeffords, Connexions, March 1996.