Network Working Group Keith Moore Internet-Draft Jason Cox Expires: 23 August 1996 Stan Green University of Tennessee 23 February 1996 SONAR - A Network Proximity Service draft-moore-sonar-01.txt 1. 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 and 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 ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract SONAR is a service which, when presented with a list of Internet Protocol addresses, attempts to order that list according to the proxim- ity from the SONAR server to each address. Given multiple locations for a network accessible resource, SONAR is designed to help networked applications make a reasonable choice between those alternatives. This memo describes the SONAR protocol as well as an experimental implementa- tion of the SONAR service. While the name ``SONAR'' is intended as a pun on the ``ping'' util- ity that uses ICMP echo requests to verify network connectivity, SONAR servers may employ other means besides ICMP echo requests to estimate network proximity. 3. Introduction One way to make a network-accessible resource available to a world- wide audience is to provide several copies (or mirrors) of that resource Moore/Cox/Green Expires 23 August 1996 [Page 1] SONAR 23 February 1996 at multiple locations. If a there are several locations from which a resource can be accessed, the user will obtain better service if a ``nearby'' location is chosen instead of a ``distant'' one. The SONAR service is designed to allow such a choice to be made by an application program. Given several alternative locations from which to access a resource, an application program can query a nearby SONAR server to determine which locations are closer than others. The SONAR server will return, for several of those locations, a metric which pro- vides a rough indication of the proximity of that location to the SONAR server. Using those metrics, the application can then choose a single location from which to access the resource. SONAR is designed as an alternative to building proximity estima- tion algorithms into different applications. By placing such function- ality into a separate network-accessible service, the proximity estima- tion algorithm can be tuned (in one place) to suit the requirements of a particular site. It also allows SONAR to evolve independently of the applications that use it. When a better proximity estimation algorithm is developed, a site can upgrade its SONAR server to allow its existing applications to take advantage of it. SONAR does not guarantee that it finds the ``best'' location of a resource, nor does it attempt to accurately measure proximity, either in terms of round-trip-time, hop count, or available bandwidth. Instead, the goal of SONAR is to provide a ``good'' choice without imposing a long delay and without consuming significant network resources in making that choice. If the time required to access a resource using SONAR is usually less than the time required to access the resource without it, or if the use of SONAR avoids the ``worst case'' selection, users will see SONAR as beneficial. Likewise, if the amount of network resources consumed by a SONAR server in measuring network proximity is less than the amount of resources that would be consumed when accessing a randomly chosen loca- tion, SONAR will improve the utilization of the network. 4. Protocol The first version of the SONAR protocol is intentionally as simple as possible while allowing extensibility for future needs. An application communicates with a SONAR server using UDP port 572. A SONAR query and response each consist of a single UDP datagram. In the descriptions below, all numeric quantities are in standard network byte order (``big-endian'' format, most significant byte transmitted first). Moore/Cox/Green Expires 23 August 1996 [Page 2] SONAR 23 February 1996 The format of a SONAR query is as follows: offset datum +----------------------+ 0 | protocol-version = 0 | +----------------------+ 4 | request-type = 0 | +----------------------+ 8 | request-id | +----------------------+ 12 | timeout.secs | +----------------------+ 16 | timeout.usecs | +----------------------+ 20 | count | +----------------------+ 24 | address[0] | +----------------------+ 28 | address[1] | +----------------------+ | ... | +----------------------+ 24+(count-1)*4 | address[count-1] | +----------------------+ The protocol-version is used to distinguish this version of the SONAR protocol from other versions. This document describes version 0 of the protocol. A SONAR server MUST check the version-number of each request and return a VERSION_MISMATCH response if that version is not supported. For SONAR version 0, the only valid request-type is 0, correspond- ing to a request for proximity information for one or more IP version 4 addresses. Future versions of SONAR may allow additional requests, including support for IP version 6 addresses. The request-id is any 4 bytes chosen by the client, and used to associate a response with the particular request that produced. The request-id will be included in the SONAR server's response. The timeout is the maximum number of seconds (4 bytes) and microseconds (4 bytes) which the SONAR server should wait before reply- ing. The server MAY return a response sooner than requested. A timeout of zero seconds and zero microseconds requests that the SONAR server return a response immediately, based on whatever proximity data it has at hand. Moore/Cox/Green Expires 23 August 1996 [Page 3] SONAR 23 February 1996 The count (4 bytes) is the number of addresses for which the SONAR client wants the server to determine relative proximity. The count may be any value between 1 and 185, inclusive. SONAR servers MUST ignore queries with a count of zero, and SHOULD ignore the 186th and later addresses in a query that contains more than 185 addresses. Following the count are that many Internet Protocol (v4) addresses. Version 0 of the SONAR service has two possible response formats. A SUCCESS response returned by the SONAR server is in the following for- mat: offset datum +----------------------------+ 0 | protocol-version = 0 | +----------------------------+ 4 | response-type = 0x80000000 | +----------------------------+ 8 | request-id | +----------------------------+ 12 | count | +----------------------------+ 16 | result-address[0] | +----------------------------+ 20 | metric[0] | +----------------------------+ 24 | result-address[1] | +----------------------------+ 28 | metric[1] | +----------------------------+ | ... | +----------------------------+ 16+(count-1)*8 | result-address[count-1] | +----------------------------+ 20+(count-1)*8 | metric[count-1] | +----------------------------+ Protocol-version will also be zero. For all versions of SONAR, the protocol-version of the response will match that of the request. (All response-types have their most significant bit set to 1, so that responses can be distinguished from queries.) For a SUCCESS response, response-type will be 0x80000000. The request-id in the response matches the one from the SONAR query. Moore/Cox/Green Expires 23 August 1996 [Page 4] SONAR 23 February 1996 The count is the number of IP addresses for which proximity data is being returned. The SONAR server MAY return fewer responses than the number of IP addresses for which proximity information was requested. The SONAR server SHOULD limit the amount of information returned (by discarding proximity estimates for distant hosts) so that the resulting datagram does not need to be fragmented. Following the count are several (address, metric) pairs. Each address is an IP address which appeared in the a query, and the metric is an unsigned 4 byte integer which indicates relative proximity of that host to the SONAR server. The addresses returned in a SONAR response are not in any particular order; the client must sort them if needed. The metrics are not necessarily in any particular units, and should be used only for comparison of locations returned within a single response. A FAILURE response is of the following form: offset datum +----------------------------+ 0 | protocol-version = 0 | +----------------------------+ 4 | response-type = 0xc0000000 | +----------------------------+ 8 | request-id | +----------------------------+ 12 | low-version | +----------------------------+ 16 | high-version | +----------------------------+ For a VERSION_MISMATCH response, response-type will be 0xc0000000. (All response-types indicating errors will have their two most signifi- cant bits set to 1.) Low-version is the lowest protocol version supported by the SONAR server. High-version is the highest protocol version supported by the server. 5. Finding a SONAR server SONAR complicates configuration of networked applications, because they need to know the address of one or more SONAR servers to use it. It is therefore desirable to minimize the burden of configuration. SONAR-aware applications should perform a DNS query of QTYPE=A on Moore/Cox/Green Expires 23 August 1996 [Page 5] SONAR 23 February 1996 the name ``sonar-server'' to determine if there are any SONAR servers defined for use by the local domain. (This assumes that DNS searches for unqualified names take place relative to the local domain.) Even though the local DNS hierarchy does not necessarily correspond to net- work topology, this approach will work well for many sites. Even if a ``sonar-server'' host is defined in DNS, it is desirable to allow the server to be overriden on a per-host, per-user, or per- process basis. For instance, on UNIX, a /etc/sonar-server file could contain names of SONAR servers to be used by that host in preference to those defined by DNS. These could be overriden for a user by defining a $HOME/.sonar-server file, or on a per-process basis by defining a SONAR_SERVER environment variable (note ``_'' instead of ``-''). Simi- lar techniques could be used by other operating systems. A future version of SONAR may support location of servers using IP broadcast. 6. Sample Implementation This section describes an initial implementation of a SONAR server merely as an example. Other implementations may use different proximity metrics, different methods for obtaining proximity data, and different algorithms for filtering that data; such implementations are encouraged. Our initial implementation of SONAR sends ICMP echo requests to each of the addresses for which a proximity measure is desired, and uses the time between when the request is sent, and when an ICMP echo reply is received, as its metric for evaluating relative proximity. Round- trip-time estimates obtained using ICMP are cached for a certain amount of time (currently several hours) so that subsequent SONAR queries within that time do not result in generation of additional ICMP requests. Any ICMP ``unreachable'' replies are also noted, though these are cached for a smaller amount of time. The implementation is straightforward: incoming queries are placed on a priority queue which is ordered by timeout value. (A maximum time- out value is imposed so that requests do not stay in the queue forever.) Proximity information about IP addresses is maintained in a hash table which includes the IP address, proximity metric, the time at which the metric was obtained, and a list of all queries which are waiting on proximity information for that address. A response is generated either when proximity data is available for each of the hosts in a query, or when a query times out. ICMP requests are currently sent to all addresses in a query for which there is not recent proximity data, and for which no ICMP echo requests have recently been sent. A SONAR query with a very small Moore/Cox/Green Expires 23 August 1996 [Page 6] SONAR 23 February 1996 timeout may still result in ICMP requests being sent to several of the addresses in that query (even though they could not possibly respond in time), and the proximity metrics thus obtained will be available on sub- sequent SONAR queries. The server ignores queries sent to any IP broadcast address, and ignores requests to obtain proximity information for any IP broadcast address. The server can also be configured to ignore requests not orig- inating from certain sets of addresses. 7. Security Considerations A naive implementation of SONAR could be used as a vehicle for a denial-of-service attack on a network, for instance, by requesting SONAR to probe multicast or broadcast addresses and thus generating large amounts of traffic. For this reason it is recommended that SONAR servers refuse to process queries sent to IP broadcast or multicast addresses, ignore requests to obtain proximity information for broadcast or multicast addresses, and perhaps to ignore requests from remote sites. Some sites use a ``firewall'' to filter ICMP echo requests from external sites for security reasons, even though other protocols such as ftp, http may be allowed. Such practices will make the hosts behind the firewall appear inaccessible to the authors' SONAR implementation. 8. Authors' addresses Keith Moore Jason Cox Stan Green University of Tennessee 107 Ayres Hall Knoxville, TN 37996-1301 USA A mailing list has been established to discuss the SONAR protocol and its implementation. To request a subscription to the list, send mail to sonar-request@cs.utk.edu. Moore/Cox/Green Expires 23 August 1996 [Page 7]