Patent Application
20070064661
Use of mobile computing devices (hereafter “mobile nodes”) such as laptops, notebook computers, personal digital assistants (“PDAs”) and cellular telephones is becoming increasingly popular today. These mobile nodes enable users to move from one location to another (“roam”), while continuing to maintain their connectivity to the same network. Given its increasing popularity, it is unsurprising that most corporate (“enterprise”) networks today attempt to facilitate fast and secure mobile computing.
In order to roam freely, networks typically conform to one or more industry-wide mobile internet protocol (“IP”) standards. More specifically, the Internet Engineering Task Force (“IETF”) has promulgated roaming standards (Mobile IPv4, IETF RFC 3344, August 2002) and Mobile IPv6, IETF Mobile IPv6, Internet Draft draft-ietf-mobileip-ipv6-24.txt, June 2003) to enable mobile node users to move from one location to another while continuing to maintain their current connectivity to the same network, and/or to the networked devices (e.g., printers). These industry standards have unfortunately encountered various adoption and implementation problems. As a result, although these standards exist, there is still a need for one or more schemes to enable mobile nodes to roam easily.
The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements, and in which:
Embodiments of the present invention provide a method, apparatus and system for mobile nodes to maintain a consistent IP tunnel while roaming across networks. More specifically, embodiments of the present invention utilize a mobile IP router to enable mobile nodes to maintain a consistent IP tunnel, while roaming across networks. The phrase “roaming across networks” is well known to those of ordinary skill in the art and includes roaming from one subnet to another on a single network (e.g., moving within a single building having multiple access points), roaming from one type of network to another (e.g., an 802.11 [Institute of Electrical and Electronics Engineers (“IEEE”) Std 802.11-1999 (Reaff 2003),] network to an 802.16 [IEEE Std 802.16-2004] network) and/or roaming from one location to another (e.g., roaming from a company to a residence, which may include changing access points and/or changing network types). Reference in the specification to “one embodiment” or “an embodiment” of the present invention means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment,” “according to one embodiment” or the like appearing in various places throughout the specification are not necessarily all referring to the same embodiment.
In order to facilitate understanding of embodiments of the present invention,
Corporate Intranet 100 may, however, also be connected to an external network, such as the Internet, and MN 140 may roam between Corporate Intranet 100 and the external network.
Typically, when MN 125 roams from Corporate Intranet 100 to External Network 200 or from access point to access point on Corporate Intranet 100 and/or on External Network 200, MN 125 may be required to establish an IPSec tunnel (“IPSec Tunnel 215”) to VPN Gateway 210 in order to securely access the corporate network. As is well known to those of ordinary skill in the art, IP tunnels such as IPSec are statically bound to fixed IP addresses at the time the tunnel is established. In other words, the binding of IPsec VPN tunnels is between the IP addresses of MN 125 and VPN Gateway 210 and if either of these IP addresses changes, the IPSec tunnel has to be renegotiated. As MN 125 roams from one location to another, its IP address typically changes, thus necessitating tear down of the existing IPSec tunnel and establishment of a new IPSec tunnel. This constant need to renegotiate IPSec VPN tunnels may cause a significantly degraded user experience, due to the latency in performing elaborate VPN tunnel setup procedures. Additionally, the constant need to renegotiate VPN tunnels may also disrupt and break many applications that rely on these tunnel. For example, corporate applications such as email and voice-over-IP (“VoIP”) services may experience problems when a user roams from network to network.
Embodiments of the present invention enhance the usability of mobile nodes by providing a method, apparatus and system for maintaining a consistent IP tunnel while roaming across networks. More specifically, according to an embodiment of the present invention, a mobile router (“MR”) may enable existing VPN tunnels to persist, even when MN 125 roams, i.e., as MN 125's IP address changes. It will be readily apparent to those of ordinary skill in the art that embodiments of the invention may be implemented in hardware, software, firmware and/or any combination thereof. Although the following description assumes that the MR is implemented in a “mobile” node, embodiments of the present invention are not so limited and may have other applicability (e.g., in scenarios where a computing device has multiple IP interfaces and the platform moves from one interface to another).
Additionally, although the following description assumes a virtualized environment, embodiments of the invention are not so limited. Instead, embodiments of the invention may have applicability within other environments such as in multi-core processing devices and/or devices having specialized processors dedicated to managing the platform. Other embodiments may include using Intel Corporation's Active Management Technologies (“AMT”), “Manageability Engine” (“ME”), Platform Resource Layer (“PRL”) and/or other comparable or similar technologies. Embodiments of the present invention may additionally include various personal devices, i.e., devices coupled to the mobile node. Thus, for example, although the following description assumes VMs on a host, instead of or in addition to a VM, one embodiment of the invention may include a personal digital assistant coupled to a mobile node and/or a cell phone coupled to the mobile node. Finally, although the following description assumes that a mobile node is moving from one location to another within a single network, other embodiments of the invention may include a mobile node moving from one type of network to another (e.g., from an 802.11 to an 802.16 network).
In order to facilitate understanding of embodiments of the invention,
VM 310 and VM 320 may function as self-contained platforms respectively, running their own “guest operating systems” (i.e., operating systems hosted by VMM 330, illustrated as “Guest OS 311” and “Guest OS 321” and hereafter referred to collectively as “Guest OS”) and other software (illustrated as “Guest Software 312” and “Guest Software 322” and hereafter referred to collectively as “Guest Software”). Each Guest OS and/or Guest Software operates as if it were running on a dedicated computer rather than a virtual machine. That is, each Guest OS and/or Guest Software may expect to control various events and have access to hardware resources on Host 300. Within each VM, the Guest OS and/or Guest Software may behave as if they were, in effect, running on Host 300's physical hardware (“Host Hardware 340”).
According to embodiments of the present invention, a virtual machine host as described above may be leveraged to enable mobile nodes to maintain a persistent VPN tunnel while roaming.
DHCP Server/Client 410 may function as a DHCP server for MN 125 internally (i.e. it may allocate internal IP addresses on request) and a DHCP client otherwise (e.g., requesting external IP addresses for MN 125 from other DHCP servers on Corporate Intranet 100 or External Network 200). According to an embodiment of the present invention, Guest OS 311 may request an IP address for VM 310. This request may be intercepted by VMR 400 and DHCP Server/Client 410 may assign Guest OS 311 an “internal” address. Similarly, VMR 400 may request an IP address from a DHCP server on Corporate Intranet 100 or External Network 200. In this example, the request from VM 310 is assumed to be for Interface 420 (e.g., an 802.11 interface). Upon receipt of an address from the DHCP server on External network 200 (“external” IP address, hereafter referred to as the “Original Address”), VM 310 may establish VPN Tunnel 450 with VPN Gateway 225 using the Original Address. In on embodiment, NAT 405 may perform address translations and store all IP addresses for VPN Tunnel 450. All network traffic between VM 310 and VPN Gateway 225 may thereafter be encrypted and transmitted to and from via VPN Tunnel 450 (Path A, solid line in
In one example, to illustrate how embodiments of the present invention maintain VPN Tunnel 450, MN 125 is assumed to roam to a new IP subnet. In one embodiment, MN 125 may move from one subnet to another, while in an alternate embodiment, VMR 400 may be configured to recognize a new network type and make the determination whether to move from one network type to another (e.g., an 802.11 network to an 802.16 network). It will be readily apparent to those of ordinary skill in the art that VMR 400 may be configured according to various predetermined scheme. As a result of the roaming, VMR 400 may be assigned a new IP address (hereafter referred to as the “New Address”) by the new subnet or network. If MN 125 is roaming within the same network, this New Address may be assigned to Interface 420 but if MN 125 roams to a different network and has to use a different wireless interface (e.g., NIC Interface 425 corresponding to the 802.16 NIC), the New Address may be assigned to the new interface. Regardless, as a result of roaming, VMR 400 now has a new address. Typically, at this point, MN 125 tears down VPN Tunnel 450 (established between VPN Gateway 225 and the now-obsolete Original Address) and reestablishes a new VPN tunnel (between VPN Gateway 225 and the New Address).
According to embodiments of the present invention, however, to eliminate the need to tear down and reestablish VPN Tunnel 450 and to avoid problems for VoIP and other applications when roaming across IP networks, VMR 400 may detect the oncoming transition to a new network and perform a DHCP renew of the Original Address and save this Original Address in a “mobility table”. A mobility table, as used herein, may include any type of data structure (e.g., buffered information, a table, etc.) In one embodiment, the mobility table may be a data structure that is maintained only for a predetermined period. The Original Address lease time may also be noted to ensure that the subnet does not allocate this IP address to any new client during this predetermined period.
VMR 400 may then request a New Address from the DHCP Server/Client 405 and send a “route update” message (via Router 415) to other routers on External Network 200 to publish its New Address as the route for its Original Address. As a result, the route update takes effect in the network, i.e., the network views Router 415 in VMR 400 as the router for the Original Address and packets destined for the Original Address are now routed to Router 415 VMR 400, which in turn routes the packets to the New Address (illustrated as Path B in
A significant advantage of embodiments of the present invention is that no complex tunneling protocols are required, unlike typical Mobile IP schemes, to make roaming transparent to Guest OS 310 applications (e.g., VoIP and/or multimedia applications). According to embodiments of the invention, each mobile device having a mobile router may be self reliant. As previously described, although the above description assumes the use of a virtual machine host, embodiments of the present invention are not so limited. Thus, for example, one embodiment of the invention may be implemented on a mobile device having a multi-core processor. According to this embodiment, one core of the multi-core processor may be dedicated to provide the mobile router functionality described herein while the remaining processors remain unchanged. Similarly, in an alternate embodiment, special purpose hardware may be added to a device to enable a mobile router to be implemented while allowing the main processor(s) to remain unchanged.
When MN 125 moves to a different subnet or network, in 505, DHCP Server/Client 410 in VMR 400 may request a new IP address from a DHCP server on Corporate Intranet 100 or External Network 200. VMR 400 may then in 506 maintain Original Address in its mobility table while updating NAT 405 with the new IP address (New Address). In 507, Router 415 in VMR 400 may send a “route update” message to other routers on Corporate Intranet 100 and/or External Network 200 to publish its New Address as the route for its Original Address. Since NAT 405 in VMR 400 continues to perform address translation (i.e., translating New Address into the internal IP address assigned to VM 310), VPN Tunnel 450 appears to Guest OS 311 and VPN Gateway 210 to be unchanged. As a result, when IPSec packets are transmitted from Guest OS 311 in 508, the packets may continue to be routed in 509 by Router 415 in VMR 400 through VPN Gateway 210.
The hosts according to embodiments of the present invention may be implemented on a variety of computing devices. According to an embodiment, a computing device may include various other well-known components such as one or more processors. The processor(s) and machine-accessible media may be communicatively coupled using a bridge/memory controller, and the processor may be capable of executing instructions stored in the machine-accessible media. The bridge/memory controller may be coupled to a graphics controller, and the graphics controller may control the output of display data on a display device. The bridge/memory controller may be coupled to one or more buses. One or more of these elements may be integrated together with the processor on a single package or using multiple packages or dies. A host bus controller such as a Universal Serial Bus (“USB”) host controller may be coupled to the bus(es) and a plurality of devices may be coupled to the USB. For example, user input devices such as a keyboard and mouse may be included in the computing device for providing input data. In alternate embodiments, the host bus controller may be compatible with various other interconnect standards including PCI, PCI Express, FireWire and other such existing and future standards.
In the foregoing specification, the invention has been described with reference to specific exemplary embodiments thereof. It will, however, be appreciated that various modifications and changes may be made thereto without departing from the broader spirit and scope of the invention as set forth in the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.
