Hi Hannu, Thanks for your message, in which you wrote:
> Routing and mobility act on different time scales. 5 - 10s > handovers are not acceptable in any working system. The model of mobility I am proposing is significantly different from that developed in mobile IPv4/6. With a global network of ITRs, some new and much simpler and better methods can be employed. Since you have read my message: http://psg.com/lists/rrg/2008/msg00535.html I think you can see that the mapping doesn't have to change every time the mobile device hands over from one base-station to another. As long as the base-stations belong to the same access network, then the mobile device will be using the same TTR. The mapping points to the TTR, not to the mobile node's care of address. If a mobile node leaves one access network and finds another, it can still keep using the same TTR. It would use the new care-of address to establish a tunnel to the current TTR. However, it might be best to establish an encrypted tunnel to a second TTR which is topologically closer to the new access network. Once that is up, then the mapping can be changed. There will be no loss of connectivity, since the mobile device is receiving incoming packets on two tunnels with two TTRs, and the correspondent hosts' packets are being tunnelled by all the world's ITRs to one or the other of these. > I agree that > an ideal routing scalability solution could support and handle > some forms of mobility (maybe network mobility?), but I fail to > see why to put so much emphasis to mobility support as we do not > even have the scalability part carved out. It so happens that the essentially real-time control of ITR tunnelling which I think is the best approach for scalable multihoming, TE and portability can also be used for this new approach to mobility. Mobility is such a valuable thing that even if we didn't care at all about it, it would be good to have so we could convince people to adopt the new map-encap type of address space. > Robin, your solution seems to build on the idea that the MN could > tell its location and from there to determine where the closest > TTR is located. Are you assuming GPS or are you possibly > concluding from the EID (care of address) that is not > topologically determining? Or are you pinging the original TTR? I envisage that the TTRs will be run by some company, and that there will probably be multiple competing global networks of TTRs. Each such company, say GTI (Global TTRs Inc) will as part of its system provide its customers (each with a mobile laptop, cellphone or whatever) with software to run which sends out packets to GTI's management servers around the Net. The GTI servers and this software would regularly exchange packets, enabling the GTI system to monitor reachability via the one or more TTRs the device has 2-way tunnels to and/or directly to the devices one or more care-of addresses. This mobile host software would be aware that it has a new care of address every time it connects to a new network. Say it can use 3G, WiFi, WiMax, Bluetooth and cabled Ethernet - all at the same time. Every time it gets a new care-of address it sends out a few probe packets, identifying itself, to various GTI servers. The care-of address may be behind one or more layers of NAT. But this still enables the GTI servers to figure out where the mobile device is, and to send packets back to it. I am assuming UDP packets with nonces, crypto etc. to make it robust against attackers. The GTI management system would probably make the decision about which TTR the mobile device should try to build a 2-way tunnel to. This would require some sophistication, but before actually building the tunnel, the GTI system could give the mobile device a few TTR addresses, which it could ping or traceroute to. Then the system or the host software could decide which one to build a tunnel to. Once it has done so, then the GTI system can use that tunnel to verify delay, packet loss etc. characteristics of the link to the second TTR. Probably the control of mapping would by by the GTI system, rather than directly by software in the mobile device. If the GTI software for some reason figures the previous care of address is going to disappear soon - and with it the tunnel to the first TTR - then it will change the mapping over to the second TTR. Also, if there is a second TTR established, but not yet in use for traffic, and the first TTR link disappears, the GTI system would detect this reasonably quickly and change the mapping - so the end-user's connectivity would be re-established after (ideally) 5 seconds or so. > Many times in the real life systems it is exactly the access that > costs, therefore the access authorization plays a critical role. > TTR or some other part of the system, maybe the AAA needs to be > involved to grant the access. Naturally we need to bring in the > user identities as well for the AAA. I envisage the end-user being a customer of one of the TTR companies, and giving that company their username and password or whatever is needed to control the mapping of the end-user's micronet (which is probably a single IPv4 address, or a /64 in IPv6). The end-user would pay for the TTR service, which would be wholly independent of whatever access networks they were using. Nonetheless, the TTR company could have its own TTRs embedded in particular access networks, as well as TTRs outside but near to those access networks. Also, the TTR company could pay to use the TTRs of other TTR companies - so there could be TTR "wholesalers" and customer-facing "retailers". > There are a number of active WGs addressing the various aspects > of the mobility, shouldn't we co-ordinate with them? Probably, but this Ivip approach to mobility is in its early stages of development, and seems to make at least some of the current mobility work irrelevant. People have put a lot of effort into this work, and I am wary about presenting the Ivip proposal too boldly, since it depends on new routing and addressing architecture and a global ITR system which is yet to be built. I did write to a few WG mailing lists last year when I first developed this concept. One or two people joined the RAM mailing list and could see the value in what I was suggesting. However, until about two weeks ago I had assumed that the TTR needed to change with every new access network. That involved relatively frequent mapping changes. Now I think that in most mobile scenarios, as long as the TTR is within 1000km or so of the access network, there is no pressing need to use another one - so the mapping can remain stable until people move really large distances. In many cases, they wouldn't move this 1000km for months. So most of the mobility action is taking place between the mobile device and its nearby chosen TTR. Also, there is access network mobility in actions, such as between different base-stations or base-station controllers, all of which is invisible to the IP system as long as the mobile device keeps its care-of address. This new approach to mobility is only possible because we assume we have a global TTR system to send packets on optimal paths to the TTR. The whole thing would work with LISP, APT and TRRP too - its just that Ivip's fast control of all the world's ITRs enables fast responses to the need to use a different TTR. Just because this fast (ideally 5 second) mapping change time is valuable for mobility (sometimes essential, like when you fire up your device in another part of the world, and it makes no sense to use the old TTR in Melbourne when you are in London) doesn't mean that these mapping changes need to be frequent. People don't move 1000km every few minutes. I am working on a message depicting how a mobile device (such as a laptop) keeps its own IP address as I fly from Melbourne to London, with continued connectivity via WiFi to the passenger jet's network, which also uses an Ivip-mapped micronet to seamlessly switch between different ground-stations as it flies around the world. SSH sessions stay up, browsing continues etc. I know this seems like overkill, but once you have a real-time controllable global ITR system, it makes sense to develop the TTR system and host software and do mobility this way. Then it all happens automatically, with generally optimal path lengths, no need for new applications or specific mobility protocols (apart from the tunnelling stuff in the mobile device) - and no mucking around getting a new IP address, playing with DNS, starting up sessions again etc. - 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
