An Introduction to TMip
Welcome to TMip...


Project Status

The latest version of TMip is v0.13a. You can download the release by following the link below.

TMip SourceForge


 TMip Overview

 Quick Introduction

Transparent Mobile IP (TMip) is an open source project, which aims to solve the problem of providing mobility across separated networks without the need for client configuration. The primary benefits of this are that all active TCP sessions will be maintained during migration, as the client never physically changes IP. What separates this project from the standard concept of IP mobility is that it requires no client software, configuration or alteration to IP stack. This implies that any IPv4 equipped host will just work.

However, TMip in fact does lots more that just transparent mobility. It contains a fully integrated DHCP server, and as the client address allocation takes place taking into account the entire network, it acts as a distributed DHCP server. If your local node has run out of address space to allocate to migrating clients, you can simply use some from a neighbouring node.

 What Makes up a TMip Network?

 The Correspondent Node

The core concept in a TMip network is the notion of a correspondent node or CN. These sit on the edges of mobility equipped cells (i.e. the border routers) and serve all mobile clients within that cell. They take responsibility for identifying new and migrated clients, and manipulating the network to ensure that the clients they are serving maintain connectivity. Within a single network there will be many CNs.

 The Mobile Location Register

The other important concept is the mobile location register or MLR. There will only be a single MLR per mobile network. It stores details about where mobile clients are currently active, and the address allocations it can issue to new clients.

 The Mobile Stations

Finally, you have the mobile stations or MS. These can be any device that can talk IPv4, and in fact don't have to be mobile at all. These are free to roam the network, transparently migrating as they go. In fact, they don't even know they are mobile, as to them they are always using the same IP, sending traffic to the same gateway on the same network.

 Why is TMip Useful?

 Transparent Mobility

An mentioned in the previous section, the main reason for TMip is to allow clients to migrate between networks without loosing connectivity, or terminating active sessions.

 Distributed Address Allocation

A client arriving in a mobile cell can request an address allocation from any registered cell in the network, and the local CN will attempt to assign it. This may involve contacting the owner of that address space, negotiating the tunnel to be used, and finally updating the network to allow traffic to pass.

 Static Addressing

Mobile clients can register that they always want to be assigned the same IP address no matter where they appear in the network. This allows them to register this address in DNS for example, and others can simply use that address and know that it will always identify them, no matter where they may be located.

 Node Tracking

At any one time, the network knows exactly where all mobile clients are, and the address allocations they are using. This allows analysis and graphing of the network to establish load and performance characteristics.

 Ease of Configuration

TMip has been designed to simply fit into existing network topologies, and just work. A single daemon runs on each of the CN machines, acting as a bolt on service that can be started and stopped to control migration into that cell. Once the location of the MLR is known, clients can instantly migrate to that new cell.

Goto Top




 Methods of Network Deployment

TMip has been designed to fit into various different network deployments that exist. Even though it is aimed at wireless LANs, there is absolutely no requirement for them to be wireless. In fact it works quite happily in a switched, wired LAN. Following are three different deployment ideas, the first two aimed towards traditional commercial or home deployments, the last at community based WLan deployments (such as SOWN).

 Typical Commercial/Home Deployment

Most wireless LAN deployments follow this basic structure. Essentially, a wired backbone runs around the company/home, and access points are attached to this periodically. I've assumed in the following diagram that they have all been separated by different networks (hence there is some routing taking place). So, the aim is to allow clients to migrate around all wireless access points, without loosing their active sessions.

The diagram shows four CNs, serving four different subnets. A central MLR is situated to serve them all, and a default route is included off to the rest of the Internet. Where clients are shown connected by a green connection, it implies they are at home. By this I mean their current IP allocation is owned by the access point they are bound to (so they are not using any tunnels to deliver traffic).

However, in the case of clients connected by a blue connection, they are remote. The diagram shows how client 10.13.4.17 is having its IP traffic delivered by the tunnel between the CNs at 10.13.2.1 and 10.13.4.1. Note that only inbound traffic (destine for the client) will traverse this tunnel, outgoing traffic leaves the normal route.

In this situation, each CN has registered its own address allocation in the MLR. Therefore, when a client connects for the first time, they will be issued an address within the local CN allocation. If they migrate, a tunnel will be created to maintain their connectivity. If you now imagine that a clients appears in each of the four subnets, then migrates to another access point. This will create four tunnels. However, if another four clients appear, and migrate to four different access points, an additional four tunnels will be created.

