Network Working Group Keith Moore Internet-Draft University of Tennessee Expires: 8 October 1998 8 April 1998 SONAR - A Network Proximity Service draft-moore-sonar-02.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 view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (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, the SONAR service does not specify use of any particular means of estimating network proximity. To the contrary, the design of SONAR assumes that the best means of estimating network proximity will change over time and perhaps from one network location to another. The SONAR protocol is intended to provide a stable interface for applications that need to measure network proximity, thus allowing proximity measurement algo- rithms to evolve separately from those applications. K. Moore Expires 8 October 1998 [Page 1] SONAR 8 April 1998 3. Introduction One way to make a network-accessible resource available to a large, and perhaps geographically distributed audience is to provide several replicas (or ``mirrors'') of that resource at multiple locations. If a there are several locations from which a resource can be accessed, and either bandwidth or response-time is important to the user's perceived quality of service, the user will often obtain better service if a ``nearby'' location of that resource is favored over 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 each of several applications. By placing such functionality into a separate network-accessible service, the proximity estimation algorithm can be tuned (in one place) to suit the require- ments of a particular site. It also allows SONAR to evolve indepen- dently of the applications that use it. When better proximity estima- tion algorithms are developed, a site or ISP can upgrade its SONAR servers to allow its existing applications to take advantage of those improvements. SONAR does not guarantee that it finds the ``best'' location of a resource, nor does it attempt to accurately measure proximity in terms of round-trip-time, hop count, available bandwidth, or any other metric. 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, and if the use of SONAR avoids the ``worst case'' selection, users will see SONAR as beneficial. Likewise, if the amount of network resources con- sumed by a SONAR server in measuring network proximity is less than the amount of resources that would be consumed when accessing a randomly chosen location, SONAR will improve the utilization of the network. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document, when they appear in all capital letters, are to be interpreted as described in RFC 2119. K. Moore Expires 8 October 1998 [Page 2] SONAR 8 April 1998 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). 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. It is expected that future versions of SONAR will define additional request types; for example, a query which supports IPv6 addresses and/or allows the user to request a particular kind of K. Moore Expires 8 October 1998 [Page 3] SONAR 8 April 1998 proximity estimation (RTT vs. bandwidth). This memo documents the for- mat of the SONAR query for request-type 0 only. The format of the por- tion of the SONAR query following the count field will be different for requests other than type 0. 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. 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: K. Moore Expires 8 October 1998 [Page 4] SONAR 8 April 1998 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. 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 if nec- essary to prevent the resulting datagram from being fragmented. If a SONAR returns fewer responses than requested, it SHOULD return the prox- imity estimates of the nearest hosts, discarding the estimates of those that appear to be the most distant. However, a server which has several cached proximity estimates from among those requested MAY return esti- mates for some subset of the cached estimates without estimating proxim- ity for all hosts requested. K. Moore Expires 8 October 1998 [Page 5] SONAR 8 April 1998 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. Caveats Since different SONAR servers may employ different proximity esti- mation algorithms, metrics obtained from one SONAR server should not be compared with those obtained from a different server. Similarly, met- rics obtained from SONAR should not be cached by an application for any significant amount of time. An application should normally be configured (by whatever means) to use one or more SONAR servers that have a similar view of the network to that application. However, for the case of an application running on a single host which is separated from the rest of the Internet by a slow pipe, where all of the resources of interest are on the ``well-con- nected'' side of the link (e.g. a modem dialup connection) the SONAR K. Moore Expires 8 October 1998 [Page 6] SONAR 8 April 1998 server should normally be located on the ``well-connected'' side. In general, applications which examine raw IP addresses may be con- fused by network address translation (NAT) devices. In particular, applications that use SONAR may be confused if the application and SONAR server are on different sides of a NAT box. In the case where a NAT box dynamically maps 'global' addresses onto some set of 'local' addresses which can be reused (e.g. when mapping global IPv6 addresses onto a local IPv4 network), an application using SONAR will also be confused if the combination of the SONAR server and the application, cache proximity estimation data longer than the NAT box retains its mappings between global and local addresses. Many sites employ firewalls or filtering in routers to discourage hostile attacks or probes from outside (or inside!) of a perimeter. For example, some sites filter ICMP echo requests. Such sites may interfere with the operation of particular kinds of SONAR servers. Sites that employ NATs and/or firewalls often utilize application level gateways or proxies. Use of proxies with SONAR is a topic for further study. 6. 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 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 one or more local domains.) Even though the local DNS hierarchy does not necessarily correspond to network topology, this approach will work well for many sites. A future version of SONAR may support location of servers using IP broadcast, IP multicast, DHCP, PPP extensions, service location proto- col, or some other means to be determined. 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 K. Moore Expires 8 October 1998 [Page 7] SONAR 8 April 1998 sites. The security mechanisms employed by a site to prevent certain kinds of attack may thwart use of SONAR. For example, some sites filter ICMP echo requests from external sites for security reasons, even though other protocols such as ftp or http may be allowed. A SONAR implementa- tion that uses ICMP echo will not be able to estimate proximity to hosts behind such a filter. 8. Author's address Keith Moore 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 . K. Moore Expires 8 October 1998 [Page 8]