Dismiss
The IQ application will be briefly unavailable on Sunday, March 31st, starting at 10:00am ET. Access will be restored as quickly as possible.
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: 2019-Feb-13
Document File: 9 page(s) / 13K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

C. Partridge: AUTHOR [+2]

Related Documents

10.17487/RFC1546: DOI

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. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 16% 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

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

Processing...
Loading...