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

I should also mention that an initial implementation
is available:

http://www.ietf.org/mail-archive/web/int-area/current/msg02471.html
http://www.ietf.org/mail-archive/web/int-area/current/msg02472.html

Thanks - Fred
[email protected] 

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