In a simple word, the ITR-ETR scheme will coexist with NEMO and Mobile IP mechanisms. Host mobility and network mobility will not trigger an update in the mapping system with ITR-ETR scheme. Correct?
Best wishes, Xiaohu Xu > -----邮件原件----- > 发件人: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 代表 Robin Whittle > 发送时间: 2007年12月7日 5:48 > 收件人: Routing Research Group list > 抄送: Tony Li; Russ White; Jari Arkko > 主题: [RRG] Re: Mobility in the future - passenger jets again > > 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 -- 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
