Yakov Rekhter Cisco Systems Dilip Kandlur T.J. Watson Research Center, IBM Corp. September 1995 Address Prefix Region and its application to Switched Data Link Subnetworks 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. A pair of hosts with the same network number communicate directly (with no routers); a pair of hosts with different network numbers always communicate through one or more routers. As indicated in RFC1620, these assumptions may be violated for large data networks, and specifically for networks based on switched virtual circuit (SVC) based technologies (e.g. ATM, X.25). The architecture works even when this assumption is violated, but it imposes constraints on communication among hosts and routers through a network, which in turn may preclude full utilization of the capabilities provided by the underlying SVC-based Data Link subnetwork. This document describes extensions to the IP architecture that relaxes these constraints, thus enabling the full utilization of the services provided by SVC-based Data Link subnetworks. The document also specifies how the proposed extensions could be used for other types of subnetworks. Expiration Date March 1996 [Page 1] INTERNET DRAFT September 1995 1 Background 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 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 resolves IP address to Link Layer address (e.g. by using ARP), 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 with a common network number are assumed to be attached to a common link (subnetwork), and thus communicate with each other directly, without any routers -- "local" hosts with different network numbers are assumed to be attached to different links (subnetworks), and thus communicate with each other only through routers -- "remote" A typical example of applying the IP subnet architecture to an SVC- based Data Link subnetwork is "Classical IP and ARP over ATM" (RFC1597). 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; for destinations outside its LIS the host must forward packets through a router. Important to stress that 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 Motivations 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. Expiration Date March 1996 [Page 2] INTERNET DRAFT September 1995 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). SVC-based Data Link subnetworks offer certain unique capabilities that are not present in other (non-SVC) subnetworks (e.g. Ethernet, Token Ring). The ability to dynamically establish and tear-down SVCs between communicating entities attached to an SVC-based Data Link subnetwork enables to dynamically dedicate and redistribute certain communication resources (e.g. bandwidth) among the entities. This dedication and redistribution of resources could be accomplished by relying solely on the mechanism(s) provided by the Data Link layer. The unique capabilities provided by SVC-based Data Link subnetworks do not come "for free". The mechanisms that provide dedication and redistribution of resources have certain overhead (e.g. the time needed to establish an SVC, resources associated with maintaining a state for an SVC). Therefore, it is very important to be cognizant of such an overhead and to carefully balance the benefits provided by the mechanisms against the overhead introduced by such mechanisms. One of the key issues for using SVC-based Data Link subnetworks in the TCP/IP environment is the issue of switched virtual circuit (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 with respect to the ability to efficiently exploit capabilities provided by the underlying Data Link layer. The traditional IP subnet model provides a poor match for flexible and adaptive use of the SVC-based Data Link subnetworks - the use of a subnetwork is driven by information completely unrelated to the characteristics of individual applications. To illustrate the problem consider "Classical IP and ARP over ATM" (RFC1597). 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 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, and has nothing to do with the nature of particular applications. Expiration Date March 1996 [Page 3] INTERNET DRAFT September 1995 3 QoS/Traffic Driven "Local/Remote" Decision To exploit capabilities provided by the SVC-based Data Link subnetworks we propose to allow SVC management to be directly controlled by applications, and more specifically by the QoS and/or traffic 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 SVC-based Data Link subnetwork, irrespective of hosts' IP addresses. Prudent use of the router-based infrastructure reduces unnecessary load on the SVC-based 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 SVC-based Data Link environment this decision should be driven solely by the applications and their QoS and/or traffic 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 SVC (direct 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 SVC (direct 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 Link Layer 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 Link Layer 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 Data Link subnetworks, or may be on a common Data Link subnetwork that is partitioned. Only the actual SVC establishment is sufficient to enable direct communication. If a host can not establish an SVC, the host may default (depending on the Expiration Date March 1996 [Page 4] INTERNET DRAFT September 1995 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. 4 Address Prefix Region (APR) To provide flexible and adaptive use of SVC-based Data Link subnetworks we proposed to replace the concept of a traditional IP subnet with the concept of an Address Prefix Region (APR). An Address Prefix Region (APR) can be formally defined by the following properties: An APR is a set of routers and hosts Every element in the set (either a host or a router) can establish direct communication (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 single IP address prefix; each element in the set knows the prefix 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 Expiration Date March 1996 [Page 5] INTERNET DRAFT September 1995 From an address assignment point of view an APR is identical to a traditional IP subnet (and in this sense it is identical to a LIS). The major difference between the two is the impact on the "local/remote" decision. 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 an APR should have no impact on the outcome of the "local/remote" decision made by the hosts within the APR. For the purpose of IP unicast forwarding the role of the APR 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. An APR would identify for a given set of hosts the set of routers that these hosts can use as their first hop (first-hop routers). For the purpose of IP layer broadcasts an APR provides a mechanism that is identical to the subnet directed broadcast. An IP packet is destined to all the elements of an APR if the destination address in the packet is equal to the IP address prefix of the APR. We'll refer to such a broadcast as an APR Directed Broadcast. An APR may have more than one router for redundancy. To select among several routers a host may use information provided by the Data Link layer (SVC teardown) as an indication of a "dead" router. Likewise, for a given router an APR would identify the set of hosts for which the router should serve as the last hop router. The APR could serve as a useful migration tool from the current (traditional IP subnet model) environment, as it provides backward compatibility for hosts that support only the traditional IP subnet model (e.g. hosts that support only "classic" IP over ATM model), while allowing the intermix of these hosts with modified hosts that support application driven "local/remote" decision. The APR could be used to implement administrative constraints on connectivity at the network (IP) layer. Finally, the APR may also be used to facilitate association of elements within an APR with various network layer servers (e.g. ARP Server, Multicast Server, etc...). Details of such an association are outside the scope of this document. 4.1 Host Modifications A host implementation should allow SVC management to be placed under control of applications (and be controlled by the QoS/traffic requirements of the applications). For an application whose QoS requirements could benefit from a direct SVC (direct connectivity), the host should attempt to establish an Expiration Date March 1996 [Page 6] INTERNET DRAFT September 1995 SVC, 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 Data Link layer) from the host (e.g. such a router may be one of the routers of the APR the host is in). For all other applications the host should forward data through one of the routers of the APR (as defined in this document) the host is in. For certain SVC-based Data Link technologies (e.g. ATM) application controlled SVC management could benefit if the information related to the top level application end points is carried in the SVC Setup messages. For example, in the case of ATM such information could be carried by the B-HLI IE (information element), as described in RFC1755. 4.2 Router Modifications When a router associated with a given APR (as defined in this document) receives an IP packet from a host in the APR that is destined to another host in the same APR, the router should forward the packet (if possible), and refrain from sending an ICMP Redirect message to the originating host. 5 Transition for ATM-based subnetworks Given that the LIS model outlined in RFC1577 is now being implemented by several vendors, it is instructive to consider how the architecture proposed in this document could be phased into the environment that supports RFC1577 in a backward compatible fashion. The APR model implies that packets among hosts within a common APR may traverse through a router associated with the APR. 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 APRs, as it requires the router to be configured with as many subnets as there are hosts in the APR. 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 an APR since it provides them with direct SVCs. A host could start with this default behavior and provide direct SVCs to destinations outside the APR only upon application (QoS) request. At a suitable time, Expiration Date March 1996 [Page 7] INTERNET DRAFT September 1995 when more applications become ATM aware and can explicitly request SVCs, the host can transition to the APR behavior. 6 Conclusions Different approaches to SVC-based Data Link subnetworks use by TCP/IP yield quite different results with respect to the ability of TCP/IP applications to efficiently exploit the functionality provided by such subnetworks. For example, in the case of ATM 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 SVC-based Data Link subnetworks. Enabling direct connectivity for applications that could benefit from the functionality provided by SVC-based Data Link subnetworks, while relying on routers for other applications, could facilitate exploration of the capabilities provided by the subnetworks. 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 to the environment proposed in this document. The proposed model utilizes the SVC-based infrastructure for the applications that could benefit from the capabilities supported within such infrastructure, 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 document 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. The concept of APR proposed in this document could be also applicable in a non-SVC based environment. 7 Security Considerations Security issues are not discussed in this document. Expiration Date March 1996 [Page 8] INTERNET DRAFT September 1995 8 Acknowledgements The authors would like to thank Joel Halpern (NewBridge), Allison Mankin (ISI), and Tony Li (cisco Systems) for their review and comments. 9 References [NHRP] Katz, D., Piscitello, D., "NBMA Next Hop Resolution Protocol (NHRP)", draft-ietf-rolc-nhrp-04.txt, May 1995. [Postel 81] Postel, J., Sunshine, C., Cohen, D., "The ARPA Internet Protocol", Computer Networks, 5, pp. 261-271, 1983. [RFC792] Postel, J., "Internet Control Message Protocol- DARPA Internet Program Protocol Specification", STD 5, RFC 792, ISI, September 1981. [RFC1122] Braden, R., Editor, "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, USC/ISI, October 1989. [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. 14 Authors' Address Yakov Rekhter Cisco Systems 170 West Tasman Drive, San Jose, CA 95134-1706 Phone: (914) 528-0090 email: yakov@cisco.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 March 1996 [Page 9]