Distributed Identifier-Locator Mapping Management in Mobile ILNP Networks

Abstract

In the Identifier Locator Network Protocol (ILNP) networks, the existing mobility control schemes based on the centralized entity, called the Dynamic Domain Name Service (DDNS) server, such that all the control traffic is processed at the DDNS server. However, the centralized mobility schemes have significant limitations, such as control traffic overhead at the server and large handover delay. In order to resolve these issues, we propose a new mobility control scheme for ILNP networks, which manages the identifier-locators (ID-LOCs) in the fully distributed manner. In our scheme, each domain has a dedicated mobile DDNS (m-DDNS) server at the site border router (SBR). The m-DDNS server maintains two databases; i.e., home host register (HHR) and visiting host register (VHR), to support the roaming of mobile hosts. When a mobile host roams into a domain, the m-DDNS server in the visiting domain registers the host’s ID-LOC in the VHR and requests the update of HHR to the m-DDNS server in the home domain. Since the m-DDNS servers communicate each other directly, the ID-LOC mappings are managed without involvement of any central entities. We analyzed our proposed mobility scheme via numerical analysis and compared its performance with those of existing schemes. Numerical results showed that our scheme outperforms the existing mobility control schemes substantially in terms of control traffic overhead at the servers, total transmission delay and handover delay.

1. Introduction

With the advent of smart phones and various smart devices, the number of mobile users on the Internet is increasing explosively. This mobile trend has caused the rapid growth of the routing table size in routers [1,2]. To tackle the routing scalability issue, the Internet Engineering Task Force (IETF) has proposed the Identifier Locator Network Protocol (ILNP) protocol [3,4], which operates based on the address rewriting scheme. Under the ILNP, the identifier (ID) of a host is separated from its locator (LOC). Specifically, in the IPv6 address of 128 bits, the upper 64 bits are used for LOC and the lower 64 bits are used for ID. Then the Dynamic Domain Name System (DDNS) [5] server maps the ID onto the LOC for each mobile host.

For the ILNP-based networks, a mobility control scheme was proposed in [3,6,7,8,9,10,11,12,13,14,15,16,17], where individual mobile hosts conduct the binding and query operations with the DDNS server. We call the mobility scheme “ILNP-Global” in this paper, since it depends on the centralized DDNS server for ID-LOC mappings. Unfortunately, the centralized mobility control scheme has significant limitations in scalability and performance. Indeed, as the number of mobile hosts increases, the DDNS server suffers from huge control overhead. Moreover, all the centralized schemes are subject to large operational costs and service quality degradation due to the single point of failure problem.

An alternative mobility control scheme was proposed in [4] to enhance the ILNP-Global, where a local mapping table was employed in addition to the central DDNS server. We call this scheme “ILNP-Local” here. In the ILNP-Local, each domain maintains the local mapping table at its site border router (SBR). The SBR performs the ID-LOC mapping, where the locator is a local LOC (LLOC), for the hosts in the serving domain. On the other hand, when a host is not in the domain, SBR refers to the central DDNS server for the host’s locator, which is a global LOC (GLOC). This localized approach improves the scalability and performance over the centralized mobility control scheme. However, it still depends on the central DDNS server for inter-domain ID-LOC mappings.

In this paper, we propose a fully distributed ID-LOC management scheme for mobile ILNP networks, which is denoted by “ILNP-Distributed.” In the proposed scheme, we use both the GLOC and LLOC for a mobile host as in the ILNP-Local scheme [4]. We place the dedicated mobile DDNS (m-DDNS) server at each SBR to eliminate the centralized DDNS server. The m-DDNS server manages two databases, called Home Host Register (HHR) and Visiting Host Register (VHR), for ID-LOC mappings. When a host is in the home domain, its ID-LLOC is stored in the HHR of the home domain. On the other hand, when the host moves into another domain, its ID-LLOC is registered in the VHR of the visiting domain and the ID-GLOC is set in the HHR of the home domain. Here, it is the SBR of the visiting domain that requests the ID-GLOC update to the m-DDNS server of the home domain.

The rest of this paper is organized as follows. In Section 2, we review the existing mobility control schemes for ILNP networks. In Section 3, we describe our proposed mobility control scheme. We analyze the considered schemes in Section 4 and compare their performances numerically in Section 5. Finally, we conclude the paper in Section 6.

2. Materials and Methods

In this section, we review two previous mobility control schemes for ILNP networks, which are denoted “ILNP-Global” and “ILNP-Local” respectively.

2.1. ILNP-Global

We consider the mobility scenario shown in Figure 1 to discuss the operation of ILNP-Global. MN (bob.SKT.com) and CN (alice.SKT.com) are located in the same domain initially, but MN moves to another domain then. Further, the MN changes the serving access router (AR) by handover in the visiting domain.

In Figure 2, we illustrate the ID-LOC management of the ILNP-Global scheme in cases of non-roaming, roaming and handover [3]. When MN attaches to AR2 in the home domain (non-roaming case), the MN registers its GLOC by sending a LOC binding update message to the centralized DDNS server (Step 1). The DDNS server registers the MN’s ID-GLOC mapping, and returns the LOC binding update ACK to the MN (Step 2). When CN has data packets for the MN, it needs the MN’s GLOC for packet delivery, so the CN sends a LOC query request to the DDNS server (Step 3), and obtains the MN’s GLOC from the associated LOC query response message (Step 4). We recall that the DDNS server keeps the ID-GLOC information of all the hosts in the network. The CN then transmits the packets directly to the MN since GLOC is the MN’s global locator in ILNP-Global, as shown in Figure 1.

When MN moves to another domain and attaches to AR3 (roaming case), the MN updates its GLOC stored in the DDNS server. That is, MN sends a LOC binding update message to the DDNS server (Step 5). The DDNS server updates the MN’s ID-GLOC in its database, and returns the LOC binding update ACK to the MN (Step 6). For data delivery, CN requests the MN’s GLOC to the DDNS server by sending a LOC query request (Step 7). The DDNS server notifies the MN’s GLOC by the LOC query response message (Step 8). The CN can send the data packets to the MN directly.

