Minimizing Mobile IP Handoff Latency Ali Diab, Andreas Mitschele-Thiel {ali.diab|mitsch}@tu- ilmenau.de Ilmenau University of Technology, Chair for Integrated HW/SW-Systems Abstract Handoff latencies affect the service quality of real-time applications of mobile users. With Mobile IP (MIP), the handoff latency highly depends on the distance, i.e. delay, between Home Agent (HA) and Foreign Agent (FA). Hierarchical MIP (HMIP) minimizes handoff latencies but depends on additional network elements introduced on the path between HA and FA. The need for additional network elements contradicts with the principles of the Internet and impedes the wide use of HMIP in a world-wide network. In the paper, we propose an alternative to HMIP to reduce handoff latencies, which does not need additional network elements beyond the FA and HA already known from MIP. The proposal is based on a new technique that uses local authentication with the new FA independent of the re-authentication with the HA. With our approach some functions previously implemented by the HA are additional supported by the FA. Thus, the MN can quickly resume the transmission in up- and downlink after an handoff. We describe the modified MIP protocol and provide a simple performance analysis comparing the handoff delay of MIP, HMIP and our approach. The comparison shows that the performance of our proposal is comparable to the performance of HMIP.

Keywords: Mobility Management, Mobile IP, Wireless LAN. I Introduction Public Wireless LANs (WLANs) show a steady growth in the Internet. IEEE 802.11 (the defacto standard for WLANs) provides services at low cost. However, as the user mobility increases, the small cell size of WLANs will induce frequent handoffs causing inevitable delays. When the Mobile Node (MN) notices that the current Access Point (AP) is no longer reachable, it performs a handoff as follows: 1- When the MN moves to a new AP belonging to the same subnet, it performs a Layer2-Handoff (L2-HO) following these procedures: a. Discovery of the available AP and Layer2 authentication. b. Reassociation, and 802.11i authentication. 2- When the MN moves to a new AP belonging to another subnet, it performs a Layer3Handoff (L3-HO) in addition to the L2-HO following the procedures: a. Discovery of the new Foreign Agent (FA). b. Registration and authentication with the Home Agent (HA) / Gateway Foreign Agent (GFA). In order to implement Layer3-Handoffs, several protocols ha ve been proposed. With Mobile IP Version 4 (MIPv4) [Per98], [Per02], [Gon98] the MN must be registered and authenticated by the HA every time it moves from one subnet to another. This introduces extra latency to the communication, especially when the HA is far away from the FA. The generation of secret keys for the security association between HA and FA, and/or between FA and MN is another reason for latency. This is optional with MIP and depends on the configuration. However, these keys are mandatory for some extensions of MIP (e.g. hierarchical MIP, route optimisation for MIP) [BA00], [PR01]. In order to avoid these sources for extra latency, an approach to use an Anchor FA (AFA) has been proposed [DY00]. If the MN is away from the home network, it will be initially registered by the HA. During this registration a shared secret between MN and FA (K MN-FA) is established. The FA then acts as AFA. Thus, in subsequent registrations, the MN is registered at this AFA instead of the HA as long as it remains in the same domain, which the AFA belongs to. In this approach there is no need to generate more secret keys to authenticate the MN, and no need to establish a tunnel between HA and FA. Instead, an additional tunnel from the AFA to the current FA is established. However, the forwarding delay on the downlink as well as the uplink, i.e. the path from HA via AFA and current FA to MN, increases compared to MIP. Additional tunnels are needed if smooth P48/1

