The problem with putting nomadic devices on to the Internet is that the Internet is designed to route packets hierarchically. The Mobile IP protocol was created to address this issue directly.
Network connectivity has had a significant impact on the design of embedded systems. The requirements of devices that participate in a general-purpose network-let alone the world-encompassing Internet-must be determined on a different scale than was necessary before connectivity. Those requirements also create the need for a new set of skills on the part of embedded developers. Among other things, we have had to come up to speed quickly on networking protocols.
Embedded systems generally participate in networks in the same way as other devices-from mainframes to PCs-have done in the past. A precedent exists. Granted, there may now be more devices than the Internet was originally built to support, but localization of the address space through Network Address Translation (NAT) and the increased addressing provided by version six of the IP protocols (IPv6) have largely made that a non-issue. Likewise, protocols like Dynamic Host Control Protocol (DHCP) have made device configuration much simpler than it used to be. The establishment of network support for embedded systems is coming along nicely. Or maybe not.
The TCP/IP suite of protocols works well so long as all of the nodes stand still. IP's hierarchical addressing scheme depends on the assumption that once something comes up at a particular place in the network, it stays there. This is a reasonable assumption for servers, and it's not a bad bet for PCs either. Even laptops are generally powered down when they are moved. When they arrive at their new destination, they have a chance to go through a new initialization cycle (preferably automated by DHCP) to get a new address.
Wireless communication has added a new wrinkle. What if the networked embedded device is portable and has to maintain an always-on connection? At first this may seem like a fairly unlikely combination of requirements, but anyone who has ever designed a cell phone or a wide-area pager would probably disagree. Add to that the number of new devices that need to switch seamlessly between wide-area PCS protocols and local connectivity through Bluetooth or 802.11b and suddenly the problem seems disturbingly close to our domain.
This article will examine an extension to TCP/IP that addresses the unique needs of mobile systems. Mobile IP is designed around the idea of presenting applications with a consistent virtual network that is in a constant place in the addressing hierarchy though the reality may be that the user has wandered far from that physical place. This allows the user to operate as if he were in the middle of his office while he is, in fact, sitting on the subway or even in the living room. The transitions between these settings are transparent to the user.
The mobility problem
The addressing scheme of TCP/IP distributes the chore of information delivery very effectively. The IP address consists of a combination of a network address and a node address. This is so that the backbone can deliver information to the appropriate network and local routing can take care of delivering it the “last mile” to the individual computer that needs to receive it.
The distribution of the addressing load is twofold. The network address is typically handled as a range of network addresses that are managed by a particular routing entity from the backbone. This range is often arranged as a set of subnets that has been assigned to a particular ISP. The routing tables on the Internet backbone can thus deliver in bulk any packet that has a network address within that range to a particular ISP.
The ISPs can afford to be more detailed in their examination of the address. This level of routing often takes it down to at least the exact network that should receive the packet. Each network handled by the ISP has a routing entry that tells it how to reach that network. Since the ISP only has to worry about the networks it administers, these routing tables are much smaller than they would be if administered by the backbone servers.
Once the packet reaches the network, it can generally be sent directly to the node that should receive it. This is done through yet another level of routing tables. This one has a list of all of the nodes that are appropriate for that network address.
This scheme works as long as no one ever goes anywhere or, at least, doesn't travel too far. As long as a node stays within a particular network address, it is strictly up to the local gateway to be able to find it. If this gateway handles a wireless 802.11 network, the user can wander within a sphere with a radius of up to about 300 feet. This can handle the offices at many companies, but it certainly won't get far beyond the parking lot. If the user switches to a different wireless hub or even to a different wireless protocol (GPRS, for example), suddenly, they are on a different network and their node address is no longer valid.
Laptop computers have generally solved this problem by requiring the user to reboot. This has not been a major hardship because it is rare for users to have laptops powered up while they are moving. Once they reach their destination, the laptop gets powered up and gets assigned a node address within whatever network it has access to at that location.
This can still be a problem. A laptop requiring access to local resources within a company, can find itself on the outside looking in, unable to reach those resources. This is why the Virtual Private Networking (VPN) was created. It allows devices to tunnel into a network from the outside, making it appear that the device resides directly on a particular network. This arrangement is shown in Figure 1.
This works okay as long as the device is forced to go through an initialization cycle. The new place in the hierarchy is established at that time, and the applications running on that device do not have to endure the limbo of the transition.
Nomadic devices are much more problematic. They are typically expected to either be always connected or to have a minimal startup time. Either of these expectations make it difficult to justify an extended initialization sequence. If the device also supports push capability, it must be able to negotiate changes in connectivity dynamically, presenting the application with the appearance of constant and consistent connectivity. This is what mobile IP does.
How mobile IP works
The basic concept behind mobile IP is simple. A mobile device's IP address must change as it moves from network to network, so mobile IP allows it to do so. Applications require a constant IP address, so it allows that too. The apparent conflict is resolved by maintaining two separate addresses for each device.
The first of these is the home address. This is the natural address for the device, the one that resides in the address space of the home network. The home address is assigned by the home network itself (via DHCP or some other mechanism) and stays with the device long-term. With regard to applications, this is always the IP address of the device.
The second address is referred to as the care-of address. This address could potentially change from minute to minute as a user travels through the connectivity range of several networks. To the routing protocols of the Internet, this is the destination address of the device.
That last point deserves a closer look. How can the Internet keep up with a mobile device that is flitting from network to network? The key is to remember that the backbone routing protocols only pay attention to the network address portion of the IP address. The node address is only used within that network. As each new care-of address is assigned to a device, it gets assigned to a new network, and that network alone has the responsibility of keeping track of the individual device.
The new components that make this work start within the home network. Any packets that are destined for the prodigal device will be routed to the home network first, since that is the network defined in the home address of the device. A new entity called the home agent will be present in a mobile IP-enabled network.
The home agent is responsible for intercepting any packets addressed to mobile devices that are not currently “at home,” and then forwarding those packets to the current care-of address for the device. It does this by encapsulating the packet inside another packet with the care-of address on it. This packet is then sent out on the Internet, where the routing protocols will ensure that it arrives at the network that is temporarily hosting the device, which is called the foreign network.
Once the packet gets to the foreign network it still has to get to our device. This last piece of the routing puzzle is handled by a new entity called the foreign agent. The foreign agent unwraps the packet and sends it to the actual device via the home address, which it has associated with a hardware destination address for the wireless device. When the packet arrives at the device, it is accepted as being appropriately addressed; it then travels up the TCP/IP stack to the relevant application software.
Figure 2 illustrates the routing of a packet to a mobile device that is currently attached to a network other than its home network.
I have skipped a few details here that set up all of this sleight of hand. The sequence of events that make all of this possible goes something like this:
- The device enters a new wireless network. It negotiates physical connectivity with that network through whatever protocol is appropriate.
- The device connects with a foreign agent on that network. It sends that agent a request packet that indicates its home address and the address of the appropriate home agent.
- The foreign agent communicates with the home agent. If the request is judged to be valid, the home agent records a new care-of address for the device and signals acceptance to the foreign agent.
- The foreign agent then matches up the newly assigned care-of address to the physical address that is used to reach the device in its routing tables.
This sequence of steps allows packets to reach the device, but what about packets coming from the device? The obvious way to handle this would be to have them reverse the course, flowing from the device to the foreign agent to the home agent to the final destination. In general this is not necessary, because the routing algorithms of TCP/IP don't really care where a packet is coming from. They only care where it needs to go. So it turns out that in most cases the device can simply send packets directly to the destination, with a return address of the home address.
The real charm of this solution is that most of the elements of the Internet do not need to change. The server with which the device is communicating does not need to do anything special. Most of the protocol stack on the device itself can be blissfully unaware, with the exception of the piece that negotiates with the foreign agent to establish the care-of address.
This plan works well in the mainstream of IP addressing, but complications are introduced by a number of other protocols that have become commonplace on the Internet. The next few sections will take a look at some of these complications and how mobile IP works around them.
DHCP has made the lives of system administrators much simpler. At one time it was necessary to maintain a list of all the computers on the network and to pre-assign unique IP addresses to each of them. This manual process inevitably led to situations where multiple computers had the same address. Needless to say, address duplication is a bad thing.
The advent of mobile computing just accentuates this. It is hard enough to maintain a group of relatively immobile desktop computers, but the task of updating the address space for computing devices that might wander into and out of a network several times an hour is daunting, to say the least.
From that point of view, DHCP (or some other form of automatic address assignment) is a necessity for the implementation of mobile IP. Note that the foreign agent can fulfill this function, since it ultimately has the responsibility for assigning care-of addresses to mobile nodes. One problem with this, though, is that it requires segmenting off a set of addresses that can be handled by this entity as opposed to a DHCP server. This segmentation reduces flexibility in the use of addresses within a particular network. In general, it is preferable to allow address allocation to be handled by a single central DHCP server.
Given this, where is the problem? It appears that DHCP should be able to allocate addresses to mobile nodes just as it does to fixed ones. By and large, it appears that mobile IP should be transparent to the address allocation operations of DHCP.
Generally speaking, this is correct. One problem that does show up, though, is in the lease time that is normally associated with that address. A DHCP server in a public place like a mall would quickly exhaust its pool of addresses if it allocated each of them with a lease time of a day or more. Unfortunately, the shorter lease times more appropriate for a typical mobile node would be far too short for a fixed system.
One way to resolve this issue would be to set up a separate DHCP server for mobile nodes. This would allow mobile leases to be set up on a time interval appropriate to mobile nodes while the DHCP servers handling fixed nodes could use a different, much longer value. This could work quite well for the extreme example of a public server in a mall, but it also segments the address space, which could cause problems in a business setting.
While it does complicate things, DHCP can have positive benefits for mobile IP. Right now it is possible for a DHCP client to obtain an IP address and information about DNS servers, gateway addresses, and resources on the local network. This capability is easily extended to support dynamic discovery of available home agents. Foreign agents, however, must be discovered through different protocols, since the travelling device does not fully join the local network.
Actually, a new option in DHCP will do just that, though it is not yet widespread enough in DHCP software to be assumed. This is one of the few places where mobile IP can benefit from a modification of the other protocols that define the Internet.
Firewalls are a fact of life on the Internet today. They provide a significant degree of security against a number of threats. Thus, most business networks (as well as a growing number of residential systems) include one. Properly configured, firewalls should be relatively transparent to most of the Internet's normal operations. Unfortunately, mobile IP involves one operation that does not meet the definition of “normal.”
The problem is the unique three-cornered way that packets are sent from the mobile node. The fact that packets are sent from the mobile node directly to their destination works very nicely as far as routing is concerned, but a firewall that detects a packet originating from within its network that has a return address from somewhere else may become suspicious. In fact, many firewalls and border routers implement a feature called ingress filtering, which blocks any packet that exhibits just these characteristics.
The solution is to sidestep the elegant hack that allows traffic outbound from the mobile device to be sent directly to the target. In this modification this traffic would instead be encapsulated and sent to the home agent, where it would be unwrapped and sent on to its final destination. This procedure puts a heavier load on the network, and significantly increases the computational requirements of the home agent, but it does allow mobile IP to get around the problems caused by intervening firewalls.
IPv6 is a major revamp to the IPv4 architecture. The upgrade is largely seen as driven by a shortage of IP addresses, but it is more correct to say that it was motivated by fragmentation of the address space. However, the designers of IPv6 used the opportunity presented by this upgrade to address a number of lingering problems in IPv4. As a result, it is a major upgrade, with several implications for mobile IP.
Several of the enhancements mesh quite well with mobile IP. For starters, the increased security options built into IPv6 go a long way towards verifying the identity of a mobile node to a home agent. IPv6 supports encrypted packets, allowing a home agent to more fully trust packets coming in from a remote location that purport to be from a supported mobile node.
But IPv6 has an even bigger impact on the foreign agent. In fact, it eliminates the foreign agent completely. IPv6 supports neighbor discovery protocols that replace the network discovery protocols necessary for a mobile node to join a foreign network, and the source routing options allow the home agent to specify the care-of address as an intermediate node for any packets. These factors combine nicely with the ability to pass updates to the care-of address to the home agent directly, in the form of source routing information. This eliminates the need for a foreign agent.
This convenient combination of factors is not coincidental, of course. IPv6 was built to support the mobile IP protocols natively as much as possible, and, in turn, mobile IP was designed to upgrade smoothly into IPv6. As a result, mobile IP will become much more useful as IPv6 is distributed.
The past and the future
The Internet is very different today than it was just five years ago. The addition of millions of mobile devices will make the Internet just as different five years in the future. It is a true testament to both the technical design of the Internet protocol and the RFC process that modifications can be made as they are needed. This is why IP continues to be useful, even under remarkably different requirements.
Mobile IP is an example of the adaptation that IP has undergone over this time period. It makes a networking standard that was designed for massively immobile computers serve the needs of mobile devices that can be held in one's hand, and may, in the near future, be even smaller and more portable.
As these networking needs are met more effectively, new uses will be found for mobile nodes.
Larry Mittag is chief technologist for Stellcom, a wireless systems integrator. He has been a contributing editor of Embedded Systems Programming for longer than anyone can remember. He can be reached at .