We now look over the handover of MN from AR3 to AR4. Once MN attaches to the target router AR4, the MN reports its GLOC to the DDNS server. Specifically, MN sends a LOC binding update message with its GLOC to the DDNS server (Step 9). The DDNS server updates the ID-GLOC mapping and returns the LOC binding update ACK to the MN (Step 10). Then, the MN transmits a LOC Update message to CN also, to notify its new GLOC. The CN updates the MN’s GLOC, and replies to the MN by the LOC Update ACK (Step 11 and 12). CN can send the data packets to the MN directly with the updated GLOC.

2.2. ILNP-Local

The ILNP-Global scheme depends on the centralized DDNS server to manage the ID-LOC mappings, which incurs significant control message overheads at the server in the global scale. To deal with this problem, the ILNP-Local scheme was proposed in [4]. Differently from ILNP-Global, the ILNP-Local employs a local mapping table (LMT) at the SBR, in conjunction with the DDNS server, to provide the localized mobility control.

For ILNP-Local, we consider the same mobility scenario with that in the ILNP-Global, as shown in Figure 3. MN and CN are located in the same domain but MN moves to another domain by roaming. After some time, the MN makes a handover to another AR in the visiting domain.

In Figure 4, we illustrate the ID-LOC management operations of the ILNP-Local. We first consider the non-roaming case, where MN attaches to AR2 in the home domain. The MN configures its LLOC and registers it to SBR1 by sending a LOC binding update message (Step 1). SBR1 stores the MN’s ID-LLOC mapping in its LMT, and responds with the LOC binding update ACK to the MN (Step 2). Subsequently, SBR1 sends a LOC binding update message to the central DDNS server to register the MN’s ID-GLOC (Step 3). The DDNS server replies with the LOC binding update ACK to SBR 1 (Step 4) after storing the ID-GLOC in its database. We notice here that the GLOC is the SBR’s locator in ILNP-Local, as shown in Figure 3, whereas a GLOC is the MN’s locator in ILNP-Global. When CN has data packets for the MN, the packets are delivered to the SBR1 first. Then, SBR1 looks up its LMT to find the MN’s LLOC. Since the LLOC is in the LMT in non-roaming case, SBR1 knows the MN’s current location and forwards the data packet successfully.

We turn to the roaming case now, where MN attaches to AR3 in the visiting domain. Once the MN is connected to AR3, it configures its LLOC and registers it to SBR2 by sending a LOC binding update message (Step 5). SBR2 stores the MN’s ID-LLOC in its LMT and returns the LOC binding update ACK to the MN (Step 6). Right after, SBR2 sends a LOC binding update message to the centralized DDNS server (Step 7) to update the MN’s ID-GLOC mapping. The DDNS server then responds with the LOC binding update ACK to SBR2 (Step 8). For data delivery to the MN, CN sends data packets to SBR1 in the home domain. SBR1 searches the LMT but fails to find the MN’s LLOC. In that case, SBR1 refers to the DDNS server for the MN’s GLOC by sending the LOC query request message (Step 9). When the DDNS server returns the associated LOC query response (Step 10), SBR1 knows the MN’s GLOC and forwards the data packets to SBR2 in the visiting domain. The SBR2 delivers the packets to the MN since it has the MN’s LLOC in its LMT.

During the handover from AR3 to AR4, MN sends a LOC binding update message to SBR2 to update its ID-LLOC in the LMT (Step 11). The SBR2 replies with the LOC binding update ACK to the MN (Step 12). In succession, the MN transmits a LOC Update message to CN, to notify its new LOC. CN updates the MN’s LOC and responds with the LOC Update ACK message to the MN (Steps 13 and 14). CN can deliver the data packets to the MN via AR1, SBR1, SBR2 and AR4 in sequence.

We have looked over the existing mobility control schemes for ILNP-based mobile networks; i.e., ILNP-Global and ILNP-Local. We observe both the mobility schemes rely on the centralized DDNS server in some degrees. This results in poor scalability and performance in mobile environments.

Accordingly, we propose a new mobility control scheme in this paper, which manages the ID-LOC information in the fully distributed fashion.

3. Proposed Scheme

In this section, we describe our distributed mobility control scheme, named ILNP-Distributed, in detail.

3.1. Overview

We consider the mobility scenario of Figure 5 to discuss the operation of our proposed ILNP-Distributed scheme. In the scenario, MN (bob.SKT.com) and CN (alice.SKT.com) are in the same domain initially, and MN moves to another domain by roaming. Further, the MN changes the serving AR by handover in the visiting domain.

In the proposed scheme, each SBR has the dedicated mobile DDNS (m-DDNS) server and the server maintains two databases, called HHR and VHR. HHR keeps track of the ID-LOC (can be LLOC or GLOC) mappings for the home hosts, i.e., the hosts whose home domain is the SBR’s serving domain, as shown in

Table 1. Home Host Register (HHR) in SKT.com domain.

No.	Host Name	ID	LOC	Status
1	alice.SKT.com	ID1	LLOC	Home
2	bob.SKT.com	ID2	GLOC	Roaming
3	∙∙∙	∙∙∙	∙∙∙	∙∙∙

. VHR stores the ID-LLOC mappings for the hosts visiting the SBR’s serving domain. In

Table 2. Visiting Host Register (VHR) in LGU.com domain.

No.	Host Name	ID	LOC	Home Domain
1	bob.SKT.com	ID2	LLOC	GLOC
2	∙∙∙	∙∙∙	∙∙∙	∙∙∙
3	∙∙∙	∙∙∙	∙∙∙	∙∙∙

, we provide the example of VHR in LGU.com domain. We can use the host’s IP address as the LLOC and the associated SBR’s IP address as the GLOC. We manage the ID-LOC information similarly to the ILNP-Local, but we do not depend on the centralized DDNS server.

Before discussing the proposed scheme further, we compare our scheme with the existing mobility control schemes in the architectural perspective, as in

Table 3. Comparison of candidate mobility control schemes.

Schemes	LOC	Mapping Architecture	Mobility Agent
ILNP-Global	GLOC	Centralized	DDNS
ILNP-Local	LLOC, GLOC	Centralized	SBR (LMT), DDNS
ILNP-Distributed	LLOC, GLOC	Distributed	SBR (m-DDNS)

.

