Title of Invention

METHOD AND SYSTEM FOR SEAMLESS MOBILITY SUPPORT USING HIERARCHICAL HOME AGENTS

Abstract

This invention relates in general to mobile communication technology. Further, this invention relates to a hierarchical administrative domain in mobile communication. More particularly, this invention relates to a method and System for Seamless Mobility Support using Hierarchical Home Agents. The method for seamless mobility support using hierarchical home agents comprising the steps of: addition of a new server called Home Agent Information Server that maintains a database of Home Agents inside the domain; each HA inside the domain sending its details such as IP address, current prefix list and the addresses of all routers in the path to HA from Gateway to the HIS when it is started initially or whenever there is any change in such information or whenever HIS requests for it; detection of failure of any HA or router acting as HA by HIS and handling its failure by requesting the routers in the path to HA/router from Gateway to act as HA on behalf of failed HA/router; detection of any failed HA/router recovery by HIS and requesting the router that is handling its failure to stop acting as HA on behalf of recovered one; transferring the latest Binding Cache Information to the recovered HA/router from the router that is handling its failure; detection of failure of HIS by HAs and stop communication with it; and detection of recovery of HIS by HAs and Routers, and resuming communication with it; wherein the said method is employed in a communication system, comprising an enterprise domain with a Border Gateway that is used to connect to Internet, routers and home agents.

Full Text

