I am responding to Tony Li and Jari Arkko. Tony Li wrote, quoting Russ White, quoting me:
>>> I agree. An ITR-ETR scheme with mapping updates which take a few >>> seconds to be implemented in all ITRs provides a whole new global >>> system for highly optimised mobility - for both IPv4 and IPv6, with >>> few new host requirements. >> >> But.... A few seconds is probably too long for it to be useful in a >> mobile environment. > > A few seconds is more than sufficient to deal with a number of > portability and migration use cases. In particular, anything that is > quick enough so that TCP connections don't break is extremely interesting. > > This isn't to say that this type of delay is acceptable for all mobility > use cases. You'd probably be pretty upset if your cell phone cut out > for two seconds at the edge of every cell. However, for cases where > your laptop transitions from WiFi to wired Ethernet, a few seconds to > transition seems eminently doable and beneficial. In general, Ivip's mapping wouldn't need to change when the Mobile Node (MN = host or router for some network) changes from one cell-phone base-station to another. The same ETR would still be used. The mapping would only need to change when the MN - or some external monitoring system which controls the mapping - chooses another ETR. Let's say the MN is a laptop with 3G, WiFi and wired Ethernet. Initially the MN uses 3G, in a single mobile carrier's network, using multiple base-stations. Unless they cross some fundamental border between sections of that network (maybe France to Germany or similar) then at all times, the optimal ETR to use will be one provided by that mobile carrier. (The MN could also use a Translating Tunnel Router - a combined ETR and ITR - outside the carrier's network, but close to it.) Now lets say the MN comes into a WiFi hotspot and is able to establish a connection. Mobility like this could be managed manually, but I think the best approach is for the MN to work with some global, distributed, management system to help it find ETRs in the networks it connects with or to choose a TTR near to those networks. There could be all sorts of management systems. These are not part of the Ivip system, but the one chosen by this end-user would have his or her credentials so it could authenticate itself and reliably change the mapping of the MN's micronet. The management system would also change the mapping for the micronet the MN is using (perhaps a single IP address) according to whatever logic the system has, and the end-user wants, to cause packets to be tunneled to one ETR or another. This would probably include a fancy systems to organise and authorise the ETR in the new network to handle packets for this MN, and probably for that network to accept outgoing packets with the MN's micronet address in the source address. Lets say the MN can now receive packets from an ETR in the WiFi operator's network. This is a cheaper and faster path for data than the 3G network. So the MN keeps the (presumably volume-charged, rather than time-charged) 3G link going, but has the mapping changed so incoming data comes to the ETR in the WiFi network. Whether the MN itself (automatically or manually) or the management system changes the mapping is up to the end-user. Most likely it would be the management system communicating with suitable software in the MN. There could be a role for IETF involvement in such protocols, but they don't directly impact Ivip or whatever ITR-ETR scheme is used, so the end-user can create their own systems, or use other organisation's management systems. Over a few seconds (ideally) the ITRs through which packets addressed to this micronet are being tunneled change their tunneling to the new ETR in the WiFi network. As long as there are two links and two ETRs operating at the same time, there is no break in connectivity. So VoIP and all other protocols would be completely unaffected. If the WiFi link fails for more than some predetermined time, then the MN and/or the management system needs to change the mapping. One option is the MN using the 3G link to send packets to the management system to this effect. (Cryptographic credentials required, using something previously established.) Then the management system can issue a mapping change so the ITRs send packets to the 3G network's ETR. Ideally, before leaving the WiFi zone, the mapping needs to be changed back to 3G system's ETR, so there is no break in service. The MN could signal this to the management system, due to the user indicating that the WiFi link was about to disappear. Alternatively, the MN could tell the management system to do so after when the WiFi signal became so weak as to cross some threshold beyond which the 3G system is preferred. The same principles apply when switching between 3G, WiFi and wired Ethernet - or any other physical layers which can operate at the same time. The same principles apply when a passenger jet is flying from one country to another. The aircraft initially has a link via some means to a network X, and the mapping for its micronet sends packets to the correct ITR at X. Alternatively, the aircraft's router itself has some PA of address space it temporarily uses from network X. Then, the aircraft's router can be the ETR for its micronet, even if XX is only one IP address. While connected to network X, the aircraft comes close to another country and establishes a connection to network Y in that country. When this connection is robust and preferred over the X connection, either the aircraft's router or some centralised management system (the airlines would run their own, most likely) would switch the mapping to the ETR in Y's address space. There would be absolutely no loss of connectivity. Also, the aircraft can use both links for outgoing packets, as it chooses. In this way, an aircraft could travel the globe, with continual connectivity for its own micronet. Jari wrote: > Maybe, maybe not. You are skipping over a lot of significant > detail. Me, skip over details?? I am trying to keep it brief, since this is a mailing list. The Ivip ID has lots more detail, but would be longer if I covered mobility in it. Instead, I refer readers to some June discussions on the RAM list, which contain informative diagrams and descriptions of the Translating Tunneling Router (TTR), such as: http://www1.ietf.org/mail-archive/web/ram/current/msg01547.html > What type of mobility are you trying to solve? Networks moving > around? Hosts moving around? Both, since they both need a micronet - one or more IP addresses. An IPv6 host is likely to be indistinguishable from a network anyway, since I can't imagine that any ITR-ETR scheme will divide IPv6 space into divisions finer than a /64 for the purposes of tunneling one ETR or another. > The implications for what the global routing system > must know about the moving entities are big. I agree. Pure push to every ITR in the world is not practical. Pure pull is too slow, as long as the queries are typically answered by only one or a few authoritative sources in the world. Ivip enables any locally chosen penetration of push - to ITRDs and QSDs. Beyond that, it is pull, with the QSDs being smart enough to remember recent queries about particular micronets, and to push updates to the querier (a caching Query Server or an ITRC or ITFH in host) when it receives updated mapping information for that micronet. I think there needs to be some kind of financial charge for changed mapping. Maybe this needn't be more than a few cents - but it is needed to deter high volumes of changes from users, unless of course they actually value the mobility enough to pay for their global impact. This could be tricky, since there is a big difference in impact between a cell-phone changing mapping, when only one or two ITRs in the world are handling packets to its micronet - and a whole public server farm changing its mapping, since there could be tens of thousands of caching ITRs sending packets to the micronet at that time. > Also, what are the requirements for speed of updates? I think it will be possible to securely and robustly get changes out to all ITRDs and QSDs in "a few seconds". In principle, maybe two seconds or so, but it is early days yet and I am yet to write up a detailed proposal for what I currently call the "Replicator" system. > The type of mobility that is requested in today's networks goes > all the way to up to the speed that is capable of avoid > interruptions in VoIP calls. This may be possible to > do in the routing system, too, but the requirements are very > different from merely supporting, say, site multihoming. I can't imagine a secure, robust, way of getting mapping data out to ITRs all over the Net in less than about a second. That is bad news for VoIP, but cellphone users tolerate such glitches now. As noted above, the changed mapping only occurs when there is a switch from one network's ETR to another. In many cases, this will involve simultaneous links to the two networks, using two radio or wired technologies at the same time. Assuming the 3G radio in the mobile device can't maintain communications with two separate 3G networks at the same time, then there will be a break of a few seconds when roaming to another, commercially and technically separate network. Maybe 3G voice systems can minimise that glitch - I am not sure. I think this approach of using a fast push distribution of probably simple mapping data has many advantages for ordinary multihoming and portability - most notably the modular approach of allowing the end-user to employ their chosen control system. This extends directly into "mobile" speeds and frequencies of mapping changes. But there there needs to be some kind of fee to help finance the impact of each change on the global ITR-ETR system. - Robin http://www.firstpr.com.au/ip/ivip/ -- 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