The ILNP-Global employs only the GLOC as a LOC. A central DDNS server is used for the ID-GLOC mappings. The ID-GLOC binding and query operations are performed between each host and the DDNS server. The ILNP-Local is similar to the ILNP-Global. However, it has two types of LOCs, i.e., GLOC and LLOC, for each host. Each SBR performs the localized ID-LLOC mappings for the hosts in the serving domain, while it depends on the centralized DDNS server for the ID-GLOC information of the hosts in the visiting domains. In the ILNP-Distributed, we use LLOC and GLOC, as in ILNP-Local. Each SBR (or m-DDNS server) manages HHR and VHR databases. The ID-LOC information is managed by m-DDNS servers in the distributed manner without any centralized entities. We describe the detailed operations in the subsequent sections.

3.2. Procedures for Non-Roaming Scenario

When MN establishes the network connection with an AR in the home domain, it performs the ID-LOC binding and query operations as in Figure 6.

MN registers the LLOC to SBR1 by sending a LOC binding update message (Step 1). The SBR1 stores the MN’s ID-LLOC in the HHR, which maintains the ID-LOC (can be LLOC or GLOC) mappings of all the home hosts. Then the SBR1 returns the LOC binding update ACK message to the MN without further action (Step 2). When CN has data packets for the MN, CN queries the MN’s LLOC to SBR1 by sending a LOC query request message (Step 3). Since the MN is in the home domain, SBR1 finds the LLOC in the HHR and returns it to the CN by the LOC query reply message (Step 4). CN then sends the data packets to the MN directly.

3.3. Procedures for Roaming Scenario

We illustrate the ID-LOC binding and query operations in Figure 7. When MN visits another domain (roaming case). When MN attaches to AR2 in the visiting domain, the MN sends a LOC binding update message to the SBR2 (Step 1), to register its LLOC. SBR2 then checks whether the MN belongs to its serving domain (home host) or not (roaming host). In the proposed scheme, we assume that each host has a name with its home domain information. For example, if a host has a name of alice.SKT.com, we can see its home domain is SKT.com, so the SBR2 recognizes that the MN is a roaming host, and stores the MN’s ID-LLOC in VHR. In succession, SBR2 sends a LOC binding update message to the SBR1 in the MN’s home domain (Step 2). SBR2 locates the SBR1 by using the m-DDNS server and the MN’s home domain information. Then, SBR1 updates the MN’s ID-GLOC mapping in the HHR and responds with the LOC binding update ACK to SBR2 (Step 3). The ACK message is eventually delivered to the roaming MN also by SBR2 (Step 4). When CN has data packets for the MN, the CN requests the MN’s LOC to the SBR1 by sending a LOC query request message (Step 5). SBR1 finds the MN’s GLOC in the HHR since the host is in the visiting domain, and returns it to the CN by the LOC query reply message (Step 6). With the GLOC, CN can send the data packets to the MN via AR1, SBR1, SBR2 and AR3 in sequence.

3.4. Procedures for the Handover Scenario

We assume the proposed scheme exploits the link-layer information for handover, as defined in the IEEE 802.21 standard [18]. With the help of link-layer triggers, e.g. link-detected (LD) and link-up (LU), MN can tell if it has moved to a new network or not, while connected to the old network.

We show the ID-LOC management operation during the handover in Figure 8, under our ILNP-Distributed scheme. When MN detects a new network, it sends a LOC binding update message to SBR2 (Step 1), in order to register the LLOC in the VHR therein. After updating the ID-LLOC mapping, SBR2 replies to the MN with the LOC binding update ACK message (Step 2). We notice that the MN’s GLOC does not change during handover. Hence the packets from CN arrive at SBR2 still. SBR2 looks up VHR and finds the LLOC of the MN. Then the packets are delivered to the MN via AR4 from SBR2.

4. Performance Analysis

In this section, we analyze the three candidate mobility control schemes for ILNP networks; i.e., ILNP-Global, ILNP-Local and INLP-Distributed. Especially, we evaluate their performances in terms of control traffic overhead, total transmission delay and handover delay.

4.1. Analysis Model

We consider the network model of Figure 9 to analyze the mobility control schemes. We first summarize the notations used for the analysis in

Table 4. Parameters used for cost analysis.

Parameters	Description
Sc	Size of control packets (bytes)
Sd	Size of data packets (bytes)
Bw	Bandwidth of a wired link (Mbps)
Bwl	Bandwidth of a wireless link (Mbps)
Lw	Latency of a wired link (ms)
Lwl	Latency of a wireless link (ms)
Hx-y	Hop count between nodes x and y
α [17]	Unit cost for binding update
β [17]	Unit cost for database search
NHost/AR	Number of hosts attached to an AR
NAR	Number of ARs in the domain
NSBR	Number of SBRs
q	Wireless link failure probability
Tq [15,16,17,19,20,21]	Average queuing delay at each router

[15,16,17,19,20,21].

We denote the transmission delay of a message with size S as $T_{X-y}(s)$ [15,16,17,19,20,21], where x and y are the sending and receiving nodes connected by a wireless link. We note that $T_{X-y}(s)$ can be written as

$$T_{X-y}(s)=\frac{1+q}{1-q} \times [\frac{S}{B_{wl}}+L_{wl}].$$

Similarly, we let $T_{X-y} (S,H_{X-y})$ [15,16,17,19,20,21] denote the transmission delay of a message with size S in the wired network, where x and y are the sending and receiving nodes connected by one or more wired links and $H_{X-y}$ denotes the hop count between x and y. It is straightforward to write $T_{X-y} (S,H_{X-y})$ as

$$T_{X-y} (S,H_{X-y})=\frac{1+q}{1-q} \times [\frac{S}{B_{wl}}+L_w+T_q].$$

4.2. Analysis of Control Traffic Overhead

We evaluate the control traffic overhead (CTO) for ID-LOC mapping managements at the SBRs and/or the DDNS server.

4.2.1. ILNP-Global

In the ILNP-Global scheme, we evaluate the CTO by the number of ID-LOC mapping messages the DDNS server handles. We consider the non-roaming case first. There, MN attaches to the serving AR, and registers its LLOC to the DDNS server by sending a LOC binding update message. Therefore, the DDNS server processes $S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}$ bytes of the control messages. Furthermore, each host sends a LOC query request message to the DDNS server for data delivery, which incurs additional $S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}$ bytes of control messages to the server. Therefore, the CTO for non-roaming case can be written as

$$\begin{array}{ll}CTO-N{R}_{ILNP-Global}& \\ & =S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}+S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}\end{array}$$

(1)

In ILNP-Global, we note that the mobility control messages do not change for roaming and non-roaming cases. We, hence, obtain the CTO for roaming case as