handoff is supported, i.e. a tunnel from the previous FA to the current FA and a reverse tunnel from the current FA to the AFA. In order to reduce the problem of temporarily discontinued communication with the MN during handoff, Hierarchical Mobile IP (HMIP) [GJP98] has been proposed. With HMIP the HA is not aware of every change in the point of attachment. This is due to the fact that the MN is registered and authenticated by the GFA or the Regional Foreign Agent (RFA) instead of the HA. Thus, the MN only communicates with the HA if it moves from one domain to another. As a result, the handover latency known from MIP is incurred in rare cases only. Proposals for low latency handoffs use a trigger originating from layer 2 (L2-trigger) to anticipate handoffs prior to a break of the radio link. In [ElMa02] methods for pre-registration, postregistration and a combined method have been proposed. Thus, a layer 3 handoff is triggered by a L2-trigger. With the pre-registration method, the MN scans the medium for other APs if the strength of the signal received from the current AP deteriorates or if the error rate increases. If another AP is available, a L2-trigger is fired. This prompts the MN to register with the new FA through the old one. Thus, the L3-HO is performed while the MN performs L2-HO. The L2-trigger may be fired not only by the MN, but also by the current FA or even the new FA. When the radio link of the current FA is turned down, i.e. the current FA receives a Layer 2 Link Down trigger (L2LD-trigger) the current FA forwards the packets directly to the new FA. The post-registration method works as follows: if the MN notices that the link with the current AP is not adequate, it tries to move to a neighbouring AP. In case the AP belongs to another subnet, it informs the current FA about the possible movement and performs only L2-HO. If the link between the current FA and the MN breaks down (receiving L2- LD trigger), a bidirectional tunnel (downlink and uplink) is established between the old FA and the new one. When the L2-HO is finished, the MN can register with the new FA while receiving the packets. Thus, the MN receives the packets before the registration. [BCCW03] and [CCWB+03] describe performance studies and an implementation of the preregistration and post-registration method, respectively. [BCCW+03] present a comparison between the two methods. The simulation results indicate that the timing of the trigger has a major influence on the latency of the handoff methods as well as the packet lose rate. If the L2-trigger for PreRegistration is delayed, increased latency results. In case the Registration Request (Reg-Rqst) is dropped, the method resorts to standard L3-HO method, e.g. MIP or HMIP. In addition, the causes for latency of MIP still remain which is due to the forwarding delay between the FA and the HA. Even though Post-Registration is faster than Pre-Registration, the impact of delayed L2-triggers with Post-Registration is the same as with Pre-Registration. Due to the missing MIP registration with the Post-Registration approach, the packet delay is larger (uplink and downlink). The combined method (i.e. to try pre-registration first and to use post-registration if it fails) inherits the problems of the both approaches. To avoid the negative impact of timing problems, an improved approach is proposed in [PJ-SCT02]. In this approach the MN scans for other APs similar to the Pre- and Post-Registration methods. When the MN notices that a handoff is necessary, it informs the current FA about this and registers with the new FA through the old one similar to the PreRegistration approach. However, the old FA forwards the packets directly to the new FA without waiting of L2-LD trigger. Thus, the negative impact of the timing of the L2-trigger is eliminated. When the new FA receives a Reg-Rply from the HA and the link to the MN is established (receiving the Link Up trigger ), it forwards Reg-Rply message and the packets forwarded from the previous FA and from the HA to the MN. However, the problems of MIP due to transmission delays between the HA and the FA remain. Also note that the low latency methods violate the separation between the layers 2 and 3. II Proposed Protocol 1 Basic idea Mobile IP Fast Authentication protocol (MIFA) avoids the problems of MIP. The basic idea of MIFA is that the HA delegates the authentication to the FA. Note that this does not require the

P48/2

distribution of the shared secret between the HA and the MN to the FA. Thus, there is no need to forward the Registration Request (Reg-Rqst) send by the MN beyond the FA, e.g. to the HA. Instead, the FA directly replies a Registration Reply (Reg-Rply) to the MN. The basic operation of MIFA is depicted in Figure 1. After receipt of the Reg-Rply, the MN can resume the transmission on the uplink. In downlink a tunnel is established to forward the packets, arriving at the previous FA, to the current FA, until the HA is informed about the movement of MN. The HA establishes then a tunnel to forward the packets directly to the current FA. In our approach the delay to forward Reg-Rqst from the FA to the HA and to send Reg-Rply form the HA to the FA is eliminated. The packets will be received by the previous FA while the HA establishes the new tunnel to the current FA. Thus, Layer3-Handoff delays are reduced. The local authentication by FAs relies on groups of neighbouring FAs. Each FA defines a set of neighbouring FAs called a Layer3 Frequent Handoff Region (L3-FHR) [PaCh02].

