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 [EMAIL PROTECTED] >-----Original Message----- >From: Robin Whittle [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 13, 2008 10:02 AM >To: [email protected] >Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; >[EMAIL PROTECTED]; 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
