rfc1546.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 507 行 · 第 1/2 页

Network Working Group                                       C. Partridge
Request for Comments: 1546                                     T. Mendez
Category: Informational                                      W. Milliken
                                                                     BBN
                                                           November 1993


                        Host Anycasting Service


Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This RFC describes an internet anycasting service for IP.  The
   primary purpose of this memo is to establish the semantics of an
   anycasting service within an IP internet.  Insofar as is possible,
   this memo tries to be agnostic about how the service is actually
   provided by the internetwork.  This memo describes an experimental
   service and does not propose a protocol.  This memo is produced by
   the Internet Research Task Force (IRTF).

Motivation

   There are a number of situations in networking where a host,
   application, or user wishes to locate a host which supports a
   particular service but, if several servers support the service, does
   not particularly care which server is used.  Anycasting is a
   internetwork service which meets this need.  A host transmits a
   datagram to an anycast address and the internetwork is responsible
   for providing best effort delivery of the datagram to at least one,
   and preferably only one, of the servers that accept datagrams for the
   anycast address.

   The motivation for anycasting is that it considerably simplifies the
   task of finding an appropriate server.  For example, users, instead
   of consulting a list of archie servers and choosing the closest
   server, could simply type:

                             telnet archie.net







Partridge, Mendez & Milliken                                    [Page 1]

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                                    [Page 2]

RFC 1546                Host Anycasting Service            November 1993


   After considering the two examples, it seems clear that the correct
   definition of IP anycasting is a service which provides a stateless
   best effort delivery of an anycast datagram to at least one host, and
   preferably only one host, which serves the anycast address.  This
   definition makes clear that anycast datagrams receive the same basic
   type of service as IP datagrams.  And while the definition permits
   delivery to multiple hosts, it makes clear that the goal is delivery
   to just one host.

Anycast Addresses

   There appear to be a number of ways to support anycast addresses,
   some of which use small pieces of the existing address space, others
   of which require that a special class of IP addresses be assigned.

   The major advantage of using the existing address space is that it
   may make routing easier.  As an example, consider a situation where a
   portion of each IP network number can be used for anycasting.  I.e.,
   a site, if it desires, could assign a set of its subnet addresses to
   be anycast addresses.  If, as some experts expect, anycast routes are
   treated just like host routes by the routing protocols, the anycast
   addresses would not require special advertisement outside the site --
   the host routes could be folded in with the net route.  (If the
   anycast addresses is supported by hosts outside the network, then
   those hosts would still have be advertised using host routes).  The
   major disadvantages of this approach are (1) that there is no easy
   way for stateful protocols like TCP to discover that an address is an
   anycast address, and (2) it is more difficult to support internet-
   wide well-known anycast address.  The reasons TCP needs to know that
   an address is an anycast address is discussed in more detail below.
   The concern about well-known anycast addresses requires a bit of
   explanation.  The idea is that the Internet might establish that a
   particular anycast address is the logical address of the DNS server.
   Then host software could be configured at the manufacturer to always
   send DNS queries to the DNS anycast address.  In other words,
   anycasting could be used to support autoconfiguration of DNS
   resolvers.

   The major advantages of using a separate class of addresses are that
   it is easy to determine if an address is an anycast address and
   well-known anycast addresses are easier to support.  The key
   disadvantage is that routing may be more painful, because the routing
   protocols may have to keep track of more anycast routes.

   An intermediate approach is to take part of the current address space
   (say 256 Class C addresses) and make the network addresses into
   anycast addresses (and ignore the host part of the class C address).
   The advantage of this approach is that it makes anycast routes look



Partridge, Mendez & Milliken                                    [Page 3]

RFC 1546                Host Anycasting Service            November 1993


   like network routes (which are easier for some routing protocols to
   handle).  The disadvantages are that it uses the address space
   inefficiently and so more severely limits the number of anycast
   addresses that can be supported.

   In the balance it seems wiser to use a separate class of addresses.
   Carving anycast addresses from the existing address space seems more
   likely to cause problems in situations in which either applications
   mistakenly fail to recognize anycast addresses (if anycasts are part
   of each site's address space) or use the address space inefficiently
   (if network addresses are used as anycast addresses).  And the
   advantages of using anycast addresses for autoconfiguration seem
   compelling.  So this memo assumes that anycast addresses will be a
   separate class of IP addresses (not yet assigned).  Since each
   anycast address is a virtual host address and the number of
   anycasting hosts seems unlikely to be larger than the number of
   services offered by protocols like TCP and UDP, the address space
   could be quite small, perhaps supporting as little as 2**16 different
   addresses.

Transmission and Reception of Anycast Datagrams

   Historically, IP services have been designed to work even if routers
   are not present (e.g., on LANs without routers).  Furthermore, many
   in the Internet community have historically felt that hosts should
   not have to participate in routing protocols to operate.  (See, for
   instance, page 7 of STD 3, RFC 1122). To provide an anycasting
   service that is consistent with these traditions, the handling of
   anycast addresses varies slightly depending on the type of network on
   which datagrams with anycast addresses are sent.

   On a shared media network, such as an Ethernet and or Token Ring, it
   must be possible to transmit an anycast datagram to a server also on
   the same network without consulting a (possibly non-existent) router.
   There are at least two ways this can be done.

   One approach is to ARP for the anycast address.  Servers which
   support the anycast address can reply to the ARP request, and the
   sending host can transmit to the first server that responds.  This
   approach is reminiscent of the ARP hack (RFC 1027) and like the ARP
   hack, requires ARP cache timeouts for the anycast addresses be kept
   small (around 1 minute), so that if an anycast server goes down,
   hosts will promptly flush the ARP entry and query for other servers
   supporting the anycast address.

   Another approach is for hosts to transmit anycast datagrams on a
   link-level multicast address.  Hosts which serve an anycast address
   would be expected to listen to the link-level multicast address for



Partridge, Mendez & Milliken                                    [Page 4]

RFC 1546                Host Anycasting Service            November 1993


   datagrams destined for their anycast address.  By multicasting on the
   local network, there is no need for a router to route the anycast
   datagrams.  One merit of this approach is that if there are multiple
   servers and one goes down, the others will still receive any
   requests.  Another possible advantage is that, because anycast ARP
   entries must be quickly timed out, the multicasting approach may be
   less traffic intensive than the ARP approach because in the ARP
   approach, transmissions to an anycast address are likely to cause a
   broadcast ARP, while in the multicast approach, transmissions are
   only to a select multicast group.  An obvious disadvantage is that if
   there are multiple servers on a network, they will all receive the
   anycast message, when delivery to only one server was desired.

   On point-to-point links, anycast support is simpler.  A single copy
   of the anycast datagram is forwarded along the appropriate link
   towards the anycast destination.

   When a router receives an anycast datagram, the router must decide if
   it should forward the datagram, and if so, transmits one copy of the
   datagram to the next hop on the route.  Note that while we may hope
   that a router will always know the correct next hop for an anycast
   datagram and will not have to multicast anycast datagrams on a local
   network, there are probably situations in which there are multiple
   servers on a local network, and to avoid sending to one that has