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) 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," , 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]