Figure 1: Registration with MIFA and MIP

These L3-FHRs can be built statically by means of standard algorithms (e.g. neighbour graph [Sen99] or others [PaCh02]), or dynamically by the network itself, by observing the movements of MNs. We define tha t FA2 is a neighbour of FA1, if the MN performs a Layer3-Handoff when moving outside of the area covered by the APs belonging to the FA1 to the APs belonging to the FA2. Typically the L3-FHR of a FA consists of a small number of FAs compared to the whole number of FAs the MN may connect to. Every FA defines its own L3-FHR. The L3-FHR doesn’t necessarily comprise all of the adjacent FAs, e.g. in the case of physical obstacles between the areas that prevent a move between the adjacent FA areas. There is a security association between the FAs in one L3-FHR. This security association can be established statically, e.g. by the network administrator, or dynamically, e.g. by the network itself by depending and evolving the methods described in [BA00], [PR01]. 2 MIFA description For the initial registration, the MN uses the regular MIP procedures. In addition, the MN informs the FA and the HA that it prefers to use MIFA in future registrations. As a response to this, the HA builds a security association between the HA and the FA K1FA-HA on one side and between the MN and the FA on the other side K1MN-FA. The FA in turn derives the keys, generates two random variables R1, R2, generates another key (K2MN-FA) between the MN and the FAs in the L3FHR, to which the current FA belongs to, encrypts K2MN-FA with K1MN-FA, add R1,R2 and the encrypted K2MN-FA in extentions to the Reg-Rply message, authenticates the new message with

P48/3

K1MN-FA, and sends it to the MN. Next, the FA performs the Initial_Authentication_ Exchange procedure (Figure 2).

Figure 3: Move_Notification

Figure 2: Initial_Authentication_ Exchange

With this procedure, the current FA sends a Move_Probability_Notification to the HA. The message contains two random variables R1, R2 and the security association between the HA and all of the FAs in the L3-FHR, to which the current FA belongs to, (K2FA-HA). This key is encrypted with K1FA-HA, which has been generated during the initial registration. K1FA-HA authenticates This message too. The HA responds to the notification by sending an Acknowledgement (Move_Probability_Acknowledgement ). In order to notify the FAs in the neighbourhood of a potential handoff of a MN, the current FA performs the Move_Notification procedure (Figure 3). With this procedure the current FA sends a Move_Probability_Notification to all of the FAs in the L3-FHR. The message contains the security associations between the MN and the FAs in the L3-FHR (K2MN-FA) and between these FAs and the HA (K2FA-HA). These security associations are encrypted with the shared security association existing between the FAs (KFA-FA), which authenticates these messages too. The MN will move to one of these FAs. As a result, the two keys will be used by one of these FAs and deleted from the others, when the keys lifetime expires. Each neighbouring FA replies optionally a Move_Probability_ Acknowledgment as a response to the notification, as depicted in figure 3. Next, the Authenticators_Exchange procedure is executed as shown in figure 4 to transmit the authentication information to every FA of the L3-FHR. Each FA in the L3-FHR sends an Authentication_Information_Request to the HA. This message is authenticated by K2FA-HA. The HA then responds by an Authentication_Information_Response. This message contains the authentication values that the MN and the HA have to generate in the next registration. In addition, the message includes the supported features of the HA (e.g. simultaneous binding, GRE, etc..) which are required by the FA to decide whether the MN is authenticated or not and whether the requirements of the MN can be satisfied or not.These featurres are used to support replay protection too. This message is authenticated by K2FA-HA. The Authenticators_Exchange procedure is optional as depicted in figure 4. Instead of using this procedure, the information existing in the Authentication_Information_Response can be sent with the Move_Probability_ Acknowledgment message sent from the HA to the current FA during the Initial_Authentication_ Exchange procedure. The current FA spreads this information to the neighbouring FAs with Move_Probability_Notification procedure. This guarantees the scalability of MIFA. When the MN moves to one of these FAs it performs the Registration_by_Neighbour _Agent procedure (Figure 5). The MN receives an Agent_Advertisement, which indicates that the current FA supports MIFA. The MN builds and sends a Reg_Rqst to this FA. This message contains MIFA authentication information and will be authenticated by the security association existing between the MN and the FA (K2MN-FA). The current FA then compares the MN-FA authentication information using K2MN-FA. If the authentication succeeds, it compares the MIFA authentication information and the identification field, to be sure that the replay protection requirements are met. If these requirements are met, the current FA examines whether the HA can satisfy the requirements of the MN (by examination of the features supported by the HA). If this examination is successful, the current FA sends a Previous_FA_Notification to inform the previous FA that it must tunnel the

