Section 3.3 discussed five objectives of this research work. Below is a discussion of how the objectives of the thesis are achieved.
1. Implement a LOC/ID protocol on a laboratory testbed including all the required components for its mobility mechanism...
2. Analyse the inter-domain mobility performance of MIPv6 and a LOC/ID protocol on the testbed...
These two objectives were fulfilled in chapter five and six with the implementation of LISP-MN using the LISPmob code and MIPv6 using the umip code on the laboratory testbed. The LISPmob code ran on the MN, the map- server and PXTR while the UMIP ran on the MN and the HA. We chose LISP- MN for the implementation for two reasons: firstly, all the required network nodes for the protocol’s operation can be implemented on a laboratory testbed; secondly, tests could potentially be carried out on the Internet using the open LISP beta network [105]. As far as we know, none of the other protocols have a dedicated Internet overlay network similar to the LISP beta network. We have also mentioned in section 3.3 (second objective) that we would be using MIPv6 as the benchmark for measuring the handover performance of LOC/ID split
172 protocols. MIPv6 is implemented to serve as the benchmark for measuring the handover performance of LISP-MN as presented in chapter six.
A qualitative and quantitative comparison of the two protocols was presented in chapter six as a contribution to the argument of LISP-MN’s possible adoption as the host mobility protocol of the future. We also provided performance analysis of video applications on top of the two mobility protocols.
3. Design and implement a buffer node; we call Location Area Server (or simply Loc-server) that will be storing packets for a pre-registered MN and forwarding the packets at the request of the MN.
In chapter four, we presented the design description of our newly developed ILISA, as a network architecture that proposed the introduction of a new network node named Loc-server into LOC/ID split-based architectures to improve the performance of this class of mobility protocols. Loc-server is central to this architecture and designed to ensure that no packet is lost at the point of an MN’s handover. We presented how the new node could be integrated to work with different LOC/ID protocols.
In the fifth chapter, we discussed the modules developed on the MN to make it aware of the Loc-server. We also detailed the development of the server itself with different modules that perform the functions outlined in the objectives, including registering an MN and reserving buffer space for it, buffering the packets as they come in and forward to the new location of the device.
4. Implement new signalling mechanisms on the MN to enable the mobile device to interact with the Loc-server. In addition to the LOC/ID protocol’s
173
control messages, build four new signalling mechanisms on the MN to enable the packets’ redirection at the point of handover…
The four signalling mechanisms (new control messages) introduced on the MN are detailed in the design chapter to include HITr, BU-Null, BU-MN_LOC and a BU message with Loc-server address. While HITr is a newly developed module on the MN, the three other messages were built by making changes to the map- reply message of the LISP-MN as discussed in the fifth chapter on implementation.
5. Re-evaluate the performance of the LOC/ID protocol with the support of Loc- server to determine how much improvement the new node brings to the protocol in question.
In the sixth chapter, we provided a thorough performance evaluation of the newly built architecture by testing the system in both homogeneous and heterogeneous wireless environments. In each of the scenarios, we looked at the performance of the two popular transport protocols, TCP and UDP, as well as the file download and video application running on top of TCP. We performed tests on wireless links with low and high available bandwidth to gain insight into the type of environment that our new architecture will produce better performance, and at the same time determine how much support the Loc-server could give to the LOC/ID protocols.
174
7.3 Revisiting Requirements
We discussed three main requirements of any network architecture based upon LOC/ID split concept and geared towards improving the mobility of nodes to include the following:
1. Mitigating the Drop in Throughput. 2. Eliminating/Reducing Packet Loss 3. Reducing Service Disruption Time
As shown in the evaluation chapter, both LISP-MN and MIPv6 suffered long SDT, which affected both TCP and UDP-based applications. The handover of the two protocols caused throughput degradation and a high number of packet losses. Hence, the performance of an application running on the two protocols will suffer greatly during handovers. This is demonstrated with the performance of DASH video players as the players experienced low average video quality download, poor network utilisation, and increased instability. The packet loss experienced by the two protocols could potentially increase network congestion as MNs request for retransmission of lost TCP packets at handover completion. ILISA, as implemented on LISP-MN, has significantly reduced the drop in throughput experienced by Plain_LISP during a handover. With the improved architecture, the throughput attained during the handover period was significantly improved for both fast and slow wireless links. This is regardless of the wireless environment (heterogeneous or homogeneous) that the handover took place, although the new architecture improved throughput experience for MNs in HoWE more than it does in HeWE. LOC_LISP significantly reduced throughput degradation during a handover.
175 ILISA has significantly reduced the packet losses that are experienced during handover as the Loc-server buffered and forwarded all the packets sent to it during the handover. In fact, an MN in Plain_LISP environment experienced four times more losses in a HoWE than an MN in ILISA. Introduction of the Loc- server in LISP-MN architecture significantly reduced SDT by 41% for the fast link and 38% for the slow link in HeWE and similar improvements were recorded in HoWE. We also observed that sending buffered packets to the MN spurred the device into requesting for subsequent segments and the streaming continued immediately. A reduction in packet loss significantly improved UDP downloads as demonstrated by the newly improved architecture.
There is a significant improvement in the video streaming experience as all the players demonstrated improved performance on ILISA. While the throughput- based and the mixed-mode players recorded improvement in network utilisation running on the new architecture, the buffer-based player did not show any improvement in utilisation even with the Loc-server support. In fact, the improved average quality level recorded by the player is at the expense of stability.
7.4 Future Work
The most important work for the future is to integrate the Loc-server functionality into anchor nodes or remote servers. For instance, in the case of LISP-MN, the Loc-server functionality can be installed on the PXTR or the CN (in scenarios with no PXTR). It could also be on the TTR for IVIP, or the CN for ILNP and HIP. This will significantly reduce the number of control messages sent pre and post-handover. The CN expected to have this functionality will be servers that
176 provide services on the Internet and are running in LOC/ID split environment – we discussed this type of CNs in chapter 2. In such instances, an MN informs the server to hold up sending packets as the MN moves and requests the server to resume on completion of the switch.
Another work is to integrate a predictive handover capability into the new architecture. Although we can save packets to prevent loss during handover and can resume communication much faster after the handover with ILISA, we still suffer some break in communication due to link-switching delay and the associated handover events for hard handover in HeWE and handovers in HoWE. In our current architecture, once the MN discovers that its link is going down, it sends buffering request message to its Loc-server.
We will build a mechanism where the MN scans for and starts association procedure with its target AR by exchanging router solicitation and advertisement messages via its current link. If the MN can associate with the target link before the handover, it provides its new location to its anchors and CNs for redirection of its packet. This will make handover smoother for the MN as we saw with soft handover in HeWE (section 6.4.2.2) where the reduction in throughput was unnoticed on the fast link and even recorded an increase on the slow link. If the MN could not associate with any link prior to handover, it reverts to requesting for buffering of packets by the PXTR, or for remote nodes to hold sending packets.
There is also the need to test the newly improved LISP-MN architecture on the Internet by connecting to the LISP BETA network.