$$CTO-R{O}_{ILNP-Global}=CTO-N{R}_{ILNP-Global}$$

(2)

4.2.2. ILNP-Local

In ILNP-Local, we first consider the non-roaming case, where we measure the CTO as the number of ID-LOC mapping messages processed by SBR1 and the DDNS server. When MN attaches to the AR in the home domain, the MN registers its LLOC to SBR1 by sending a LOC binding update message. That is, the SBR1 should handle $S_C \times N_{Host/AR} \times N_{AR}$ bytes of control messages. Subsequently, SBR1 sends a LOC binding update message to the DDNS server to register the MN’s GLOC, so the DDNS server handles $S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}$ bytes of control messages from the SBRs. Accordingly, the CTO for non-roaming case is given as

$$CTO-N{R}_{ILNP-local}=S_C \times N_{Host/AR} \times N_{AR}+S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}$$

(3)

We now take into account the roaming case, where we evaluate the CTO by the amount of ID-LOC mapping messages at SBR2 and the DDNS server. When MN attaches to the AR in the visiting domain, the MN registers its LLOC to SBR2 by sending a LOC binding update message. Hence, the SBR2 handles $S_C \times N_{Host/AR} \times N_{AR}$ bytes of control messages. Then, the SBR2 sends a LOC binding update message to the DDNS server to update the MN’s ID-GLOC information. For this, the DDNS server processes $S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}$ bytes of control messages. Further, when CN has packets for the MN, CN passes the packets to the SBR1 first. SBR1 sends the LOC query request message to the DDNS server to obtain the MN’s GLOC, which incurs additional $S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}$ bytes of control messages. Thus, the CTO in roaming case can be written as

$$\begin{gathered} CTO-R{O}_{ILNP-local}=S_C \times N_{Host/AR} \times N_{AR}+S_C \times N_{Host/AR} \times N_{AR} \times N_{SBR}+S_C \times \\ {N}_{Host/AR} \times N_{AR} \times N_{SBR} \end{gathered}$$

(4)

4.2.3. ILNP-Distributed

For non-roaming case, we measure the CTO by the amount of ID-LOC mapping messages at SBR1. When MN attaches to the serving AR, it sends the LOC binding update messages to SBR1 and registers its LLOC. So SBR1 processes $S_C \times N_{Host/AR} \times N_{AR}$ bytes of control messages. Moreover, if CN has data packets for the MN, it sends a LOC query request message to the SBR1. Then the SBR1 should handle additional $S_C \times N_{Host/AR} \times N_{AR}$ bytes of control messages. Thus, we can write the CTO as

$$\begin{gathered} CTO-N{R}_{ILNP-Distributed}=S_C \times N_{Host/AR} \times N_{AR}+S_C \times N_{Host/AR} \times N_{AR} \\ CTO-N{R}_{ILNP-Distributed}=2\times S_C \times N_{Host/AR} \times N_{AR} \end{gathered}$$

(5)

When MN visits a foreign domain (roaming case), we measure the CTO as the amount of ID-LOC mapping messages processed by SBR1 and SBR2. MN attaches to AR3 and registers its LLOC to SBR2 by sending a LOC binding update messages. Hence, the SBR2 processes $S_C \times N_{Host/AR} \times N_{AR}$ bytes of control messages. Successively, SBR2 sends a LOC binding update message to SBR1 to update the HHR entry. So the SBR1 handles $S_C \times N_{Host/AR} \times N_{AR}$ bytes of the control messages. Additionally, for data delivery, CN inquires the MN’s LOC of SBR1 by sending a LOC query request message. Then, SBR1 processes $S_C \times N_{Host/AR} \times N_{AR}$ bytes of control messages. In total, the CTO for the roaming case is given as

$$\begin{gathered} \begin{array}{ll}CTO-R{O}_{ILNP-Distributed}& \\ & =S_C \times N_{Host/AR} \times N_{AR}+S_C \times N_{Host/AR} \times N_{AR}\\ & +S_C \times N_{Host/AR} \times N_{AR}\end{array} \\ CTO-R{O}_{ILNP-Distributed}=3 \times S_C \times N_{Host/AR} \times N_{AR} \end{gathered}$$

(6)

4.3. Analysis of Total Transmission Delay

In this section, we derive the total transmission delay (TTD) for the ID-LOC management and data delivery. We notice that the TTD can be written as the sum of binding update delay (BUD), binding query delay (BQD) and data delivery delays (DDD), respectively. Hence, for each mobility scheme, we calculate the BUD, BQD and DDD separately and sum up them to obtain the TTD.

4.3.1. ILNP-Global

When MN attaches to the AR1 in the home domain (non-roaming case), it conducts the binding update with the DDNS server by exchanging the LOC binding update and ACK messages. This operation takes 2 × (T_MN-AR(S_c) + T_AR-SBR(S_c,H_AR-SBR) + T_SBR-DDNS(S_c,H_SBR-DDNS)) + P_DDNS, where P_DDNS = αlog(N_AR × N_Host/AR × N_SBR) represents the processing time in the DDNS server for the ID-GLOC update. We assume the processing time is proportional to the logarithm of the number of active hosts (N_AR × N_Host/AR × N_SBR), which can be attained with tree-based data structures. So, the BUD is written as

$$\begin{array}{ll}BUD-N{R}_{ILNP-Global}& \\ & =2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR})\\ & +T_{SBR-DDNS }(S_C,H_{SBR-DDNS}))+ P_{DDNS}\end{array}$$

$$\begin{gathered} BUD-N{R}_{ILNP-Global}=2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR})+ \\ {T}_{SBR-DDNS }(S_C,H_{SBR-DDNS}))+\alpha \log ( N_{Host/AR} \times N_{AR} \times N_{SBR}). \end{gathered}$$

In ILNP-Global, the binding update operation does not change regardless of the roaming and non-roaming cases. Hence, we obtain

$$BUD-R{O}_{ILNP-Global}=BUD-N{R}_{ILNP-Global}.$$

We next calculate the time for binding query operations. When CN has the data packets for MN in the home domain (non-roaming case), it sends a LOC query request message to the DDNS server to obtain the MN’s GLOC. The DDNS server searches its database, which takes P_DDNS = βlog(N_AR × N_Host/AR × N_SBR), and responds to the CN by the LOC query reply message. This operation takes 2 × (T_CN-AR(S_c) + T_AR-SBR(S_c,H_AR-SBR) + T_SBR-DDNS(S_c,H_SBR-DDNS)). Thus, we have the BQD for non-roaming case as

