IP-Based Protocols for Mobile Internetworking

John Ioannidis and Dan Duchamp, Columbia

One-line summary:
Mobility support by tunneling and encapsulation (IPIP) and a simple MSS-to-MSS protocol (MICP). M-IP requires no changes to higher-level protocols, scales reasonably well due to small amount of state at MSS (cached and timed out), and places the burden of mobility on the MHıs and MSSıs rather than the rest of the world.

Overview/Main Points

MH maintains a permanent home address; its MSS is responsible for reaching it

Routing cases:

MH-to-MH within a cell, normal ARP delivers pkts (MSS not involved)

MH to FH, normal gateway thru MSS

FH to MH, gateway thru MSS which then "discovers" what MSS is responsible for the MH (see below)

MH to MH across cells: receiving MSS proxy-ARPs for MH

Handoff

MH detects beacons coming from MSSıs (multiple beacons is "still a research issue")

MH sends greeting and old MSS to new MSS, waits for ACK that includes new transient-IP addr

New MSS informs old MSS of handoff and starts forwarding before that message is ACKıd (in case of partition or old MSS down)

Beaconing done by MSS (not MH) to reduce traffic (no req/response needed), allow MH to verify it is still in range, and conserve power on MH

MH periodically sends "still here" packet if no other traffic, to inform MSS it is still in this cell

Redirect: MSS receives pkt for MH it no longer serves; redirect is sent to sender, and pkt is forwarded (to avoid having to rely on higher-level timeouts)

Peer MSS discovery: multicast, link-level broadcast, or unicast; list can be static and distributed to new MSSıs as they join, or each MSS can propagate discovery requests to its immediate neighbors (modulo problems with connectedness of the graph, partitioning, etc)

Some perf issues: handoff latency, MSS load, encaps overhead. It is argued that all are within reason during normal operation.

Fault tolerance: exploit multiple beaconing?

Scalability: "dogleg routing" is the worst problem. Argument: scalability should be compared to alternative of reconfiguring MH on every handoff, rather than to "MH-less" alternative.

Tunneling: some discussion of earlier approach based on "loose source routing" (what is this?) and why it doesnıt work here, since dest addr of MH is a valid unicast address.

Relevance

Shows how to support mobility transparently to higher-level software by exploiting the "proxy concept" for address resolution, encaps, and routing.

Flaws

Approach is advertised as scalable, but argument seems weak. Perhaps they really meant intracampus (not intercampus) scalability, since the latter requires cooperation among the campuses and makes peer MSS discovery a larger size problem. A hierarchical discovery approach might alleviate this, but seems to be outside scope of this paper.
Back to index