Internet DRAFT - draft-ettikan-ipngwg-fault-tolarance-anycast
draft-ettikan-ipngwg-fault-tolarance-anycast
Individual Submission
Internet Draft
K. Ettikan
Document: draft-ettikan-ipngwg-fault-tolarance
-anycast-00.txt
Intel ASG,Malaysia
Expires: February 2003
August 2002
Fault Tolerance and Load Balance Services using IPv6 Anycast
draft-ettikan-ipngwg-fault-tolarance-anycast-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [ ].
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 inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes how fault tolerant anycast service can be
achieved using IPv6 anycast service. Communication between an anycast
client and an anycast server is required as indicated in [ANALYSIS].
While, proposed host based anycast MLD [HOSTANY] or other anycast
group address management scheme is in place for this fault tolerant
anycast service to take place.
Table of Contents
1. Introduction 2
1.1 Terminology 2
2. Anycast Server Management 2
3. Anycast Server and Client Communication 3
4. Anycast Client Communication 3
4.1 Link State Changes 4
4.2 Server Unavailability 5
5. Anycast Server's Unicast Address Selection Algorithm 5
6. Security Considerations 6
References 6
Acknowledgments 7
Author's Addresses 7
1. Introduction
In order to support Fault tolerance and Load Balance anycast service,
host based anycast MLD [HOSTANY] or other anycast group address
management scheme assumed is in place. This allows an anycast service
address management much easier and all the routers can advertise the
anycast address at their links similar to multicast group address.
Similarly, any anycast clients that wish to join or leave the anycast
group address can do so by sending MLD Report and MLD Leave messages.
The routers also need to generate, receive and processes the messages
for the anycast group. This allows Anycast Server Group management to
be much efficient and effective. Since anycast packet will be
delivered to the nearest anycast server based on routing protocol
measure of distance [RFC2373], this feature can be exploited to
expand the anycast service for a pool of identical service servers.
This allows service reachability at layer 3 without application layer
support for a nearest anycast server, which runs anycast service.
1.1 Terminology
Anycast Service: Anycast service is a service that is provided by a
group of nodes, which is identical among the nodes. Anycast client
should be transparent to the services provided by the anycast servers
in terms of quality and information.
Anycast Client: Node with unicast address that contacts anycast
server for service.
Anycast Server: Node/Server that provides anycast service and it must
have an unicast address besides its anycast group address.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119.
2. Anycast Server Management
Let say there are N(s) number of anycast services with N(a) number of
anycast addresses for each services, to maintain service uniqueness.
These anycast addresses allocation specific to an anycast service is
out this paper's scope. We assume there is a unique address
allocation scheme, which allocates anycast addresses for different
duplicate services. Each service should be uniquely supported by an
anycast server which has been assigned that anycast address. The
routing system has the knowledge to deliver any anycast query packet
by the anycast client to an anycast server by routing protocol
measure of distance. So any anycast server can offer N(s) or less
than N(s) number of services, thus making it member of N(a) or less
than N(a) anycast group addresses.
Anycast servers that wish to join or leave to N(s) number of any
anycast service or less than N(s) number of services, thus making it
member of N(a) anycast addresses or less than N(a) anycast addresses,
can use the host-based anycast message [HOSTANY]to join and leave the
anycast group. Thus anycast server maintenance becomes much simpler.
Routers will maintain the route to the nearest anycast server at
their route table. Any packet communication will be forwarded to the
nearest Anycast Server.
3. Anycast Server and Client Communication
In the rest of the section we adopt anycast server's unicast address
discovery mechanism as discussed in [ANALYSIS] is done prior to any
service specific packet communication. The communication sequence is
as follows,
Request : client unicast (Cu) -> server anycast (Sa)
<packet size 1280 bytes>
Response : server unicast (Su) -> client unicast (Cu)
Communication : client unicast (Cu) -> server unicast (Su)
4. Anycast Client Communication
Anycast client that wish to utilize any anycast services, need to
know know the anycast service address. This knowledge can be obtained
via simple name to address resolving mechanism. DNS can maintain all
the duplicated services addresses corresponding to their names such
as DNS service itself, tunnel initialization and termination, address
translation services and etc.
In order to support for any host to use the anycast server's service,
due to Packet Fragmentation problem the hosts need to discover the
server's unicast address for further communication as indicated in
[ANALYSIS] and in Section 3 above. Routing state changes, link
unstability and server unavailability imposes some risks to this
solution.
R2---[S3, ASA]
/\
/ \
/ \
(5) (3)
/ \
H1---R1---(2)ùR3
\ \
(2) (2)
\ \
R4--(4)--(R6)---[S2,ASA]
|
[S1,ASA]
Figure 1: Routing State and communication path for anycast
communication.
Figure 1 depicts an example of a routing state and communication path
for H1 to an anycast server with similar Anycast Server Address, ASA
for there anycast servers. For the above figure S1 is the nearest
Anycast Server based on routing measure of distance of (2). However
if the link between R1 and R2 goes down the next nearest Anycast
Server is S2 with distance factor of (4). If the server S1 and S2
goes down for some reason the nearest Anycast Server will be S3 with
routing distance factor (5) father in the above Figure 1, but the
only available one. This link state changes and server availability
will change at any time. There are two possible risks, which will be
discussed further.
4.1 Link State Changes
If the link, which connects to the anycast server, unavailable than,
the existing unicast communication should continue to avoid any
service disruption. However any attempt for new communication to
anycast server should continue with new nearest anycast server based
on routing protocol measure of distance for anycast service from the
pool of identical service servers.
In order to discover the new server, [HOSTANY] solution can be used
to have, up to date anycast group address. Using this anycast group
address the proposed Communication as indicated in Section 3 must be
done to discover the unicast address of the Anycast Server and
further communication can be continued as usual using the discover
Anycast Server's unicast address. This can be done adopting update
address update algorithm, which will be described in Section 5.0.
4.2 Server Unavailability
If the anycast server is unavailable the current and future
communication must resume with a new anycast server which should be
the nearest anycast server based on routing protocol measure of
distance for anycast service from the pool of identical service
servers. In the event of server S1 goes down, than the Anycast
Server's unicast address is useless and new address need to be
obtained. Current communications need to be discarded and new
anycast server's unicast address need to be obtained. Address update
algorithm, which will be described in Section 5.0 can be used for
this purpose.
5. Anycast Server's Unicast Address Selection Algorithm
A) Prerequisites
The anycast client discovers or knows the anycast servers anycast
address to which it would like to communicate.
B) Algorithm
i) Anycast client uses unicast address of the anycast server, which
has weight 1, and timer has not expired. (Only one unicast
address is active at anytime, which is the address with weight =
1. That address is used for the anycast server communication.)
ii) If the timer expires or current unicast address is unreachable
then
-Anycast Cliet send a Request packet to Anycast Server based on
the Anycast group address.
-Anycast Server responses with Response Packet and unicast
address in the reply.
iii) Anycast Client learns the new unicast address and sets a weight
of 1 to that unicast address. All the other addresses will have
weight of 0.
iv) At the same time the timer value will be updated for that unicast
address. By default all the unicast addresses will have timer
value of 0.
v) If new address is learned it will be updated to the table.
Anycast Address Table
--------------------
Anycast Address Weight Timer Unicast Address for Anycast Server
[n bits /128-n] 1 x1 a:b:c::d
0 x2 a:b:c::e
[n bits/128-n] 1 y1 s:t:u::v
0 y2 o:p:q::r
Adopting the above algorithm the communicating host needs to keep an
anycast address table, associating anycast server's anycast address
and their unicast address. The unicast address for the anycast server
update will be done periodically as the timer expires or if the
server is unreachable. Only one anycast server should be active at
any time, which is maintained by weight value. This ensures only the
nearest anycast server is reached for communication. While timer
mechanism allows constant update of the unicast address for
connection stability. This algorithm will obviate the two problems as
discussed in Section 4 and provide fault tolerant and load balanced
anycast service.
6. Security Considerations
The document should introduce no new security issues. It inherits the
security vulnerability as indicated in [ANALYSIS] for unicast address
discovery.
References
Acknowledgments
None.
Author's Addresses
Ettikan Kandasamy Karupiah
ASG Penang & Shannon Operations,
Intel Microelectronis (M) Sdn. Bhd.,
Bayan Lepas Free Trade Zone III,
Penang, Malaysia.
Tel: +60-4-859-2591
Fax: +60-4-859-7899
Email: ettikan.kandasamy.karuppiah@intel.com
[RFC 2026] S. Bradner, "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[ANALYSIS] Hagino, J., and Ettikan, T., "An Analysis of IPv6 Anycast,"
<draft-itojun-ipv6-anycast-analysis-02.txt>, February 2001
"work in progress."
[HOSTANY] B. Haberman and D. Thaler, "Host-based Anycast using MLD" in
draft- haberman-ipngwg-host-anycast-00.txt (February 2001).
work in progress material.
INTERNET-DRAFT Fault Tolerance and Load Balance Services using IPv6
Anycast August 2002
K.Ettikan [Page 7]