P48/4

packets destined to the MN, to the current FA. This message is authenticated by the FA-FA security association (KFA-FA).

Figure 4: Authenticators_Exchange

Figure 5: Registration_by_Neighbour_Agent

The current FA then generates two random variables R1,R2, generates the keys (K3FA-HA, K3MN-FA), which will be used to authenticate the messages in the next registration with the next FA in the L3FHR, encrypts K3MN-FA with K2MN-FA and sends Reg-Rply message to the MN. This message contains of extentions containing R1, R2, and the encrypted K3MN-FA additionally to the standard fields used by MIP. After that the current FA encrypts K3FA-HA with K2FA-HA and sends an HA_Notification to inform the HA about the new binding, the two random variables and the encrypted K3FA-HA are sent with this message. The HA then sends an HA_Acknowledgment message and starts to establish the tunnel to the current FA. The HA_Acknowledgment message contains the information existing in Authentication_ Information_Response message if the Authenticators_Exchange procedure is not in use. After that the current FA sarts then the Move_Notification procedure. When the previous FA receives Previous_FA_Notification message it sends a Move_Probability_ Acknowledgment as a response to this message and starts the tunneling of the packets destined to the MN to the new FA. In order to be compatible with MIP and to avoid that the communication is disrupted due to a loss of a MIFA control message, each MIFA Registration Request has to contain the MN-HA authentication extension. When a failure happens during any MIFA procedure (message loss), the Reg_Rqst will still be processed by MIP. III Comparison with Mobile IP We have designed a simple analytical model to compare the proposed protocol with Mobile IP. The network topology used is shown in Figure 1. We define the following terms: TWL : The time required for a message to pass through the wireless link from the MN to the FA. TW : The time required for a message to pass through the wired link from the FA to the HA. TPFA: The time required for a message to pass through the wired link from the current FA to the previous FA. P48/5

