RE: [RRG] Re: Supposed impossibility of scaling for mobility - easy explanation

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

Robin et al,

The question of mobility interactions with scalable routing
was raised (by me) at the MEXT meeting yesterday, and I will
be looking to these messages to help formulate requirements
that might actually be attainable. I will try to comment in
more detail next week.

Thanks - Fred
fred.l.templin@boeing.com 

>-----Original Message-----
>From: Robin Whittle [mailto:rw@firstpr.com.au] 
>Sent: Thursday, March 13, 2008 10:02 AM
>To: rrg@psg.com
>Cc: louise.burness@bt.com; hannu.flinck@nsn.com; 
>jmh@joelhalpern.com; Scott Brim; William Herrin
>Subject: [RRG] Re: Supposed impossibility of scaling for 
>mobility - easy explanation
>
>Here's an easy way to convert an understanding of conventional
>mobile IP into an understanding of the Ivip approach.
>
>This Ivip vision of mobility is very different from Bill Herrin's
>(message 766).  His vision involves the ITRs tunnelling packets
>directly to Care of Addresses in each access network.  The Ivip
>approach involves the ITRs tunnelling to relatively stable TTRs,
>which involves far less mapping changes than with Bill's model.
>Also, Bill's model involves each mobile node somehow forwarding
>packets with its own IP address as the source, from various access
>networks.  In the Ivip model, these outgoing packets are forwarded
>from the TTRs, which are operated by a company with which the mobile
>end-user has a lasting business relationship.
>
>
>Start with the MN (Mobile Node) and a Home Agent (HA) router.
>
>The HA is in one fixed location and the MN can be anywhere.  The MN
>gains one or more Care of Addresses, CoA-A, CoA-B etc.  It builds a
>2-way encrypted tunnel from each CoA to the HA.
>
>Ordinary Correspondent Hosts (CHs) send packets to the MN on its
>permanent IP address, which is always handled by the HA.  The HA
>tunnels the packets to the MN.  In the opposite direction, the
>packets from the MH addressed to the CH are tunnelled to the HA and
>forwarded conventionally to the CH.
>
>The MN needs some new software, which is fine.  In the above
>scenario, the CH doesn't need new software.
>
>The trouble is that the HA isn't necessarily anywhere near the CH or
>the MN, so there is often really excessive path lengths.  If the MN
>is in Los Angeles and the CH in San Francisco, it is clearly bad if
>the HA is in Prague.  This is called "triangle routing".
>
>The only way of fixing this with conventional Mobile IP is to put
>fancy software in the OS of the CH, so it can send the packets
>directly to the MN, thereby achieving optimal path lengths.  There
>is a lot of complexity in this, in order to do it robustly and
>securely.  This is called "route optimisation".
>
>So conventional mobile IP can only achieve optimal path lengths by
>the use of elaborate new software in both the MH and the CH - and I
>think there needs to be a HA somewhere too to get things going and
>to support CHs which lack the fancy software.
>
>
>Now return to the plain use of the HA, with the CH having no special
>software.  This is OK, except for the problem of "triangle routing".
>
>With Ivip, the MH can set up 2-way tunnels with one or more
>Translating Tunnel Routers.  These can be thought of like "Home
>Agents" - except there are thousands of them around the Net,
>operated by some company which the end-user has a business
>relationship with.   The MN chooses a TTRs which is close to the
>current access networks - and sets up tunnels to that TTR.  Now it
>can use it somewhat like a HA.
>
>This is where the map-encap scheme comes in.
>
>Without the map-encap scheme, there is no way CHs could get packets
>to these TTRs - unless the CHs had elaborate software and were in
>some way coordinated, such as by a HA.
>
>The map-encap scheme solves this problem neatly.  The end-user has a
>micronet of address space (EID prefix, in LISP or ALT terminology).
> That micronet may be as small as a single IP address, but it could
>be of any size.
>
>The end-user arranges things so the TTR company can control the
>mapping of their micronet.
>
>The TTR company sets the mapping to point to the TTR which the MN
>has one or more 2-way tunnels to.
>
>This one TTR could have two 2-way tunnels to the MH, each via a
>different CoA at a different access network.  Suitable software in
>the TTR and MH sends incoming and outgoing packets over both links
>for redundancy.
>
>As long as the MH is in the same approximate geographic area, it
>gains new CoA addresses in various access networks and makes 2-way
>tunnels to the same currently active TTR.
>
>Path lengths are optimal, since the TTR is near the MH and there are
>ITRs near all the CHs.  The key point is that there is no need at
>all for the CHs to have special mobility software.  So it works fine
>for all IPv4 and IPv6 CHs.
>
>
>When the MH moves significantly - typically 1000s of km - it can
>still make 2-way tunnels from its new access network CoAs to the
>current TTR.  However, it figures out (with the help of the TTR
>company's network and its special software provided by that company)
>that it is now far from the current TTR.  So it finds a nearby
>second TTR and builds 2-way tunnels to it.
>
>Once this is done, the mapping is changed to point to the new TTR.
>There is no break in connectivity, since the MH has tunnels to both
>TTRs.
>
>Once the mapping change is complete, the old TTR isn't needed any
>more.  All packets are again following optimal or close to optimal
>paths, since the new TTR is close to the MN, and all the CHs are
>close to ITRs.
>
>As long as there is some kind of connectivity to some access
>network, there is no loss of connectivity to the MN.
>
>There is no need for mobility features in CHs, or in the access
>networks.
>
>The end-user needs a micronet and to be a customer of a TTR company.
> Neither the end-user or the TTR company need to have any business
>relationship or technical coordination with the access network -
>beyond whatever the end-user needs for their MN to be admitted to
>the access network and to gain a CoA.
>
>It is fine if the CoA is behind one or more layers of NAT, since the
>MN makes the 2-way encrypted tunnel to the TTR.
>
>Please see my previous message 765 for how there are 3 separate
>mobility systems at work here, and how the mapping only needs to
>when the MN moves large geographic distances.
>
>Note that the MN <==> TTR relationship does all the mobility work
>which is required while the MN stays in the one geographic area.
>The same TTR can be used after a big move, but it is best to get
>another one after moving a large distance.  It is only then that the
>mapping needs to change.
>
>When the mapping does needs to change, most end-users will want or
>need it to change in a few seconds.  However, even the most rapidly
>moving end-user won't be changing their mapping more than every hour
>or two.
>
>Unlike BGP and APT, which involve flooding of changes, with no
>gateway, with difficulties authenticating the changes and with no
>reasonable way of charging for each change, Ivip's changes are
>propagated by a highly efficient past-push system, which will
>involve charges in one form or another per update.
>
>http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-pu
>sh-00.pdf
>
>
>This pays for the fast push system and avoids the problem which is
>inherent in BGP and APT of some end-users propagating what others
>consider to be an unreasonably number of changes, burdening the
>whole system, without contributing any payment towards it.
>
>The role of the map-encap scheme in this form of mobility is to:
>
>1 - Allow the use of TTRs - which are like inventing a HA nice and
>    close to the current access network(s), while:
>
>2 - Ensuring packets get to the the TTR with optimal or nearly
>    optimal path lengths, while:
>
>3 - Requiring no mobility software in the correspondent hosts.
>
>
>This is not at all like multihoming to multiple CoAs and access
>networks rather than to multiple ETRs.
>
>It is a little like multihoming to one TTR or another according to
>large (> 1000km) geographic movements.  However, there is typically
>not a way of predicting where the new TTR will be.
>
>So to make the system work well, there needs to be fast (seconds,
>not minutes or hours) control of the mapping for all ITRs, so the
>end-user can use the nearest TTR without undue delay.  Only Ivip is
>intended to provide this.  However, the end users don't need to
>change their mapping every few seconds, or in most cases every few
>hours.
>
>Since most people spend most of their time in the one 1000km
>geographic area, the mapping update rate is slow and not at all
>related to the changes in access network, which could be very
>frequent indeed.
>
>  - Robin
>
>
>--
>to unsubscribe send a message to rrg-request@psg.com with the
>word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
>

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg