RFC 1546 (rfc1546) - Page 2 of 9

Host Anycasting Service

RFC 1546                Host Anycasting Service            November 1993


   and be connected to the nearest archie server.  DNS resolvers would
   no longer have to be configured with the IP addresses of their
   servers, but rather could send a query to a well-known DNS anycast
   address.  Mirrored FTP sites could similarly share a single anycast
   address, and users could simply FTP to the anycast address to reach
   the nearest server.

Architectural Issues

   Adding anycasting to the repertoire of IP services requires some
   decisions to be made about how to balance the architectural
   requirements of IP with those of anycasting.  This section discusses
   these architectural issues.

   The first and most critical architectural issue is how to balance
   IP's stateless service with the desire to have an anycast address
   represent a single virtual host.  The best way to illustrate this
   problem is with a couple of examples.  In both of these examples, two
   hosts (X and Y) are serving an anycast address and another host (Z)
   is using the anycast address to contact a service.

   In the first example, suppose that Z sends a UDP datagram addressed
   to the anycast address.  Now, given that an anycast address is
   logically considered the address of a single virtual host, should it
   be possible for the datagram to be delivered to both X and Y?  The
   answer to this question clearly has to be yes, delivery to both X and
   Y is permissible.  IP is allowed to duplicate and misroute datagrams
   so there clearly are scenarios in which a single datagram could be
   delivered to both X and Y.  The implication of this conclusion is
   that the definition of anycasting in an IP environment is that IP
   anycasting provides best effort delivery of an anycast datagram to
   one, but possibly more than one, of the hosts that serve the
   destination anycast address.

   In the second example, suppose that Z sends two datagrams addressed
   to the anycast address.  The first datagram gets delivered to X.  To
   which host (X or Y) does the second datagram get delivered?  It would
   be convenient for stateful protocols like TCP if all of a
   connection's datagrams were delivered to the same anycast address.
   However, because IP is stateless (and thus cannot keep track of where
   earlier datagrams were delivered) and because one of the goals of
   anycasting is to support replicated services, it seems clear that the
   second datagram can be delivered to either X or Y.  Stateful
   protocols will have to employ some additional mechanism to ensure
   that later datagrams are sent to the same host.  Suggestions for how
   to accomplish this for TCP are discussed below.





Partridge, Mendez & Milliken