FIELD OF THE INVENTION This invention relates in general to mobile communication technology. Further, this invention relates to a hierarchical administrative domain in mobile communication. More particularly, this invention relates to a method and System for Seamless Mobility Support using Hierarchical Home Agents. DESCRIPTION OF THE RELATED ART The [MIPv6] specifies a protocol which allows nodes to remain reachable while moving around in the IPv6 internet. Mobile node is always identified by its home address, regardless of its current point of attachment to the Internet. While away from home, a mobile node registers its remote point of attachment address called Care-of Address with a router on its home link, requesting this router to function as the "home agent" for the mobile node. HA is now responsible to forward packets, addressed to the MN at its home link, to its current location. The MN is reliant on this HA for its connectivity. Thus the HA represents the possibility of a single point of failure for Mobile IPv6. A HA may be responsible for multiple MNs on the home link. The failure of a single HA may then result in the loss of connectivity for numerous MNs located throughout the Internet. To overcome this problem Mobile IPv6 allows deployment of multiple HAs on the home link so that upon the failure of serving HA, another HA can take over the functions of failed HA and thus provide continuous service to the MN(s) registered with failed HA. This transfer of service from the failed HA to a new working HA is problematic and the current specification of Mobile IPv6 does not provide solution to these problems. Figure 1 depicts a basic deployment scenario where multiple HAs, referred as HAs 1..n, have to coexist on the same home link to provide continuous service to MN in case of failure of the serving HA. MN runs Mobile IPv6 MN functionality with the mobility signaling messages protected by IPsec. Also all the HAs 1..n run Mobile IPv6 HA functionality along with IPsec server software. Initially MN is registered and has IPv6 tunnel with HA_1. Referring to fig.1 consider the failure of HA_1 and switching of service to a new HA__x (where x = 2...n) on the same home link. The process of failure detection, switching and the problems associated with it are described below: Detection of HA failure Transfer of service from the failed HA_J to new HA_x will occur after the detection of failure by MN. MN could detect the failure of HA_1 under certain conditions. These are listed below. • When MN sends Binding Update (BU) message to the failed HA_1 and does not receive matching Binding Acknowledgment (BA) message, it will retransmit BUs until timeout occurs. Upon this MN will come to know about the failure of HA • Similarly when MN sends Mobile Prefix Solicitation (MPS) message to the failed HA_1 and does not receive Mobile Prefix Advertisement, it will retransmit MPSs until timeout occurs and that's how it will come to know that HA_1 has failed. According to Mobile IPv6 MN after sending first BU or MPS message to failed HA_1 will wait for a initial timeout period which is set to INITIAL_BINDACK_TIMEOUT (1 second) in case of BU and INITIAL_SOLICITJTIMER (3 seconds) in case of MPS. This timeout period will be doubled for each subsequent BU or MPS message until value of MAX_BINACK_TIMEOUT (32 seconds) is reached. MN MAY send infinite BUs or MPSs to failed HA_1 before the final timeout occurs. So the detection of failed HA_1 will be delayed by a considerable amount of time. Moreover BU and MPS are not periodic rather on demand. MN will send BU only to register new Care-of Address or to extend the lifetime of existing registration with its serving HA. Similarly MN will send MPS only when its serving HAs address is about to become invalid. As a result MN will suffer packet loss and disconnectivity problems. This could have noticeable performance implications on real-time applications. Recovery Once the failure is detected, according to the current specifications of Mobile IPv6 MN will try to register its Care-of Address with any other HA on the home link. For this MN must know which other HAs are available on the home link. MN MAY start Dynamic Home Agent discovery(DHAD) protocol and as a result will get a list of available HAs on the home link. MN could then select HA_x (in our scenario) on the list as its potential serving HA. MN will send BU message to HA_x setting Home Registration(H) bit. But this recovery mechanism is problematic. If there is only one HA available on the home link then according to current specifications of Mobile IPv6 even if the retransmission parameter MAXJ3INACK_TIMEOUT (32 seconds) is reached MN will continue to send BU messages to the HA_1 until it receives valid BA message and this will never happen because HA_1 has failed. This makes the MN enter into an endless loop. Even if there are multiple HAs exist (as in our scenario), besides failure detection, there is an extra burden on MN to perform Home Registration with the new HA and in some cases multiple Home Registrations if there are unsuccessful attempts. Also if there is no information about the available HAs on the home link then MN has to perform DHAD. All these factors together result in extra messages overhead on the air interface, service interruption and burden on MN. Also upon the HA_1 failure the sequence number information in the Binding Cache of HA_1 will also be lost. The new HA_x to which MN will switch will not have the knowledge about the sequence number of last sent BU by the MN. This introduces new security vulnerabilities to the Mobile IPv6. SUMMARY OF THE INVENTION In Mobile IPv6, the Mobile Node is dependent on a single Home Agent for the seamless roaming over the internet. Home Agent is a router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. A HA may be responsible for mobility of multiple MNs on the home link. The failure of a single HA may then result in the loss of connectivity for numerous MNs located throughout the Internet. A MN cannot afford the loss of its HA. Thus the primary objective of the present invention is to provide a communication system and method to detect the failure of any HA inside the domain and to handle its failure to support the mobility of all mobile nodes handled by this HA. A new node called Home Agent Information Server (HIS) is used to achieve the same. The invention proposes a method to handle the failure of any Home Agent inside a hierarchical administrative domain and thus supports the mobility of all mobile nodes handled by this Home Agent. A new node called Home Agent Information Server is added to the domain, which detects and handles the failure of any HA inside the domain. The method requires no change in mobile node functionality but all the routers inside the domain should be equipped with Home Agent functionality. Accordingly this invention explains a method for seamless mobility support using hierarchical home agents comprising the steps of: (a) addition of a new server called Home Agent Information Server that maintains a database of Home Agents inside the domain; (b) each HA inside the domain sending its details such as IP address, current prefix list and the addresses of all routers in the path to HA from Gateway to the HIS when it is started initially or whenever there is any change in such information or whenever HIS requests for it; (c) detection of failure of any HA or router acting as HA by HIS and handling its failure by requesting the routers in the path to HA/router from Gateway to act as HA on behalf of failed HA/router; (d) detection of any failed HA/router recovery by HIS and requesting the router that is handling its failure to stop acting as HA on behalf of recovered one; (e) transferring the latest Binding Cache Information to the recovered HA/router from the router that is handling its failure; and (f) detection of failure of HIS by HAs and stop communication with it; and (g) detection of recovery of HIS by HAs and Routers, and resuming communication with it; wherein the said method is employed in a communication system, comprising an enterprise domain with a Border Gateway that is used to connect to Internet, routers and home agents. HIS maintains a database where: For each HA in the domain, it will maintain: IP address; current prefix list; list of all router's IP addresses in its path from the Gateway; flag indicating whether it is functioning or not; Handling router IP address if it is not functioning; For each router acting as HA on behalf of failed HA, it will maintain: IP address of the router; Flag indicating whether it is functioning or not; List of all failed HAs for which it is acting as HA; and Handling router IP address if it is not functioning. The step of detection of HA failure consists of: sending periodically a "Hello" Packet to HIS located in the domain by Each Home Agent inside the domain, after receiving "HA information Ack" packet from HIS; sending a "Hello request" packet to HA which request it to send "Hello" packet by the HIS if the said HIS doesn't receive "Hello" packet from a particular Home Agent for a configurable period of time; sending a message to HA by the HIS requesting it to send "Hello" packet for a configurable number of times if HIS does not get any "Hello" packet from a particular HA; and assuming a failure of HA if HIS does not get any "Hello" packet even after specifically sending a request; wherein the time interval to send Hello packet by HA is very less to detect the failure of HA immediately. The step of handling failure of any HA acting as HA consists of: getting the immediate router of failed one from its database by the HIS and sending a "HA proxy solicitation" message to the router requesting it to act as HA on behalf of failed one; sending an acknowledgement by the requested router to the HIS on receiving this request and start acting as HA on behalf of failed one; and trying for next level routers by HIS if it does not get any response from the immediate router to take up the functionality of failed HA. The router acting on behalf of failed HA consists of maintaining of Binding cache entries of each HA, by all the routers in its path to it from Gateway by observing BU and Back packets. The router acting on behalf of failed HA consists of sharing of security context between MN and HA along all the routers in the path to HA from Gateway, to understand the packets sent by MN to HA by all routers in the path. The router after taking the responsibility of acting as HA, establishing the security context with the mobile nodes of HA using IKE and then communicating with the MN in a secure way. If the failed HA is not on link to the router which it knows from the prefix list of HA, router does not perform any ND proxy functionality on behalf of failed HA. The step of handling failure of any router acting as HA consists of: sending a "HA Proxy Solicitation" request to its immediate router to take up the HA functionality for all failed HAs if HIS detects failure of some router acting as HA on behalf of some failed HAs ; Wherein in the said request , HIS includes the current prefix list and IP address of all the HAs handled by the failed router. If the router accepts, then HIS updates the handling router entry for each HA with the new router's address. The steps of detection and handling of recovery of any failed HA and transferring the latest binding cache information to the recovered HA consists of: sending "HA Information" packet to HIS by the recovered HA; sending the "HA Proxy Stop" message to the handling router by HIS for the recovered HA to stop functioning as HA on behalf of recovered one; sending the latest Binding cache information to the recovered HA using "Bcache Information" message by the handling router; sending "Bcache Information Ack" message by the Recovered HA to the Router that sends "Bcache Information" message; sending "HA Proxy Stop Ack" to HIS indicating the success or failure of requested functionality by the Handling Router; and updating the database by marking the recovered HA as functioning by the HIS on receiving success response from Router. In the said method the step of recovery of any failed router comprising the steps of: sending "Ready" message to HIS by the router; sending "Ready Ack" response to confirm the reception of "Ready" message by the HIS; getting the list of failed HAs by the HIS; checking whether the router which has come up is in the path to the gateway; checking whether the current handling router of the failed HA is more ancestor than the router which has come up; sending a message to handling router of these failed Has by HIS to stop functioning as HA on behalf of these and to send the latest binding cache information of the HAs to the recovered router which takes up the functionality on behalf of the failed Has; and sending a response indicating success or failure to HIS of requested functionality by the Handling router; wherein the recovered router after receiving Binding cache information starts functioning as HA on behalf of the failed ones. The step of detection of HIS failure by HA comprising the steps of: sending "HIS Hello Request" message to the HIS periodically by each HA; sending "HIS Hello" message as response to it by the HIS; and assuming the failure of HIS and stopping communication with it if HA does not get any response for the request from HIS. The step of detection of recovery of failed HIS by HA comprising the steps of: sending "HA Information Request" message to all the HAs in the domain requesting for its information by HIS; wherein HA on receiving this message, detects that HIS has recovered and starts communication with it by sending "HA Information" and "Hello" messages. The step of detection of recovery of HIS by routers comprising the steps of: sending "HIS Ready" message to all the routers in the domain by HIS; sending "HIS Ready Response" message to the HIS by the routers; filling its database with the details of routers acting as HA by HIS on receiving this response; sending "HIS Ready Response Ack" to the routers acting as HA confirming the reception of "HIS Ready Response" by HIS; wherein if the router is acting as HA on behalf of failed ones, the response message contains IP address and current prefix list for each failed HA and if the router is not acting as HA on behalf of any failed ones, the response message is just a null message to confirm the reception of "HIS Ready" message from HIS. The other objects, features and advantages of the present invention will be apparent from ensuing the detailed description of the invention taken in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS Figure 1 illustrates an MIPv6 deployment scenario. Figure 2 illustrates an enterprise domain connected to Internet through Border Gateway. Figure 3 illustrates signaling between HIS &HA when HIS comes up. Figure 4 shows the sequence of operations that will take place while detecting and handling HA failure. Figure 5 shows the sequence of operations that occur when HA has recovered from failure. Figure 6 shows the sequence of operations that occur when some router has come up. Figure 7 shows the signaling between HIS and Router when HIS comes up. DETAILED DESCRIPTION OF THE INVENTION The preferred embodiments of the present invention will now be explained with reference to the accompanying drawings. It should be understood however that the disclosed embodiments are merely exemplary of the invention, which may be embodied in various forms. The following description and drawings are not to be construed as limiting the invention and numerous specific details are described to provide a thorough understanding of the present invention, as the basis for the claims and as a basis for teaching one skilled in the art how to make and/or use the invention. However in certain instances, well-known or conventional details are not described in order not to unnecessarily obscure the present invention in detail. Figure 1 shows the components of Mobile IPv6 network and how they are connected. In this figure home link is the link that is assigned the home subnet prefix, from which the mobile node obtains its home address. The home agent resides on the home link. There exists multiple HAs on the home link to account for failure of some HA. In the figure HA1, HA2 and HA3 are the home agents. Foreign link is a link that is not the mobile node's home link. Mobile node registers its primary care of address with home agent, while away from home. Figure 2 shows a reference scenario for the proposed method. It contains an enterprise domain connected to the internet through a Border Gateway. Inside the domain shown are Routers, Home Agents and a new node called Home Agent Information Server which is responsible for achieving the objectives of the current invention. Figure 3 shows the signaling between HIS and HA when HIS comes up. HIS sends "HA Information Request" message to all the HAs when it is started initially or recovered from failure. All the HAs sends "HA Information" message to HIS. HIS after receiving this information sends an acknowledgement message "HA Information Ack" to the corresponding HAs. HAs after getting acknowledgement will start sending "Hello" messages to HIS periodically. Figure 4 shows the sequence of operations that occur while detecting and handling failure of any HA. Upon failure of some HA, HIS didn't receive any "Hello" message from that HA. Upon time out, HIS sends "Hello Request" message to that HA requesting it to send "Hello" message. Since HA has failed, HIS will not get any response from HA now also. HIS will now request the immediate router of failed HA to act as router by sending "HA Proxy Solicitation" message. Router sends "HA Proxy Ack" message to the HIS upon receipt of this request and starts acting as HA on behalf of failed one by sending "Hello" messages to HIS. Figure 5 shows the sequence of operations that occur when HA comes up. Whenever HA is started or recovered from failure, it sends "HA information" message to HIS. HIS will send "HA Proxy Stop" message to the router acting as HA on behalf of recovered one, to stop acting as HA. Router, on receiving this message, will send the "Bcache information" message which contains the corresponding Binding cache information to the recovered HA. HA sends acknowledgement message "Bcache Information Ack" after receiving this information. Router sends "HA Proxy Stop Ack" to HIS after getting acknowledgement from the HA. Figure 6 shows the sequence of operations that occur when Router comes up. Whenever Router is started or recovered from failure, it sends "Ready" message to HIS. HIS will send "Ready Ack" message to the router confirming the router that it has received "Ready" message. HIS, after sending acknowledgement, will get the list of all failed HAs the recovered router should handle. It will send "HA proxy stop" message to the current handling router of these failed HAs requesting it to delegate the task of acting as HA to the recovered router. Handling router now sends the "Bcache Information" message to the recovered router which contains the binding cache information of all these failed HAs. Recovered router sends acknowledgement to the handling router after receiving the binding cache information. Handling router will now send "HA proxy stop Ack" to the HIS. Figure 7 shows the signaling between HIS and Router when HIS comes up. HIS sends "HIS Ready" message to all the routers inside the domain whenever it is started or recovered from failure. Routers will send "HIS Ready Response" message to the HIS which contains information whether it is acting as HA on behalf of any failed ones or not. HIS on receiving this message will update its database about the routers acting as HA and sends an acknowledgement to those routers acting as HA. Routers which are acting as HA, after receiving this acknowledgement, will start sending "Hello" messages to HIS. Operation of the Invention Figure 2 depicts an example scenario where the proposed method is applicable. The system shown in fig.2 comprises a hierarchical administrative domain connected to the internet using a Border Gateway. Inside the administrative domain shown are the routers, Home Agents and a new node called Home Agent Information Server (HIS). This new node is responsible for achieving the objectives of the current invention. The detailed operation of the current invention is as follows: o A new server called Home Agent Information Server should be added to the domain. This node handles the failure of any Home Agent inside the domain o It maintains a database of Home Agent information inside the domain, which includes for each Home Agent, its IP address, current prefix list, addresses of all routers from the HA to Border Gateway of the domain. o Each HA should send this information to HIS when it is started initially or whenever there is a change in this information or when it receives "HA information request" message from HIS. o This information will be contained in a message "HA information" o HIS after receiving "HA information" message should send a "HA information Ack" packet as an acknowledgement. o If HA didn't receive any acknowledgement, it can resend the information for configurable number of times and finally it can assume the absence/failure of HIS if it didn't receive any acknowledgement Then it stops communicating with the HIS. o Once the HIS is up in the domain, it can send "HA information request" message to all the HAs in the domain thus starting the communication with HAs again. For this, HIS should be configured with the addresses of HAs inside the domain Home Agent Failure detection o Each Home Agent inside the domain, after receiving "HA information Ack" packet from HIS starts sending a "Hello" Packet to HIS located in the domain periodically o If HIS doesn't receive "Hello" packet from a particular Home Agent for a configurable period of time, it will send a "Hello request" packet to HA requesting it to send "Hello" packet. o If HIS doesn't receive any "Hello" packet, it will repeat the process of sending "Hello request" packet to HA for a configurable number of times. o If it didn't receive any "Hello" packet after all the tries, it will assume it as failure of HA and will proceed with the operations needed to handle it o The time interval to send Hello packet by HA should be very less to detect the failure of HA immediately Handling HA failure o The binding cache entries of each HA are maintained in all the routers in the path to HA inside the domain by observing the BU and BAck packets sent to or from HA. o Security contexts or policies maintained by each HA for each MN are also shared across the routers in the path to HA from Gateway. o Once HIS detects failure of any HA (say HA1 in fig.2), it will mark the entry for this HA in its database as failed and then it will get its immediate router (R1) from its database and sends a "HA proxy solicitation" message to router (R1) requesting it to act as HA on behalf of failed HA. o It will include the current prefix list of the failed HA, its IP address in the "HA proxy solicitation" message. This information will be stored in the HA information database maintained by HIS > Router (R1) after receiving the request sends "HA Proxy Ack" to HIS as an acknowledgment. ) If HIS didn't get any response from Router, it will resend the request for configurable number of times. If it didn't get any response after all tries, it will get the next higher Router (R2) for HA and sends the request to that Router. This process will be repeated for all the routers in the path to HA inside the domain until it gets an acknowledgement or all routers in the path are tried If router (R1) has accepted the request to act as HA, as it already contains the binding cache entries of failed HA and also the security context or policy for each mobile node handled by HA, it will act as HA on behalf of failed HA. Before starting communication with the MN, router (R1) sets up security context with the MN using IKE. After establishing the security context, router (R1) can send packets to the MN securely. Since the router (R1) already knows the security policy used between failed HA and MN, it can receive and understand the packets sent by MN. If the failed HA is not on link to the router which it will know from the prefix list of HA, router need not perform any ND proxy functionality on behalf of failed HA. Since router (R1) is acting as HA now, it should start sending "Hello" packets to HIS. HIS, after receiving "HA Proxy Ack" from router (R1 or R2 or BG)), will update the failed HA record in database by adding the address of the router that is handling its failure. HIS also adds a new record to the HA information database for the router (R1) as it is acting as HA. It adds the IP address field and marks it as functioning in the database. HIS from now onwards should receive "Hello" packet from the router (R1) periodically Handling Router failure (Refer to fig.2) o If HIS detects failure of some router acting as HA (say R1) on behalf of some failed HAs (say HA1, HA2), it will send a "HA Proxy Solicitation" request to its immediate router (R2) to take up the HA functionality for all failed HAs (HA1, HA2). o In this request, it will include the current prefix list and IP address of all the HAs (HA1, HA2) handled by the failed router (R1). o If the router (R2) accepts, then HIS updates the handling router entry for each HA (HA1 & HA2) with the new router's (R2) address HA Information Database Entries o HA information database entries maintained by HIS are as follows: o For each HA in the domain, it will maintain ■ IP address ? current prefix list ? list of all router's IP addresses in its path from the Gateway ■ flag indicating whether it is functioning or not ■ Handling router IP address if it is not functioning o For each router acting as HA on behalf of failed HA, it will maintain ■ IP address of the router ■ Flag indicating whether it is functioning or not ? List of all failed HAs for which it is acting as HA ? Handling router IP address if it is not functioning Recovery of failed HA (Refer to fig.2) o If some HA (say HA1) starts functioning again, it will send "HA information" packet to HIS. o HIS on receiving this, checks whether it is from some failed HA. If it is from failed HA, it sends a "HA Proxy Stop" request to the router (say R1), handling this HA failure, requesting it to stop acting as HA on behalf of recovered HA. The request includes the recovered HA ip address and prefix list o Router R1 on receiving this request, will send a "Bcache information" packet to the HA that contains the Binding Cache information corresponding to the HA o HA after receiving this information, sends acknowledgement message "Bcache information Ack" to the router R1 and will start functioning as HA. o Router R1 after receiving acknowledgement from HA (HA1) sends "HA Proxy Stop Ack" to the HIS indicating failure or success of sending information to the HA o If HIS receives success, will remove the HA (HA1) from the list of failed HAs handled by the above router R1. Now if the list of failed HAs handled by router is empty, and if it is not HA by itself, the entry for the router is removed from the database. o Also HIS makes handling router entry for recovered HA in the database as null and marks the HA as functioning Recovery of failed Router (Refer to fig.2) o If some failed router (say R1) starts functioning again, it will send "Ready" message to the HIS. o HIS should send "Ready Ack" to the Router (R1) confirming that it has received the "Ready" message. o HIS, after sending "Ready Ack", checks for all failed HAs in its database, o whether the router (R1) which has come up is in their path to the gateway o whether the current handling router of failed HA is more ancestor than the router which has come up. o It will get a list of these failed HAs (say HA1 and HA2) and will send "HA proxy Stop" request to the handling router (say R2) of these failed HAs. The message includes the IP address and current prefix list of these failed HAs (HA1, HA2) and the address of router (R1) which has come up. o Handling router (R2), sends the binding cache information of all the HAs listed in the request (H1, HA2) to the router (R1) which has come up. o After getting acknowledgement, Handling router (R2) sends "HA Proxy Stop Ack" to the HIS. o HIS after getting this acknowledgement, will remove the above obtained list of failed HAs (HA1, HA2) from the list of failed HAs handled by this router (R2). Now if the list of failed HAs handled by router (R2) is empty, and if it is not HA by itself, the entry for the router (R2) is removed from the database. o HIS also updates the new handling router address for the above list of failed HAs (HA1, HA2) in the database with the recovered router address (R1) HIS failure detection o To detect the failure of HIS, each HA should send a special packet "HIS Hello Request" to the HIS periodically. o HIS should send "HIS Hello" response to the HA. o HA on receiving this response makes sure that HIS exists and is functioning properly o If HA doesn't receive any "HIS Hello" response, it'll send the request to HIS again for configurable number of times. o If HA didn't get any response after all tries, it'll assume it as failure of HIS and stops communicating with the HIS. o HA will restart communication with HIS when it receives "HA information request" packet from HIS. Detection of HIS recovery by Routers o HIS on recovery or when started initially sends "HIS Ready" message to all routers in the domain o If Router is acting as HA on behalf of any failed HAs, it will send a "HIS Ready Response" message containing the following details o For each failed HA ? IP address ? Current prefix list o If Router is not acting as HA on behalf of any failed ones, it will send "HIS Ready Response" which is just a null message to confirm that it has received the "HIS Ready" message o HIS fills it's HA information database with the details of routers acting as HA on receiving this response. o HIS sends "HIS Ready Response Ack" to the Router after receiving the response from the router. Effects / Advantages of the Invention a. Failure of HA is transparent to the MN and hence reduces burden of detecting and recovering from the failure of if s HA. b. Minimizes the period of service interruption c. No change is required on MN side d. No need to have multiple HAs on a single subnet to handle the failure of HA. The above-presented description is of the best mode contemplated for carrying out the present invention. The manner and process of making and using it is in such a full, clear, concise and exact terms as to enable to any person skilled in the art to which it pertains to make and use this invention. New embodiments in particular, which also lie within the scope of the invention can be created, in which different details of the different examples can in a purposeful way be combined with one another. This invention is however, susceptible to modifications and alternate constructions from that disclosed above which are fully equivalent. Consequently, it is not the intention to limit this invention to the particular embodiment disclosed. On the contrary, the intention is to cover all modifications and alternate constructions coming within the spirit and scope of the invention as generally expressed by the following claims which particularly point out and distinctly claim the subject matter of the invention. GLOSSARY OF TERMS AND DEFINITIONS THEREOF HA : - Home Agent MIPv6 : - Mobility support in IPv6. MN : - Mobile Node HIS : - Home Agent Information Server BU : - Binding Update MPS : - Mobile Prefix Solicitation DHAD : - Dynamic Home Agent discovery BG : - Border Gateway ND : - Neighbor Discovery IP : - Internet Protocol IKE : - Internet Key Exchange Ack : -Acknowledgement REFERENCES: [MIPv6] D. Johnson, C. E. Perkins, and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. WE CLAIM 1. A method for seamless mobility support using hierarchical home agents comprising the steps of: (a) addition of a new server called Home Agent Information Server that maintains a database of Home Agents inside the domain; (b) each HA inside the domain sending its details such as IP address, current prefix list and the addresses of all routers in the path to HA from Gateway to the HIS when it is started initially or whenever there is any change in such information or whenever HIS requests for it; (c) detection of failure of any HA or router acting as HA by HIS and handling its failure by requesting the routers in the path to HA/router from Gateway to act as HA on behalf of failed HA/router; (d) detection of any failed HA/router recovery by HIS and requesting the router that is handling its failure to stop acting as HA on behalf of recovered one; (e) transferring the latest Binding Cache Information to the recovered HA/router from the router that is handling its failure; and (f) detection of failure of HIS by HAs and stop communication with it; and (g) detection of recovery of HIS by HAs and Routers, and resuming communication with it; wherein the said method is employed in a communication system, comprising an enterprise domain with a Border Gateway that is used to connect to Internet, routers and home agents. 2. A method as claimed in claim 1, wherein HIS maintains a database where: For each HA in the domain, it will maintain: IP address; current prefix list; list of all router's IP addresses in its path from the Gateway ; flag indicating whether it is functioning or not; Handling router IP address if it is not functioning; For each router acting as HA on behalf of failed HA, it will maintain: IP address of the router; Flag indicating whether it is functioning or not; List of all failed HAs for which it is acting as HA; and Handling router IP address if it is not functioning. 3. A method as claimed in claim 1 wherein the step of detection of HA failure consists of: (i) sending periodically a "Hello" Packet to HIS located in the domain by Each Home Agent inside the domain, after receiving ,CHA information Ack" packet from HIS; (ii) sending a "Hello request" packet to HA which request it to send "Hello" packet by the HIS if the said HIS doesn't receive "Hello" packet from a particular Home Agent for a configurable period of time; (iii) sending a message to HA by the HIS requesting it to send "Hello" packet for a configurable number of times if HIS does not get any "Hello" packet from a particular HA; and (iv)assuming a failure of HA if HIS does not get any "Hello" packet even after specifically sending a request; wherein the time interval to send Hello packet by HA is very less to detect the failure of HA immediately. 4. A method as claimed in claim 1, wherein the step of handling failure of any HA acting as HA consists of: (a) getting the immediate router of failed one from its database by the HIS and sending a "HA proxy solicitation" message to the router requesting it to act as HA on behalf of failed one; (b) sending an acknowledgement by the requested router to the HIS on receiving this request and start acting as HA on behalf of failed one; and (c) trying for next level routers by HIS if it does not get any response from the immediate router to take up the functionality of failed HA. 5. A method as claimed in claim 4, wherein the router acting on behalf of failed HA, consists of maintaining of Binding cache entries of each HA, by all the routers in its path to it from Gateway by observing BU and Back packets. 6. A method as claimed in claim 4, wherein the router acting on behalf of failed HA, consists of sharing of security context between MN and HA along all the routers in the path to HA from Gateway, to understand the packets sent by MN to HA by all routers in the path. 7. A method as claimed in claim 4 wherein the router after taking the responsibility of acting as HA, establishing the security context with the mobile nodes of HA using IKE and then communicating with the MN in a secure way. 8. A method as claimed in claim 4 wherein if the failed HA is not on link to the router which it knows from the prefix list of HA, router does not perform any ND proxy functionality on behalf of failed HA. 9. A method as claimed in claim 1, wherein the step of handling failure of any router acting as HA consists of: sending a "HA Proxy Solicitation" request to its immediate router to take up the HA functionality for all failed HAs if HIS detects failure of some router acting as HA on behalf of some failed HAs; wherein in the said request, HIS includes the current prefix list and IP address of all the HAs handled by the failed router. 10.A method as claimed in claim 9, wherein if the router accepts, then HIS updates the handling router entry for each HA with the new router's address. 11. A method as claimed in claim 1, wherein the steps of detection and handling of recovery of any failed HA and transferring the latest binding cache information to the recovered HA consists of: (a) sending "HA Information" packet to HIS by the recovered HA; (b) sending the "HA Proxy Stop" message to the handling router by HIS for the recovered HA to stop functioning as HA on behalf of recovered one; (c) sending the latest Binding cache information to the recovered HA using "Bcache Information" message by the handling router; (d) sending "Bcache Information Ack" message by the Recovered HA to the Router that sends "Bcache Information" message; (e) sending "HA Proxy Stop Ack" to HIS indicating the success or failure of requested functionality by the Handling Router; and (f) updating the database by marking the recovered HA as functioning by the HIS on receiving success response from Router. 12. A method as claimed in claim 1, wherein the step of recovery of any failed router comprising the steps of: (a) sending "Ready" message to HIS by the router; (b) sending "Ready Ack" response to confirm the reception of "Ready" message by the HIS; (c) getting the list of failed HAs by the HIS; (d) checking whether the router which has come up is in their path to the gateway; (e) checking whether the current handling router of the said failed HAs is more ancestor than the router which has come up; (f) sending a message to handling router of these failed Has by HIS to stop functioning as HA on behalf of these and to send the latest binding cache information of the HAs to the recovered router which takes up the functionality on behalf of the failed Has; and (g) sending a response indicating success or failure to HIS of requested functionality by the Handling router; wherein the recovered router after receiving Binding cache information starts functioning as HA on behalf of the failed ones. 13. A method as claimed in claim 1, wherein the step of detection of HIS failure by HA comprising the steps of: (a) sending "HIS Hello Request" message to the HIS periodically by each HA; (b) sending "HIS Hello" message as response to it by the HIS; and (c) assuming the failure of HIS and stopping communication with it if HA does not get any response for the request from HIS. 14. A method as claimed in claim 1, wherein the step of detection of recovery of failed HIS by HA comprising the steps of: sending "HA Information Request" message to all the HAs in the domain requesting for its information by HIS; wherein HA on receiving this message, detects that HIS has recovered and starts communication with it by sending "HA Information" and "Hello" messages. 15. A method as claimed in claim 1, wherein the step of detection of recovery of HIS by routers comprising the steps of: (a) sending "HIS Ready" message to all the routers in the domain by HIS; (b) sending "HIS Ready Response" message to the HIS by the routers; (c) filling its database with the details of routers acting as HA by HIS on receiving this response; (d) sending "HIS Ready Response Ack" to the routers acting as HA confirming the reception of "HIS Ready Response" by HIS; wherein if the router is acting as HA on behalf of failed ones, the response message contains IP address and current prefix list for each failed HA and if the router is not acting as HA on behalf of any failed ones, the response message is just a null message to confirm the reception of "HIS Ready" message from HIS. 16. A system for seamless mobility support using hierarchical home agents comprising: (a) a new server called Home Agent Information Server added that maintains a database of Home Agents inside the domain; (b) HA's inside the domain sending its details such as IP address, current prefix list and the addresses of all routers in the path to HA from Gateway to the HIS when it is started initially or whenever there is any change in such information or whenever HIS requests for it; (c) HIS detecting the failure of any HA or router acting as HA and handling its failure by requesting the routers in the path to HA/router from Gateway to act as HA on behalf of failed HA/router; (d) HIS detecting of any failed HA/router recovery and requesting the router that is handling its failure to stop acting as HA on behalf of recovered one; (e) Means for transferring the latest Binding Cache Information to the recovered HA/router from the router that is handling its failure; and (f) HAs detecting of failure of HIS and stop communication with it; and (g) Has and routers detecting of recovery of HIS, and resuming communication with it; wherein the said system is employed in a communication system, comprising an enterprise domain with a Border Gateway that is used to connect to Internet, routers and home agents. 17.A system as claimed in claim 16, wherein HIS maintains a database where: For each HA in the domain, it will maintain: IP address; current prefix list; list of all router's IP addresses in its path from the Gateway ; flag indicating whether it is functioning or not; Handling router IP address if it is not functioning; For each router acting as HA on behalf of failed HA, it will maintain: IP address of the router; Flag indicating whether it is functioning or not; List of all failed HAs for which it is acting as HA; and Handling router IP address if it is not functioning. 18. A system as claimed in claim 16 wherein for detection of HA failure consists of: (a) Each Home Agent inside the domain which sends periodically a "Hello" Packet to HIS located in the domain, after receiving "HA information Ack" packet from HIS; (b) HIS which sends a "Hello request" packet to HA which request it to send "Hello" packet if the said HIS doesn't receive "Hello" packet from a particular Home Agent for a configurable period of time; (c) HIS which sends a message to HA by the HIS requesting it to send "Hello" packet for a configurable number of times if HIS does not get any "Hello" packet from a particular HA; and (d) means for assuming a failure of HA if HIS does not get any "Hello" packet even after specifically sending a request; wherein the time interval to send Hello packet by HA is very less to detect the failure of HA immediately. 19.A system as claimed in claim16, wherein for handling failure of any HA acting as HA consists of: (a) HIS which gets the immediate router of failed one from its database and sending a "HA proxy solicitation" message to the router requesting it to act as HA on behalf of failed one; (b) the requested router which sends an acknowledgement to the HIS on receiving this request and start acting as HA on behalf of failed one; and (c) HIS which tries for next level routers if it does not get any response from the immediate router to take up the functionality of failed HA. 20. A system as claimed in claim 19 wherein the router acting on behalf of failed HA consists of maintaining of Binding cache entries of each HA, by all the routers in its path to it from Gateway by observing BU and Back packets. 21. A system as claimed in claim 19 wherein the router acting on behalf of failed HA consists of sharing of security context between MN and HA along all the routers in the path to HA from Gateway, to understand the packets sent by MN to HA by all routers in the path. 22. A system as claimed in claim 19 wherein the router after taking the responsibility of acting as HA, establishes the security context with the mobile nodes of HA using IKE and then communicates with the MN in a secure way. 23. A system as claimed in claim 19 wherein if the failed HA is not on link to the router which it knows from the prefix list of HA, router does not perform any ND proxy functionality on behalf of failed HA. 24. A system as claimed in claim16, wherein handling failure of any router acting as HA comprising: means for sending a "HA Proxy Solicitation" request to its immediate router to take up the HA functionality for all failed HAs if HIS detects failure of some router acting as HA on behalf of some failed HAs; wherein in the said request, HIS includes the current prefix list and IP address of all the HAs handled by the failed router. 25. A system as claimed in claim 16, wherein if the router accepts, then HIS updates the handling router entry for each HA with the new router's address. 26. A system as claimed in claim 16, wherein detection and handling of recovery of any failed HA and transferring the latest binding cache information to the recovered HA comprising: (a) recovered HA which sends "HA Information" packet to HIS; (b) HIS which sends the "HA Proxy Stop" message to the handling router for the recovered HA to stop functioning as HA on behalf of recovered one; (c) handling router which sends the latest Binding cache information to the recovered HA using "Bcache Information" message; (d) Recovered HA which sends "Bcache Information Ack" message to the Router that sends "Bcache Information" message; (e) Handling Router which sends "HA Proxy Stop Ack" to HIS indicating the success or failure of requested functionality; and (f) HIS which updates the database by marking the recovered HA as functioning on receiving success response from Router. 27. A system as claimed in claim 16, wherein recovery of any failed router comprising: (a) the router which sends "Ready" message to HIS; (b) HIS which sends "Ready Ack" response to confirm the reception of "Ready" message; (c) HIS which gets the list of failed HAs; (d) means for checking whether the router which has come up is in the path to the gateway; (e) means for checking whether the current handling router of the failed HA is more ancestor than the router which has come up; (f) HIS which sends a message to handling router of these failed HAs to stop functioning as HA on behalf of these and to send the latest binding cache information of the HAs to the recovered router which takes up the functionality on behalf of the failed Has; and (g) Handling router which sends a response indicating success or failure to HIS of requested functionality; wherein the recovered router after receiving Binding cache information starts functioning as HA on behalf of the failed ones. 28.A system as claimed in claim 16, wherein detection of HIS failure by HA comprising: (a) each HA which sends "HIS Hello Request" message to the HIS periodically; (b) HIS which sends "HIS Hello" message as response to it; and (c) means for assuming the failure of HIS and stopping communication with it if HA does not get any response for the request from HIS. 29. A method as claimed in claim16, wherein detection of recovery of failed HIS by HA comprising: HIS which sends "HA Information Request" message to all the HAs in the domain requesting for its information; wherein HA on receiving this message, detects that HIS has recovered and starts communication with it by sending "HA Information" and "Hello" messages. 30. A system as claimed in claim 16, wherein detection of recovery of HIS by routers comprising: (a) HIS which sends "HIS Ready" message to all the routers in the domain; (b) the routers which sends "HIS Ready Response" message to the HIS; (c) HIS which fills its database with the details of routers acting as HA on receiving this response; and (d) HIS which sends "HIS Ready Response Ack" to the routers acting as HA confirming the reception of "HIS Ready Response"; wherein if the router is acting as HA on behalf of failed ones, the response message contains IP address and current prefix list for each failed HA and if the router is not acting as HA on behalf of any failed ones, the response message is just a null message to confirm the reception of "HIS Ready" message from HIS. 31A method for seamless mobility support using hierarchical home agents substantially as herein described particularly with reference to the drawings. 32. A system for seamless mobility support using hierarchical home agents substantially as herein described particularly with reference to the drawings.

Documents:

1307-CHE-2005 EXAMINATION REPORT REPLY RECEIVED 20-12-2012.pdf

1307-CHE-2005 FORM-13 19-06-2006.pdf

1307-CHE-2005 POWER OF ATTORNEY 20-12-2012.pdf

1307-CHE-2005 AMENDED PAGES OF SPECIFICATION 20-12-2012.pdf

1307-CHE-2005 AMENDED CLAIMS 20-12-2012.pdf

1307-CHE-2005 FORM-1 20-12-2012.pdf

1307-CHE-2005 FORM-13 20-12-2012.pdf

1307-CHE-2005 FORM-3 20-12-2012.pdf

1307-CHE-2005 FORM-5 20-12-2012.pdf

1307-CHE-2005 OTHER PATENT DOCUMENT 20-12-2012.pdf

1307-CHE-2005 OTHER PATENT DOCUMENT 1 20-12-2012.pdf

1307-che-2005-abstract.pdf

1307-che-2005-claims.pdf

1307-che-2005-correspondnece-others.pdf

1307-che-2005-description(complete).pdf

1307-che-2005-drawings.pdf

1307-che-2005-form 1.pdf

1307-che-2005-form 13.pdf

1307-che-2005-form 26.pdf