Mobile Communication with Virtual Network Address Translation

Mobile Communication with Virtual Network Address Translation Gong Su and Jason Nieh Technical Report CUCS-003-02 Department of Computer Science Columbia University February 2002 Abstract Virtual Network Address Translation (VNAT) is a novel architecture that allows transparent migration of end-to-end live network connections associated with various computation units. Such computation units can be either a single process, or a group of processes, or an entire host. VNAT virtualizes network connections perceived by transport protocols so that identification of network connections is decoupled from stationary hosts. Such virtual connections are then remapped into physical connections to be carried on the physical network using network address translation. VNAT requires no modification to existing applications, operating systems, or protocol stacks. Furthermore, it is fully compatible with the existing communication infrastructure; virtual and normal connections can coexist without interfering each other. VNAT func- tions entirely within end systems and requires no third party services. We have implemented a VNAT prototype with the Linux 2.4 kernel and demonstrated its functionality on a wide range of popular real-world network applications. Our performance results show that VNAT has essentially no network performance overhead except when connections are migrated, in which case the overhead of our Linux prototype is less than 7 percent over a stock RedHat Linux system. 1 Introduction large amount of research has been conducted in an effort to Ubiquitous mobile computing is a coming reality, fueled in overcome this deficiency [BP93, IDM91, MB98-2, Perk01, part by continuing advances in wireless transmission tech- Perk96, QYB97, SB00, TYT91, ZD95]. However, previous nologies and handheld computing devices. As computations approaches either require changes to network or transport are increasingly networked, mobility in data networks is be- layer protocols, or suffer from substantial performance pen- coming a growing necessity. Examples of this demand in- alties [ZM01], which limit their deployment. clude laptop users who would like to roam around the To effectively support efficient transparent migration of network without losing their existing connections, system end-to-end live network connections without any changes to administrators of network service providers who would like existing network protocols, we introduce Virtual Network to move running server processes from one machine to an- Address Translation (VNAT). VNAT is a novel mobile other due to maintenance or load balancing requirements communication architecture that enables connection mobil- without service disruption, and scientific users who would ity for a spectrum of computation units, ranging from a sin- like to move their long-running distributed computations off gle process to the entire host. VNAT utilizes three key to another machine due to faulty processor or power failure mechanisms to enable transparent live connection mobility: without having to restart the computation all over again. connection virtualization, connection translation, and con- However, data networks today offer very limited support for nection migration. VNAT connection virtualization virtual- mobility among communicating devices. One cannot move izes end-to-end transport connection identification by using either end of a live network connection without severing the virtual endpoints rather than physical endpoints (e.g., IP ad- connection. dresses and port numbers). As a result, connection identifi- The lack of system support for mobile data communication cations no longer depend on lower layer network endpoints today is due to the fact that the current de facto worldwide and are no longer affected by the movement of network end- data network protocol standards, the Internet Protocol (IP) points. VNAT connection translation translates virtualized suite, were designed with the assumption that devices at- connection identifications into physical connection identifi- tached to the network are stationary. In addition, higher lay- cations to be carried on the physical network. As connec- er protocols such as TCP/UDP inherit this assumption. The tions migrate across the network, their virtual identifications key problem is that network connection properties are never change. Instead, they are mapped into appropriate shared among many entities, across network protocols, physical identifications according to the endpoints’ attach- transport protocols, and applications. For example, TCP/ ment to the physical network. VNAT connection migration UDP uses IP addresses to identify its connection endpoints; keeps states and uses protocols to automate tasks for con- and applications use sockets, which are typically bound to nection migration such as keeping connection alive, estab- IP addresses and TCP/UDP port numbers, for their network lishing a security key, locating migrated endpoint(s), and I/O. Clearly, such information sharing makes it very diffi- updating virtual-physical endpoints mappings. cult to change the network protocol endpoints without dis- VNAT is fully compatible with and does not require any rupting the transport protocols and/or the applications. A modifications to existing networking protocols, operating 1 systems, or applications. It can be incrementally deployed tion requires additional changes to the non-migrating nodes. and operates entirely within communicating end systems While VNAT incurs almost no overhead for new connec- without any reliance on third party services or proxies. If tions started after migration, MobileIP incurs tunneling necessary, however, VNAT itself can also be installed and overhead for all traffic between the mobile node and the run on a proxy to avoid any modification to the servers be- non-migrating node. Unlike VNAT, MobileIP requires net- hind it. VNAT assumes no specific transport protocol se- work layer protocol and infrastructure changes that are cost- mantics and therefore can be easily adapted to any transport ly and make it very difficult to deploy. [MB97] proposed an protocol. It also supports both client and server mobility and interesting approach that exploits the similarity between does not put any restriction on the mobility scope. We have mobility and multicasting, but it relies on a scalable multi- implemented VNAT as a loadable kernel module in Linux cast infrastructure which does not yet exist today. 2.4. Our experience with VNAT shows that it works effec- Migrate [SAB01, SB00] is a transport layer mobility archi- tively with a wide range of popular real world applications. tecture that allows migration of individual end-to-end con- Our experimental results on an unoptimized VNAT proto- nections between two applications. Since traditional type show that VNAT imposes almost no virtualization or transport protocols are not built with mobility in mind, Mi- translation overhead except when connections are migrated, grate introduces a new TCP option to support suspending in which case the overhead of our prototype is between 2 to and resuming TCP connections. Migrate does not support 7 percent for the applications tested. migration of TCP connections for which both endpoints This paper describes the VNAT architecture with a focus on move simultaneously. Unlike VNAT, Migrate is TCP-spe- the VNAT connection migration mechanism and is orga- cific and requires transport layer protocol changes which nized as follows. Section 2 surveys related work. Section 3 make it difficult to deploy. presents the main VNAT architecture concepts and con- MobileIP and Migrate also provide mechanisms for mobile structs and illustrates how VNAT can be used in a few ex- host location. MobileIP uses the notion of home and foreign ample connection migration scenarios. Section 4 describes agents to also provide mobile host location technologies. the implementation of our VNAT prototype in Linux 2.4. Migrate uses dynamic DNS updates [SB00]. Our work on Section 5 shows experimental results that measures the per- VNAT focuses on the “tracking” (preserving an end-to-end formance overhead of our VNAT prototype. Finally, we connection once it is established) aspect of connection mo- present some concluding remarks. bility while being compatible with and taking advantage of existing mobile host location technologies, such as those 2 Related Work used in MobileIP and Migrate. A variety of approaches have been taken in previous work MSOCKS [MB98-2] is a proxy-based mobility architecture in providing communication mobility in current (IP) data based on the TCP Splice [MB98-1] technique. Essentially, networks. These approaches can be loosely classified as net- a single TCP connection between a mobile client and a sta- work layer mobility mechanisms, transport layer mobility tionary server is spliced by a proxy in the middle into two mechanisms, proxy-based mechanisms, and socket library separate TCP connections. The proxy handles the discon- wrapper mechanisms. We discuss these approaches and also necting and reconnecting of the client-proxy half of the TCP describe related work in process migration. connection when the mobile client moves and makes the MobileIP is the most well-known network layer mobility single TCP connection between the mobile client and the mechanism, recent versions [JP02, Perk01] have consolidat- stationary server appear to be intact. Due to its reliance on ed various improvements to the original proposals [BP93, TCP Splice, MSOCKS assumes TCP

Load more