- 1 - Yakov Rekhter T.J. Watson Research Center, IBM Corp. Dilip Kandlur T.J. Watson Research Center, IBM Corp. January 1995 IP Architecture Extensions for ATM Status of this Memo This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract The original IP architecture assumes that each Data Link subnetwork is labeled with a single IP network number. As indicated in RFC1620, this assumption may be violated for large data networks, including ATM-based networks. The architecture works even when this assumption is violated, but it imposes constraints on communication among hosts and routers through an ATM-based network, which in turn may preclude full utilization of ATM capabilities. This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by ATM. 1. Introduction The following briefly recaptures the concept of the IP Subnet. The Internet architecture is based on the "Catenet model" [Postel:81]. The topology is assumed to be composed of links (Data Link Expiration Date July 1995 [Page 1] - 2 - subnetworks) interconnected via routers. Each link has a globally unique number. An IP address of a host with an interface attached to a particular link is a tuple , where host number is unique within the link. When a host needs to send an IP packet to a destination, the host needs to determine whether the destination address identifies an interface that is connected to one of the links the host is attached to ("local" decision), or not ("remote" decision). The outcome of the "local/remote" decision is based on (a) the source address, (b) the destination address, and (c) the subnet mask associated with the source address. If the outcome is "local", then the host uses ARP to determine the destination's MAC address, and then sends the packet directly to that destination (using the Link layer services). If the outcome is "remote", then the host uses one of its first-hop routers (thus relying on the services provided by IP routing). To summarize, two of the important attributes of the IP subnet model are: - hosts attached to a common link communicate with each other directly, without any routers -- "local" - hosts attached to different links communicate with each other only through routers -- "remote" RFC1577 provides support for ATM deployment that follows the traditional IP subnet model and introduces the notion of a Logical IP Subnetwork (LIS). The consequence of this model is that a host is required to setup an ATM SVC to any host within its LIS, and it must forward packets to destinations outside its LIS through a router. This "local/remote" decision is based solely on the information carried by the source and destination addresses and the subnet mask associated with the source address. 2. QoS Driven "Local/Remote" Decision The diversity of TCP/IP applications results in a wide range of traffic characteristics. Some applications last for a very short time and generate only a small number of packets between a pair of communicating hosts (e.g. ping, DNS). Other applications have a short lifetime, but generate a relatively large volume of packets (e.g. FTP). There are also applications that have a relatively long lifetime, but generate relatively few packets (e.g. Telnet). Finally, we anticipate the emergence of applications that have a relatively long lifetime and and generate a large volume of packets (e.g. video-conferencing). Expiration Date July 1995 [Page 2] - 3 - One of the key issues for ATM in the TCP/IP environment is the issue of switched virtual connection (SVC) management. This includes SVC establishment and tear-down, class of service specification, and SVC sharing. At one end of the spectrum one could require SVC establishment between communicating entities for any application. At the other end of the spectrum, one could require communicating entities to always go through a router, regardless of the application. Given the diversity of TCP/IP applications, either extreme is likely to yield a suboptimal solution. The "classical" IP over ATM model (as specified in RFC1577) provides a poor match for flexible and adaptive use of the ATM fabric -- the use is not driven by the characteristics of individual applications. RFC1577 provides support for ATM deployment that follows the traditional IP subnet model, and introduces the notion of a Logical IP Subnetwork (LIS). The consequence of this model is that a host is required to setup an ATM SVC to any host within its LIS, and it must forward packets to destinations outside its LIS through a router. This "local/remote" decision is based solely on the information carried in the source and destination addresses and the subnet mask associated with the source address. We propose to allow SVC management to be directly controlled by applications, and more specifically by the QoS requirements of the applications. It is apparent that while the service requirements of some IP applications could justify the establishment of a dedicated SVC (e.g. applications that require high bandwidth and/or network resource reservations), other applications could be served with a shared connection. To reduce the overhead associated with the establishment and maintenance of SVCs, as well as to improve performance of short-lived applications, we propose that applications in the second category should rely on the router-based infrastructure (for example, one could hardly imagine establishing an SVC just to perform a single DNS query). The connection to the router would then serve as a shared connection for many applications. This should apply to any pair of hosts connected to a common ATM fabric, irrespective of hosts' IP addresses. Prudent use of the router-based infrastructure reduces unnecessary load on the ATM infrastructure, and at the same time will eliminate delay associated with SVC establishment, thus benefiting both the network and the applications. We propose certain modifications to the existing IP model in order to support both the applications with QoS requirements that could justify a dedicated SVC, and applications that would rely on the router-based infrastructure. While in the conventional ("classical") IP environment the "local/remote" decision is based on the information provided by the IP addresses, we propose that in the ATM environment this decision should be driven solely by the applications and their QoS requirements, (rather than by the information carried in the addresses). For example, an application running on a host A should be able to specify whether it desires a direct ATM Expiration Date July 1995 [Page 3] - 4 - connectivity to its peer on a host B ("local" decision), and in this case an SVC will be established (if possible) between A and B; in all other cases (the default behavior) packets from A to B will traverse through one or more IP routers ("remote" decision). The default behavior also covers the case where an application may desire a direct ATM connectivity, but such connectivity is unavailable (e.g. hosts are on different fabrics). The ability of a host to establish an SVC to a peer is predicated on its knowledge of the ATM MAC address of the peer. This document assumes the existence of mechanism(s) that can provide the host with this information. Some of the possible alternatives are NHRP, ARP, or static configuration; other alternatives are not precluded. The ability to acquire the ATM MAC address of the peer should not be viewed as an indication that the host and the peer can establish an SVC -- the two may be on different ATM networks, or may be on a common ATM network that is partitioned. If a host can not establish an SVC, the host may default (depending on the application) to sending data through routers. One important implication of this proposal is that in contrast with the conventional IP environment, the "local/remote" decision may no longer be time invariant. While at one moment a pair of hosts (e.g. A and B) may have an SVC between them (e.g. when there is a video- conference running between the hosts) and thus will be viewed as "local" to each other, at some later point in time communication between exactly the same pair of hosts (e.g. A and B) will be done through one or more routers (after the video-conference ends, and someone would decide to run ping) and thus will viewed as "remote". In addition to being time dependent, the "local/remote" decision may yield both "local" and "remote" outcome simultaneously. This is because a set of hosts may concurrently run multiple applications, where some of these applications could justify an SVC establishment (thus resulting in a "local" outcome), while others will rely on router-based infrastructure (thus resulting in a "remote" outcome). Even if when applications yields "local" outcome, depending on the nature of the applications a pair of hosts should be able to either multiplex several applications over a single SVC, or establish dedicated SVCs on a per application basis or both. In the case where an SVC is shared among several applications care must be taken to ensure fair sharing of the resources provided by the SVC. For example, while it may be acceptable to share a single SVC for multiple FTP sessions between a pair of hosts, sharing an SVC for an FTP session and a video-conference is likely to be more problematic. Expiration Date July 1995 [Page 4] - 5 - 2. Redefining the LIS Concept To provide flexible and adaptive use of ATM we proposed to redefine the concept and semantics of a LIS. If we are to completely decouple the "local/remote" decision from the information provided by the IP addresses, and base it solely on the applications, it follows that formation of a LIS should have no impact on the outcome of the "local/remote" decision made by the hosts within the LIS. The new role of the LIS is to act as a mechanism to associate a set of hosts with one or more routers that these hosts could use to establish connectivity (reachability) with (a) destinations that are not on a common fabric, or (b) destinations for applications that don't justify an SVC. A LIS would identify for a given set of hosts the set of routers that these hosts can use as their first hop (first-hop routers). A LIS may have more than one router for redundancy. To select among several routers a host may use ATM information (SVC teardown) as an indication of a "dead" router. Likewise, for a given router a LIS would identify the set of hosts for which the router should serve as the last hop router. The LIS could also serve as a useful migration tool from the current environment, as it provides backward compatibility for hosts that support only the "classic" IP over ATM model, while allowing the intermix of these hosts with modified hosts that support application driven "local/remote" decision. Finally, the LIS could be used to implement administrative constraints on connectivity at the network (IP) layer. Hence, our new model for a LIS can be formally defined by the following properties: - A LIS is a set of routers and hosts - Every element in the set (either a host or a router) can establish an SVC with every other element in the set - IP addresses of the hosts in the set are assigned in such a way that they can aggregated into a small number of IP address prefixes - All routers in the set advertise direct reachability to all the hosts in the set -- any router in the set is 1 IP hop away from any host in the set 2.1 Host Modifications A host implementation should allow SVC management to be placed under control of applications (and be controlled by the QoS requirements of the applications). Expiration Date July 1995 [Page 5] - 6 - For an application whose QoS requirements could benefit from a direct ATM connectivity, the host should attempt to establish the ATM connection, irrespective of the source and destination addresses. If such a connection can not be established, the host should (under the control of the application) forward data through a router that is reachable (at the ATM layer) from the host (e.g. such a router may be one of the routers of the LIS the host is in). For all other applications the host should forward data through one of the routers of the LIS (as defined in this document) the host is in. Application controlled SVC management could benefit if the information related to the top level application end points is carried in the ATM Setup messages. Such information could be carried by the B-HLI IE (information element), as described in RFC1755. 2.2 Router Modifications When a router associated with a given LIS (as defined in this document) receives an IP packet from a host in the LIS that is destined to another host in the same LIS, the router should forward the packet (if possible), and refrain from sending an ICMP Redirect message to the originating host. 3. Transition Given that the LIS model outlined in RFC1577 is now being implemented by several vendors, it is instructive to consider how the architecture lroposed in this document could be phased into the environment that supports RFC1577 in a backward compatible fashion. The new LIS model implies that packets among hosts within a common LIS may traverse through a router associated with the LIS. Typically, such forwarding would result in the generation of ICMP Redirect messages from the router to the source. As a first step, the new host may be configured to quietly ignore these messages. It should also be possible to eliminate Redirect messages by specifying multiple subnets per interface of a router, so that while every host would have a subnet in common with the router, no two hosts attached to the router will be on a common subnet. This approach may not scale to large LISs, as it requires the router to be configured with as many subnets as there are hosts in the LIS. A better long-term solution is to configure the router to suppress the generation of ICMP Redirect messages. Another dimension to be considered is that of a phased migration of applications within a host. As mentioned before, the RFC1577 LIS concept can benefit existing applications communicating within a LIS Expiration Date July 1995 [Page 6] - 7 - since it provides them with direct SVCs. A host could start with this default behavior and provide direct SVCs to destinations outside the LIS only upon application (QoS) request. At a suitable time, when more applications become ATM aware and can explicitly request SVCs, the host can transition to the new LIS behavior. 4. Conclusions Different approaches to ATM deployment yield quite different results with respect to the ability of TCP/IP applications to fully exploit ATM functionality. Both LAN Emulation and "classical" IP over ATM (RFC1577) localize host changes below the IP layer, and therefore may be good first steps in the ATM deployment. However, these approaches are likely to be inadequate for full utilization of functionality that ATM is expected to provide. It seems that any model that doesn't allow SVC management under direct control of applications (QoS) is likely to curtail efficient use of ATM. Enabling direct connectivity for applications that could benefit from ATM, while relying on routers for other applications, could facilitate exploration of ATM capabilities. Essential to the deployment of the proposed approach is to develop migration strategies that would provide graceful transition based on small incremental changes from the current environment (either LAN Emulation or "classical" IP over ATM) to the environment proposed in this document. The proposed model utilizes the ATM infrastructure for the applications that could benefit from ATM capabilities, and creates a router-based overlay for all other applications. As such it provides a balanced mix of router-based and switch-based infrastructures, where the balance could be determined by the applications requirements. The approach proposed in this paper combines switch-based infrastructure with router-based overlay and uses each for that which it is best suited: switch-based infrastructure for applications that can justify an SVC establishment; router-based overlay for all other applications. 5 Security Considerations Security issues are not discussed in this document. Expiration Date July 1995 [Page 7] - 8 - 6 Acknowledgements The authors would like to thank Joel Halpern (NewBridge) and Allison Mankin (ISI) for their review and comments. 7 References [NHRP] Katz, D., Piscitello, D., "NBMA Next Hop Resolution Protocol (NHRP)", draft-ietf-rolc-nhrp-03.txt, November 1994. [Postel 81] Postel, J., Sunshine, C., Cohen, D., "The ARPA Internet Protocol", Computer Networks, 5, pp. 261-271, 1983. [RFC1577] Laubach, M., "Classical IP and ARP over ATM", January 1994. [RFC1620] Braden, B., Postel, J., Rekhter, Y., Internet Architecture Extensions for Shared Media", May 1994. [RFC1755] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., Malis, A., "ATM Signalling Support for IP over ATM", January 1995. 7 Authors' Address Yakov Rekhter T.J. Watson Research Center IBM Corporation P.O. Box 704 Yorktown Heights, NY 10598 Phone: (914) 784-7361 email: yakov@watson.ibm.com Dilip Kandlur T.J. Watson Research Center IBM Corporation P.O. Box 704 Yorktown Heights, NY 10598 Phone: (914) 784-7722 email: kandlur@watson.ibm.com Expiration Date July 1995 [Page 8]