ROUTE OPTIMIZATION EXTENSITON FOR THE MOBILE INTERNET PROTOCOL IN LINUX

Transcription

1 ROUTE OPTIMIZATION EXTENSITON FOR THE MOBILE INTERNET PROTOCOL IN LINUX ABSTRACT The base Mobile Internet Protocol (Mobile IP) provides a means for portable computers to roam freely, changing its point of attachment to the Internet, while without having to change its IP address and reestablish its present transport layer connections. Using the base Mobile IP, all the datagrams destined to the Mobile node are routed to the its home agent first, then tunneled to the mobile node. This indirect routing can significantly delay the delivery of the datagram to the mobile node and places an unnecessary burden on the networks and routers along this path through the Internet. Route Optimization Extension Protocol enables correspondent nodes that implement them to cache the binding of the mobile node then tunnel the datagrams to it directly. This document describes an implementation of the Route Optimization Module that works together with the National University of Singapore s software of the base protocol developed by Mr. Li Yunzhou. 1. INTRODUCTION With the booming in the expansion of the use of the Internet and proliferation of powerful notebooks, being connected to the net while traveling around has become possible and more and more a necessity for people whose professions require frequent traveling and fast responses to the changing environment. However, the current Internet Protocol does not have native support for host migration from one network to another. Current version of the Internet Protocol (IPv4) assumes that the point of attachment of a host to the Internet is fixed and uniquely identified by its IP address, a 32 bit binary number. Datagrams are sent to a computer based on the destination address field in the IP header. So they are passed from one router to another until they have come to the network that the host resides on, then finally get delivered to the host. By the nature of this routing mechanism, if a host moving to a new network while leaving its IP address unchanged it will lost routing, on the other hand if the host changes it IP address accordingly, it will lose its already existent transport layer connections. Mobile IP is an enhancement to the old IP version 4. It allows transparent routing of IP datagrams to mobile computers in the Internet. To realize the functionality of the Mobile IP, three entities are defined, namely Home Agent, Foreign Agent and Mobile Node 1. Each mobile node is always identified by its home address regardless of its current point of attachment to the Internet. While not situated at home, a mobile node tries to associate itself with a care-of address which is usually the address of one of the interfaces of the foreign agent. The protocol provides for registering the care-of address with a home agent. The home agent sends datagrams destined for the mobile node through a tunnel to the care-of address. After arriving at the end of the tunnel, each datagram is then delivered to the mobile node. However, in many cases this route is not optimal, the following figure demonstrates a typical situation: 1 See glossary in the Appendix for the definitions.

2 1 Correspondent Node 2 1 Router 2 3 The Internet Home Agent 5 4 Mobile Node Foreign Agent Fig 1. A Comparison Between MIP with and without Route Optimization. The thin dot-lines is the route without Route Optimization, the thick dot-lines is the route with Route Optimization. The numbers on the line indicate the sequence that the datagrams are routed. 2. PROTOCOL OVERVIEW Route Optimization provides a means for any node that wishes to optimize its own communication with mobile nodes to maintain a binding cache containing the current location (care-of address) of the mobile nodes. The association of a mobile node s home address and its care-of address is called mobility binding in Route Optimization s context. When sending an IP datagram to a mobile node, if the sender has a binding cache entry for the destination mobile node, it may tunnel the datagram directly to the care-of address indicated in the cached mobility binding. In the absence of any binding cache entry, datagrams destined for a mobile node will be routed to the mobile node s home agent first in the same way as the base protocol, as a side effect of this indirect routing, the home agent should inform the sender by sending it a binding update message, giving it a chance to cache the binding. When a mobile node moves and registers with a new foreign agent, the base Mobile IP does not notify the mobile node s previous foreign agent. The old foreign agent eventually deletes the mobile node s registration after the expiration of the lifetime period established when the mobile node registered there. Route Optimization requires the old foreign agent to be reliably notified of the mobile node s new mobility binding. This is done by adding a previous foreign agent notification extension to the registration request message sent to the new foreign. The new foreign agent will construct a binding update message from the registration request message and send it over to the old foreign agent to update its binding cache. When the foreign agent receives a tunneled datagram whose destination mobile node is in its binding cache, the Foreign agent can deduce that the tunneling node has an out-of-date binding cache entry for the mobile node. In this case, the foreign may send a binding warning message to the home agent, advising it to send a binding update message to the node that tunneled this datagram. Due to the

