The standardisation process for Mobility Support in the Internet Protocol is well under way at this time, with IETF drafts published in the mid nineties, and a draft protocol specification published as a Request For Comment (RFC ) document in late 1996. The implementation of mobile IP will herald an important phase in the evolution of the Internet, as systems will be able to roam worldwide with transparent routing support over the existing Internet backbone.

The Internet Protocol (IP) which we all know and love (or otherwise) was devised with the implicit assumption that networks will be essentially static in topology. With the exception of relatively infrequent events, such as jackhammers boring through cables, or critical routers going up in clouds of smelly smoke, the network topology of a typical IP network will change very little, and manual reallocation of IP addresses and routing paths is both reasonable and practical.

This the the model we have lived with since the earliest days of Arpanet and the Internet. What mobility was achievable under this model was confined to what are properly termed "portable hosts", using a small set of defined ports (eg the laptop dialling in via PPP with dynamic IP address allocation). Either the host changed its IP address, or new routes had to be propagated through the network. Both schemes introduce scalability problems, the former requiring the reservation of multiple IP addresses, the latter introducing potentially high loads of route updating traffic.

Time are changing though, and the emergence of wireless networking, high performance laptops, palmtops and now "wearable" computers, and the prospect of further development of such technologies, has introduced significant pressures for robust IP support under conditions of high host mobility. Manual reconfiguration of routes or addresses ceases to be a viable proposition and a fully transparent automatic scheme is required.

Issues in IP Mobility

There are a number of important issues which arise in introducing mobility support into IP and these must be addressed for any scheme to be viable.

These issues are related to, yet separate from the issues involved in creating wide area wireless networks using centralised or cooperative routing. These are being currently researched under the massive US DARPA GLOMO (GLObal MObility) research program. GLOMO aims to produce mechanisms to support ad hoc networks with minimal if any static network infrastructure.

A mobile scheme for IP would ideally converge transparently with a wide area mobile MAC layer ad hoc networking scheme, so that any host anywhere has unlimited potential connectivity.

Clearly these are non trivial issues to be resolved, and this is also why the standard has been in gestation since the early nineties, as various schemes were proposed, tested and ultimately stripped of their best features to form the current IETF proposal.

An Historical Perspective on IP Mobility

By the early nineties at least four schemes for IP mobility were devised and to various degrees, modelled or tested (readers are referred to two papers by Myles and Skellern of Macquarie Uni).

The Sony Mobile Host Protocol (MHP) was based on the idea of the Propagating Cache Scheme, in which a Mobile Node (MN) acquires a temporary IP address from its point of attachment and then embeds the location information into a new IP option field to update routers along the path. Routers supporting this scheme would cache the location information. The location information was also to be propagated to the the MN's "home" gateway or router, which provides a fallback source for location information sought for new connections, should various caching routers in the network have timed out and trashed their cache entries. The Sony scheme was therefore not backward compatible with existing technology, while also having weaknesses such as the need to maintain a pool of uncommitted IP addresses.

The Columbia MHP was fundamentally different from the Sony proposal. It was based upon the idea of Mobile Subnet Routers (MSR), which would be located in close proximity to a MAC level interface for mobile nodes. The MSR would create the illusion of a conventional IP subnet to the outside world, yet this subnet would really comprise a number of mobile nodes. A mobile node moving between MSRs will notify the "new" and "old" MSRs of its presence, whereby the "old" MSR caches the address of the "new" MSR and forwards packets intended for the mobile node via an encapsulation protocol. The MSRs will exchange location information for nodes as required. The weakness of the Columbia scheme was it reliance on the MSR models, optimised for a LAN rather than WAN environment. This was to be addressed by a scheme termed the "popup mode", in which a temporary address was acquired at a new location, and the mobile node would then register itself at its "home" MSR, which would forward packets via a mechanism termed IP tunnelling (discussed further). The weakness of no backward compatibility and suboptimal WAN environment performance led to the demise of this scheme, although the tunnelling model has remained in the final proposal.

The IBM I MHP scheme shared features of the Sony and Columbia schemes, such as the use of a "base station" (BAS) and the use of a home node to which location information was propagated. The important difference in the IBM I scheme was the use of Loose Source Record & Routing (LSRR) to propagate location information through the network.

At this point it is worth digressing to describe LSRR since it is an existing feature of the IP network. Defined in RFC 791, LSRR allows a datagram to be routed via a series of intermediate nodes to its ultimate destination. The option is implemented by providing a header with a list of intermediate router addresses and a pointer. The datagram is then forwarded to each router in the intermediate router address list, with the pointer being incremented with each hop. Each router updates the header with its own interface addresses.

LSRR is exploited by the IBM I scheme to propagate location information through the network, and is backward compatible with existing routers. Therefore the mobile node will insert the address of its current base station into the LSRR route, and subsequent datagrams sent to it will be sent via the reverse route back to the current BAS. Upon migration between BAS' the mobile node sends an update to it previous BAS. While the use of LSRR was backward compatible, other aspects of IBM I were not and it therefore evolved into the IBM II proposal. The IBM II scheme included aspects of other schemes and adopted encapsulation.

