Vhandoff: Vertical Handoff Software

Vhandoff 1.0 ALPHA
vhandoff@daedalus.cs.berkeley.edu
University of California at Berkeley
Daedalus Group
ftp://daedalus.cs.berkeley.edu/pub/handoff



Introduction

This is version 1.0-alpha of the Daedalus project's Vertical Handoff software, which provides networking extensions to support the use of multiple wireless network interfaces in a Wireless Overlay Network structure. This system is described in more detail in the paper Vertical Handoffs in Wireless Overlay Networks , which will be appearing in an upcoming issue of ACM Mobile Networking (MONET). The reader is encouraged to read and understand that paper before continuing on.

The primary contributors to the software are:


Differences Between our Implementation and Mobile IP

It is useful to point out some of the differences between what our software provides and what Mobile IP provides:

In terms of the details of the protocol as defined by the rfc, there are some differences between our implementation and a mobile-ip compliant one, mostly having to do with low-latency handoff that Srini Seshan did for his Ph.D thesis and that I extended for the case of multiple wireles networks. Our beacon messages have a different format than mobile-ip foreign agent advertisements, and it would be easy to change the beacon format to be mobile-ip compliant. The control messages going from the mobile to the base station have a different form than the mobile-ip equivilent, and have some extra functionality as well. For example, in mobile-ip once you contact a base station, it forwards packets to you immediately. In our approach, you contact a base station and then tell it to do one of the following things:

Adding this functionality to a mobile-ip framework would mean extending the semantics of the mobile-ip client<-->base station communication.

Mobile-ip does some things, however, that our approach does not do. Because the packets from the home agent are sent out using a multicast address, there is no need to ever contact the home agent, so we don't have any home agent<-->foreign agent communication (which means we don't do any route optimization). If base stations don't listen to the multicast group, then no packets leave the mobile's home subnet. Using a multicast care-of address does not scale to many mobiles, however (the state in the intermediate routers would grow linearly with the number of mobiles), so an industrial-quality implementation would have to be heirarchical, with a unicast care-of address for delivery from the home to foreign domain and a multicast address for distribution between foreign agents in the foreign domain. We also do not implement any of the security features of Mobile-IP (the mobile trusts the base stations and the base stations trust the mobiles). In a Mobile-IP compliant implementation, this would have to be added.

In terms of implementation, there are more differences. I don't know of any mobile-ip compliant implementations (except for MosquitoNet, perhaps) that handle multiple wireless interfaces.

So the quick summary is:


Components

This software consists of several components:

There are three user-level daemons:

There are 2 user-level management programs:

There are also plans for a third program, vstatus, which shows the location and state of mobiles and base stations within the network.


IMPORTANT: Alpha Release Notes

The current version of the vertical handoff software is still in the alpha stage. As such, you will probably encounter problems. We would greatly appreciate it if upon encountering a problem, you could please relay as much information and context as possible about the problem to vhandoff@daedalus.cs.berkeley.edu.
Thank you!


Requirements

