> > Given that so much of Internet traffic is going to be with mobile > > endpoints, I don't see how can continue using the current "address" as > > an identifier good enough to support session continuity. The only way > I > > can think of is to isolate applications from what's really going on > > underneath, and present them with a token they can use for > > identification and allow them to think it's a real address. > > General agreement with all thatw, but I query the "I don't see how [we] can > continue" part. Look at what the phone system did, when faced with demands > for number portability (i.e. provider independence), etc. They still use > 'phone numbers' in the existing externally-visible interface, but those are > now directory entry names, and get mapped into 'real' phone numbers away from > the sight of the users. > > Which reminds me of another observation I had about IPv4 - it has the same > packet format for router-host and router-router interactions. Now, there's no > law of nature that says they have to be the same - it was done that way, back > when, for reasons of simplicity and economy of effort - but if there's a good > engineering reason to use differing ones, I don't see any fundamental reason > not to. We could keep the IPvN packet format as a service interface, and use > something else between the routers.
If so, the problems with map&encap approachs will still exist in your mentioned approach, such as initial packet loss/delay due to the id/loc mapping. Why not implement the map&encap function on the hosts since a clean-slate approach is welcomed? Best regards, Xiaohu XU -- 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
