ROUTE OPTIMIZATION EXTENSION FOR THE MOBILE INTERNET PROTOCOL IN LINUX

Transcription

1 ROUTE OPTIMIZATION EXTENSION FOR THE MOBILE INTERNET PROTOCOL IN LINUX M. L. Jiang and Y. C. Tay ABSTRACT The base Mobile Internet Protocol (Mobile IP)[1] 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 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 1 along this path through the Internet. The Route Optimization Extension Protocol[2] enables correspondent nodes 2 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 Li Yunzhou s implementation of the base protocol[3] at the National University of Singapore. 1. INTRODUCTION With the exponential increase in 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. The 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. This routing mechanism implies that if a host moves to a new network while its IP address is unchanged, datagrams will not reach it; on the other hand if the host changes its IP address accordingly, it will lose any existing 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 3, Foreign Agent 4 and Mobile Node 5. Each mobile node is always identified by its home address regardless of its current point 1 Router: A device which forwards traffic between networks. 2 Correspondent Node: A peer with which a mobile node is communicating. 3 Home Agent: A router on a mobile node s home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. 4 Foreign Agent: A router on a mobile node s visited network which provides routing services to the mobile node while registered. 5 Mobile Node: A host or router that changes its point of attachment from one network or subnetwork to another. A mobile node may change its location without changing its IP address.

2 of attachment to the Internet. While not situated at home, a mobile node tries to associate itself with a care-of address 6 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 7 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 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 dotted lines are the route without Route Optimization, the thick dotted lines are the route with Route Optimization. The numbers on the lines indicate the sequence that the datagrams are routed. In this example, the base Mobile IP requires at least 5 hops, while with Route Optimization the datagrams can reach the mobile node in only 2 hops. With Route Optimization, the correspondent node can tunnel its datagrams directly to the mobile node, bypassing the possibly lengthy route for each datagram to the mobile node s home agent. 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 a mobility binding in Route Optimization s terminology. 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, 6 Care-of Address: The termination point of a tunnel toward a mobile node, for datagrams forwarded to the mobile node while it is away from home. 7 Tunnel: The path followed by a datagram while it is encapsulated.

3 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 agent. 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-ofdate 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 nature of Mobile IP, indirect routing and wireless data transmission being involved, vulnerability is increased to some extent. For Route Optimization this is more so 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 these 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. Rebuilding a kernel is a very tedious and error-prone process. In future, with Mobile IP gaining popularity, we can expect a large number of computers to be equipped with some software of this kind to optimize routing to mobile computers. Thus for ease of installation and usability, a daemon program that runs in user space rather than embedded in the kernel, is designed for the correspondent nodes.

4 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 Mr Li Yunzhou s implementation of 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 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[4] 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 command line program is designed which talks to the daemon through a unix stream socket. It turns the daemon on and off, as well as reports to the users 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.

5 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 hacks. Therefore, for 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 this is done with these three entities will not be presented here. However a short description for each is given as follows: 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 registration request message. It will then keep sending binding update messages to the old foreign agent until it receives a binding acknowledgment. For the foreign agent, it has to remove entries from its registration table and optionally establish an entry in the binding cache upon 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 have a updated mobility binding, because otherwise it would have directly tunneled the datagram to the foreign agent). 4. PROBLEMS AND SOLUTIONS Our implementation conforms to the Internet Engineering Task Force s version 4 of the Route Optimization Extension. In version 3, the way a foreign agent informs a correspondent node of its outdated binding cache is quite different. It sends a binding warning message to the mobile node instead of to the home agent directly. Our correspondent node is able to cooperate with these two kinds of foreign agents. Upon receipt of the binding warning message, it will request the mobile node s mobility binding from the home agent. The base protocol supports multiple simultaneous mobility bindings, which enables the mobile node to register with multiple foreign agents and the home agent will tunnel a separate copy of each arriving datagram to each care-of address. However, the Internet draft for Route Optimization does not support this feature explicitly. In our implementation, the home agent will simply update the correspondent nodes with the first mobility binding of the mobile node it finds in its registration table. This is not an elegant way of solving this problem. In future releases, some extensions will probably be defined to support this feature in the correspondent node.

6 By default, the loadable module that deals with IP tunneling provides only two tunneling devices. This restricts the correspondent node to having a maximum of two 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. USING THE SOFTWARE The source code for Route Optimization and the base protocol can be found at the URL: ftp://ftp.nus.sg/pub/mobile-ip. Instructions for installation and using this software are also included. They are fully tested under Linux kernel version , however the correspondent node daemon and its command line program should be able to run regardless of the kernel versions. They are free software and can be redistributed and modified under the terms of the GNU General Public License. 6. CONCLUSION AND FUTURE WORK This is the first version of the Route Optimization Module and one of the first of its kind in the world. We focused mainly on feasibility. It is not meant to be used practically. Because anybody can just manipulate the correspondent node s routing by sending it some fake binding update messages and hijack its traffic. In the next version, the security features will hopefully be implemented. ACKNOWLEDGEMENTS First and foremost I would like to thank my supervisor Dr. Tay Yong Chiang and Dr. Chua Kee Chaing for their support and guidance throughout the project. Thanks to Mr. Li Yunzhou and Mr. Amlan Saha who were also working on the Mobile IP project with me; especially Yunzhou who has not only solved a lot of technical problems for me but also many problems in life. Thanks to Mr. Loh Kok Jeng for his helpfulness and caring. Finally to all my CCN lab colleagues, life in the lab would not have been so fun without them. 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] Y.Z. Li. ftp://ftp.nus.sg/pub/mobile-ip. Internet Archive, July [4] C.Perkins. IP Encapsulation within IP. Internet Draft, October 1995.