Inter-subnet localized mobility support for host identity protocol
© Muslam et al; licensee Springer. 2011
Received: 27 November 2010
Accepted: 4 August 2011
Published: 4 August 2011
Host identity protocol (HIP) has security support to enable secured mobility and multihoming, both of which are essential for future Internet applications. Compared to end host mobility and multihoming with HIP, existing HIP-based micro-mobility solutions have optimized handover performance by reducing location update delay. However, all these mobility solutions are client-based mobility solutions. We observe that another fundamental issue with end host mobility and multihoming extension for HIP and HIP-based micro-mobility solutions is that handover delay can be excessive unless the support for network-based micro-mobility is strengthened. In this study, we co-locate a new functional entity, subnet-rendezvous server, at the access routers to provide mobility to HIP host. We present the architectural elements of the framework and show through discussion and simulation results that our proposed scheme has achieved negligible handover latency and little packet loss.
KeywordsHIP mobility micro-mobility
Host mobility support is one of the key features of the next generation network which is the All-IP-based heterogeneous networks . The duality problem of IP addresses  in simultaneously serving as both host identifier and locator in the Internet is the major issue that makes host mobility support challenging.
During a communication session, a mobile node (MN) may move within a single domain (micro-mobility) or move to a different domain (macro-mobility) . These two main scenarios can be managed at different layers of the conventional TCP/IP stack . Access technologies can manage intra-link mobility (L2 handoff) and may assist one to trigger L3 handoff. The IP layer solutions are most common, especially in a heterogeneous network environment. Mobile IP (MIP) , which is one of the IP layer solutions, extends the ability of the Internet to support the host mobility, but has security threats such as Denial of Service attack (DoS) .
Host identity protocol (HIP) is developed by Internet Engineering Task Force (IETF) to provide secured mobility support in a simpler manner than the other proposed solutions  and the popular MIP [7, 8].
Mobility extension for HIP allows HIP-enabled mobile host to move with negligible handover latency (HOL) in environment where the global mobility management is acceptable but introduces long HOL and unnecessary control messages in a micro-mobility environment . Such long HOL not only increases packet loss and delay but also decreases the performance of the upper layer application, particularly the real-time application such as Voice over IP. Therefore, there is the need to develop an adequate and efficient solution to reduce HOL as well as mobility-related signaling of HIP in micro-mobility environment while retaining the same level of security of HIP. The proposed solution should support mobility to allow the mobile users access their services wherever they go in a secure and efficient manner. Some issues where localized mobility management is needed have been discussed in .
The proposed contributions in this article are (1) introducing of network-based mobility management using HIP technology, (2) development of an architecture that can be easily extended to offer HIP service for non-HIP-enabled MN, and (3) qualitative and quantitative investigations for HIP and some widely referenced HIP-based micro-mobility solutions as well as our proposed solution.
This article describes HIP (Section 2) and discusses the related work in HIP-based micro-mobility (Section 3). It then presents the proposed inter-subnet localized mobility solution (Section 4); and performance analysis based on analytic model (Section 5); and performance analysis based on simulation (Section 6); and conclusions in Section 7.
2. Host identity protocol
2.1. HIP Base Exchange
2.2. Mobility and multihoming in HIP
Mobility and multihoming support for HIP is presented in a separate IETF document . This extension allows the HIP-enabled MN to notify its peers about the set of new locators by exchange of three UPDATE packets. When an MN moves, it includes the new locator into an UPDATE packet and sends to its peers. Afterward, the peers of the MN can redirect the traffic to the new location of the MN after the required address check is performed. The purpose of the address check is to protect against different security threats due to mobility such as a DoS and traffic flooding. Moreover, a global mobility anchor point, which is the HIP rendezvous server (RVS) , is employed to offer stable location information for the MNs that are registered on the RVS. Therefore, any host who wants to communicate with the HIP MN can find the current location of the corresponding MN at the RVS.
The HIP also efficiently and securely provides multihoming feature, which is a feature that enables HIP MN to have more than one locator at the same time. The same procedures that were used to inform MN's peers about mobility (i.e., new locator) are used to inform MN's peers about multihoming (i.e., multiple locators at which MN can be reached at the same time). The HIP MN can also "declare" and use one of these locators as the preferred locator.
3. Related work
This section briefly describes the existing micro-mobility solutions based on HIP and their shortcomings. The HOL varies in different handover scenarios , for example, in macro-mobility and micro-mobility scenarios.
There is no adequate micro-mobility management solution for HIP but only some proposed solutions [16–18]. A local rendezvous server (LRVS)  has been utilized in the micro-mobility architecture for HIP. The LRVS extends the normal HIP RVS to perform network address translation as well as the normal RVS functions. Once the MN enters a given local domain, it detects the LRVS in the visited network either by actively initiating a service discovery procedure or passively waiting for a service announcement. Then, the MN registers itself at the LRVS. The LRVS also registers its IP address and the MN information at the RVS. The MN, therefore, notifies the LRVS instead of the correspondent node (CN) to redirect the data traffic to its new location, i.e., the new local IP (LIP) address. However, this solution does not avoid IP address configuration and re-registration at the LRVS whenever the MN moves from one subnet to another within the same domain. The IP configuration, which requires Duplicate Address Detection (DAD), adds some delay to the handover process while the re-registration takes considerable time that also contributes to the HOL. Moreover, for the registration, the MN always sends its new IP address to the LRVS even when there is a cross-over point between the old PoA and the new one. Hence, the time required to do the re-registration at the LRVS is relatively higher than that required at a topologically closer one (i.e., cross-over). Furthermore, during the registration at LRVS, the LRVS continues to forward the ongoing packets that are destined to the MN to the old Access Router (AR) that was the previous PoA for the MN. This increases packet delay and loss.
Another method for securing micro-mobility that is more reasonable for hierarchical mobility domains is presented in . It focuses on the authentication of the location-binding update messages to prevent the possible security issues such as man-in-the-middle attack and DoS. It uses regional anchor point which supports the dynamic binding between the end-point identifiers and their IP addresses. Once an MN enters a given region, it does not need to register at any mobility anchor points within that region. During the SA establishment, mobility anchor points in the region learn the required security context and current location information of the MN, while the nearest anchor point (NAP) only knows the shared secret key of the communication session. The solution is based on the use of Lamport one-way hash chains and secret-splitting techniques to bind the messages of location updates (LU) together and to establish a SA between the MN and the nodes (e.g., anchor points in a domain) along the path of the MN and CN.
However, this solution behaves as a macro-mobility solution in many situations. For example, if the Lamport one-way hash chain reaches the seed value or a man-in-the-middle attack between the MN and the NAP occurs, then this scheme requires the creation of a new hash chain. Furthermore, the scheme still needs to reconfigure its LIP if the MN changes its PoA, thus affecting the HOL, signaling overhead and packet loss, as well as compromising location privacy.
Finally, a HIP-based mobility management architecture scheme which used tight coupling between the UMTS and WLAN is proposed in . The architecture uses a RVS in the UMTS network to handle the handover process with a strategy to establish a new connection before terminating the previous one. However, it still suffers from the same problem that was faced by [16, 17] in terms of IP configuration delay as a result of IP address changes. The signaling flow of this scheme is similar to that of the scheme in , who, however, use the RVS to manage the mobility in a domain rather than using the LRVS. Even though the handover performance is improved, it still needs to be optimized.
4. Proposed inter-subnet mobility solution
The design of our scheme is based on two principles: (1) distributed caches are employed to store fresh R1 pre-computed packets; and (2) MN will use the same IP address, as it remains within a single domain.
The caching of fresh pre-computed R1 packet at LRVS optimizes the handover performance when re-keying is required because of a handover. Besides the re-keying, the HIP SA can be timeout. In both cases, the re-establishment of the HIP SA is required.
When a MN enters a given domain for first time, the complete process is illustrated in Figure 4: the INITIAL REGSTRATION part that is explained hereafter. The S-RVS on the access link to which the MN is attached, i.e., S-RVS1, first detects the MN and then sends an UPDATE packet (UPDATE packet 1) with registration flag to the LRVS. The packet includes the HIT of the MN. Upon receiving the UPDATE packet 1, the LRVS responds with the UPDATE packet 2. The UPDATE packet 2 includes a network prefix that will be delivered to the MN at any subnet in the given domain. After receiving the UPDATE packet 2, S-RVS1 sends a Router Advertisement (RA) including the network prefix for the MN to configure its IP address.
If the MN intends to communicate with a HIP host (e.g., CN), it then needs first to establish a HIP SA as explained in section (IIA). In this case, the MN sends I1 (triggers HIP SA establishment) packet to the S-RVS1, which in turn forwards the packet to the LRVS. Then, LRVS further forwards the packet to the CN through the RVS.
The exchange of the remaining packets (i.e., R1, I2, and R2) goes directly (i.e., not via the RVS) between the MN and the CN. After successful exchange of these packets, a HIP SA will be established between the initiator (i.e., MN) and the responder (i.e., CN). Through the SA establishment all the S-RVSs along the path between the MN and the LRVS are aware of the SA context.
When the MN performs intra-domain handover, S-RVS1 (i.e., old S-RVS) is no longer the serving S-RVS. The new S-RVS detects the attachment of the MN and sends an UPDATE packet 1 to the LRVS. Upon receiving the UPDATE packet 1, LRVS verifies the MN and then updates the MN's binding record. Afterward, LRVS responds with the UPDATE packet 2. Using the content of the UPDATE packet 2, the new S-RVS sends an RA, which includes the same network prefix that MN employed to configure its IP address during the initial registration, to the MN. The MN, therefore, retains the same IP address configuration. This may significantly reduce the HOL and signaling overheads due to handover. It is important to note that the proposed solution is intended for IPv6 networks. In addition, the study in this article is mainly concerned about localized mobility management where the host mobility is very high, but the efficient management of inter-domain handovers is expected to be taken up in future study.
This HIP-based micro-mobility management solution reduces the HOL and signaling overheads by allowing an MN to use the same IP address (to avoid the DAD process as it remains within a single domain) and sending the MN's HIT and assigned network prefix to the other S-RVSs (e.g., S-RVS2) at an appropriate time. Then, the new S-RVS sends both the same network prefix to the MN to retain the same IP configuration, and the UPDATE packet 1 to the LRVS to set up a new path for the ongoing traffic. The use of the same IP address supports the location privacy. Furthermore, the use of HIT in the upper layer protocol instead of IP address enables HIP host to use the established HIP associations during and after the handover, since the communication context remains the same. Moreover, reducing the time taken to perform HIP BE can also reduce the handover delay when the re-establishment of HIP SA is required. Having S-RVS also eliminates the need for a new location reachability check between the MN and its peer, because the new location of the MN is known to the serving S-RVS. The number of S-RVSs in a domain depends on the domain's size, and each subnet is managed by an S-RVS which acts as the authoritative S-RVS for that subnet. The number of MNs in each subnet must not exceed the capability of the S-RVS. This method can also manage simultaneous move of communicating parties (i.e., when the communicating parties move at the same time) and multihoming in an easy and efficient manner.
S-RVS is co-located within the ARs that are deployed in secure private networks. In addition, HIP hosts (i.e., MN and CN) still establish SA between themselves while S-RVSs only manage mobility packets using an established SA. Therefore, neither security nor reliability of HIP MN will be compromised by introducing S-RVS in a secure private network.
It is important to note that we provide a network-based micro-mobility support at HIP layer but not at IP layer as do some proposed solutions [19, 20]. Solutions [19, 20] are about using of PMIPv6  to support HIP MNs. Yet, both solutions are using IP technology to support host mobility for HIP MN. The main difference between providing mobility supports at HIP layer and at IP layer is that the first can utilize all the HIP features, which are security, multi-homing, interoperability between IPv6/IPv4, and mobility. Furthermore, our proposed scheme can easily be extended to support host mobility using HIP technology for non-HIP MN.
5. Analytic evaluation of handover performance
We assumed that HIP MN registered at the RVS with binding contains the MN's HIT and IP addresses of the MN which can currently be reached. We also assumed that the MN has ongoing communications with both CN 1 and CN 2 as shown in Figure 5.
When a HIP node moves from one PoA to another, the following HOL components are involved:
The latency due to the MN's movement detection (MD) at IP layer in MN's stack, LMD.
The latency due to the MN configuring its current IP address at the new location, LIP_CONF.
The latency due to the HIP MN sending the update message with a locator parameter (carried in the first UPDATE packet) to update the CNs, LLU1_CN.
The latency due to the sending of the second UPDATE packet from CN to MN to verify the new locator, LLU2_CN.
The latency due to the sending of the third UPDATE packet from the MN to CNs to confirm verification of the new locator, LLU3_CN.
where i = 1...n; n is the number of CNs to which MN has ongoing communications. In addition, n must be greater than or equal 1. This is because no UPDATE packets are needed when MN does not have any connection with CN (i.e., n = 0).
After the HOL, both CN 1 and CN 2 redirect their data traffic to the new location of the handed over MN. Yet, RVS can only direct any host that intends to establish a new communication with the handed over MN to the old POA of the MN. This continues until an MN updates its record at the RVS. The following latencies affect the required time for MN's binding update at RVS:
The latency due to the HIP MN sending the update message with a locator parameter (carried in the first UPDATE packet) to update the RVS, LLU1_RVS.
The latency due to the sending of the second UPDATE packet from the RVS to MN to verify the new locator, LLU2_RVS.
The latency due to the sending of the third UPDATE packet from the MN to RVS to confirm verification of the new locator, LLU3_RVS.(2)
where n is the number of CNs to which MN has ongoing communications, while 3 indicated the number of the required UPDATE packets to inform each CN or to update the MN's binding at the RVS.
Having the same assumption to examine handover performance of the HIP, we developed another analytic model to measure HOL and mobility-related signaling overheads of Micro-HIP while an MN has two ongoing communications with both CN 1 and CN 2 as shown in Figure 6. From the figure, when an MN performs a handover from POA1 to POA2, the following HOL components are involved:
The latency due to the MN's MD at IP layer in MN's stack, LMD.
The latency due to the IP address configuration of the MN at the new PoA, LIP-CONF.
Latency due to the HIP MN sending the update message with a locator parameter (carried in the first UPDATE packet) to update the relevant components (LRVS), LLU1_LRVS.
Latency due to the sending of the second UPDATE packet from the LRVS to MN to verify the new locator, LLU2_LRVS.
The latency due to the sending of the third UPDATE packet from MN to LRVS to confirm the verification of the new locator, LLU3_LRVS.
Unlike the HIP, the use of the Micro-HIP allows the MN to only inform LRVS about the new IP address. Three UPDATE packets as shown in Figure 6 are enough to redirect the data traffic to the MN's new location. Evidently, by explanations on Figure 6 and the developed analytic models for HIP and Micro-HIP, HOL and mobility related signaling overheads of the Micro-HIP are partially optimized. Yet, the HIP and the Micro-HIP have signaling overheads on the MN's interface and further incur the signaling overheads of the new IP configurations because of the MN's handover.
5.3. Our scheme
Figure 7 shows an explanation of handover management using our proposed scheme while the MN has ongoing communications with two CNs, CN 1 and CN 2. Again, based on the same assumption to evaluate handover performance of the HIP and the Micro-HIP, we developed an analytic model to measure HOL and mobility-related signaling overheads while the MN has ongoing communications with CN 1 and CN 2.
Our proposed scheme has the following components contributing to HOL:
The latency due to the MN's attachment detection (AD) at IP layer in POA's stack, for which reason, we called it attachment rather than MD, LAD.
Latency due to the two way handshake readdressing protocol, between S-RVS and LRVS, LLU1 + LLU2.
A comparison between Equations 1, 4, and 5 that describe HOL of the HIP, the Micro-HIP, and our proposed scheme shows the advantages of the last one, Equation 5. Our proposed scheme is better than those of the HIP and the Micro-HIP, Equations 1 and 4, respectively, because our proposed scheme reduces LU latency and the number of the required UPDATE packets as well as eliminates messages and latency related to the configuration of the new IP address.
Signaling overheads of HIP, Micro-HIP, and our proposed scheme
# of UPDATE packets per handover when communicating with two CNs
# of UPDATE packets per handover when communicating with n CNs
3*(n + 1)
Signaling overheads on MN's interface
Signaling overheads due to configuration of new IP address
The first row in Table 1 shows that the number of binding update messages when the MN has ongoing communication sessions with the two CNs. In addition, the number of binding update messages when MN has ongoing sessions with n CNs are shown in the second row of the table. It is important to note that mobility-related signaling overheads of the plain HIP are highly affected by increasing the number of the CNs to which MN has ongoing communication sessions. In contrast, mobility-related signaling overheads of the Micro-HIP and our proposed scheme do not get affected by increasing the number of CNs. This is because the Micro-HIP and our scheme update only the network gateway, irrespective of how many CNs with which MN has ongoing communication sessions. It is also important to note that the HIP, the Micro-HIP, and our proposed scheme need not consult any third party for security purpose as they have capabilities of self-certifying because of the HIP layer. However, schemes [19, 20] need to consult a third party for security purposes. This third-party security consultation incurs costs of additional signaling overheads and adds some delay to the total HOL.
6. Simulation results
# of POA
# of MN
UDP packet transmit rate
Min router Adv. Interval
Max router Adv. interval
850 * 850
Before showing our investigation of handover performance for the HIP, the Micro-HIP, and our proposed scheme, we need to first identify the evaluated parameters and define what they mean in this simulation context. During this simulation, the HOL, the lost packets, and the signaling overhead parameters are investigated. HOL here refers to the time difference between the time when the MN is able to receive packets in the new PoA and the time when the MN was unable to receive packets in the old PoA. The lost packets refer to the number of packets that are lost from the downstream traffic during the HOL. Signaling overhead means the number of the required signaling packets per handover, which are used for LU or IP address configuration.
It can also be observed that there was a significant decrease in the HOL in our scheme. Our scheme achieved the lowest HOL that was in the fourth HO instance. Over the simulation time, different HO latencies other than that our proposed scheme experienced were consistently below 1.5 s. Furthermore, our scheme has stable HOL, while the HO latencies of the others (i.e., HIP and Micro-HIP) vary over the simulation time. This is because our scheme avoided DAD latency and MD latency, which are variable, but both the HIP and the Micro-HIP are still suffering from DAD latency and MD latency.
Our proposed scheme also achieved another advantage, which is the reduction of LU latency. This is because in our proposed scheme, LU is performed by an S-RVS that is usually topologically closer to the LRVS than the MN's to the LRVS. In other words, the distance between the sender and the responder of the LU messages in our proposed scheme is shorter than the distance between the senders and the responders of the LU messages in both the HIP and the Micro-HIP. In addition, the number of the required LU messages in our proposed scheme is lesser than the LU messages of the other schemes.
As shown in Figure 9, the MN received the last packet in the P-POA (i.e., S-RVS1) at Xs = 170.85 s and the first packet in the N-POA (i.e., S-RVS2) at Xf = 171.97 s. The difference between Xf and Xs is typical to the HOL that mentioned above and used in .
From the measurements and analysis, we observed that the HOLXf-Xs includes two delay components, which are not related to the components of handoff, but are related to HO events and other parameters. We explained the delay components in Figure 9 as shaded areas, which are the areas between Ys and Xs, as well as area between Xf and Yf. Therefore, we defined the HOL as the (latency) time difference between the time at which the MN becomes able to receive data packet from the N-POA and time at which the MN was unable to receive any data packet from the P-POA. In other words it is the time that the MN remains unable to receive any data due to HO processes. This definition only includes the main HO components, such as delay of scanning (SD), authentication (AuthD), and association (AssD) in the link layer, as well as the delay of attachment detection (ADD), IP configuration, and location update (LUD) in the network layer.
We used the Ys and Yf to indicate the points of time when the first component of HO (link layer switching) took place and when the last one (LU) finished, respectively, and also used HOLYf-Ys to denote such delay. The HOLYf-Ys in our scheme was only due to attachment delay (AD) and location update latency (LUD). This is because our proposed scheme has a mechanism that ensures the avoidance of a new IP configuration delay.
The delay before scanning (Db) and delay after LU (Da) are the delay components that are not related to the components of the HO, but these delays occurred because of HO events, and were included in the first definition of HOL. The (Db) is the time difference between the time of receiving the last packet in the P-POA and time of starting the scanning for a new access point (N-AP). In our model, Db delay was 0.36 s. The delay of Db depends on factors including data sending rate at the CN, the distance between the MN and the CN, and signal strength of the N-AP. These factors also affect the delay after (Da) LU, which is the time difference between the time of receiving the first packet at the N-POA and the time of binding update completion. In our scheme, Da was about 0.1 s. The combined delay due to both Db and Da was 0.46 s which is very high.
To our knowledge, neither macro-mobility management solutions (e.g., MIPv6 and HIP) nor micro-mobility management solutions (e.g., HMIPv6 and PMIPv6) addressed the Db and Da. Therefore, these solutions will experience such delays and incur a high HOL.
The micro-mobility management solutions usually anchor mobility in a domain of the MN or somewhere close to the MN to reduce the HOL. This implies that the CN location (i.e., How far it is from the MN?) will not affect the HOL. Furthermore, when the MN has ongoing communications with many CNs, the MN only informs the mobility anchor point instead of informing all the CNs like macro-mobility solutions. It is true that LUD will not be affected by the distance between the MN and the CN, but both Db and Da are directly affected by that. For example, in our proposed micro-mobility solution, the latency due to both Db and Da was 0.46 s, which is too high and will result in relatively large HOL. This issue as well as the handling of the non-HIP-aware node as the HIP-enabled node to enable a secured (based on HIP capabilities), efficient, and seamless HO mechanism are expected to be addressed in future studies.
We have proposed a new solution to optimize the handover performance for the HIP mobile nodes in a micro-mobility environment. We have also introduced a new mobility functional entity, which is called the S-RVS. The S-RVS tracks the MN movement and acts on behalf of the MN whenever it moves. This reduces the HOL and the signaling overhead which in turn reduces the packet loss and delay. The proposed scheme can also support location privacy as well as optimize the HOL when re-keying is required (this will be modeled and examined). The proposed solution is modeled and implemented in OMNet++ network simulator. The analytic model and simulation results show that our scheme outperformed both the HIP and the Micro-HIP in terms of HOL and signaling overhead. This is because our scheme significantly reduced LU latency and totally avoided the DAD latency. In addition, our scheme also avoided the signaling overheads on the MN's interface. This is because the SRVS, which is co-located with the AR, performed all mobility-related function on behalf of the MN. Furthermore, our scheme ensured network-based mobility solution using HIP technology to efficiently support the MN's mobility.
- Chiussi FM, Khotimsky DA, Krishnan S: Mobility management in third-generation all-IP networks. IEEE Commun Mag 2002, 124-135.Google Scholar
- Pacyna P: Advances in mobility management for the NG internet. China Commun 2006., 3(3):
- Reinbold P, Bonaventure O: IP micro-mobility protocols. IEEE Commun Surv Tutorials Third Q 2003, 40-57.Google Scholar
- Le D, Fu X, Hogrefe D: A review of mobility support paradigms for the internet. IEEE Commun. Surv Tutor 2006, 8(1):38-51.View ArticleGoogle Scholar
- Perkin C: Mobile networking through mobile IP. IEEE Internet Comput 1998, 2(1):58-69. 10.1109/4236.656077View ArticleGoogle Scholar
- Gurtov A: Host Identity Protocol (HIP): Towards the Secure Mobile Internet. Wiley and Sons; 2008. ISBN 978-0-470-99790-1View ArticleGoogle Scholar
- Khurri A, Vorobyeva E, Gurtov A: Performance of host identity protocol on lightweight hardware. Proceedings of ACM MobiArch 2007.Google Scholar
- Jokela P, Rinta-aho T, Jokikyyny T, et al.: Handover performance with HIP and MIPv6. 1st International Symposium on Wireless Communication Systems, 2004 2004, 3: 324-328.View ArticleGoogle Scholar
- Henderson TR, Ahrenholz JM, Kim JH: Experience with the host identity protocol for secure host mobility and multihoming. IEEE Wirel Commun Netw 2003, 3: 2120-2125.Google Scholar
- Kempf J: Problem statement for network-based localized mobility management (NETLMM). IETF, RFC 4830 2007.Google Scholar
- Moskowitz R, Nikander P: Host identity protocol (HIP) architecture. IETF, RFC4423 2006.Google Scholar
- Jokela P, Moskowitz R, Nikander P: Using the encapsulating security payload (ESP) transport format with the host identity protocol (HIP). IETF, RFC 5202 2008.Google Scholar
- Nikander P, Henderson T: End-host mobility and multihoming with the host identity protocol. IETF, RFC 5206 2008.Google Scholar
- Laganier J, Eggert L: Host identity protocol (HIP) rendezvous extension. IETF, RFC 5204 2008.Google Scholar
- Yankov S, Wiethoelter S: Handover blackout duration of layer mobility management schemes. TKN Technical Report, Berlin 2006.Google Scholar
- Novaczki S, Bokor L, Imre S: Micromobility support in HIP: survey and extension of host identity protocol. Proceedings of the IEEE Mediterranean Electrotechnical Conference (MELECON 2006) 2006, 651-54.Google Scholar
- Melén YJ, Nikander P, et al.: Re-thinking security in IP-based micro-mobility. Proceedings of the Informational Security Conference (ICS'04), Palo Alto, CA, USA 2004, 318-329.Google Scholar
- So J, Wang J: A HIP-based mobility management for UMTS/WLAN integrated networks. Australian Telecommunication Networks and Applications Conference (ATNAC 2006) 2006.Google Scholar
- Muslam M, Chan HA, Ventura N, Magagula LA: Hybrid HIP and PMIPv6 (HIPPMIP) mobility management for handover performance optimization. 6th International Conference on Wireless and Mobile Communications, 2010, ICWMC 2010, 232-237.View ArticleGoogle Scholar
- Iapichino G, Bonnet C: Host identity protocol and proxy mobile IPv6: a secure global and localized mobility management scheme for multihomed mobile nodes. In Global Telecommunications Conference, 2009. GLOBECOM 2009. IEEE; 2009:1-6.View ArticleGoogle Scholar
- Gundavelli S, Leung K, Devarapalli V, Chowdhury K, Patil B: Proxy mobile IPv6. IETF RFC 5213 2008.Google Scholar
- OMNet++ open source network simulater Official website: http://www.omnetpp.org/
- Bokor L, Nováczki S, Zeke LT, Jeney G: Design and evaluation of host identity protocol (HIP) simulation framework for INET/OMNeT++. Proceedings of the 12th ACM International Conference on Modeling, Analysis and Simulation of Wireless and Mobile Systems (MSWIM 2009), Tenerife, Canary Islands, Spain 2009, 124-133. ISBN:978-1-60558-616-8Google Scholar
- Muslam M, Chan HA, Ventura N: Host identity protocol extension supporting localized mobility management. CCNC 2011 PerNets Workshop, Las Vegas, Nevada 2011.Google Scholar
- Kong K-S, Lee W, Han Y-H, Shin M-K, You H: Mobility management for all-IP mobile networks: mobile IPv6 vs. proxy mobile IPv6. IEEE Wirel Commun 2008, 15(2):36-45.View ArticleGoogle Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.