$$\begin{array}{ll}BQD-N{R}_{ILNP-Global}& \\ & =2 \times (T_{CN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR})\\ & +T_{SBR-DDNS }(S_C,H_{SBR-DDNS}))+ P_{DDNS}\end{array}$$

$$\begin{gathered} BQD-N{R}_{ILNP-Global}=2 \times (T_{CN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR})+ \\ {T}_{SBR-DDNS }(S_C,H_{SBR-DDNS}))+\beta \log ( N_{Host/AR} \times N_{AR} \times N_{SBR}). \end{gathered}$$

When the MN is visiting another domain (roaming case), CN obtains the MN’s GLOC from the DDNS server, following the same binding query operation. So, the BQD for roaming case is given as

$$BQD-R{O}_{ILNP-Global}=BQD-N{R}_{ILNP-Global}$$

We now investigate the data delivery of the ILNP-Global. If MN is in the home domain (non-roaming case), CN delivers data packets to the MN via AR1, SBR1 and AR2 in sequence. Hence the DDD is written as

$$DDD-N{R}_{ILNP-Global}=T_{CN-AR} (S_d) \times T_{AR-AR }(S_d,H_{AR-AR})+T_{MN-AR }(S_d).$$

When MN is visiting another domain (roaming case), CN delivers data packets to the MN via AR1, SBR1, SBR2 and AR3 in sequence. So, the DDD can be written as

$$\begin{gathered} DDD-R{O}_{ILNP-Global}=T_{CN-AR} (S_d) \times T_{AR-SBR }(S_d,H_{AR-SBR})+ \\ {T}_{SBR-SBR }(S_d, S_d,H_{SBR-SBR})+T_{AR-SBR }(S_d,H_{AR-SBR}). \end{gathered}$$

In total, we derive the TTD for non-roaming case and the TTD for roaming case as

$$\begin{gathered} TTD-N{R}_{ILNP-Global}=BUD-N{R}_{ILNP-Global}+BQD-N{R}_{ILNP-Global}+DDD- \\ N{R}_{ILNP-Global} \end{gathered}$$

(7)

$$\begin{gathered} TTD-R{O}_{ILNP-Global}=BUD-R{O}_{ILNP-Global}+BQD-R{O}_{ILNP-Global}+DDD- \\ R{O}_{ILNP-Global} \end{gathered}$$

(8)

4.3.2. ILNP-Local

In ILNP-Local, the ID-LOC binding updates are performed as follows. When MN attaches to AR1 in the home domain (non-roaming case), it registers the LLOC to SBR1 by exchanging the LOC binding update and ACK messages. This operation takes 2 × (T_MN-AR(S_c) + T_AR-SBR(S_c,H_AR-SBR) + P_SBR, where P_SBR = αlog(N_AR × N_Host/AR) is the LMT update time at SBR1. Subsequently, SBR1 updates the MN’s GLOC in the DDNS server by exchanging the LOC binding update and ACK messages. Considering the database update time PDDNS at the DDNS server, this operation takes T_SBR-DDNS(S_c,H_SBR-DDNS)) + P_DDNS, where P_DDNS = αlog(N_AR × N_Host/AR × N_SBR). So, the BUD for non-roaming case can be written as

$$\begin{array}{ll}BUD-N{R}_{ILNP-Local}& \\ & =2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR})\\ & +T_{SBR-DDNS }(S_C,H_{SBR-DDNS}))+ P_{SBR}+P_{DDNS}\end{array}$$

$$\begin{gathered} BUD-N{R}_{ILNP-Local}=2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR})+ \\ {T}_{SBR-DDNS }(S_C,H_{SBR-DDNS}))+\alpha \log ( N_{Host/AR} \times N_{AR} \times N_{SBR})+ \alpha \log ( N_{Host/AR} \times \\ N_{AR} \times N_{SBR}). \end{gathered}$$

The binding update process is not affected by the roaming and non-roaming cases. Hence, the BUD for roaming case is given as

$$BUD-R{O}_{ILNP-Local}=BUD-N{R}_{ILNP-Local}$$

We then turn to the binding query delay. In ILNP-Local, the binding query is resolved in the SBR locally for the non-roaming case. Thus, the BQD is zero.

$$BQD-N{R}_{ILNP-Local}=o.$$

When MN is in the foreign domain (roaming case), the binding query is processed as follows. First, CN passes the data packets to SBR1. SBR1 searches the LMT in vain and requests the MN’s GLOC to the DDNS server by sending a LOC query request message. The DDNS server looks for the GLOC in its database, which takes P_DDNS = βlog(N_AR × N_Host/AR × N_SBR), and responds to SBR1 by the LOC query reply message. This operation takes 2 × T_SBR-DDNS(S_c,H_SBR-DDNS). So, the BQD for roaming case can be written as

$$\begin{array}{ll}BQD-R{O}_{ILNP-Local}& \\ & =2 \times T_{SBR-DDNS }(S_C,H_{SBR-DDNS}))\\ & +\beta \log ( N_{Host/AR} \times N_{AR} \times N_{SBR})\end{array}$$

Once the binding query is resolved, data packets are transmitted from CN to MN. When the MN is in the home domain (non-roaming case), data packets are delivered from CN to MN via AR1, SBR1 and AR2 in sequence, such that

$$\begin{gathered} DDD-N{R}_{ILNP-Local}=T_{CN-AR} (S_d) \times T_{AR-SBR }(S_d,H_{AR-SBR})+ \\ {T}_{AR-SBR }(S_d,H_{AR-SBR})+T_{MN-AR }(S_d). \end{gathered}$$

If the MN is visiting another domain (roaming case), data packets from CN are delivered to MN via AR1, SBR1, SBR2 and AR3 in sequence. So the DDD is given as

$$\begin{gathered} DDD-R{O}_{ILNP-Local}=T_{CN-AR} (S_d) \times T_{AR-SBR }(S_d,H_{AR-SBR})+ \\ {T}_{SBR-SBR }(S_d,H_{SBR-SBR})+T_{AR-SBR }(S_d,H_{AR-SBR})+T_{MN-AR }(S_d). \end{gathered}$$

Therefore, we obtain the TTD for non-roaming case and the TTD for roaming case as

