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 <moore@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>.
K. Moore Expires 4 March 1998 [Page 14]