PMN: The time required by the MN to process the registration. PFA: The time required by the FA to process the registration. PHA: The time required by the HA to process the registration. PPFA : The time required by the previous FA to process the registration. We define the following values: TWL = 5 ms, TW = 10 … 100 ms, TPFA = 5 ms. The processing time for the hash function for authentication (HMAC-MD5) [KBC97] is assumed to be 1 ms. The assumed time to generate a key and to build a message is 1 ms, respectively. The calculation starts from the time of receiving an Agent_Advertisement message from the FA. The security associations (SA) considered in this analysis in the case of MIFA are: MN-current FA_SA, current FA-HA_SA, current FA-previous FA_SA and MN-HA_SA. In the case of MIP MN-HA_SA is considered. In the case of MIP, the time required by the MN to resume transmission in uplink and to receive data in downlink is given by equation [1]: TMN-Uplink = TMN-Downlink = TMN = P + 2*T [1] where T = TWL + TW and P = P MN + P FA + P HA Filling in the values specified above, we obtain the equation [2]: TMN (ms) = 25 + 2 * TW [2] From the equation [2] we notice, that the time TMN dependents on TW . Thus, this time will increase when TW increases. In the case of MIFA, the time required to resume transmission in uplink by the MN is independent of TW and given by equation [3]: TMN-Uplink = P + 2 * T [3] with T = TWL and P = P MN + P FA Entering the assumed values, we obtain equation [4]: TMN-Uplink(ms) = 40 ms [4] From equation [4] we notice, that the time TMN-Uplink is independent of TW . Thus, an increase of TW does not have a negative impact on the operation of MIFA. The time required to resume reception of downlink data is given by equation [5]: TMN-Downlink = P + 2 * T [5] where P = PMN + PFA + PPrevious FA and T = TWL + TPFA Entering the assumed values, we obtain equation [6]: TMN (ms) = 50 ms [6] The calculations show that MIFA benefits from the established tunnel between the HA and the previous FA. Until the new tunnel between HA and current FA is established, MIFA uses an additional tunnel from the previous FA to the current FA. Thus, the time required for the MN to resume reception of data in downlink is independent of TW as well. This means that MIFA performs a seamless and fast handoff independent of TW , i.e. the distance between FA and HA. Until a new tunnel between the HA and the current FA is established, the previous FA forwards the packets to the current FA. Thus, the latency resulting from the establishment of the new tunnel between current FA and HA is hidden. Figure 6 shows the time required to resume transmission in uplink by the MN for MIFA and MIP when TW = 10, 25, 50, 75 and 100 ms, respectively. From the figure we can notice that MIFA is faster than MIP even when the HA is close to the FA. E.g. for TW = 10 ms, MIFA is 5 ms faster than MIP . When TW increases, the advantage of MIFA increases. The time required in case of MIP is dependent on TW and will increase when TW increases. However, in the case of MIFA this time is independent of TW . Therefore, it will not increase (TW = 25 ms, MIFA is 35 ms faster than MIP; TW = 50 ms, MIFA is 85 ms faster than MIP; TW = 75 ms, MIFA is 135 ms faster than MIP).

In Figure 7, the time required to resume data reception in downlink by the MN is shown for MIFA and MIP when TW = 10, 25, 50, 75, and 100 ms, respectively. The figure shows that MIP is (1 to 5 ms) faster than MIFA when the HA is close to the FA (TW = 10 to 12 ms). However, if TW increases, MIFA will outperform MIP.

P48/6

Figure 7: TMN- Downlink = f(TW )

Figure 6: TMN- Uplink = f(TW )

For this case the independence of MIFA from the distance between the HA and the FA makes it faster than MIP (TW = 25 ms, MIFA is 25 ms faster than MIP; TW = 50 ms, MIFA is 75 ms faster than MIP; TW = 75 ms, MIFA is 125 ms faster than MIP).

We summarize that because of the independence of MIFA from TW , it is more efficient than MIP for most cases, especially where the time required for the message to pass through the wired link between the current FA and the HA is large. Additionally, MIFA eliminates the reasons for latency present in MIP. Moreover, MIFA improves the security of the connection due to the mandatory addition of the FA in the security association. VI Comparison with Hierarchical Mobile IP In order to compare MIFA with Hierarchical Mobile IP (HMIP) another simple analytical model has been designed. The network topology used for this study is shown in Figure 8. We define the following terms: T1 ,T2 ,T3 : The time required for the message to pass through two adjacent nodes on the wired link. PRFA: The processing time required by the Regional FA for the registration. PGFA : The processing time required by the GFA for the registration. The following values for these terms are assumed: T1 =T2 =T3 = 3 ms, TWL= 3 ms, TPFA= 3 ms and TW = 10…100 ms. The assumed processing time to authenticate a message using HMAC-MD5 is 1 ms, as well as the time to generate a key and to build a message. The calculation starts from the time of receiving an Agent_Advertisement message from the new FA. When the MN enters a new domain, it performs the home registration procedure to register the new Care-of Address (the CoA of the GFA) at the HA. This means that MIP cooperates with HMIP in this registration. The time required for this procedure has been defined by equation [1]. When we suppose that the MN initially registers with the FA1 (see Figure 8) the details in equation [1] will be: T = TWL + TW + T1 + T2 + T3 and P = PMN + PFA1 + PRFA3 + PRFA1+ PGFA+ PHA When we enter the values specified above, we obtain equation [7]: THMIP-Uplink = THMIP-Downlink = 49,5 + 2*TW [7] This is the time after which the MN can resume transmission in uplink and receive data in downlink. The equation shows that the time required for resuming transmission and reception depends on TW . Thus, the disruption time will increase when TW increases. In the case of MIFA, the time after which the MN can resume transmission in uplink is given by equation [3] with the terms T = TWL and P = PMN + P FA1 Applying the assumed values , we get: TMN-Uplink(ms) = 27 ms [8] The time required to resume reception in downlink is given by equation [5] with the terms: T = TWL and P = PMN + P FA1 + PPFA