$$\begin{gathered} TTD-N{R}_{ILNP-Local}=BUD-N{R}_{ILNP-Local}+BQD-N{R}_{ILNP-Local}+DDD- \\ N{R}_{ILNP-Local} \end{gathered}$$

(9)

$$TTD-R{O}_{ILNP-Local}=BUD-R{O}_{ILNP-Local}+BQD-R{O}_{ILNP-Local}+DDD-R{O}_{ILNP-Local}$$

(10)

4.3.3. ILNP-Distributed

In the ILNP-Distributed, when MN attaches to AR1 in the home domain (non-roaming case), it performs the ID-LOC binding operation with SBR1 by exchanging the LOC binding update and ACK messages. Then, SBR1 updates the HHR entry. This operation takes 2 × (T_MN-AR(S_c)+ T_AR-SBR(S_c,H_AR-SBR)) + P_SBR, where P_SBR = αlog(N_AR × N_Host/AR). Hence, the BUD for non-roaming case can be written as

$$\begin{gathered} BUD-N{R}_{ILNP-Distributed}=2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR}))+P_{SBR} \\ BUD-N{R}_{ILNP-Distributed}=2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR}))+ \\ \alpha \log ( N_{Host/AR} \times N_{AR} \times N_{SBR}). \end{gathered}$$

When MN is not in the home domain (roaming case), the MN conducts the binding update operation with SBR2 by exchanging the LOC binding update and ACK messages. Incorporating the VHR update time at SBR2, this operation takes 2 × (T_MN-AR(S_c) + T_AR-SBR(S_c,H_AR-SBR) + P_SBR, where P_SBR = αlog(N_AR × N_Host/AR). In succession, SBR2 performs the binding update operation with SBR1 by exchanging the LOC binding update and ACK messages. There, the SBR1 updates the ID-GLOC information in the HHR. This operation takes T_SBR-SBR(S_c,H_SBR-SBR)) + P_SBR, where P_SBR = αlog(N_AR × N_Host/AR). So, the BUD for roaming case is given as

$$\begin{gathered} BUD-R{O}_{ILNP-Distributed}=2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR})+ \\ {T}_{SBR-SBR }(S_C,H_{SBR-SBR}))+P_{SBR}+P_{SBR} \\ BUD-R{O}_{ILNP-Distributed}=2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR})+ \\ {T}_{SBR-SBR }(S_C,H_{SBR-SBR}))+\alpha \log ( N_{Host/AR} \times N_{AR} \times N_{SBR})+ \alpha \log ( N_{Host/AR} \times N_{AR} \times \\ N_{SBR}). \end{gathered}$$

We now calculate the BQD in the non-roaming case. First, CN sends a LOC query request message to SBR1 to find the MN’s LLOC. SBR1 looks for the LLOC in the HHR, which takes P_SBR = βlog(N_AR × N_Host/AR), and responds to the CN by the LOC query reply. This takes 2 × T_CN-AR(S_c) + 2 × T_AR-SBR(S_c,H_AR-SBR). Hence, we can write the BQD for non-roaming case as

$$\begin{gathered} BQD-N{R}_{ILNP-Distributed}=2 \times T_{CN-AR }(S_C)+2 \times T_{AR-SBR }(S_C,H_{AR-SBR})+ \\ \beta \log ( N_{Host/AR} \times N_{AR}). \end{gathered}$$

In the ILNP-Distributed, the binding query process is the same for roaming and non-roaming cases. So, we have

$$BQD-R{O}_{ILNP-Distributed}=BQD-N{R}_{ILNP-Distributed}.$$

When MN is in the home domain (non-roaming case), CN can send data packets to the MN via AR1 and AR2 in sequence, once it acquires the MN’s LOC. Hence, the DDD is given as

$$DDD-N{R}_{ILNP-Distributed}=T_{CN-AR} (S_d) \times T_{AR-AR }(S_d,H_{AR-AR})+T_{MN-AR }(S_d).$$

If MN is in the foreign domain (roaming case), the data packets from CN are delivered to the MN via AR1, SBR1, SBR2 and AR3 in sequence, such that DDD is written as

$$\begin{gathered} DDD-R{O}_{ILNP-Distributed}=T_{CN-AR} (S_d) \times T_{AR-SBR }(S_d,H_{AR-SBR})+ \\ {T}_{SBR-SBR }(S_d,H_{SBR-SBR})+T_{AR-SBR }(S_d,H_{AR-SBR})+T_{MN-AR }(S_d). \end{gathered}$$

Conclusively, we obtain the TTD for non-roaming case and the TTD for roaming case as

$$\begin{gathered} TTD-N{R}_{ILNP-Distributed}=BUD-N{R}_{ILNP-Distributed}+BQD- \\ N{R}_{ILNP-Distributed}+DDD-N{R}_{ILNP-Distributed} \end{gathered}$$

(11)

$$\begin{gathered} TTD-R{O}_{ILNP-Distributed}=BUD-R{O}_{ILNP-Distributed}+BQD- \\ R{O}_{ILNP-Distributed}+DDD-R{O}_{ILNP-Distributed} \end{gathered}$$

(12)

4.4. Analysis of Handover Delay

We here analyze the handover delay (HOD) of the three candidate mobility control schemes.

4.4.1. ILNP-Global

Completing the handover to AR4, MN updates its GLOC in the DDNS server by exchanges the LOC binding update and ACK messages. Considering the database update time at the DDNS server, it takes 2 × (T_MN-AR(S_c) + T_AR-SBR(S_c,H_AR-SBR) + T_SBR-DDNS(S_c,H_SBR-DDNS)) + P_DDNS, where P_DDNS = αlog(N_AR × N_Host/AR × N_SBR). Then, the MN notifies the new GLOC to CN by exchanging the LOC Update and ACK messages, which takes the additional time of 2 × (T_MN-AR(S_c) + T_AR-SBR(S_c,H_AR-SBR) + T_SBR-SBR(S_c,H_SBR-SBR) + T_AR-SBR(S_c,H_AR-SBR) + T_CN-AR(S_c)). At last, CN delivers the data packets to the MN via AR1, SBR1, SBR2 and AR4, which takes T_CN-AR(S_d) + T_AR-SBR(S_d,H_AR-SBR) + T_SBR-SBR(S_d,H_SBR-SBR) + T_AR-SBR(S_d,H_AR-SBR) + T_AR-MN(S_d).

