Title of Invention

METHOD FOR CONTROLLING TWO OR MORE ANYCAST MACHINES PLACED ON THE SAME LINK

Abstract

The invention relates to a method to control and manage more than one anycast machine on the same link in IPV6 networks.This method can be used for load sharing whiule customers are unaware that there exists more than one machine serving them.in this invention,the anycast member that is currently overloaded or busy will hide from the router and router directs the user service requests to other anycast member.This new proposal aims at providing a centralized cluster management of hosts bound by the same IPV6 anycast address.in this method,the anycast membres play a role in delivering the packets among the anycast members of the same link.This method necessitates that each member of the anycast group keeps a record of its load state and information of the load it can handle.The router need not maintain any information about the member of anycast.The anycast members themselves"instruct" the router as to who takes upo ther load next.

Full Text

FIELD OF INVENTION This invention in general relates to IPv6 technology and Anycast communication in IPv6 which is the next generation network layer protocol that surpasses the shortcomings of its predecessor IPv4. More particularly, this invention relates to a method for controlling plurality of Anycast machines on the same link. DESCRIPTION OF RELATED ART The [ADDR__ARCH] introduces the concept of Anycast Addressing and its use in IPv6. But it restricts the assignment of Anycast addresses to routers only. The present invention extends the use of Anycast Addresses for Hosts also and in particular to anycast machines placed on a single link. The [ANALYSIS] has discussed the issues pertaining to Anycast address assignment for hosts. IPv4 uses IGMP for registration and deregistration purposes which is discussed in [HOSTANYv4]. The same concept has been extended in [HOSTANYv6]forlPV6. The [Patent application No. 988/CHE/2003] titled "A Method for Load Sharing using IPv6 Anycast addressing" extends the use of Anycast to Hosts and hence sharing the load specifically for the anycast hosts/servers that are geographically distributed. In this method a set of anycast members that provide a particular service join a group. If a particular member is busy then the new request will be forwarded to another member of the group. LIMITATIONS When there are two Anycast members on the same link, the existing architecture always finds only one of the hosts among the Anycast Group and others will be idle. a. The routers always deliver the packets to one of the Anycast Members (the one that has first given the response for Neighbor Discovery) irrespective of its current load, so there is no Load Sharing among the Anycast members on the same link. The other Anycast Members are idle. Hence the existing architecture does not allow placing more than one Anycast member on the same link. b. The service provider needs to distribute the Anycast Servers geographically based on distribution of customer density. This increases the infrastructure and deployment cost. OBJECTS OF THE INVENTION The primary object of this invention is to provide a method for placing and managing more than one Anycast Machine on the same link in IPV6 Network. It is another object of this invention to invent a technique for Load Sharing Using IPv6 Anycast Address. It is another object of this invention to make all the Anycast Members independent of each other, i.e. an anycast member does not know if there exists any other anycast member, this leads more scalability so that one can place any number of anycast machines without any traffic overhead for managing the anycast members. It is a further object of this invention to invent a technique for an Anycast Machine to hide from Routers when it is overloaded. SUMMARY OF THE INVENTION This invention describes a method to control and manage more than one Anycast machine on the same link in IPV6 Networks. This method can be used for load sharing while customers are unaware that there exists more than one machine serving them. In this invention the Anycast member that is currently overloaded or busy will hide from the router and router directs the user service requests to other Anycast member. This new invention provides a centralized cluster management of hosts bound by the same IPV6 Anycast address. In this method, the Anycast members play a role in delivering the packets among the Anycast Members of the same link. This method necessitates that each member of the Anycast group keeps a record of its load state and information of the load it can handle. The capacity of the host to handle the load has to be defined so that it can "refuse" to take on any further load so that the other members of Anycast can share the load. The Service Load can be defined either at Network Layer (works better for general Purpose Machines) or at Application layer (Works good for special Purpose Machines like Printer, AudioA/ideo Servers etc.) For general purpose machines the load can be defined with the number packets it is being transmitted per second at layer 3. If it this exceeds the capacity of the machine then it is overloaded. This threshold value needs to be defined by the administrator based on machine configuration. For special purpose machines, which provide a single service and one request at a time, the application decided if it is busy and informs the Layer 3. The router need not maintain any information about the members of Anycast. The Anycast members themselves "instruct" the router as to who takes up the load next. One feature which is better supported in IPV6 than in IPV4 is Anycast. Anycast is contra distinct from multicast and unicast in that, any packet sent to an Anycast address is routed to the 'nearest' interface having that address (Anycast member), nearest from the routing protocols' measure, unlike multicast where it is sent to all the members of multicast group. Accordingly this invention provides a method for controlling a plurality of anycast machines on the same link in IPV6 network wherein a centralized cluster management of hosts bound by the same IPV6 anycast address is carried out in the steps comprising: (a) sending a solicitation message through a router which is received by all anycast members; (b) starting an anycast random delay timer through the member (c) sending a neighbor advertisement message with Override flag = 0 through a host which can service and whose timer expires; (d) updating router's Neighbor Cache to the host whose timer expired first and whose message the router receives first; and (e) ignoring other NA messages that are received for this anycast address. Accordingly, this invention further provides a method of load sharing among a plurality of anycast machines in an IPV6 network where the capacity of a host to handle the load is the threshold value which is set for each member - host so that it refuses to take on any further load thereby other members of anycast can share the load characterized in that each member of the anycast group keeps a record of its load state and information of the load it can handle. Accordingly, this invention further provides a method for controlling plurality of Anycast machine on the same link in IPV6 network wherein a host machine without overload is selected in that the Anycast Machine which is overloaded is made unavailable to a router characterized in that the overloaded machine ignores NS messages sent by the router and the router updates its cache with details of the host machine without overload and receives the neighbor advertisement of the host machine without overload and by sending packets addressed to that particular anycast address to the said machine BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 shows the existing communication paradigm between the router and the Anycast hosts. Figure 2 depicts the message exchange that take place between the Anycast hosts and the router. Figure 3 depicts the proposed centralized cluster management system. Figure 4 shows how a host that is overloaded behaves. Figure 5 details the sequence of message exchanges by the Anycast hosts and the router. DETAILED DESCRIPTION OF THE INVENTION The IPV6 architecture specifies that the router need not maintain any information about the Anycast group, in which case, the Anycast routing takes place just like any other unicast address. The nodes that are a part of the Anycast address need not even know about each other. The user who wants to use a particular service provided at the Anycast Address, sends out a request to that particular Anycast address. The request is processed by the router in its vicinity. The router as per the routing norms sends the packet to the "nearest" node which is a member of that Anycast address. When the last router receives the packet and finds that the Anycast member exists on the link attached to the router, it sends a NS (neighbour solicitation) for resolving the Anycast Address to MAC address. Both the Anycast Members receives the NS and starts a random timer. After expiry of this timer the nodes respond with their MAC address. The router delivers the packet to the node that responds first. It ignores the second response. The router makes an entry in its neighbor cache against that Anycast address for that host. Any subsequent packets that are bound for that Anycast address are then on forwarded to that host [NDP]. Each Anycast host maintains some information about its current load, maximum load it can process. There has to be a threshold value set for each member-host as to how much load it can handle. Once the threshold value is reached, then any subsequent address resolution neighbor solicitation packets arriving to that host will be dropped. Hence, the router assumes that its information in neighbor cache is no more valid. When the router sends out a multicast NS message, as part of address resolution for anycast address, the other hosts which receive the NS start their Anycast delay timer with a random interval chosen from [0, MAX_ANYCAST_DELAY_TIME] to send back NA (Neighbour Advertisement) response as per [NDP]. The overloaded host doesn't respond to any Neighbor Solicitations (either unicast or multicast) because current load is greater than the threshold load. The router then makes an entry against that anycast address with the alternate host's link layer address which would have sent a reply to the Neighbor Solicitation. Any new request for service to the anycast address is then forwarded to the alternate host. Figure 2 refers the message exchange that take place between the Anycast hosts and the router before the router gets a NA message as part of address resolution as per [NDP]. The router sends a Solicitation message which is received by all the Anycast members. The members start an Anycast Random Delay Timer. The host whose timer expires will send a Neighbor Advertisement message with Override flag = 0. The router updates its Neighbor Cache to the one whose message it receives first as per [NDP]. The other NA messages that are received for this Anycast address are ignored. Referring to Figure 3 it depicts the proposed centralized cluster management system. Here, depending on the load, the host decides if it can service the next packet or not. So it does not respond to the solicitation from the router if it is overloaded. The other hosts which are not overloaded respond to the Neighbor solicitation. Figure 4 shows how a host that is overloaded behaves when it is overloaded. The overloaded host ignores NS messages sent by the router, and so the other host that responds to the message makes the router to update its neighbor cache entry to the new link layer address. Henceforth the packets are forwarded to this host. Further Figure 5 details the sequence of message exchanges by the Anycast hosts and the router. Initially Host 1 responds to the neighbor solicitation and so packets are sent to that host. When Host 1 becomes overloaded, it ignores the solicitation message and so the router receives the neighbor advertisement of host 2. So the router updates its cache with Host 2 details. Then on it sends any packets that are addressed to that particular Anycast address to Host 2. The foregoing description of a preferred embodiment of the invention has been presented for the purpose of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Obvious modifications or variations are possible in light of the above teachings. Although the invention has been described with respect to specific embodiments thereof, these embodiments are merely illustrative, and not restrictive of the invention. In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the present invention. One skilled in the relevant art will recognize, however, that an embodiment of the invention can be practiced without one or more of the specific details, or with other apparatus, systems, assemblies, methods, components, materials, parts, and/or the like. In other instances, well-known structures, materials, or operations are not specifically shown or described in detail to avoid obscuring aspects of embodiments of the present invention. Embodiments of the invention may be implemented by using a programmed general purpose digital computer, by using application specific integrated circuits, programmable logic devices, field programmable gate arrays, optical, chemical, biological, quantum or nano-engineered systems, components and mechanisms may be used. In general, the functions of the present invention can be achieved by any means as is known in the art. Distributed or networked systems, components and circuits can be used. Communication, or transfer, of data may be wired, wireless, or by any other means. It will also be appreciated that one or more of the elements depicted in the drawings/figures can also be implemented in a more separated or integrated manner, or even removed or rendered as inoperable in certain cases, as is useful in accordance with a particular application. It is also within the spirit and scope of the present invention to implement a program or code that can be stored in a machine-readable medium to permit a computer to perform any of the methods described above. Additionally, any signal arrows in the drawings/Figures should be considered only as exemplary, and not limiting, unless otherwise specifically noted. Furthermore, the term "or1' as used herein is generally intended to mean "and/or" unless otherwise indicated. Combinations of components or steps will also be considered as being noted, where terminology is foreseen as rendering the ability to separate or combine is unclear. As used in the description herein and throughout the claims that follow, "a", "an", and "the" includes plural references unless the context clearly dictates otherwise. Also, as used in the description herein and throughout the claims that follow, the meaning of "in" includes "in" and "on" unless the context clearly dictates otherwise. The foregoing description of illustrated embodiments of the present invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed herein. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes only, various equivalent modifications are possible within the spirit and scope of the present invention, as those skilled in the relevant art will recognize and appreciate. As indicated, these modifications may be made to the present invention in light of the foregoing description of illustrated embodiments of the present invention and are to be included within the spirit and scope of the present invention. Thus, while the present invention has been described herein with reference to particular embodiments thereof, a latitude of modification, various changes and substitutions are intended in the foregoing disclosures, and it will be appreciated that in some instances some features of embodiments of the invention will be employed without a corresponding use of other features without departing from the scope and spirit of the invention as set forth. Therefore, many modifications may be made to adapt a particular situation or material to the essential scope and spirit of the present invention. It is intended that the invention not be limited to the particular terms used in following claims and/or to the particular embodiment disclosed as the best mode contemplated for carrying out this invention, but that the invention will include any and all embodiments and equivalents falling within the scope of the appended claims. REFERENCES [IPV6] Deering S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [NDP] Narten, T., Nordmark, E. and W.Simpson, "Neighbor Discovery for IPV6", RFC 2461, December 1998. [HOSTANYV4] Partridge, C, Mendez, T. and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [ADDR-ARCH] Deering S. and R. Hinden, "Internet Protocol, Version 6 (IPV6) Addressing Architecture", RFC 3515, April 2003. [HOSTANYv6] Haberman, H. and Thaler, D. , "Host based Anycast using MLD", , May 2002 "work in progress". [ANALYSIS] Hagino, J., and Ettiken, T., "An Analysis of IPV6 Anycast", , February 2001 "work in progress". [Patent application No. 988/CHE/2003] A Method for Load Sharing using IPv6 Anycast addressing GLOSSARY OF TERMS AND THEIR DEFINITIONS Anycast address IPV6 supported address which enables the sender to send any packet to this address and the packet reaches one of the many hosts which have assumed this address. Anycast member Any host which has been configured with the Anycast address. WE CLAIM 1. A method for controlling a plurality of anycast machines on the same link in IPV6 network wherein a centralized cluster management of hosts bound by the same IPV6 anycast address is carried out in the steps comprising: a. sending a solicitation message through a router which is received by all anycast members; b. starting an anycast random delay timer through the member c. sending a neighbor advertisement message with Override flag = 0 through a host which can service and whose timer expires; d. Updating router's Neighbor Cache to the host whose timer expired first and whose message the router receives first; and e. ignoring other NA messages that are received for this anycast address. 2. A method of load sharing among a plurality of anycast machines in an IPV6 network where the capacity of a host to handle the load is the threshold value which is set for each member-host so that it refuses to take on any further load thereby other members of anycast can share the load characterized in that each member of the anycast group keeps a record of its load state and information of the load it can handle. 3. A method as claimed in claim 2, wherein the service load is defined at network layer. 4. A method as claimed in claim 2, wherein the service load is defined at application layer. 5. A method as claimed in claim 2, wherein the load information is maintained by the anycast members themselves and they inform the router as to which member takes up the load next. 6. A method for controlling plurality of Anycast machine on the same link in IPV6 network wherein a host machine without overload is selected in that the Anycast Machine which is overloaded is made unavailable to a router characterized in that the overloaded machine ignores NS messages sent by the router and the router updates its cache with details of the host machine without overload and receives the neighbor advertisement of the host machine without overload and by sending packets addressed to that particular anycast address to the said machine. 7. A method of controlling more than one anycast machine on the same link in IPV6 network substantially as herein described particularly with reference to the drawings.

Documents:

691-che-2004-abstract.pdf

691-che-2004-claims duplicate.pdf

691-che-2004-claims original.pdf

691-che-2004-correspondnece-others.pdf

691-che-2004-correspondnece-po.pdf

691-che-2004-description(complete) duplicate.pdf

691-che-2004-description(complete) original.pdf

691-che-2004-drawings.pdf

691-che-2004-form 1.pdf

691-che-2004-form 13.pdf

691-che-2004-form 26.pdf