The IBM II scheme evolved into the Internet Mobile Host Protocol (IMHP) scheme, by incorporating features from the 1993 Macquarie University Internet draft proposal and could therefore be described as a hybrid of all of the described schemes. IMHP became the basis of the current RFC 2002 "IP Mobility Support" draft standard.

While the path to RFC 2002 has been rather tortuous, it is an excellent illustration of the IETF standards process, and a good case of evolution in action, whereby the best features of several competing schemes are merged into a common standard.

IP Mobility Support - RFC 2002

RFC 2002 (Perkins, 1996) extends the existing Internet protocol suite with backward compatible additions to support mobility, which address the basic issues in IP mobility in a robust manner.

Several new network "entities" are defined:

The central idea of this scheme is that every mobile node has a home IP address associated with its home network and colocated home agent/router (see Fig.1). The binding between the mobile node and its home address is intended to be permanent, so as to retain the existing DNS scheme. When a mobile node moves away from home, the home agent is provided with a current "care-of address" which tells the home agent where to forward datagrams to. When a mobile node sends a datagram, it always uses its home IP address as the source IP address, with the exception of some mobility management protocols. Connections made to the mobile node go to the home IP router, which then forwards them to the current IP "care-of address" via IP tunnelling. The mobile node may sent datagrams directly to any other node in the network, not necessarily passing through the home agent. In this manner the traffic overhead is minimised ( the pathological example could be a mobile node with a Melbourne home address communicating from the UK with a node in an adjacent room ).

The model adopted in many respects parallels the model used in mobile telephony, where the home agent is analogous to a local base station.

The traffic overhead is acceptable in the context of a mobile node acting as a client in a client-server software architecture, in that it will initiate connections to a foreign server directly and not incur the long distance overhead of tunnelling. The reverse is however true should the mobile node be a server, in that clients initiating connections will have to connect to the home router and then tunnel back to the foreign router supporting the mobile node (in the context of our pathological case we would avoid cross mounting NFS drives). For applications such as SMTP (email) the modest traffic volume should not introduce an overhead any greater than that incurred via the established forwarding mechanism.

The process of registering with a foreign agent is worth closer scrutiny. It takes place in several steps:

It is worth noting that this scheme does impose the burden upon mobile agents (home or foreign being a matter of context) of maintaining some pool of IP addresses which are to be dynamically allocated for mobile hosts, be they local residents or visitors. However, given that this is no different from the current practice of reserving a pool of IP addresses for dial in PPP connections, this should not prove to be a major issue especially with the advent of IPv6. The mobility mechanism as is will support mobile hosts using PPP over a modem dial-in to a foreign agent, or plugging into a foreign wireless network, since both will support dynamic IP address allocation for connecting hosts.

The tunnelling method for encapsulating IP datagrams within IP datagrams is flexible in the RFC 2002 standard. Either the Generic Routing Encapsulation (GRE) specified in RFC 1701 may be used, incurring the overhead of an additional header, or the newer Minimal Encapsulation within IP specified in RFC 2004 may be employed (see Fig.3 and Fig.4). This scheme is simple and elegant, but requires that datagrams have not been previously fragmented. An IP datagram to be encapsulated has a Minimal Forwarding Header of 8-12 bytes attached to it. This contains a protocol specifier, a header checksum, the Original Destination Address and an optional Original Source Address. The IP header itself is also modified, with the protocol field changed, the Destination field changed to point to the endpoint of the tunnel, the Source field replaced by the address of the encapsulator, the Total Length field adjusted and the Header Checksum recomputed. The total size increment is a modest 8-12 bytes and the computational effort is trivial for contemporary routers.

The registration mechanism with a home agent is authenticated using the RSA MD5 secure hash algorithm, with a 128 bit key. The key is to be distributed manually, which is not an unreasonable constraint.

A plethora of other management related details are specified in the standard suite, but will not be discussed in detail to maintain brevity and clarity. Some nice mechanisms have been specified, such as the addition of further home agents to alleviate load on routers which may be heavily burdened with traffic tunnelling for a large number of wandering mobile nodes away from home. An SNMPv2 MIB has also been defined, thereby allowing integration with existing management tools. The PPP Internet Protocol Control Protocol standard, used to configure PPP links, has been extended to support mobile IP (RFC 2290), allowing the direct use of a visiting node's home address rather than the (above) mechanism of address assignment. Multicasting will be supported via reverse tunnelling, now specified in RFC 2344. Sun Microsystems have also proposed a firewall traversal mechanism, specified in RFC 2356.

Implementations have been produced by CMU, FTP Software, IBM, Motorola, Nokia, Sun Microsystems, Telxon and interoperability demonstrated for standardisation purposes.

Internet drafts now exist for a number of useful extensions to the RFC 2002 (almost) standard:

In summary, it is fair to say the proliferation of Mobile IP is now imminent with mutually interoperable implementations of the early draft standard now in existence, and refined extensions of the baseline standard now well into the standardisation process.

While we are yet to see the final incarnation of this family of standards for some time yet, we can be certain that computing will never be quite the same once it does arrive. Tired of mobiles ringing in your favourite restaurant disturbing a candlelit dinner ? Try wearables beeping the arrival of new email ....