Accessibility

6.033--Computer System Engineering

Suggestions for classroom discussion

Topic: David B. Johnson. Scalable support for transparent mobile host Internetworking. In Mobile Computing. Tomasz Imielinski and Henry F. Korth, editors. Kluwer Academic Publishers, c1996. ISBN 079239697-9

By J. H. Saltzer, March 9, 1999, major revision of a March, 1997 version. March 7, 2000, minor editing for uniform terminology. January 2001, minor additions.

Mobile networking is an important idea on its own, but the real significance of this paper to 6.033 students is that in the course of figuring out what is going on it greatly boosts their understanding of the fundamental issues of networking in the non-mobile case. For this reason, the following discussion is framed in terms of the network model of chapter 4, rather than in terms of IP and Ethernet that the original paper uses.

  • A prerequisite to discussion of mobile networking is a clear understanding of two non-mobile networking things from chapter 4:
    1. advertising when a new node attaches to the network.
    2. hierarchical addressing and forwarding.
    Thus before discussing this paper it is a good idea to hold a preliminary discussion that has as its goal the placement on the board of a picture that shows an end-to-end layer sending something that requires forwarding from one hierarchical region to another. You can try to use IP addresses, but a two-component address is sufficient. The picture should include forwarding tables of both the starting node and one of the nodes that connects the two regions. This picture of how IP forwarding works in the normal case is essential, because the mobile host mechanism begins tinkering with the ground rules of that normal case. The discussion of the paper can then be supported by referring to and modifying the standard picture.

    Walk through how a message from a.b to c.e is handled in the normal case:

    If a = c then the target is in the same region. The router has an entry for c.e. If a != c then it uses the entry for c.* to forward the packet to a router that knows how to get to region c.

    Suppose I unpack a new computer and connect it to an unused network attachment point in region 18. The network manager assigns me the address <18, 142>. I call up and tell a friend to send me a message at this address. How does that message find its may to my attachment point, given that up until a couple of minutes ago there was no address assigned to it? (Advertising. My network layer sends a message down the link saying "Hi, I'm at the other end of this link, and I am known as <18,142>. This is a message from my network layer to the router's network layer, with network layer message type "route-advertise". The router then propagates this fact among the the routers of region 18, and after a litle while every region 18 router knows which link to use to forward packets toward you.)

    What if my friend was in region 15? (They follow the same procedure, noticing that a != c, so their network layer forwards it to a router that connects the two regions. Once the packet gets to a router that is in region 18, that router will have heard my advertising and will forward the packet to me.)

    What if someone in region 15 tries to send a message to <18,143>, which isn't assigned yet. (They will forward it to the nearest region-18 router, and that router will discover no entry in its routing table for a node 143. It will send back an error packet saying "no such address". In the internet the usual error message is "destination unreachable", to distinguish it from "network unreachable", which is the error you get if you try to send to non-existent region 94.)

    Now we can start talking about the mobile case.

  • What really is the requirement for mobility? What might be moving and why? Can you come up with several possible mobility scenarios?

    (1. My laptop has a telephone line port. I carry the laptop to a hotel room in Peoria, plug it into the phone there, call M.I.T., and want to read my mail.)

    (2. My laptop has a telephone line port and I own a cell phone. I carry both to Peoria, and call M.I.T. using the roving feature of the cell phone.)

    (3. My laptop has a network socket. I carry the laptop to the lecture hall and plug it into the network socket on the wall. The lecture hall is in a different building, thus in a different region of the routing hierarchy.)

    (4. I have a wireless modem in my laptop. Before leaving my office, where the laptop is in communication with a wireless concentrator in Tech Square, I started running a network client that has open connections to four servers. I carry the laptop to the lecture hall, where it is necessary to talk to a different wireless concentrator. We have changed link-level connections, and the new concentrator is in a different addressing region. I want the connections to continue to operate. This is the scenario that this paper envisions when it talks about handoff.)

    Compare those scenarios. Which ones are realistic; which ones are important to solve?

    So let's suppose that we are going with scenario 3. I plug the laptop into the socket in the lecture hall and start advertising its usual network address. What goes wrong? (Since the address is from a different region, the local routers get very upset. They send all packets that start with your region number to the inter-region router. They should reject or ignore your advertisement.)

    Maybe I should ask the network administrator to assign me an address in this region, for use in the lecture hall. Won't that work? (Two problems. 1. you have to do this every place you go. [If DHCP has been implemented on the network and in your computer, then it does this automatically. The only remaining problem is any software in your computer that has squirreled away its own network address.] 2. All those people who sent messages to the old address will get "no such address" responses. Open connections will certainly die.)

    The Johnson paper has a proposal at this point. What is it? (When your attempt to advertise is rejected, you realize that things are more complicated. So instead of sending a message with the network-layer type "route-advertise" you instead send a message with the network-layer type "foreign-agent". Assume that the router has a handler for that type.)

    What is in the message that I send to the foreign agent? (My network address--from my home region-- and the network address of the local agent in my home region. This message is in effect a request to set up a tunnel between the two agents.)

  • How does a tunnel work? (Take the present IP packet and use it as data in a new IP packet with a different address on it. The type field says IP-IP rather than IP; this ensures that it will get to the proper handler at the receiving end.)

  • What does the receiving end of a tunnel do with the message? (It unwraps the IP-IP layer, esposing the IP packet inside, and then just re-sends that IP packet.)

  • What good did the tunnel do? Couldn't we just have sent the packet normally? (We are now sending it in a different routing environment; that is, one in which there is a different routing table available. We expect this routing table to actually know how to get the packet to its proper destination. Note that a tunnel is a simple example of the concept that goes by the buzzword "Virtual Private Network".)

  • This paper provides a very nice example of backward compatibility. What does that mean? (Legacy IP implementations do not need to be modified. The new stuff works with the old stuff. But if two new implementations are talking to each other, things may work better.)

  • What is the fundamental problem that must be solved if a host is mobile? (Sending a message to that host requires asking "where in the world is car 54?" There must be some systematic way of answering that question.)

  • How does this paper answer that question? (By placing a forwarding agent in the mobile host's home network. The mobile host is expected to tell the forwarding agent where it is, and everyone else can just send stuff to the original address, where the forwarding agent will intercept and send the packet to the new location through the tunnel.)

  • How does the forwarding agent intercept packets that are addressed to me? (It advertises that it is me. There is nothing to keep a node from advertising two or more network addresses. It must then examine each arriving packet to see who it was really addressed to.)

  • Why is the foreign agent needed? (It sits at the other end of the tunnel, and when a packet comes through the tunnel, it is the entity that knows the physical link address of the mobile host, so it can forward the packet there. Display the special routing table that it must maintain. For each such mobile host that it is handling, it has an entry of the form [foreign IP address, physical link].)

  • But it says that there are some cases where the mobile host can be directly at the other end of the tunnel. When is that allowed? (This is important; if you understand this you understand a lot of stuff. When a mobile host attaches to a distant network, it attaches to a physical link. But a tunnel leads to an IP address, not to a link address. So there must be a foreign agent in the picture to stand at the other end of the tunnel and then do the last step of forwarding to the physical link going to the mobile host. IF the distant network is managed in such a way that it is willing to temporarily assign the mobile host a network address in its region, then the mobile host can itself act as the other end of the tunnel and there is no need for an extra intermediary to forward packets to it. This approach, of course, blows away the backward compatibility as far as the mobile host is concerned. But the mobile host's correspondents don't need to be changed.)

  • Does this scale well? How well would it work if every host were mobile? (Basic problem is that every packet must go to the home network and then through a tunnel. In the worst case, two mobile hosts on the same network send packets around the world a couple of times when they talk to each other. But you might guess that the average cost, measured by number of packet-forwardings, is about twice that for a fixed host, which isn't a bad multiplier.)

  • Route optimization is supposed to help. How? (First, it won't work with legacy network implementations: the network layer of anyone who participates must be updated. The idea is that when a packet intended for a mobile host arrives at the agent, the agent does two things: forward the packet through a tunnel, and send a "binding update" packet back to the original sender, giving the IP address where the mobile host is really attached now. When the original sender gets the binding update packet, it updates a binding cache and from then on it takes the responsibility to tunnel all packets directly to the new address.)

  • How does route optimization keep up if the mobile host moves to a new location? (Worst case: foreign agent drops tunneled packets. Originating host times out and resends, to no avail. Eventually the cache entry expires and the originating host sends the packet to the original IP address. Presumably the home agent knows where to find the mobile host, and will send a new binding update. There are several refinements that reduce the time required to discover and get the cache pointed properly.)

  • Is this paper describing a widely-deployed system, an experimental system, or a proposal? (It is actually just a set of proposals that has not made much progress in the real world. Hari Balakrishnan offered the following commentary on why:

    Interesting question---what is the status of mobile IP in the real world?

    The answer, to be brutally honest, is that it really hasn't had as much impact as one might have thought at first sight. Not that many real-world deployments, and the deployment of a similar system at UC Berkeley doesn't have that many users. However, there are implementations available for most OSes.

    Why might this be the case? Is it that mobility isn't important? Given the increasing numbers of laptops, handhelds, and such like, this doesn't seem right.

    And it isn't. The answer, in my opinion, is that mobile IP's solution is far too heavyweight for the rewards you get in return. The rewards aren't commensurate with the efforts. What are the efforts---kernel change or special routers to support home agent functionality, (optional) kernel changes or special routers to act as foreign agents, and the killer of them all, kernel changes at your end clients.

    All these efforts will have been undertaken by Cisco and Microsoft had the rewards been commensurate. (Actually cisco has implementations of home and foreign agents but I doubt that most installations turn them on). Pretty much the only things you can accomplish with Mobile IP that you can't using a very simple mechanism like DHCP are:

    1. Acting as a server of information (e.g., a mobile web server). This is not a common application TODAY, although it is likely and certain to change in the future. But it isn't that important today.

    2. CONTINUOUS IP connectivity while mobile. E.g., IP cellular telephony or real-time streams to mobile users. Again, a potentially useful application but not a killer one yet.

    The result is that the common case for mobile Internet access today, viz. acting as a client in the relocatable (rather than continuously mobile) context, is well-served by a simple mechanism like DHCP that assigns temporary IP addresses.

    The rewards aren't commensurate with the efforts for Mobile IP, especially the way it is implemented today.

    Having said that, claims are that Windows 2000 may have client support for Mobile IP. That's what they told me when I interviewed a year ago [1998] at Microsoft, but who knows.

  • (Slightly different set of issues, suggested by Frans Kaashoek) What are the constraints that mobile computing puts on systems? (size constraints--it has to be small to carry it around with you; power constraints--it runs on batteries with limited lifetime; security issues--you may lose your mobile with all your valuable data).
    Comments and suggestions: Saltzer@mit.edu