Yakov Rekhter Cisco Systems Dilip Kandlur T.J. Watson Research Center, IBM Corp. November 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 IP architecture assumes that each Data Link subnetwork is labeled with a single IP subnet number. A pair of hosts with the same subnet number communicate directly (with no routers); a pair of hosts with different subnet numbers always communicate through one or more routers. As indicated in RFC1620, these assumptions may be too restrictive for large data networks, and specifically for networks based on switched virtual circuit (SVC) based technologies (e.g. ATM, Frame Relay, X.25), as these assumptions impose 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. 1 Background The following briefly recaptures the concept of the IP Subnet. The Expiration Date May 1996 [Page 1] INTERNET DRAFT November 1995 topology is assumed to be composed of links (Data Link subnetworks) interconnected via routers. An IP address of a host with an interface attached to a particular link is a tuple , where host number is unique within the subnet address prefix. 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 subnet address prefix are assumed to be attached to a common link (subnetwork), and thus communicate with each other directly, without any routers - "local"; hosts with different subnet address prefixes 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" (RFC1577). 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. It is 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. 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 generate a large volume of packets (e.g. Expiration Date May 1996 [Page 2] INTERNET DRAFT November 1995 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 the dynamic dedication and redistribution of 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). There may also be a monetary cost associated with establishing and maintaining 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 (on a common Data Link subnetwork) 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 is too restrictive for flexible and adaptive use of 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" (RFC1577). 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 no relation to the nature of the applications that generated these packets. 3 QoS/Traffic Driven "Local/Remote" Decision To exploit the capabilities provided by SVC-based Data Link Expiration Date May 1996 [Page 3] INTERNET DRAFT November 1995 subnetworks we propose to allow SVC management to be controlled by applications (through an appropriate API), 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 communication among the applications in the second category may rely on the router-based infrastructure (for example, one could hardly imagine establishing an SVC just to perform a single DNS query). The connection (an SVC) from a host to its first-hop router would then serve as a shared connection for many applications running on the host. This should apply to any pair of hosts connected to a common SVC- based Data Link subnetwork, irrespective of the 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 the overhead (e.g., delay and/or cost) 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 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 by the applications (through an appropriate API), and specifically by their QoS and/or traffic requirements and/or cost factors. For example, for a pair of hosts, A and B, both on a common switched Data Link subnetwork, 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 other cases (the default behavior) A should be able to deliver packets to B 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 Data Link subnetworks). The ability of a host to establish an SVC to a peer on a common switched Data Link subnetwork 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. If a host can not establish an SVC, the host may default (depending on the application) to sending data through routers. Expiration Date May 1996 [Page 4] INTERNET DRAFT November 1995 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). In the case when applications direct a "local" outcome, depending on the nature of the applications, a pair of hosts should be able to either multiplex packets from 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. To summarize, the "local/remote" decision may not be time invariant, may depend on factors other than the addresses of the source and the destination, and may involve either shared or dedicated SVCs. 4 Address Prefix Region (APR) To provide flexible and adaptive use of SVC-based Data Link subnetworks we propose to replace the concept of a Logical IP Subnet (LIS) with the concept of an Address Prefix Region (APR). An Address Prefix Region (APR) is a set of routers and hosts that meet all of the following properties: An APR must be fully contained within a single Data Link subnetwork, but a single Data Link subnetwork may include one or more APRs. 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 be aggregated into a single IP address prefix; each element in the set knows the prefix. Expiration Date May 1996 [Page 5] INTERNET DRAFT November 1995 All routers in the set advertise direct reachability to all the hosts in the set - any router in the set is one (1) IP hop away from any host in the set. From the point of view of address assignment an APR is identical to a LIS. The major difference between the two is the impact on the "local/remote" decision. Since formation of an APR should have no impact on the outcome of the "local/remote" decision made by the hosts within the APR, it allows the decoupling of the "local/remote" decision from the information provided by the IP addresses. 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 Data Link subnetwork, 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/last hop (first-hop/last-hop routers). At the same time, a host within a given APR is not restricted to use only the routers within its APR as its first-hop/last-hop routers. The host could use any router, whether in the same or in a different APR as the host, as its first- hop/last-hop router, provided that the router is on the same Data Link subnetwork as the host. Procedures by which a host could find such routers are outside the scope of this document. 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 shall 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 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 For an application whose QoS and/or traffic requirements could benefit from a direct SVC (direct connectivity), the host should Expiration Date May 1996 [Page 6] INTERNET DRAFT November 1995 attempt to establish an SVC, irrespective of the source and destination addresses. If such a connection can not be established, the host should 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, or may be some other router on the same Data Link subnetwork as the host). For all other applications the host may forward data through one of the routers of the APR (as defined in this document) the host is in. 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 Conclusions Different approaches to SVC-based Data Link subnetworks used by TCP/IP yield substantially 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 [LANE] 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 the full utilization of the functionality that ATM is expected to provide. It appears that any model that does not allow SVC management under control of applications, and specifically their QoS and/or traffic requirements 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. While this document does not define any specific coupling between various QoS, traffic characteristics and other parameters, and SVC management, it is important to stress that efforts towards standardization of various QoS, traffic characteristics, and other parameters than an application could use (through an appropriate API) to influence SVC management are essential for flexible and adaptive use of SVC-based Data Link 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 Expiration Date May 1996 [Page 7] INTERNET DRAFT November 1995 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 an 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. 6 Security Considerations Security issues are not discussed in this document. 7 Acknowledgements The authors would like to thank Joel Halpern (NewBridge), Allison Mankin (ISI), Tony Li (cisco Systems), Andrew Smith (BayNetworks), and Curtis Villamizar (ANS) for their review and comments. Appendix: 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. Expiration Date May 1996 [Page 8] INTERNET DRAFT November 1995 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, when more applications become ATM aware and can explicitly request SVCs, the host can transition to the APR behavior. References [LANE] "LAN Emulation over ATM specification- version 1", ATM Forum, Feb.95. [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 May 1996 [Page 9] INTERNET DRAFT November 1995 Expiration Date May 1996 [Page 10]