Method, apparatus and system for obtaining and retaining a mobile node home address

A method, apparatus and system which enable a mobile node to request dynamic allocation of a home address and to maintain that home address when roaming between a home subnet and a foreign subnet. According to one embodiment, the mobile node may acquire a home address from its home agent by using a Network Access Identifier (“NAI”) extension in a registration request. The mobile node may send out this registration request when it first starts up, regardless of whether it is on its home subnet or a foreign subnet. Additionally, the mobile node may set a bit in the registration request to inform the home agent that it is on its home network. If the bit is not set, the home agent may deduce that the mobile node is on a foreign network. In either instance, the mobile node may continue to use its originally acquired home address.

FIELD

The present invention relates to the field of mobile computing, and, more particularly to a method, apparatus and system for enabling a mobile node to dynamically obtain a home address and to retain the home address while roaming between its home subnet and foreign subnets.

BACKGROUND

Use of mobile computing devices (hereafter “mobile nodes”) such as laptops, notebook computers, personal digital assistants (“TDAs”) 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 IP standards. More specifically, the Internet Engineering Task Force (“IETF”) has promulgated roaming standards (Mobile IPv4, IETF RFC 3344, August 2002, hereafter “Mobile IPv4,” and Mobile IPv6, IETF Mobile IPv6, Internet Draft draft-ietf-mobileip-ipv6-24.txt (Work In Progress), June 2003, hereafter “Mobile IPv6”) to enable mobile node users to move from one location to another while continuing to maintain their connectivity to the same network.

DETAILED DESCRIPTION

Embodiments of the present invention provide a method, apparatus and system for mobile nodes to dynamically discover configuration information while roaming. 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.

FIG. 1illustrates a known corporate intranet (“Corporate Intranet100”) structure. Corporate Intranet100may include both wired and wireless networks and may comprise multiple subnets. Typically, an organization's network is comprised of one or more subnets. A subnet refers to a portion of an organization's network interconnected to other subnets by a routing element. Subnets are well known to those of ordinary skill in the art and further description thereof is omitted herein.

Mobile nodes that conform to Mobile IPv4 standards today may roam freely across subnets within Corporate Intranet100. Thus, for example, when a mobile node (“MN140”) exits its home subnet, it may continue to maintain its current transport connections and constant reachability by registering with a home agent (“HA130”). During the registration process, MN140informs HA130of MN140's home address (i.e., the invariant address assigned to MN140) and its “care-of address” (hereafter “COA”), namely MN140's address on its new subnet. MN140may obtain COAs via Dynamic Host Configuration Protocol (“DHCP”) or other similar protocols. Immediately after the registration process completes, HA130may broadcast a series of unsolicited ARP packets on behalf of MN140(hereafter referred to as “gratuitous ARPing”). HA130may also respond to ARP requests targeted to MN140(hereafter referred to as “proxy ARPing”). Both gratuitous ARPing and proxy ARPing have the effect of causing traffic addressed to MN140to be delivered to HA130. HA130thereafter intercepts all IP packets addressed to MN140and reroutes the packets to MN140's COA using IP tunneling. IP tunneling is well known to those of ordinary skill in the art and further description thereof is omitted. As MN140moves from one foreign subnet to another, to ensure that HA130is able to properly route packets to MN140, MN140must continuously update HA130with its new COA. If MN140moves to its home subnet, it deregisters with HA130, causing HA130to cease performing the proxy ARP and IP tunneling functions.

As previously described, in order for MN140to register with HA130, it typically provides HA130with an invariant home address that uniquely identifies it to HA130. In other words, HA130requires both a home address and a COA for MN140in order to properly perform IP tunneling. Typically, home addresses are assigned statically to mobile nodes, e.g., by a system administrator on Corporate Intranet100. A proposed IETF solution (IETF RFC 2794, March 2000, hereafter referred to as “RFC 2794”) enables MN140to acquire a home address dynamically by using a NAI extension. More specifically, when MN140first attaches to a foreign subnet (i.e., when it exits its home subnet or starts up on a foreign subnet), it sends a registration request to HA130to register its COA; the registration request may also include a NAI extension requesting a home address assignment. HA130may dynamically assign a home address to MN140from a pool of addresses maintained by HA130, or acquire a home address on behalf of MN140from a DHCP server (“DHCP Server150”) on Corporate Intranet100. HA130may return the home address to MN140via a registration reply and MN140may thereafter utilize this home address in subsequent registration requests each time it moves within the network.