P48/7

Figure 8: Network topology for HMIP

Filling in the assumed values we get [9] Figure 9 shows the relation between TMN-Downlink and TMN-Uplink for TW = 10, 25, 50, and 100 ms, respectively. In Figure 9 we see that for the case that the MN enters a new domain, MIFA is more efficient than HMIP for the both directions (uplink and downlink). This is because of the independence of MIFA from TW. The movement of the MN is independent of TW provided the MN moves inside the domain. This is similar to MIFA. In case the MN moves from the area covered by the FA1 to the area covered by the FA2, only the RFA3 must be aware of this movement. This means that the MN registers with the second level of the hierarchy. The time required by HMIP for the registration with RFA3 is defined again by the equation [1] with the terms : T = TWL + T1 and P = PMN+ PFA2+PRFA3 Entering the assumed values specified above, we get : THMIP-Uplink=THMIP-Downlink = 24 ms [10] Let us suppose that the MN will move from the area covered by the FA2 to the area covered by the FA3. In this case, the movement will only be controlled by the RFA1. Thus, the MN registers with the third level of the hierarchy. Applying equation [1], we obtain the time required to complete the registration with RFA1 for the case that the MN supports HMIP. P and T are defined as follows: T = TWL + T1 + T2 and P = PMN + PFA3 + PRFA4 + P RFA1. Entering the assumed values, we get : THMIP-Uplink=THMIP-Downlink = 32 ms [11] When the MN now moves from the area covered by the FA3 to the area covered by the FA5, the GFA must be aware of this movement. This means that the MN registers with the fourth level of the hierarchy. The time required in case of HMIP to complete the registration with the GFA is given by equation [1], too. P and T are defined as the follows: T = TWL + T1 + T2 + T3 and P = PMN + PFA5 + PRFA5 + P RFA2 + PGFA Filling in the values as specified above, we get: THMIP-Uplink = THMIP-Downlink = 40 ms [12] Figure 10 shows a comparison between the time required to resume transmission in uplink and to continue receiving in downlink in the case of MIFA and in the case of HMIP, when the MN registers with the second level, the third level and the fourth level of the hierarchy. Figure10 shows that HMIP outperforms MIFA in the case that the second level of the hierarchy is informed about the movement of the MN. HMIP is about 3 ms faster than MIFA in uplink and about 15 ms faster in downlink. If the third level of the hierarchy is informed about this movement, with HMIP the MN TMN-Downlink(ms) = 39 ms

P48/8

resumes the reception in downlink 7 ms earlier than with MIFA. In opposite to this, the MN resumes transmission in uplink 5 ms earlier with MIFA. If the movement is controlled by the fourth level of the hierarchy, MIFA is faster than HMIP in the both directions. The MN resumes reception in downlink 1 ms faster with MIFA than with HMIP. In uplink the advantage of MIFA is 13 ms. These differences remain constant regardless of TW . Summarizing the comparison, we can state the following: • MIFA adds extra security to the connection because the FA authenticates the MN by using the MN-HA and the MN-FA security association while HMIP authenticates the MN only by using the MN-FA security association. • MIFA does not require a hierarchy of FAs and only the FA and the HA must support MIFA. This is different to HMIP where a hierarchical structure of mobility agents must be installed and maintained which all have to support HMIP. • With respect to performance, MIFA and HMIP are comparable. • MIFA supports falls back to MIP in the case of errors or missing MIFA support. • MIFA may be combined with HMIP to improve the handoff between the domains. This can be achieved by supporting MIFA in the GFAs. Thus, the MN can move from one domain to another without the need of registration at the HA.

Figure 10: Comparison between MIFA and HMIP for the different hierarchical levels

Figure 9: TMN-Downlink /-Uplink = f(TW )

IV Conclusion Compared to MIP, MIFA reduces the re-authentication and the re-registration latency, and enables the FA to authenticate the MN accurately. Thus, there is no loss of security. In addition, it enables the MN to quickly resume the transmission of data packets in uplink and downlink. Thus, the handoff latency is reduced. This also should reduce the problems with wireless TCP connections. A comparison with HMIP shows that MIFA is comparable to HMIP with respect to performance and does not need the hierarchical structure of mobility-aware nodes as it is the case with HMIP. In addition, MIFA can be combined with HMIP to improve the handoff between the domains. Currently, we implement the MIFA protocol with the Network Simulator (NS2) in order to perform a detailed performance study of the protocol. References [Per98] Charles E. Perkins. MOBILE IP - Design Principles and Practices. 1998. [Per02] C. Perkins, Ed, Nokia Research Center. IP Mobility Support for IPv4. RFC: 3344 August 2002 [Gon98] J. Maria Gonzälez. Mobile IP. Internet draft, March 1998. http://www.cs.berkeley.edu/~adj/cs 294-1.s98/notes5.html, January 2004.

P48/9

[PR01] Charles E. Perkins (Nokia Research Center), Pat R (Calhoun Sun Microsystems Laboratories). Generalized Key Distribution Extensions for Mobile IP. draft- ietf- mobileip-genkey-00.txt. 2 July 2001 [BA00] David B. Johnson, Nokia Research Center, Carnegie Mellon University, N. Asokan, Nokia Research Center. Registration Keys for Route Optimization. < draft- ietf- mobileip-regkey-03.txt >. 14 July 2000. [DY00] Gopal Dommety, cisco Systems, Tao Ye, RPI. Local and Indirect Registration for Anchoring Handoffs. < draft-dommety- mobileip-anchor- handoff-01.txt >. July 2000. [GJP98] Eva Gustafsson, Annika Jonsson, Charles E. Perkins. Mobile IPv4 Regional Registration. < draft- ietf- mobileip-reg-tunnel-08.txt > 22 November 2003. [ElMa02] K. El Malki et al. Low Latency Handoffs in Mobile IPv4. draft- ietf- mobileip- lowlatencyhandoffs-v4-04.txt, June 2002. [BCCW03] C. Blondia, O. Casals, L1. Cerda, N. Van den Wijngaert, G. Willems, P. De Cleyn. Low Latency Handoff Mechanisms and Their Implementation in an IEEE 802.11 Network. Proceedings of ITC18, Berlin, Germany, 2003. [BCCW+03] C. Blondia, O. Casals, L1. Cerda, N.Van den Wijngaert, G.Willems, P.De Cleyn. Performance Comparison of Low Latency Mobile IP Schemes. Proceedings atWiOpt’03 Modeling and Optimization in Mobile Ad Hoc and Wireless Networks, INRIASophia Antipolis, pp. 115-124, March 2003. [CCWB+03] O. Casals, L1. Cerda, G. Willems, C. Blondia, N. Van den Wijngaert. PerformanceEvaluation of the Post-Registration Method, a Low Latency Handoff in MIPV4 . Proceedings of IEEE 2003 International Confernence on Communications (ICC 2003),Anchorage, May 2003. [PJ-SCT02] Shiva Raman Pandey,Satish Jamadagni, Sasken Communication Technologies Ltd. Improved Low Latency Handoff in Mobile IPv4. < draft-shiva- improved- lowlatency-handoffv4-01.txt > February 2002. [PaCh02] S. Pack, Y. Choi. Fast Inter-AP Handoff using Predictive-Authentication Scheme in a Public Wireless LAN. Networks 2002, Aug. 2002. [Sen99] S.K. Sen, et al. A Selective Location Update Strategy for PCS Users. ACM/Baltzer J. Wireless Networks, September 1999. [KBC97] H. Krawczyk, M. Bellare, R. Canetti, HMAC: Keyed-Hashing for Message Authentication, RFC: 2104 , February 1997.

P48/10