* TMip - Transparent Mobile IP * * Simon Robert Chudley * * sly@slyware.com * * * * http://www.slyware.com/projects_tmip.shtml * * http://tmip.sourceforge.net * ********************************************** * VERSION: 0.14a (16/06/2003) *
Introduction
TMip aims to provide IP mobility across multiple networks, ensuring that all active TCP sessions will be maintained upon migration. No client side software or alteration to IP stack is required. The network itself changes to provide connectivity to the mobile clients.
It provides this by having a central mobile location register (MLR), then a series of correspondent nodes (CNs) sitting on the border gateways between 'mobility equipped' cells and the rest of the network. Each client keeps a single cell subnet (/30) as they wander.
What makes it different from most other IP mobility schemes is that there is no client interaction in the process at all, hence allowing any IPv4 device to roam around a TMip network.
Even though this is aimed at wireless network deployment, the software works just as well on wired. In practice, TMip networks would probably consist of both.
Another major aspect of tmip is that it essentially provides a distributed DHCP server across all CNs. As all address assignment is performed at the MLR, a mobile client can request an IP (via DHCP lease, or just statically setting it) from any address allocation registered in the network. As soon as they do this, the network will be updated, tunnels created and MLR notified to allow this new client to retain that same IP.
A more detailed introduction can be found at http://www.slyware.com/projects_tmip_intro.shtml.
NOTE!
This version of tmip (and v0.13a or higher) will not talk to the old version of tmip OR the old version of the MLR! (<=v0.12a). This is due to the change in supported tunnel types, and the binding process that CNs do to attach to the MLR. Remember to patch up your MLR!
Second note, I'm sorry to say that FreeBSD support in tmipd has now vanished. It's only a few places that need patching up, but the target really is now just Linux, mainly due to supporting HostAP (with wds links). However, the MLR runs quite happily under FreeBSD etc.
TMip Deployment
The amazing drawings below shows how you could deploy TMip networks. Basically, you can do one of the following for CN's:
- Have a CN with one mobile interface, cross-overed to an access point, or a PCI WLan card. The other interface is wired & connected to the main network.
- Have a CN with a single network interface, either wired or wireless, both serving mobile hosts and being used as the CN interface.
- Have a node with two wired interfaces, one being used to serve wired mobile hosts, and the other for the connection to the rest of the network.
- Use any of the above, but additionally register some other address allocation for use by the network. This could be a wired interface, implying that the route of all tunnels (i.e. parent) is on wired rather than wireless (quicker).
- Have a node with a combination of all the others above. This is a new feature since v0.13, where multiple CN's are allowed per physical node. Note that an instance of TMipd is required to serve each mobile interface (idea is to make tmipd able to handle multiple mobile interfaces in the future).
Whatever the combination, you should be able to roam between all 'cells' transparently.
[MS]~~ ~~[MS] [MS]--+
|
WIRELESS ~~~~~~~ WIRELESS |
~~~~~~~~ ~~~~~~~~ |
| <(crossover to AP | (bit of wired network)> |
| or PCI WLan card)> | +-------+-------+
| | |
+-----------+ +-------------------+ +------------+
| Mobile_IF | | Mobile_IF & CN_IF | | Mobile_IF |
+-----------+ +-------------------+ +------------+
| CN1 | | CN2 | | CN3 |
+-----------+ +-------------------+ +------------+
| CN_IF | | CN_IF |
+-----------+ +------------+
| (some wired network) |
+--+-------------------+-----------------+--+--+
| | | | +---------+
| | | +-| Bck_MLR |
| +-------------------+ +-----+ +---------+
[MS] | Mobile_IF & CN_IF | | MLR |
+-------------------+ +-----+
| CN4 |
+-------------------+
The example above demonstrates how you could use TMip in a community based deployment. The aims of such a system are to allow transparent mobility across lots of nodes, most of which are connected via wireless links (i.e. are just nodes on poles with their default route being over wireless). This also includes some nodes that are routes off the network (have a wired interface).
However, TMip also works well in the standard corporate wireless deployment. Here, you typically have lots of access points, all connected via a wired backbone to the main network. Therefore, each access point offers its own address subnet, and you want to maintain transparent mobility across them all without client support.
There are two approaches. You could either just run tmipd on each access point (or PC directly connected to the access point), offering out the address allocation of that mobile device. So, in this situation, a new host would bind to the access point and get given an IP within that subnet. When it migrates, its parent will remain as that original access point, hence all incoming traffic will route to it first, before being tunneled to the client.
However, since version 0.13a a more efficient implementation can be deployed. Each CN runs as before, directly connected to the access points, but defaults to offer out NO address space. In the centre of the wired network, an instance of tmipd runs registering some wired address allocation (so a random subnet that you have reserved for wireless). Now, when a client binds to ANY access point, it will be assigned an address out of this central pool. This means that wherever it migrates to, its parent (hence point of incoming data) will remain in the centre of the wired network. This is much more efficient. Have a look in tmipd.rc, at the 'addr_pool' command.
Getting Started
There is a how-to linked from the main project site, http://tmip.sourceforge.net, This covers the basics of setting up a complete TMip mobile network.
For the Impatient
If you really don't want to read the docs, follow these steps and hope...
- You will need libpcap installed, so install that first. Also, you need the ability to tunnel IP inside IP (so check ipip under 'network options' in the kernel is installed).
- Compile everything. You will need the MLR (./mlrd/) and the main tmipd daemon (./tmipd/). Just go into each of these and type 'make'.
- Start the MLR. You need to define a few settings in the configuration file first (called mlrd.rc). Following is the bare setup you will need.
network_name my-tmip-mobility
port 6554
foreground false
log_file /var/log/mlrd.log
log true
If you want mlrd to stay in the foreground, either set the option for it to true, or give the -F parameter at startup. Feel free so pick some network name of your own.
Right, so starting the mlr, just do that following, specifying the location of your configuration file. If you are using logging, check that you can write to the log file (may need root to write to /var/log etc).
./mlrd -f mlrd.rc
The output should be something like:
[root@tnode1 mlrd]$ ./mlrd -f mlrd.rc
+ Starting MLR Server [v0.14a]
+ Loading settings from configuration file...
+ Using mlrd.rc
+ Switching into daemon mode (Logging to /var/log/mlrd.log)
Then it will disappear into the background (use -F to stop this). So, catting the logfile...
[root@tnode1 mlrd]$ cat /var/log/mlrd.log
+ Logging started for Mobile Location Register [v0.14a]
+ Serving network [my-tmip-mobility].
+ Bringing up MLR services...
[Session Dispatcher (port 6554)]: Done.
[MLRCache]: Done.
[CNList]: Done.
+ MLR up and listening...
Note that you can now control the MLR using various signals. See mlrd.rc for details on what signal does what. If any warnings were generated, they should be indicated on the screen and the logfile.
4. The next stage is to get the CN's up and running:
Again, a configuration file is supported, default location is tmipd.rc within the tmipd directory. You only really need to change five options within this if you just want to get it all running.
At the bottom of the file, change the mlr, cn_if, mobile_if, network_name and addr_alloc options.
Replacing the correct location of your MLR, the right network name that you entered into the MLR, and setting the interface names. The interface after 'cn_if' should be the CN INTERFACE, and 'mobile_if' THE MOBILE FACING INTERFACE. By default, you prob just want to register the address space of your mobile interface out, so if your mobile interface was wlan0, doing 'addr_pool wlan0 * *' will do this. Read the config file for details on what it means!
In the above case, the mobile cell (access point) is attached to rl1, and the CN interface (wired network) is rl0. Note that these can both be the same if you have a single interface in the box. If you get complaints about IP conflicts, see the options to 'addr_pool' to see how to restrict what IP allocations are given out. Refer to the docs online for a bit more on details :-)
The default is to have DHCP enabled, allocating out the entire address space. You may want to change the DNS address, domain name and static routes.
So, bog standard configuration may look like this... remember to change the network name to the same as your MLR configuration:
mlr mlr.foo.bar.com
cn_name My Test CN
tunnel_prefix tmip0
cn_if rl1
mobile_if rl0
network_name my-tmip-mobility
addr_pool rl0 * *
log_file /var/log/tmipd.log
log true
If you plan to run more than one CN per node, you must ensure that their tunnel_prefix settings are unique for every instance of tmipd on that machine. This simply controls the naming of tunnels.
Now to check connectivity. On each of your CN's, from the ./tmipd/ directory type:
./tmipd -Ef tmipd.rc
This should give a connectivity statement, such as:
[root@tnode1 tmipd]$ ./tmipd -Ef tmipd.rc
+ Starting TMip Correspondent Node [v0.14a]
+ Loading settings from configuration file...
+ Using tmipd.rc
Network Connectivity Evaluation
+ MLR @ 10.13.0.250: Passed.
+ CN @ 10.13.0.1 [Oakhurst directional]: Passed.
+ CN @ 10.13.2.1 [SUSU Roof]: Passed.
+ CN @ 10.13.4.1: Passed.
+ CN @ 10.13.7.1 [ECS Roof]: Passed.
+ CN @ 10.13.100.1 [TNode3 - Rack box]: Passed.
+ CN @ 10.13.150.1 [TNode1 - Si's room]: Passed.
+ CN @ 10.13.0.29 [Oakhurst omni-directional]: Passed.
Assuming that this CN can see the MLR and all other CNs you have established so far, you can start to set up the CNs. Note that it uses MLRP_Ping requests (i.e. application level pings). If you have firewalls between your CNs, note that port tcp:5554 must be let into each CN, tcp:6554 must be let into the MLR, and ipip must be allowed between CNs.
You can change the location of the configuration file using the -f parameter to tmipd, otherwise, just run the following, which will default to using tmipd.rc in the local directory:
./tmipd -f tmipd.rc
You should now have output such as:
+ Starting TMip Correspondent Node [v0.14a]
+ Loading settings from configuration file...
+ Using tmipd.rc
+ Switching into daemon mode (Logging to /var/log/tmipd.log)
By default, tmipd will turn into a daemon and vanish to the background. It logs to /var/log/tmipd.log by default, so you may want to tail this log file. To keep tmipd in the foreground, set the 'foreground true' option in the configuration file, or give the -F parameter option.
If any errors were generated during the start up of the CN, they should be printed to standard error.
Try the following:
$ cat /var/log/tmipd.log
+ Logging started for TMip Correspondent Node [v0.14a]
+ Bringing up TMipd services...
[MLRP Session Dispatcher]: Done.
[MLRCache]: Done.
[Tunnel Controller]: Done.
+ Supported tunnels (in order of preference):
+ Local loopback tunnels (1000 devices)
+ Standard IPv4 in IPv4 (50 devices)
+ Purging system of stale tunnel devices:
+ Checking connectivity to MLR @ 10.13.0.250: Seems ok.
+ Established local address allocation pool:
+ Available [10.13.150.4 --> 10.13.150.248] mask: 255.255.255.252
+ Binding CN to the mobile network [my-tmip-mobility]: Bind accepted.
+ Using the following CN interface...
+ Interface: rl0
+ IP: 10.13.0.250
+ Mac: 00:03:ce:88:62:c3
+ Subnet: 255.255.255.248
+ Broadcast: 10.13.0.255
+ Using the following mobile facing interface...
+ Interface: rl1
+ IP: 10.13.100.1
+ Mac: 00:d0:70:01:04:48
+ Subnet: 255.255.255.0
+ Broadcast: 10.13.100.255
+ Checking for address pool conflicts:
+ Using IP/ARP activity for migration detection
+ Launching final migration detection services...
[ProxyAdapter]: Done.
[DHCP Server]: Done.
+ Attempting network re-establish - Querying MLR: None listed
+ Correspondent node [10.13.0.250] (My test CN) is now up and running...
Review the logfile for errors, it should give hints on what might be wrong. The most common problems are invalid MLR address (check it resolves), incorrect network name, and network interfaces that are not correct.
I recommend starting tmipd with the -F parameter until you have everything working, and also with a higher debug level. The default is 2 (see the debug_level option). The higher (max 7) the more output. When in interactive mode, typing 'debug' then entering a number between [0..7] will set it at run time. Can also use the -D parameter option.
5. The CN will now be listening on the mobile interface for DHCP requests. So,
simply bind to your access point/plug into the network, and start up your DHCP client!.
If you want to manually enter the address into the client, the following would work with the CN above:
Net: 10.13.102.4
IP: 10.13.102.5
GW: 10.13.102.6
Broadcast: 10.13.102.7
Netmask: 255.255.255.252
Remember, given network address N, IP = N + 1, GW = N + 2, netmask = 255.255.255.252.
6. Go mobile! That should be it, assuming everything is correctly set up, you should be
able to migrate between all CN's with ease, keeping all TCP sessions active etc. You should even be able to move to a remote CN, and do a new DHCP request, and get the same IP back you had previously (assuming it hasn't timed out in the MLR).
7. If it doesn't work, first check out the how-to, as it goes into more details, being
as I've just skimmed the surface here. If still no joy, read the 'Help!' section below. Good tip is switching to debug level 3, as this details exactly what is going on during the handovers. Level 5 lists the contents of all the MLRP packets, so if you really want to know what's going on! Level 7 is just silly ;-)
8. To close the application, just call 'kill' on it and it will exit nicely. If in
interactive mode, type Ctrl+D.
Signals
You can now send signals to the mlrd and tmipd applications. Sending HUP will cause them to re-parse their configuration files, USR1 will output their internal status to 'status_file', and USR2 causes different behaviour depending on the application. See the top of tmipd.rc and mlrd.rc for more details on these.
The main use for these are so that you can change the debug level remotely, or get a list of the currently bound mobile stations etc.
Help!
For interactive help, try #tmip or #sown on irc.sown.org.uk, either myself (Sly) or one of the other SOWN guys are usually around (try #sown if not). Feel free to mail me (sly@slyware.com), or use the forums on the SourceForge site (http://sourceforge.net/projects/tmip). As time progresses, more documentation will appear on the main project site (http://tmip.sourceforge.net).
Release History
See CHANGELOG.