Network Working Group R. Cole Request for Comments: 1932 D. Shur Category: Informational AT&T Bell Laboratories C. Villamizar ANS April 1996 IP over ATM: A Framework Document Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract The discussions of the IP over ATM working group over the last several years have produced a diverse set of proposals, some of which are no longer under active consideration. A categorization is provided for the purpose of focusing discussion on the various proposals for IP over ATM deemed of primary interest by the IP over ATM working group. The intent of this framework is to help clarify the differences between proposals and identify common features in order to promote convergence to a smaller and more mutually compatible set of standards. In summary, it is hoped that this document, in classifying ATM approaches and issues will help to focus the IP over ATM working group's direction. 1. Introduction The IP over ATM Working Group of the Internet Engineering Task Force (IETF) is chartered to develop standards for routing and forwarding IP packets over ATM sub-networks. This document provides a classification/taxonomy of IP over ATM options and issues and then describes various proposals in these terms. The remainder of this memorandum is organized as follows: o Section 2 defines several terms relating to networking and internetworking. o Section 3 discusses the parameters for a taxonomy of the different ATM models under discussion. o Section 4 discusses the options for low level encapsulation. Cole, Shur & Villamizar Informational [Page 1] RFC 1932 IP over ATM: A Framework Document April 1996 o Section 5 discusses tradeoffs between connection oriented and connectionless approaches. o Section 6 discusses the various means of providing direct connections across IP subnet boundaries. o Section 7 discusses the proposal to extend IP routing to better accommodate direct connections across IP subnet boundaries. o Section 8 identifies several prominent IP over ATM proposals that have been discussed within the IP over ATM Working Group and their relationship to the framework described in this document. o Section 9 addresses the relationship between the documents developed in the IP over ATM and related working groups and the various models discussed. 2. Definitions and Terminology We define several terms: A Host or End System: A host delivers/receives IP packets to/from other systems, but does not relay IP packets. A Router or Intermediate System: A router delivers/receives IP packets to/from other systems, and relays IP packets among systems. IP Subnet: In an IP subnet, all members of the subnet are able to transmit packets to all other members of the subnet directly, without forwarding by intermediate entities. No two subnet members are considered closer in the IP topology than any other. From an IP routing and IP forwarding standpoint a subnet is atomic, though there may be repeaters, hubs, bridges, or switches between the physical interfaces of subnet members. Bridged IP Subnet: A bridged IP subnet is one in which two or more physically disjoint media are made to appear as a single IP subnet. There are two basic types of bridging, media access control (MAC) level, and proxy ARP (see section 6). A Broadcast Subnet: A broadcast network supports an arbitrary number of hosts and routers and additionally is capable of transmitting a single IP packet to all of these systems. A Multicast Capable Subnet: A multicast capable subnet supports a facility to send a packet which reaches a subset of the destinations on the subnet. Multicast setup may be sender Cole, Shur & Villamizar Informational [Page 2] RFC 1932 IP over ATM: A Framework Document April 1996 initiated, or leaf initiated. ATM UNI 3.0 [4] and UNI 3.1 support only sender initiated while IP supports leaf initiated join. UNI 4.0 will support leaf initiated join. A Non-Broadcast Multiple Access (NBMA) Subnet: An NBMA supports an arbitrary number of hosts and routers but does not natively support a convenient multi-destination connectionless transmission facility, as does a broadcast or multicast capable subnetwork. An End-to-End path: An end-to-end path consists of two hosts which can communicate with one another over an arbitrary number of routers and subnets. An internetwork: An internetwork (small "i") is the concatenation of networks, often of various different media and lower level encapsulations, to form an integrated larger network supporting communication between any of the hosts on any of the component networks. The Internet (big "I") is a specific well known global concatenation of (over 40,000 at the time of writing) component networks. IP forwarding: IP forwarding is the process of receiving a packet and using a very low overhead decision process determining how to handle the packet. The packet may be delivered locally (for example, management traffic) or forwarded externally. For traffic that is forwarded externally, the IP forwarding process also determines which interface the packet should be sent out on, and if necessary, either removes one media layer encapsulation and replaces it with another, or modifies certain fields in the media layer encapsulation. IP routing: IP routing is the exchange of information that takes place in order to have available the information necessary to make a correct IP forwarding decision. IP address resolution: A quasi-static mapping exists between IP address on the local IP subnet and media address on the local subnet. This mapping is known as IP address resolution. An address resolution protocol (ARP) is a protocol supporting address resolution. In order to support end-to-end connectivity, two techniques are used. One involves allowing direct connectivity across classic IP subnet boundaries supported by certain NBMA media, which includes ATM. The other involves IP routing and IP forwarding. In essence, the former technique is extending IP address resolution beyond the boundaries of the IP subnet, while the latter is interconnecting IP subnets. Cole, Shur & Villamizar Informational [Page 3] RFC 1932 IP over ATM: A Framework Document April 1996 Large internetworks, and in particular the Internet, are unlikely to be composed of a single media, or a star topology, with a single media at the center. Within a large network supporting a common media, typically any large NBMA such as ATM, IP routing and IP forwarding must always be accommodated if the internetwork is larger than the NBMA, particularly if there are multiple points of interconnection with the NBMA and/or redundant, diverse interconnections. Routing information exchange in a very large internetwork can be quite dynamic due to the high probability that some network elements are changing state. The address resolution space consumption and resource consumption due to state change, or maintenance of state information is rarely a problem in classic IP subnets. It can become a problem in large bridged networks or in proposals that attempt to extend address resolution beyond the IP subnet. Scaling properties of address resolution and routing proposals, with respect to state information and state change, must be considered. 3. Parameters Common to IP Over ATM Proposals In some discussion of IP over ATM distinctions have made between local area networks (LANs), and wide area networks (WANs) that do not necessarily hold. The distinction between a LAN, MAN and WAN is a matter of geographic dispersion. Geographic dispersion affects performance due to increased propagation delay. LANs are used for network interconnections at the the major Internet traffic interconnect sites. Such LANs have multiple administrative authorities, currently exclusively support routers providing transit to multihomed internets, currently rely on PVCs and static address resolution, and rely heavily on IP routing. Such a configuration differs from the typical LANs used to interconnect computers in corporate or campus environments, and emphasizes the point that prior characterization of LANs do not necessarily hold. Similarly, WANs such as those under consideration by numerous large IP providers, do not conform to prior characterizations of ATM WANs in that they have a single administrative authority and a small number of nodes aggregating large flows of traffic onto single PVCs and rely on IP routers to avoid forming congestion bottlenecks within ATM. The following characteristics of the IP over ATM internetwork may be independent of geographic dispersion (LAN, MAN, or WAN). o The size of the IP over ATM internetwork (number of nodes). o The size of ATM IP subnets (LIS) in the ATM Internetwork. Cole, Shur & Villamizar Informational [Page 4] RFC 1932 IP over ATM: A Framework Document April 1996 o Single IP subnet vs multiple IP subnet ATM internetworks. o Single or multiple administrative authority. o Presence of routers providing transit to multihomed internets. o The presence or absence of dynamic address resolution. o The presence or absence of an IP routing protocol. IP over ATM should therefore be characterized by: o Encapsulations below the IP level. o Degree to which a connection oriented lower level is available and utilized. o Type of address resolution at the IP subnet level (static or dynamic). o Degree to which address resolution is extended beyond the IP subnet boundary. o The type of routing (if any) supported above the IP level. ATM-specific attributes of particular importance include: o The different types of services provided by the ATM Adaptation Layers (AAL). These specify the Quality-of-Service, the connection-mode, etc. The models discussed within this document assume an underlying connection-oriented service. o The type of virtual circuits used, i.e., PVCs versus SVCs. The PVC environment requires the use of either static tables for ATM-to-IP address mapping or the use of inverse ARP, while the SVC environment requires ARP functionality to be provided. o The type of support for multicast services. If point-to-point services only are available, then a server for IP multicast is required. If point-to-multipoint services are available, then IP multicast can be supported via meshes of point-to-multipoint connections (although use of a server may be necessary due to limits on the number of multipoint VCs able to be supported or to maintain the leaf initiated join semantics). o The presence of logical link identifiers (VPI/VCIs) and the various information element (IE) encodings within the ATM SVC signaling specification, i.e., the ATM Forum UNI version 3.1. Cole, Shur & Villamizar Informational [Page 5] RFC 1932 IP over ATM: A Framework Document April 1996 This allows a VC originator to specify a range of "layer" entities as the destination "AAL User". The AAL specifications do not prohibit any particular "layer X" from attaching directly to a local AAL service. Taken together these points imply a range of methods for encapsulation of upper layer protocols over ATM. For example, while LLC/SNAP encapsulation is one approach (the default), it is also possible to bind virtual circuits to higher level entities in the TCP/IP protocol stack. Some examples of the latter are single VC per protocol binding, TULIP, and TUNIC, discussed further in Section 4. o The number and type of ATM administrative domains/networks, and type of addressing used within an administrative domain/network. In particular, in the single domain/network case, all attached systems may be safely assumed to be using a single common addressing format, while in the multiple domain case, attached stations may not all be using the same common format, with corresponding implications on address resolution. (See Appendix A for a discussion of some of the issues that arise when multiple ATM address formats are used in the same logical IP subnet (LIS).) Also security/authentication is much more of a concern in the multiple domain case. IP over ATM proposals do not universally accept that IP routing over an ATM network is required. Certain proposals rely on the following assumptions: o The widespread deployment of ATM within premises-based networks, private wide-area networks and public networks, and o The definition of interfaces, signaling and routing protocols among private ATM networks. The above assumptions amount to ubiquitous deployment of a seamless ATM fabric which serves as the hub of a star topology around which all other media is attached. There has been a great deal of discussion over when, if ever, this will be a realistic assumption for very large internetworks, such as the Internet. Advocates of such approaches point out that even if these are not relevant to very large internetworks such as the Internet, there may be a place for such models in smaller internetworks, such as corporate networks. The NHRP protocol (Section 8.2), not necessarily specific to ATM, would be particularly appropriate for the case of ubiquitous ATM deployment. NHRP supports the establishment of direct connections across IP subnets in the ATM domain. The use of NHRP does not require ubiquitous ATM deployment, but currently imposes topology constraints to avoid routing loops (see Section 7). Section 8.2 Cole, Shur & Villamizar Informational [Page 6] RFC 1932 IP over ATM: A Framework Document April 1996 describes NHRP in greater detail. The Peer Model assumes that internetwork layer addresses can be mapped onto ATM addresses and vice versa, and that reachability information between ATM routing and internetwork layer routing can be exchanged. This approach has limited applicability unless ubiquitous deployment of ATM holds. The peer model is described in Section 8.4. The Integrated Model proposes a routing solution supporting an exchange of routing information between ATM routing and higher level routing. This provides timely external routing information within the ATM routing and provides transit of external routing information through the ATM routing between external routing domains. Such proposals may better support a possibly lengthy transition during which assumptions of ubiquitous ATM access do not hold. The Integrated Model is described in Section 8.5. The Multiprotocol over ATM (MPOA) Sub-Working Group was formed by the ATM Forum to provide multiprotocol support over ATM. The MPOA effort is at an early stage at the time of this writing. An MPOA baseline document has been drafted, which provides terminology for further discussion of the architecture. This document is available from the FTP server ftp.atmf