3 nature of Mobile IP, indirect routing and wireless data transmission being involved, vulnerability is increased to some extend. For Route Optimization this is more of the case because everyone can have the current location of the Mobile Node by just sending something to it, and the home agent will try to update the sender s binding. Therefore, some authentication algorithms such as key exchange, electronic signature(md5) are included in the draft. However, due to time constraint those are not implemented in this module. 3.1 General Knowledge 3. SYSTEM DESIGN Four more messages are defined as the format given by the draft, namely Binding Update Message, Binding Warning Message, Binding Request Message and Binding Acknowledgment Message. They are all UDP(User Datagram Protocol) messages. Route Optimization uses the same UDP port(434) to transfer messages as the base protocol does. The base protocol of Mobile IP was designed as part of the TCP/IP stacks in the kernel of Linux. People who have used Linux should know how cumbersome it is to rebuild a kernel. In the future, with Mobile IP gaining its popularity, we can expect a large number of computers to be equipped with some program of this kind to optimize its route to the mobile computers. Thus for ease of installation and usability, a daemon program was designed for the correspondent nodes. For the other 3 entities (mobile node, foreign agent and home agent), because of the strong interaction between the Route Optimization Module and the base protocol, the code has been embedded in the base protocol. All the routines are written in C. Compilation directives are added carefully so that users are free to choose whether to have this module or not. 3.2 Correspondent Node The daemon program listens on the UDP port 434 for any Route Optimization messages. It makes use of the tunneling device, which is a loadable module of the kernel, to encapsulate the IP messages to be sent to the mobile node in another IP header whose destination address is the foreign agent. Datagrams that are encapsulated in this way are called IPinIP 2 datagrams. Then the Internet will be able to route them to the foreign agent. The daemon is implemented with three soft states: Idle, Binding Awaiting, Binding Updated. They are controlled by timers which improve the robustness of the system even when control messages are lost in transit. Figure 2 shows the transition datagrams of the correspondent node. Since the correspondent node may talk to several mobile nodes at the same time. Different Binding Cache entries can be in different states independently. Timer Twait is to limit the amount of time to wait for the Binding Update message to come back. Timer Tlife is the life time of the binding cache entry. Since a daemon program does not have a controlling terminal, normally the behavior of a daemon is instructed through some Inter Process Communication. In this case a 2 For details of IPinIP, please refer to

4 command line program is designed which talks to the daemon through a unix stream socket. It turns on and off the daemon, as well as reports the tunneling and routing information of the daemon. Idle CN0 Binding Warning Twait Expiry Binding Update (lifetime 0) Tlife Expiry Binding Awaiting CN1 Binding Warning Binding Update Binding Updated CN2 Fig 2. Transition Datagram for the Correspondent Node. 3.3 Mobile Node, Home Agent and Foreign Agent The base protocol of Mobile IP was implemented in the Linux Kernel, so it is virtually impossible to achieve the Route Optimization Extension s goal without any kernel hack. Therefore, under these three entities the entire code of Route Optimization is in the kernel. Various interceptions have been added into the TCP/IP stack of the Linux kernel to allow interaction. Due to the complexity of the kernel, detailed explanation of what and how is done with these three entities will not be presented here. However a short description for each is given as following: For the Mobile Node, whenever it detects that it is registering through a new foreign agent, it will affix a previous foreign agent notification extension inside the binding update message. It will keep sending binding update messages to the old foreign agent until it receives a binding acknowledgment. For the Foreign Agent, it is responsible to remove entries from its registration table and optionally establish an entry in the binding cache at receipt of the binding update message; to assemble a binding update message using the previous Foreign Agent notification extension in the registration request message and send it to the previous Foreign Agent; to advise the Home Agent to inform the Correspondent Node of its outdated mobility binding by sending the Home Agent a binding warning message. For the Home Agent, it should send a binding update message to the correspondent node when it receives a binding warning message or an IP datagram to be forwarded to the Mobile Node (the home agent can deduce that the correspondent node does not

5 have a updated mobility binding, because otherwise it would have directly tunneled the datagram to the Foreign Agent). 4. PROBLEMS AND SOLUTIONS Various tests have been conducted on our testbed. In the first few experiments TCP connections from the correspondent node to the mobile node broke occasionally for some applications when the mobile node migrated from the home agent to the foreign agent. This was due to the poor quality of the physical layer. And some of the TCP datagrams in transit are lost, thus the applications though that there was connection failure and timed out. Later on, when we switched the foreign agent to another Ethernet socket, the performance was good. A sniffer on the same physical Ethernet cable as the correspondent node has shown that the correspondent node is sending IPinIP datagrams to the foreign directly. By default the loadable module tunnl.o provides only 2 tunneling devices. This restricts the correspondent node to have maximum 2 binding cache entries at the same time. This will not be enough in practice. Though it is possible to modify the source code of the kernel in order to have more tunneling devices, that has not been tested. 5. CONCLUSION AND FUTURE WORK This is the first version of the Route Optimization Module and one of the first programs of this kind in the world. We focused mainly on the its feasibility. It does not meant to be used practically. Because anybody can just manipulate the correspondent node s routing and hijack its traffic to the mobile nodes. In the next version, the security features will hopefully be implemented. REFERENCES [1] C. Perkins. IP Mobility Support, Internet Draft, December [2] D.B. Johnson and C. Perkins. Route Optimization in Mobile IP. Internet Draft, November [3] C.Perkins. IP Encapsulation within IP. Internet Draft, October [4] A.Dixit, V.Gupta and B. Lancki. Mobile-IP for Linux (version 0.95). Release Document. November 1995.