Browse Prior Art Database

Host Anycasting Service (RFC1546)

IP.com Disclosure Number: IPCOM000002378D
Original Publication Date: 1993-Nov-01
Included in the Prior Art Database: 2000-Sep-12
Document File: 8 page(s) / 21K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Partridge: AUTHOR [+3]

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).

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 14% of the total text.

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

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 anyca...