The following libraries and capabilities are required for a build of the vertical handoff software:

  • A binary license for BSDI BSD/OS 3.0.

  • Platforms

    The kernel sources have only been ported to BSD/OS 3.0. The user-level programs only depend on a UNIX-like operating system, and should be quite portable.


    Installation

    There are two steps to the installation process: the kernel source integration, and the installation of the user-level programs.

    Integration of the kernel binaries

    To install the kernel-level binaries, follow the following steps:

    Installation of user-level programs

    To install the user-level software, follow the following steps:


    Running The User-level Software

    The /etc/daedalus.conf file

    We recommend making an /etc/daedalus.conf file which contains common arguments that are passed when user-level programs are invoked. All of the user-level programs look for this file and use the configuration information contained in the file. Any command-line arguments override entries in the /etc/daedalus.conf file. The format of the /etc/daedalus.conf file is the following:

    <Name> <Value>

    Where <Name> is the name of the argument passed to the user-level program, and <Value> is the value associated with that name. For example, a line

    beaconPort 1200

    in the configuration file would correspond to the command line argument -beaconPort 1200. A command line argument of -beaconPort 1300 would override the value of 1200 specified in the daedalus.conf file.

    The possible <Names> in the /etc/daedalus.conf file are the following:

    debug: Enables printing of debuggging messages. A higher level implies more debugging messages.

    beaconPort: The UDP port used for outgoing beacon packets.

    decapPort: The TCP port for incoming encapsulation requests.

    beaconAddrs: A list of IP addresses for beacon packets. One packet every beaconDelay seconds is sent to each beaconAddr on the UDP port beaconPort.

    beaconDelay: The delay between beacon packets, in seconds.

    wiName: The name or address of the wired interface for this host.

    wlNames: A list of names or IP addresses for wireless interfaces on this host. The order of the wireless interfaces should correspond to the order of beacon addresses.

    multiName: The multicast address that the home agent uses to encapsulate packets destined for the mobile.

    ifaces: A list of (interface, address of interface) pairs that should be managed by vrouted.

    burstThreshold: When using header doublecasting, the number of packets that must be received over a higher overlay before switching to that overlay.

    beaconSwitchTimeout: The number of seconds that an overlay is unreachable before switching to a new overlay.

    Sample daedalus.conf files for base station and mobile host configurations are included in the user-level distribution as doc/daedalus.conf.sample.*.

    Running vrouted

    The arguments to vrouted are:

    vrouted [-debug <debugLevel>] [-beaconPort <port>] [-decapPort <port>] [-burstThreshold <number of packets>] [-beaconSwitchTimeout <seconds>] [-confFileName <path>] [-wiName <name or address>] [-multiName <name or address>] [-ifaces <(if, addr) list>]

    The argument confFileName allows the user to specify an alternate location for the daedalus.conf file. All of the other arguments are described above.

    Running beacond

    The arguments to beacond are:

    beacond [-debug <debugLevel>] [-confFileName <path>] [-beaconPort <port>] [-beaconDelay <sec>] [-beaconAddrs <addr list>] [-wiName <name or address>] [-wlNames <name or address list>]

    The argument confFileName allows the user to specify an alternate location for the daedalus.conf file. All of the other arguments are described above.

    Running decapd

    The arguments to decapd are:

    decapd [-debug <debugLevel>] [-confFileName <path>] [-decapPort <port>] [-wiName <name or address>] [wlNames <name or address list>]

    The argument confFileName allows the user to specify an alternate location for the daedalus.conf file. All of the other arguments are described above.

    Running mipset

    The arguments to mipset are:

    mipset [-l] [-r] [(-ae | -de | -au | -du | -ru | -eu | -cs)] [-m <addr>] [(-s <addr> | -ia)] [-s2 <addr>] [ -i <addr>] [-t ttl]

    The arguments are broken into two parts: commands and arguments.

    The commands are:

    -l: List kernel-level state.

    -r: Reset kernel-level state.

    -ae: Add an encapsulation entry for the specified mobile.

    -de: Disable the encapsulation entry for the specified mobile.

    -au: Add an unencapsulation entry for the specified mobile.

    -du: Disable an unencapsulation entry for the specified mobile.

    -ru: Remove the unencapsulation entry for the specified mobile.

    -eu: Enable the unencapsulation entry for the specified mobile.

    -cs: Change the source address for outgoing packets.

    The arguments are the following. They only apply to the two letter commands, and specify which translation entry to modify/add/delete.

    -m: specify the multicast address for the entry.

    -s: specify the unicast address for the entry.

    -i: specify the interface address for the entry.

    -t: specify the ttl value for the multicast address for the translation entry.

    Running mipset_mobile

    The arguments to mipset_mobile are:

    mipset_mobile [-l] [-r] [(-sm | -cm | -ifon | -ifoff | -bthresh <thresh> | -bpid <pid>)] [-s <addr>] [-i <ifstring>]

    The arguments are broken into two parts: commands and arguments.

    The commands are:

    -l: List kernel-level state.

    -r: Reset kernel-level state.

    -sm: Set the mobile host's address. This address will be inserted in all outgoing packets.

    -cm: Clear the mobile host's address. The address of the outgoing interface is inserted in all outgoing packets.

    -ifon: Turn on the specified interface (i.e. allow packets to be passed through the IP layer to higher layers).

    -ifoff: Turn off the specified interface (i.e. prevent packets from this interface from being passed through the IP layer to higher layers).

    -bthresh: Set the burst threshold to <thresh> packets.

    -bpid: Specify the process id of the process who should be signaled when more than <thresh> packets arrive in a row over a single interface.

    The arguments are:

    -s: Specify the unicast address for the command.

    -i: Specify the interface for the command.


    Example: Setting up for a single mobile client

    This section contains detailed instructions on how to set up a single mobile client. This section assumes that the daedalus kernel and user-level software has been installed on your base stations and mobile clients. This example will show you how to set up a single mobile host roaming between two base stations of different wireless interfaces. The actual addresses for this example are shown below, and the daedalus.conf.sample.* files match this configuration.

    In this scenario, there are a home agent and 2 base stations connected by a wired network. We assume that the home agent has an ethernet interface with the link-level address a1:a2:a3:a4:a5:a6. The home location of the Mobile Host is also on this subnet. The mobile host is roaming within coverage of two wireless networks with netmask 0xffffffe0. Each wireless network has a base station and a wireless interface on the mobile host.

    Setting up involves three parts: setting up the home agent, setting up the base stations, and setting up the mobile host.

    Setting up the Home Agent

    You might want to add the last two commands to the /etc/rc.local file of the home agent.

    The home agent is now set up to forward packets to the base stations.

    Setting up the Base Stations

    To set up each base station, do the following.

    The Base Stations are now set up to advertise to mobile devices and forward packets to them.

    Setting up the Mobile Host

    To set up the mobile host, do the following.

    The Mobile Host should now be set up for roaming between the two wireless networks. To test to make sure that everything is working, try pinging from the mobile host to some wired host and move between overlays. Also try pinging the home address of the mobile host from a wired address.


    Bugs/Todo list


    Comments, Feedback and Bug Reports

    All comments, feedbacks and bug reports should be directed to: vhandoff@daedalus.cs.berkeley.edu.
    Thank you!

    This work was supported by:
    ARPA Contract #DAAB07-95-C-D154, ARPA Contract #J-FBI-93-153, California MICRO Program, Hughes Aircraft Corporation, Metricom Corporation

    Mark Stemm (stemm@cs.berkeley.edu)