Hence, in ILNP-Global, we obtain the HOD as

$$\begin{array}{ll}HO{D}_{ILNP-Global}& =2 \times (T_{MN-AR} (S_C)+T_{AR-SBR }(S_C,H_{AR-SBR})\\ & +T_{SBR-DDNS }(S_C,H_{SBR-DDNS}))+\alpha \log (N_{\frac{Host}{AR}} \times N_{AR} \times N_{SBR})+2\\ & \times (T_{MN-AR} (S_C)+T_{AR-SBR }(S_C,H_{AR-SBR})+T_{SBR-SBR }(S_C,H_{SBR-SBR})\\ & +T_{AR-SBR }(S_C,H_{AR-SBR})+(T_{CN-AR} (S_d)+T_{AR-SBR }(S_d,H_{AR-SBR})\\ & +T_{SBR-SBR }(S_d,H_{SBR-SBR})+T_{AR-SBR }(S_d,H_{AR-SBR})+(T_{MN-AR} (S_d))\end{array}$$

(13)

4.4.2. ILNP-Local

MN makes a handover to AR4 and updates its LLOC at SBR2, by exchanging the LOC binding update and ACK messages. With the LMT update time at SBR, i.e., PSBR, it takes 2 × (T_MN-AR(S_c) + T_AR-SBR(S_c,H_AR-SBR)) + P_SBR, where P_SBR = αlog(N_AR × N_Host/AR). The MN then notifies the LOC to CN by exchanging the LOC Update and ACK messages, which takes 2 × (T_MN-AR(S_c) + T_AR-SBR(S_c,_HAR-SBR) + T_SBR-SBR(S_c,H_SBR-SBR) + T_AR-SBR(S_c,H_AR-SBR) + T_CN-AR(S_c)). The CN delivers the data packets to the MN via AR1, SBR1, SBR2 and AR4 in sequence. The delivery time of each packet can be written as T_CN-AR(S_d) + T_AR-SBR(S_d,H_AR-SBR) + T_SBR-SBR(S_d,H_SBR-SBR) + T_AR-SBR(S_d,H_AR-SBR) + T_AR-MN(S_d), we obtain the HOD of ILNP-Local as

$$\begin{array}{ll}HO{D}_{ILNP-Local}=& 2 \times (T_{MN-AR} (S_C) \times T_{AR-SBR }(S_C,H_{AR-SBR}))\\ & +\alpha \log (N_{\frac{Host}{AR}} \times N_{AR} \times N_{SBR})+2 \times (T_{MN-AR} (S_C)\\ & +T_{AR-SBR }(S_C,H_{AR-SBR})+T_{SBR-SBR }(S_C,H_{SBR-SBR})\\ & +T_{AR-SBR }(S_C,H_{AR-SBR})+(T_{CN-AR} (S_d)+T_{AR-SBR }(S_d,H_{AR-SBR})\\ & +T_{SBR-SBR }(S_d,H_{SBR-SBR})+T_{AR-SBR }(S_d,H_{AR-SBR})+(T_{MN-AR} (S_d))\end{array}$$

(14)

4.4.3. ILNP-Distributed

In ILNP-Distributed, when MN changes the serving AR, it updates the LLOC in SBR2 by exchanging the LOC binding update and ACK messages. Letting PSBR denote the VHR update time, we express the operation time as 2 × (T_MN-AR(S_c) + T_AR-SBR(S_c,H_AR-SBR)) + P_SBR, where P_SBR = αlog(N_AR × N_Host/AR). Then, SBR2 can deliver the data packets from CN to the MN with additional delay of T_AR-SBR(S_d,H_AR-SBR) + T_AR-MN(S_d). We, hence, obtain the HOD of ILNP-Distributed as

$$\begin{gathered} HO{D}_{ILNP-Distributed}=2 \times (T_{MN-AR} (S_C)+T_{AR-SBR }(S_C,H_{AR-SBR}))+ \\ \alpha \log (N_{\frac{Host}{AR}} \times N_{AR} \times N_{SBR})+T_{AR-SBR }(S_d,H_{AR-SBR})+(T_{MN-AR} (S_d)). \end{gathered}$$

(15)

5. Numerical Results

We compare the performances of the considered mobility control schemes, i.e., ILNP-Global, ILNP-Local and ILNP-Distributed, based on the equations in the previous section. For numerical results, we use the parameter values in

Table 5. Default parameter values.

Parameter	Default	Minimum	Maximum
Lwl (ms)	10	1	55
q	0.1	0.1	0.8
Tq (ms) [15,16,17,19,20,21]	5	1	55
HAR-SBR	10	1	55
NHost/AR	500	100	10000
NAR	30	1	45
HSBR-DDNS	20	1	55
NSBR	100
HAR-AR	$\surd$NAR
HSBR-SBR	$\surd$NSBR
α [17]	0.1
β [17]	0.2
Lw	2 ms
Sc	50 bytes
Sd	200 bytes
Bwl	11 Mbps
Bw	100 Mbps

, as in [15,16,17,19,20,21].

5.1. Non-Roaming Case

We discuss the performance results for the non-roaming case.

5.1.1. Control Traffic Overhead (CTO)

We show the CTOs, i.e., amount of control messages processed at the SBRs and/or the DDNS server, of the considered mobility control schemes in Figure 10 and Figure 11, for different N_Host/AR and N_AR respectively. Our proposed scheme, ILNP-Distributed, has a significantly smaller CTO, compared to the existing mobility schemes. This is due to the fact that our scheme distributes the ID-LOC management messages over all the SBRs in the network. The performance gaps increase fast as the numbers of hosts and/or ARs increase. We also note that the ILNP-Local has a smaller CTO than the ILNP-Global because the ILNP-Local scheme does not conduct the binding query operations for the hosts in the home domain (non-roaming case).

5.1.2. Total Transmission Delay (TTD)

In Figure 12, we demonstrate the impact of wireless link delay (L_wl) on the TTD. We observe that TTD increases steadily with L_wl for every mobility control scheme. However, among them, our proposed scheme shows the minimal delay. Further, we note that the ILNP-Local has smaller TTDs than the ILNP-Global since the ILNP-Local scheme does not perform the binding query operations for intra-domain data delivery.

Next, we show the impact of wireless link failure probability (q) on the TTD in Figure 13. In all the mobility schemes, the TTD increases with q. The growth rate is low with small q but becomes high with large q. We can see that our ILNP-Distributed scheme has smaller TTDs for any fail probabilities, compared to the two existing schemes. Further, the ILNP-Local outperforms the ILNP-Global since the ILNP-Local scheme does not conduct the binding query operation for intra-domain data delivery.

In Figure 14, we observe the TTD curves while varying the average queuing delay (T_q) at each router. TTD increases quickly with larger T_q in all the candidate schemes. However, our proposed scheme shows the smallest value and the smallest growth rate among them. We note that the ILNP-Local is better than the ILNP-Global since the ILNP-Local scheme does not perform the binding query operation for intra-domain data delivery.

Figure 15 shows the impact of the hop count between AR and SBR (H_AR-SBR) on the TTD. TTD increases with the hop count for all the mobility schemes. Our ILNP-Distributed outperforms the competitors for any hop counts, and the ILNP-Local works better than the ILNP-Global.

We provide the TTD curves for different hop counts between SBR and the DDNS server (H_SBR-DDNS), in Figure 16. TTDs of the existing schemes are significantly affected by H_SBR-DDNS, since many binding messages are exchanged between SBRs and the DDNS server. On the contrary, our scheme does not employ the DDNS server and its TTD remains constant regardless of H_SBR-DDNS.

5.2. Roaming Case

We here study the roaming case.

5.2.1. Control Traffic Overhead (CTO)

We present the CTOs for different N_Host/AR and N_AR, in Figure 17 and Figure 18 respectively. We observe that our proposed ILNP-Distributed shows a smaller CTO than the existing schemes, which can be explained as follows. In the previous mobility schemes, all the control messages are processed by the DDNS server. On the contrary, in our scheme, the control messages are distributed to the SBRs in the network. Their performance gaps increase rapidly with the number of hosts and/or ARs. We can see that the ILNP-Local performs poorly in roaming case and its CTO curves are overlapped with those of the ILNP-Global, due to the frequent binding update operations between each SBR and the DDNS server.

5.2.2. Total Transmission Delay (TTD)

We show the impact of wireless link delay (L_wl) on the TTD in Figure 19. The TTD increases steadily with L_wl in all the candidate mobility schemes. However, our ILNP-Distributed has, relatively, a smaller TTD than the existing schemes. Moreover, the ILNP-Local is better than the ILNP-Global. Their performance gap increases with L_wl.

In Figure 20, we show the impact of wireless link failure probability (q) on the TTD. The TTD increases with q slowly for small value, but the growth rate increases for large failure probability. We can see that our ILNP-Distributed has the smallest TTD compared to the competitors. We also note that the ILNP-Local works better than the ILNP-Global since the ILNP-Local scheme does not perform the binding query operations for intra-domain data delivery.

In Figure 21, we compare the TTDs for average queuing delay (T_q) at each router. The TTD value increases with T_q for all the mobility control schemes, but our scheme has smaller values than the existing schemes for any T_q.

We show the impact of the hop count between AR and SBR (H_AR-SBR) on the TTD, in Figure 22. We note that the TTD increases with the hop count for all the candidate schemes. Our proposed scheme works well when the hop count is small. However, as the hop count increases, it performs poorer than the ILNP-Local. This is because our ILNP-Distributed scheme conducts the binding query operations for data delivery between hosts and the SBR, for both roaming and non-roaming cases. In ILNP-Distributed the processing time have been done twice on PSBR.

Figure 23 compares the TTDs of the candidate schemes for different hop counts between SBRs and the DDNS server (H_SBR-DDNS). We can see that H_SBR-DDNS has significant impacts on the TTD in the two existing schemes. In those schemes, the ID-LOC management messages are exchanged between SBRs and the DDNS server frequently. So, the two existing schemes depend on the centralized DDNS. The binding update and binding query operations perform with centralized DDNS.

5.3. Handover Delay (HOD)

In Figure 24, we present the impact of wireless link delay (L_wl) on the HOD. We observe the HOD increases with L_wl for all the candidate schemes. Our ILNP-Distributed scheme has a significantly smaller handover delay than the existing schemes. Moreover, the ILNP-Local works better than the ILNP-Global since the ILNP-Local conducts the binding update operations with the SBR only. We recall that in ILNP-Global, the binding updates after handover occurs between the hosts and the centralized DDNS server.

We show the impact of wireless link failure probability (q) on the HOD in Figure 25. For every mobility control scheme, the HOD increases with q, but our scheme performs much better than the existing schemes. The ILNP-Local gives smaller handover delay than the ILNP-Global due to the binding update operations within the domain.

We compare the HODs of candidate schemes while varying the average queuing delay (T_q) at each router, in Figure 26. The HOD increases with T_q for every mobility scheme. However, among them, our proposed scheme shows much better performance than any other schemes.

In Figure 27, we demonstrate the impact of the hop count between AR and SBR (H_AR-SBR) on the HOD. We can see that the HOD increases with the hop count for all the mobility schemes, but the rate is relatively slow in our proposed scheme. The ILNP-Global and the ILNP-Local have a similar tendency while keeping a constant gap.

5.4. Implementation Perspective

For applicability validation of the proposed scheme, we performed the testbed experimentation. For the testbed the locator was implemented by using the IPv4 address. The device ID was implemented by using the IPv6 address, which operates as 3.5 layer over IPv4.

The proposed scheme operations at GW can be summarized in Figure 28, which were implemented by using the Click Router software. When a packet arrives at the GW, it checks whether it is a control or data packet. If it is a control packet, the GW identifies the home GW for the device, based on the home domain information. Note that the home GW of device can be identified from the home domain information. In case that the packet is a data packet, if the GW already knows the LOC of the corresponding device, it will forward the packet directly. Otherwise, GW should first get the LOC of the device by contacting with the home GW of the device.

6. Conclusions

In this paper, we propose a new distributed mobility control scheme for mobile ILNP networks. Each SBR has the dedicated m-DDNS server, which maintains a Home Host Register (HHR) and a Visiting Host Register (VHR) to support the roaming. We let the m-DDNS trace all the ID-LOCs of the home hosts and the visiting hosts in the distributed manner. Hence, we obtain the LOC of any host of interest from the SBR (or m-DDNS server) of its home domain. By numerical analysis, we showed that our proposed scheme performs much better than the existing mobility control schemes in terms of control traffic overhead, total transmission delay and handover delay.