Network Working Group Keith Moore Internet-Draft University of Tennessee Expires: 4 March 1998 4 August 1998 SONAR - A Network Proximity Service Version 1 draft-moore-sonar-03.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 proximity 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 implementation of the SONAR service. While the name "SONAR" is intended as a pun on the "ping" utility 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 algorithms to evolve separately from those applications. K. Moore Expires 4 March 1998 [Page 1] SONAR 4 August 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 provides 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 estimation 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 requirements of a particular site. It also allows SONAR to evolve independently of the applications that use it. When better proximity estimation 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 claim to provide a precise measurement of proximity. Instead, the goal of SONAR is to aid clients in making a "good" choice among alternative locations of a service. It should do this without imposing a long delay, and without consuming significant network resources. 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 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 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 4 March 1998 [Page 2] SONAR 4 August 1998 4. Protocol This memo describes the second version of SONAR, called version 1. Version 0 of the SONAR protocol was intentionally as simple as possible. Version 1 of SONAR adds support for IPv6, the ability to request a particular kind of proximity metric, and establishes uniform ways for servers to report proximity estimates. An application communicates with a SONAR server using UDP port 572. A SONAR request 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). 4.1 Request formats The format of a SONAR query for IPv4 addresses is as follows: offset datum +-------------------+ 0 | protocol-version | +-------------------+ 4 | request-type | +-------------------+ 8 | request-id | +-------------------+ 12 | reserved (MBZ) | +-------------------+ 16 | timeout (usec) | +-------------------+ 20 | count (1..255) | +-------------------+ 24 | address[0] | +-------------------+ 28 | address[1] | +-------------------+ | ... | +-------------------+ 24+(count-1)*4 | address[count-1] | +-------------------+ K. Moore Expires 4 March 1998 [Page 3] SONAR 4 August 1998 The format of a SONAR query for IPv6 addresses is as follows: offset datum +-------------------+ 0 | protocol-version | +-------------------+ 4 | request-type | +-------------------+ 8 | request-id | +-------------------+ 12 | reserved (MBZ) | +-------------------+ 16 | timeout (usec) | +-------------------+ 20 | count (1..255) | +-------------------+ 24 | address[0] | +-------------------+ 28 | address[0] | +-------------------+ 32 | address[0] | +-------------------+ 36 | address[0] | +-------------------+ 40 | address[1] | +-------------------+ 44 | address[1] | +-------------------+ 48 | address[1] | +-------------------+ 52 | address[1] | +-------------------+ | ... | +-------------------+ 24+(count-1)*16 | address[count-1] | +-------------------+ 28+(count-1)*16 | address[count-1] | +-------------------+ 32+(count-1)*16 | address[count-1] | +-------------------+ 36+(count-1)*16 | address[count-1] | +-------------------+ 4.1.1 Protocol version The protocol-version field is used to distinguish this version of the SONAR protocol from other versions. This document describes version K. Moore Expires 4 March 1998 [Page 4] SONAR 4 August 1998 1 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. 4.1.2 Request type For SONAR version 1, valid request-types are as follows: request-type meaning 00 hex cheapest proximity estimate 01 hex minimum round-trip time (microseconds) 02 hex mean round-trip time (microseconds) 03 hex minimum client-to-server delay (microseconds) 04 hex mean client-to-server delay (microseconds) 05 hex minimum server-to-client delay (microseconds) 06 hex mean server-to-client delay (microseconds) 07 hex maximum client-to-server bandwidth (bits per second) 08 hex mean client-to-server bandwidth (bits per second) 09 hex maximum server-to-client bandwidth (bits per second) 0A hex mean server-to-client bandwidth (bits per second) 0B hex mean client-to-server packet loss rate (percent) 0C hex mean server-to-client packet loss rate (percent) 0D hex mean time between circuit failure (seconds) 0E hex end-to-end MTU (octets) 0F hex hop count (hops) NOTE: There is no requirement that a SONAR server implement all of these request types. The large number of request types is intended to allow clients to differentiate responses from different kinds of proximity estimation services, and also to encourage experimentation into different ways of estimating proximity. Bit 80000000 (hex) of the request-type MUST be zero. This bit is used to distinguish SONAR requests from SONAR responses. The request-type MAY be ORed with 40000000 (hex) to indicate that substitutions are allowed. If this bit is 0, the server must either return a result in terms of the requested proximity metric, or it must return a "metric unsupported" error. If the bit is 1, the server may substitute some other metric for the one requested. The request-type MAY be ORed with 20000000 (hex) to indicate that the request is for IPv6 addresses. When this bit is set to 0, it indicates that the request contains IPv4 addresses. If the bit is set to 1, it indicates that the request contains IPv6 addresses. K. Moore Expires 4 March 1998 [Page 5] SONAR 4 August 1998 4.1.3 Request ID The request-id is any 4 octets chosen by the client, and is used to associate a response with the particular request that produced. The request-id will be included in the SONAR server's response. 4.1.4 Reserved field The 4 octets beginning at offset 12 are reserved for future use, (and for compatibility with SONAR version 0 implementations), and MUST be zero. 4.1.5 Timeout The timeout is the maximum number of microseconds (4 bytes) which the SONAR server should wait before replying. The server MAY return a response sooner than requested. A timeout of zero microseconds requests that the SONAR server return a response immediately, without any active probing, based on whatever proximity data it has on hand. 4.1.6 Address count The address count (4 octets) is the number of addresses for which the SONAR client wants the server to estimate relative proximity. The count may be any value between 1 and 255, inclusive. SONAR servers MUST ignore queries with a count of zero. The most significant three octets of the count field are reserved for future use, and MUST be zero. 4.1.7 Addresses Following the address count are that many Internet Protocol addresses. If the request-type had the 20000000 (hex) bit set to 1, the addresses are assumed to be IPv6 addresses; otherwise, they are assumed to be IPv4 addresses. 4.2 SUCCESS response formats Version 1 of the SONAR service has several possible response formats, depending on whether the request was successful, and whether the request was for IPv4 or IPv6 addresses. K. Moore Expires 4 March 1998 [Page 6] SONAR 4 August 1998 A SUCCESS response for IPv4 is returned in the following format: offset datum +----------------------+ 0 | protocol-version = 1 | +----------------------+ 4 | response-code | +----------------------+ 8 | request-id | +----------------------+ 12 | response-count | +----------------------+ 16 | address[0] | +----------------------+ 20 | metric[0] | +----------------------+ 24 | address[1] | +----------------------+ 28 | metric[1] | +----------------------+ | ... | +----------------------+ 16+(count-1)*8 | address[count-1] | +----------------------+ 20+(count-1)*8 | metric[count-1] | +----------------------+ K. Moore Expires 4 March 1998 [Page 7] SONAR 4 August 1998 A SUCCESS response for IPv6 is returned in the following format: offset datum +----------------------+ 0 | protocol-version = 1 | +----------------------+ 4 | response-code | +----------------------+ 8 | request-id | +----------------------+ 12 | response-count | +----------------------+ 16 | address[0] | +----------------------+ 20 | address[0] | +----------------------+ 24 | address[0] | +----------------------+ 28 | address[0] | +----------------------+ 32 | metric[0] | +----------------------+ 36 | address[1] | +----------------------+ 40 | address[1] | +----------------------+ 44 | address[1] | +----------------------+ 48 | address[1] | +----------------------+ 52 | metric[1] | +----------------------+ | ... | +----------------------+ 16+(count-1)*20 | address[count-1] | +----------------------+ 20+(count-1)*20 | address[count-1] | +----------------------+ 24+(count-1)*20 | address[count-1] | +----------------------+ 28+(count-1)*20 | address[count-1] | +----------------------+ 32+(count-1)*20 | metric[count-1] | +----------------------+ K. Moore Expires 4 March 1998 [Page 8] SONAR 4 August 1998 4.2.1 Protocol version Protocol-version will also be 1. For all versions of SONAR, the protocol-version of the response will match that of the request. 4.2.2 Response codes The response code indicates whether the request was successful, and if so, the type of metric actually returned in the response. This may be different than the type of metric requested. Successful response codes for SONAR version 1 include the following: response-code meaning 80000001 hex minimum round-trip time (microseconds) 80000002 hex mean round-trip time (microseconds) 80000003 hex minimum client-to-server delay (microseconds) 80000004 hex mean client-to-server delay (microseconds) 80000005 hex minimum server-to-client delay (microseconds) 80000006 hex mean server-to-client delay (microseconds) 80000007 hex maximum client-to-server bandwidth (bits per second) 80000008 hex mean client-to-server bandwidth (bits per second) 80000009 hex maximum server-to-client bandwidth (bits per second) 8000000A hex mean server-to-client bandwidth (bits per second) 8000000B hex mean client-to-server packet loss rate (percent) 8000000C hex mean server-to-client packet loss rate (percent) 8000000D hex mean time between circuit failure (seconds) 8000000E hex end-to-end MTU (octets) 8000000F hex hop count (hops) All response-types have the most significant (80000000) bit set to 1, so that responses can be distinguished from queries. The 40000000 bit MUST be zero for a successful response. This bit is used to distinguish SUCCESS responses from FAILURE responses. These responses are ORed with 20000000 hex if the response is for IPv6 addresses. This bit is 1 if the response contains IPv6 addresses; 0 if the response contains IPv4 addresses. This should match the 20000000 bit in the request-type of the request. 4.2.3 Request ID The request-id in the response matches the one from the SONAR query. K. Moore Expires 4 March 1998 [Page 9] SONAR 4 August 1998 4.2.4 Response count The response count field contains 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 necessary to prevent the resulting datagram from being fragmented. If a SONAR returns fewer responses than requested, it SHOULD return the proximity estimates of the nearest hosts (if delay estimation was requested), or those with the best bandwidth (if bandwidth estimation was requested), or the lowest loss or failure rates (if loss or failure rates were requested), or the highest MTU (if MTU was requested), discarding the estimates of those that appear to be the most distant (have less bandwidth, higher failure or loss rates, lower MTU). However, a server which has several cached proximity estimates from among those requested MAY return estimates for some subset of the cached estimates, without estimating proximity for all hosts requested. 4.2.5 Proximity estimates Following the response count are 'response count' sets of proximity metrics. Each metric consists of an (IPv4 or IPv6) address, followed by a proximity estimate. The proximity estimate must be use the correct units for the response-type, as given in section 4.2.2. The addresses returned in a SONAR response are not necessarily sorted by order of proximity; the client must sort them if needed. 4.3 FAILURE response formats A SONAR version 1 FAILURE response is of the following form: K. Moore Expires 4 March 1998 [Page 10] SONAR 4 August 1998 offset datum +-----------------------------+ 0 | protocol-version = 1 | +-----------------------------+ 4 | response-code | +-----------------------------+ 8 | request-id | +-----------------------------+ 12 | low-version | +-----------------------------+ 16 | high-version | +-----------------------------+ 20 | num-supported-request-types | +-----------------------------+ 24 | request-type-bits[0] | +-----------------------------+ | ... | +-----------------------------+ 4.3.1 Protocol version The protocol version of a FAILURE response MUST be consistent with the format of the FAILURE response. However, the server SHOULD if pos- sible return FAILURE responses that match the version of the request to maximize the likelihood that the client will be able to understand them. 4.3.2 Response code Currently defined FAILURE response codes are the following: response-type meaning C0000000 hex Version Mismatch C0000001 hex Metric Not Supported The "version mismatch" error indicates that the server does not support the version of the protocol used in the client's request. The low and high version fields indicate the versions of SONAR supported by the server. The "metric not supported" error indicates that the client requested a particular kind of metric not supported by the server. This might be either because the client did not set the 40000000 bit of the request, indicating that substitutions were allowed; or because the server could not make a reasonable substitution; or because the server did not understand the request-type used by the client. The request- K. Moore Expires 4 March 1998 [Page 11] SONAR 4 August 1998 type-bits field of the response contains the set of request-types sup- ported by the server. 4.3.3 Request-ID The request-id in the response MUST match the request-id in the request. 4.3.4 Low Version This contains the lowest-numbered version of SONAR supported by the server. 4.3.5 High Version This contains the highest-numbered version of SONAR supported by the server. 4.3.6 Number of Supported Request Types This field contains the number of request types supported by the server. It indicates the size of the following supported-request-types field. 4.3.7 Supported Request Types This field consists of an integral number of 4-octet words, where each word represents 32 elements of a set of supported request types. A bit set to 1 indicates that the corresponding request-type is supported by the server; a bit set to 0 indicates that the corresponding request- type is not supported. Examples: If request-type 0 is supported, bit 0 (00000001 hex) if word 0 is set; if request-type 1 is supported, bit 1 (00000002 hex) of word 0 is set; if request-type 31 is supported, bit 31 (80000000 hex) of word 0 is set; and if request-type 32 is supported, bit 0 (00000001 hex) of word 1 is set to 1. The length of this field is determined by the num-supported- request-types field. This field is ((num-supported-request- types+31)/32)*4 words long. 5. Caveats Since different SONAR servers may employ different proximity estimation algorithms, metrics obtained from one SONAR server should be compared with those obtained from a different server, only if they use the same proximity algorithms. K. Moore Expires 4 March 1998 [Page 12] SONAR 4 August 1998 Metrics 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-connected" side of the link (e.g. a modem dialup connection) the SONAR server should normally be located on the "well-connected" side. In general, applications which examine raw IP addresses may be confused 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 protocol, or some other means to be determined. K. Moore Expires 4 March 1998 [Page 13] SONAR 4 August 1998 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 ignore requests from remote 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 implementation 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 4 March 1998 [Page 14]