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 <moore@cs.utk.edu>
Jason Cox <cox@cs.utk.edu>
Stan Green <sgreen@cs.utk.edu>
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]