[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 01 02 03                                                      
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]