re: [RRG] Re: Mobility in the future - passenger jets again

[Xu Xiaohu <xuxh@huawei.com>]

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

> -----邮件原件-----
> 发件人: owner-rrg@psg.com [mailto:owner-rrg@psg.com] 代表 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 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