RFC 2794 includes several shortcomings. Specifically, RFC 2794 does not address the situation when initially MN140starts up on its home subnet. Since the methodology described in RFCs 2794 and 3344 to acquire a home address do not allow MN140to register with HA130until it exits its home subnet, MN140has no way of obtaining a home address when it starts on its home subnet. Additionally, according to RFC 2794, MN140must deregister when it roams back to its home subnet. Even assuming MN140does obtain a home address for use, the deregistration process in RFC 2794 effectively releases MN140's home address back to HA130's address pool or back to DHCP Server150. More specifically, HA130removes all bindings for MN140in its binding table and may release MN140's home address, making MN140's home address available for assignment to other mobile nodes. Concurrently, MN140may continue to use its home address on its home subnet, possibly leading to an address conflict if its home address was subsequently re-assigned to another mobile node.

Embodiments of the present invention alleviate the shortcomings of RFC 2794 by enabling MN140to dynamically acquire and retain a home address regardless of whether it starts up on its home subnet or a foreign subnet, and regardless of whether it subsequently moves from a foreign subnet to its home subnet. In one embodiment, MN140may be configured to register with HA130regardless of whether it is on its home subnet or on a foreign subnet. When it initially starts up, MN140may send a NAI extension with its registration request, and HA130may assign MN140a home address from its local pool of addresses or obtain a home address for MN140from DHCP Server150. This initial registration on its home subnet addresses one of MN140's problems, namely that of obtaining a home address dynamically while starting operation on its home subnet.

Additionally, according to an embodiment of the present invention, MN140may also be configured to inform HA130whether MN140is on its home subnet or on a foreign subnet. The registration request process as described in RFC 2794 currently includes various reserved bits that are not utilized. In one embodiment, MN140may set one of the reserved bits (hereafter referred to as the “OnHomeSubnet” bit) to a predetermined value to enable HA130to determine whether MN140is on its home subnet or on a foreign subnet. In one embodiment MN140may leave the OnHomeSubnet bit unchanged (i.e., at zero) when it is on a foreign subnet and set the bit to one when it is on its home subnet. MN140may then send the registration request to HA130. When HA130receives the registration request, it may examine the OnHomeSubnet bit, and upon identifying whether the bit is set to one, determine whether MN140is on its home subnet or on a foreign subnet.

HA130may utilize the information obtained from the OnHomeSubnet bit to appropriately determine how handle gratuitous and proxy ARPing on behalf of MN140, and how to forward communications to MN140. More specifically, if HA130determines that MN140is on a foreign subnet (i.e., the OnHomeSubnet bit is zero), it may perform its typical role as a home agent, i.e., maintain a binding for MN140's home address and COA in its binding table, perform proxy ARPing on behalf of MN140, and tunneling packets to MN140. If, however, HA130determines that MN140is on its home subnet (i.e., the OnHomeSubnet bit is set to one), HA130may process MN140's registration request as a special registration request. HA130may therefore release the binding for MN140's home address and COA in its binding table, but not release MN140's home address. In other words, MN140may retain its home address while roaming on its home subnet, but HA130may no longer be performing its proxy ARPing and/or IP tunneling functions on behalf of MN140. Regardless of whether MN140is on its home subnet or on a foreign subnet, it may periodically re-register with HA130to ensure that it retains its home address.

The following example describes an embodiment of the present invention further. Specifically, the example assumes that MN140starts up on its home subnet, roams to a foreign subnet, and then returns to its home subnet. When MN140initially starts up on its home subnet, in one embodiment, it may send a registration request to HA130, with a NAI extension requesting a home address assignment. The registration request may additionally include the OnHomeSubnet bit set to one. Since it is on its home subnet, MN140may not acquire and send a COA to HA130with this registration request. MN140may, for example, utilize broadcast “agent solicitation” messages and receive “agent discovery” messages from HA130to discover whether it is on its home subnet. These types of broadcast messages are well known to those of ordinary skill in the art and further description thereof is omitted herein in order not to unnecessarily obscure embodiments of the present invention.

Upon receiving the registration request from MN140, HA130may assign a home address to MN140from HA130's local pool of addresses or acquire a home address for MN140from DHCP Server150. This home address may be returned to MN140via a registration reply. Since HA130is aware that MN140is on its home subnet (because the OnHomeSubnet bit is set to one), HA130may not perform any proxy and gratituous ARPing on behalf of MN140. MN130does, however, maintain information for MN140in its binding table, and does not release the home address it had assigned to MN140.

When MN140exits its home subnet, it may acquire a COA from DHCP Server150(or other COA source), and use this COA and its home address in a registration request to HA130. Additionally, in the registration request, MN140sets the OnHomeSubnet bit to zero, since MN140is now on a foreign subnet. When HA130receives the registration request, the OnHomeSubnet bit will inform it that MN140is on a foreign subnet. HA130may therefore create a binding for MN140in its binding table and perform typical home agent routing and/or proxy ARPing on behalf of MN140. HA130may continue functioning as a typical home agent for as long as MN140continues to roam on foreign subnets.