It can be seen that if three clients appear in one CN, then each migrate to one of the other CNs, there will be three tunnels from their parent to each of their current CNs. If all four CNs did this, you will end up with twelve tunnels. This is the maximum number of tunnels that would ever exist in this situation, as if more client appear, the existing tunnels can be piggy-backed. So, in summary, in such a deployment the maximum number of tunnels you could have is n * (n - 1), where n is the number of CNs in the network.

So, the main problems with this deployment are the number of tunnels required when a fully loaded network is present. The following network deployment gets round this problem by centrally assigning addresses to clients. However, if your clients are generally static for long periods of time, but occasionally migrate (i.e. migrate to work in the morning, use the network there, then migrate home :), it makes much more sense to keep their parent CN as work, rather than something in the middle.

 Centralised Commercial/Home Deployment

In the following deployment, none of the CNs register as having address allocations available for migrating clients. However, an additional CN has attached to it a single subnet on the wired LAN to act as the central address allocation pool. Now, if a mobile client appears in any CN, it will be allocated an address from the central pool. This implies that a client can never really migrate to its home CN (as that is on wired), so there will always be a tunnel established for them.

However, the number of tunnels that will be present in such a deployment is considerably less, in this situation it is only four (i.e. n, where n is the number of CNs in the network). These tunnels will exist from the central pool CN to each access point CN, with all client traffic passing down them. So, when clients migrate, there is very little tunnel creation and deletion, so it is much more efficient in this respect. Additionally, if two access points are separated by a long distance (in terms of network hops through the network), having the source of the tunnel in the middle makes considerably more sense.

The drawback of this approach is that mobile clients will always be using a remote CN, so their inbound traffic will always be using a tunnel. This may not be appropriate if the clients typically stay static for long periods of time, and only occasionally migrate. Also, if mobile clients talking to each other is a priority over Internet connection, then using the last approach is more efficient. You have to be aware of the increased load on the central pool, but if this is designed to take such load, they it can act as an advantage.

 Community WLan Based Deployment

The third method is how TMip can be deployed in a community wireless environment. Here, there is no central backbone to the network; CNs are connected via wireless links to one another in a mesh. This kind of deployment is what TMip was initially designed for, and is currently running live on the Southampton Open Wireless Network (SOWN) project in Southampton, UK. It provides transparent IP mobility across a wide area, covering the University campus.

The above diagram uses the ideas from the previous two for address allocation. Mainly, CNs have their own address space that they offer out to clients. However, the CN in the bottom left doesn't have any address space, so in this situation it will borrow some from neighbouring nodes.

 The Hybrid Approach

You don't have to choose one of the above methods to adopt TMip. All these purely present are some ideas for how TMip can operate. It can in fact use all three methods at the same time, it is purely down to individual CN configuration.

Goto Top




 How Does TMip Achieve Transparent Mobility?

 Mobile Client Identification

The key to migration is identifying the fact that a host has actually arrived. This is achieved via various methods, and any one of them may trigger the migration process. The first is DHCP activity. As each CN contains an integrated DHCP server, clients may request a new DHCP lease, and the CN may therefore have to migrate the host before returning the new lease. The second method is via IP or ARP activity. If the host has just migrated, it will probably still be sending data to its gateway, which the CN will detect and use to trigger migration. The final method involves detecting the physical binding of the client to the access point. Such methods are still being researched, and it is hoped that they will be included in a future version.

 When at Home

When a client is at home, the CN has little to do. In fact, all that it does is pretends to be the gateway router for that client, emulating multiple IP addresses on its mobile interface.

 When Remote

When a client is remote, they will still be using their existing IP address. This is fine for outgoing data, but obviously all inbound data will be delivered to the mobile clients original home. This is where the CN becomes more active, and sends the data down an IP tunnel. The destination is the current CN of that mobile client. When it arrives, it is taken out of the tunnel and delivered to the client as normal. As ever, the client doesn't know this, it appears as if the packets arrived quite normally to it.

Goto Top




 More Information

A how to has been written to help you get started with TMip, and can be found here. The README file contained within the distribution contains some additional information. Feel free to visit #sown or #tmip on irc.sown.org.uk IRC server, or you can email me direct at sly@slyware.com.

You can download TMip from the SourceForge TMip site.

Goto Top