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

Here also is the way that operators/providers can make
a new business model for themselves:

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

The customers get to use their same addresses even if
they use an access technology other than the native one
they get directly from the provider, and the provider
gets to market a managed service that customers will
recognize as a good value at reasonable rates.

Everybody wins, and mobility management with route
optimization over multi-access end user devices is
naturally supported.

Fred
[email protected]

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On 
> Behalf Of Templin, Fred L
> Sent: Friday, January 28, 2011 3:31 PM
> To: [email protected]
> Subject: 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
> > 
> _______________________________________________
> MEXT mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mext
>