[MEXT] IRON - a new approach to mobility management

["Templin, Fred L" <[e-mail]>]

Hello,

I would like to introduce a new approach to mobility
management, which is an in-built feature of a new
routing and addressing system known as the Internet
Routing Overlay Network (IRON):

http://www.rfc-editor.org/internet-drafts/draft-templin-iron-17.txt

IRON is a product of the IRTF Routing Research Group
(RRG), which was chartered to provide recommendations
on addressing the Internet routing scaling issue. While
the IRON development effort focused primarily on routing
scaling, it soon became clear that mobility management
was also naturally afforded by the base architecture
with no need for adjunct mechanisms. Also, although this
fully-integrated proposal is new many of the concepts were
motivated by earlier works. The document therefore cites
related initiatives which explored similar concepts.

The IRON mobility management approach combines the best
aspects of both proactive and on-demand route discovery.
IRON Clients (which may include mobile end systems and
mobile routers) discover topologically-close IRON Serving
routers (i.e., "Servers") and create a connection with
one of the Servers for the purpose of maintaining 
bidirectional tunnel neighbor state. The Client then
registers one or more of its interfaces with the Server
so that the Server has handles for sending return traffic
to the Client. Since the Server can observe the public-side
address(es) of the Client without the Client needing to
discover them itself, the system therefore also naturally
supports a simplified form of NAT traversal. 

When a Client connects to the Server, the Server sends a
"link up" indication via a dynamic routing update that is
propagated to a core set of Relay routers (i.e., "Relays").
In practice, there will be O(10's) of Relays while there
may be several orders of magnitude more Servers that are
topologically distributed throughout the Internet. Only
the Relays need maintain a full topology in their routing
tables; Servers need only maintain routing table entries
for their current set of connected Clients.

When a Client 'A' connected to Server 'Y' has a packet to
send to a new correspondent Client 'B' connected to Server
'Z', 'A' first tunnels the packet to 'Y' as its default
router in the overlay network. Since 'Y' has only partial
topology information, it then tunnels the packet to a Relay
'R'. Since 'R' has full topology knowledge, it then tunnels
the packet to 'Z' which in turn tunnels the packet to 'B'.
At the same time, 'Z' also returns a Redirect message to
inform 'Y' that 'Z' is a better next hop in the overlay
network to reach 'B'. If 'Y' is configured to forward
Redirects to its Clients, it then forwards the Redirect to
'A' which then populates its routing tables with a more-
specific route. Otherwise, 'Y' uses the Redirect to update
its own routing tables. Hence, route optimization is
naturally supported.

When 'A' changes its ISP points of attachement (i.e., when
'A' moves), it need not explicitly inform 'Y' of the changes
as long as it wishes to retain 'Y' as its Server, since 'Y'
will naturally discover any changes in 'A''s address(es) via
the source addresses of 'A''s packets. 'A' also need not
inform any of its recent correspondents about the changes,
since the correspondents can still reach 'A' via 'Y'. Hence,
localized mobility events are communicated implicitly and
immediately with no need for binding updates.

When 'A' moves far away from 'Y', it can leisurely discover
a new nearby Server 'W'. It can then connect to 'W' and
disconnect from 'Y' which will cause dynamic routing between
the overlay network Relays to naturally update 'A''s
Client-to-Server bindings. Hence, routing stretch is
managed without need for delay-sensitive actions.

Finally, the base system does not require Client-to-Client
binding updates. For example, if Client 'C' has a routing
table for 'A' with next-hop 'Y', but 'A' has moved to a
new Server 'W', 'C' will receive Redirect messages from
'Y' informing it that 'A' is now associated with 'W'.
Hence, 'A' need not keep track of recent correspondents,
since any correspondents will naturally be redirected to
'A's new location without risk of packet loss. (Again,
this is a coarse-grained mobility consideration, since
'A' will typically not change to a new Server unless it
moves some significant distance, e.g., 1000 miles).

Comments and questions welcome,

Fred
[e-mail]