Re: [MEXT] IRON - a new approach to mobility management

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

Here is another aspect of the proposal that should be
of interest to this community:

http://www.ietf.org/id/draft-templin-ironmike-00.txt

This shows how the IRON approach aligns with MOBIKE to
present a system for managing VPN links that allows
clients to connect to a nearby VPN gateway that in turn
connects to a trusted and secure network. As clients
change ISP connections, the VPN gateways naturally learn
about the changes. As clients move significant distances,
they simply discover and connect to a different nearby VPN
gateway. Client-to-client communications then are conveyed
across the trusted and secure network. Very simple; very
few moving parts.

Fred
[e-mail] 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On 
> Behalf Of Templin, Fred L
> Sent: Wednesday, January 26, 2011 1:27 PM
> To: [e-mail]
> Subject: [MEXT] IRON - a new approach to mobility management
> 
> 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]
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext
>