When MN140returns to its home subnet, it may once again set the OnHomeSubnet bit to one. According to one embodiment, instead of deregistering with HA130as specified by RFC 2794, MN140may instead send another registration request to HA130. HA130may identify from the OnHomeSubnet bit in the registration request that MN140is once again on its home subnet. In one embodiment, since MN140is on its home subnet and does not require a COA, the COA value in the registration request may be zeroed out. Upon recognizing that MN140is on its home subnet, HA130may treat this registration request as a special request and instead of releasing the home address assigned to MN140, it may instead only stop sending proxy and gratuitous ARPs on behalf of MN140; it will still maintain the binding for MN140in its binding table. This effectively stops HA130from tunneling packets to MN140and performing proxy ARPing, but enables MN140to retain its home address while on its home subnet.

Although the above description assumes that MN140roams only within Corporate Intranet100, embodiments of the present invention are not so limited. Embodiments of the present invention may be applicable in any roaming scenarios, e.g., if MN140roams across a corporate demilitarized zone (“DMZ”) onto an external network. For the purposes of embodiments of the present invention, it is only necessary for HA130to determine whether MN140is on its home subnet or on a foreign subnet (either within Corporate Intranet100or on an external network) Additionally, although the above description assumes that the OnHomeSubnet bit is set to one when MN140is on its home subnet, it will be readily apparent to those of ordinary skill in the art that the bits may be reversed (i.e., set to one when MN140is on a foreign subnet) without affecting embodiments of the present invention. In such a situation, the OnHomeSubnet bit may zeroed when MN140is on its home subnet. Furthermore, it will be apparent to those of ordinary skill in the art that although the above description assumes that Corporate Intranet100is a Mobile IPv4 compliant network, embodiments of the present invention are not so limited and may also be implemented on other similar networks with minimal changes.

FIG. 2is a flow chart illustrating an embodiment of the present invention. Although the following operations may be described as a sequential process, many of the operations may in fact be performed in parallel and/or concurrently. In addition, the order of the operations may be re-arranged without departing from the spirit of embodiments of the invention. In201, MN140may initially start up and in202, MN140may determine whether it is on its home subnet. If MN140determines that it is on its home subnet, in203, MN140may send a registration request to HA130, including a NAI extension requesting a home address assignment. MN140may additionally set the OnHomeSubnet bit in the registration request to one. In204, HA130may send MN140a registration reply with a home address (either from a local pool of addresses or an address acquired from a DHCP server). Since HA130is aware from the OnHomeSubnet bit that MN140is on its home subnet, it may not perform any additional “home agent” type tasks, such as proxy ARPing, gratuitous ARPing and/or IP tunneling. MN140may, however, periodically re-register with HA130(with the OnHomeSubnet bit set to one) until it identifies that it has moved off its home subnet in206.

If, however, MN140identifies in202that it is not on its home subnet, in207, MN140may acquire a COA from a DHCP server, and send a registration request to HA130with the COA. In the registration request, MN140may also request a home address and leave the OnHomeSubnet bit set to zero. When HA130receives the registration request, it may respond with a registration reply in208. Since HA130may determine that MN140is on a foreign subnet, it may act as a typical home agent for MN140(e.g., creating a binding entry in its binding table and performing gratuitous ARPing and proxy ARPing on behalf of MN140). In209, MN140may periodically re-register with HA130(including the OnHomeSubnet bit left at zero), until it identifies that it has moved back to its home subnet in206. In205and209, if MN140senses that it has moved off or back to its home subnet, it may change the value of the OnHomeSubnet bit and re-register with HA130. This informs HA130that MN140moved off or back to its home subnet and HA130may behave accordingly.

The mobile nodes and home agents according to embodiments of the present invention may be implemented on a variety of data processing devices. It will be readily apparent to those of ordinary skill in the art that these data processing devices may include various types of software, and may comprise any devices capable of supporting mobile networks, including but not limited to mainframes, workstations, personal computers, laptops, portable handheld computers, PDAs and/or cellular telephones. In an embodiment, mobile nodes may comprise portable data processing systems such as laptops, handheld computing devices, personal digital assistants and/or cellular telephones. According to one embodiment, home agents may comprise data processing devices such as personal computers, workstations and/or mainframe computers. In alternate embodiments, home agents may also comprise portable data processing systems similar to those used to implement mobile nodes.

According to an embodiment of the present invention, data processing devices may include various components capable of executing instructions to accomplish an embodiment of the present invention. For example, the data processing devices may include and/or be coupled to at least one machine-accessible medium. As used in this specification, a “machine” includes, but is not limited to, any data processing device with one or more processors. As used in this specification, a machine-accessible medium includes any mechanism that stores and/or transmits information in any form accessible by a data processing device, the machine-accessible medium including but not limited to, recordable/non-recordable media (such as read only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media and flash memory devices), as well as electrical, optical, acoustical or other form of propagated signals (such as carrier waves, infrared signals and digital signals).

According to an embodiment, a data processing 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. 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 data processing device for providing input data.