Subject: [RRG] Supposed impossibility of scaling for mobility

From: Robin Whittle <[email-masked]>
Date: Wed, 12 Mar 2008 18:07:55 +1100

Hi Dino and Joel,

In the RRG meeting (audio http://videolab.uoregon.edu/events/ietf/
where there should soon be an archive of Tuesday's meeting) you and
perhaps some other folks were extremely negative about the routing
system, in the form of map-encap, achieving mobility directly.  So
much so, that I understand you want mobility not to be a goal.

Yet I believe that a fast-push hybrid push-pull system with reliable
notification from local query servers to ITRs will give users ~5
second latency real-time control over all the world's ITRs.  Also,
this system doesn't have the delay or drop problems inherent in pure
pull (LISP-ALT and TRRP), so that's another thing we wouldn't need
to worry about when asking people to adopt it.

You seem very committed to the idea that mobility is impossible to
achieve with map-encap.

I would be interested in your critiques of:

  Scaling, Mobility & 228 mapping changes a second
  http://psg.com/lists/rrg/2008/msg00535.html

There I debunk the storage problem - a terabyte hard drive solves
every storage problem you can imagine.

I also examine how mobility would work - with TTRs (Ivip's concept
of Translating Tunnel Routers) the mapping is to the TTRs, not to
the mobile nodes.  So the mapping only needs to change when the
mobile node moves 1000km or more and it makes sense to choose
another TTR nearby.

Also, as I will write in a future message, with Internet access on
jet aircraft, you will be able to keep your TCP sessions etc. going
while travelling around the world.  This will be easier to manage
than changing IP addresses, starting new sessions via updated DNS etc.

In the above messaged, I have some very rough guesses about the rate
of updates when there are billions of mobile nodes, and I come up
with figures in the few hundreds per second.  That is perfectly
practical, I think, with a fast-push mapping distribution system
such as I detail here:

http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.pdf

Section 4 is the benefits of fast-push, and is much the same as in

  http://www.firstpr.com.au/ip/ivip/Ivip-summary.pdf

which I assume you have read.

I suggest you skim over most of the fast-push-00 ID and read the
gutsy details in sections 7, 8 and 9 - pages 33 to 48.

I think that once you do this, if you still believe it is impossible
for map-encap to directly implement this new form of mobility (which
does not rely at all on current host-based mobile IP techniques),
then I think you should be able to articulate a robust critique of
my fast-push-00 draft and/or of my vision for mobility.

Furthermore, you should be able to argue strongly why no other
conceivable approach to fast, essentially real-time, control of ITRs
is possible - or perhaps why it is possible but undesirable.

I have been put a lot of work into evaluating LISP, APT and TRRP -
giving constructive criticism and suggesting improvements.

Ivip has been around for ten months now and I am keen for one or
more people to write a proper critique of its most unusual aspect -
the fast push mapping distribution system.  There are more details
to be sorted out of course, but there is plenty of meat for a critic
to chew on in the fast-push-00 draft.

The other part of Ivip's mapping distribution is the "Notify"
system.  This is with local query servers, full database and
optionally caching.  Some details of that follow, since it is not so
clearly documented elsewhere.

Also, if you remain unconvinced of the viability of this new form of
mobility, what is the maximum number of EIDs you expect LISP to cope
with, without each such EID being mobile?

My guess is a few tens of millions at the most - basically most
businesses and organisations on the planet.  Maybe a hundred million.

All the map-encap schemes can cope with that fine - the storage and
the update rate and volume.

The principle benefit of ALT or TRRP is its ability to handle
endless EIDs without burdening ITRs or adding volume of
communications to the mapping system beyond what is needed for ITRs
which actually need mapping for those EIDs.

This is great, but what is the point of unlimited scaling when you
are only ever going to have a hundred or so million EIDs?

Since ALT and TRRP can't provide mobility (at most ALT is intended
to work with the existing, unsatisfactory mobile IP techniques), I
can't see how you would ever get the billions of EIDs your system
could cope so well with.

Only Ivip could provide this form of mobility, so I think only Ivip
would be called upon to deal with billions of micronets (EIDs).  I
believe Ivip could cope with this.

My message and draft linked to above show why I think this is
feasible, desirable - and probably essential for anything as
momentous as a global system of ITRs and ETRs, creating a new class
of address space.

  - Robin

Ivip's local Notify system
--------------------------

QSDs respond to queries directly from caching ITRs (ITRCs) and ITFHs
(ITR functions in sending hosts, not behind NAT) and indirectly via
one or more caching query server (QSC).

The response contains the mapping - a single ETR address - and a
caching time, probably to be determined by the QSD.  If the QSD gets
a mapping update which affects the micronet (EID) of a response it
sent inside the caching time, it sends a Notify UDP packet to the
querier (a QSC, ITRC or ITFH). It expects to get an acknowledgement,
so it will retry if it doesn't get one.

The Notify message contains the new mapping information for this
micronet (EID).  It is not just cache invalidation.

The query contains a nonce, which is included in the response to
prevent attackers messing with the ITRCs, ITFHs or QSCs.

The Notify message contains the nonce from the original query, which
likewise secures it.

If the querier was a QSC, then it passes one or more Notify
messages, using the nonce of the original query, to whatever devices
queried it: ITRDs, ITFHs or other QSCs.

The QSDs and QSCs are always "local" - meaning inside a network, or
in a nearby network.  So they are within a few hundred km at most,
and a querier should have two or more upstream query servers it can
use.  A response should come back within a very short time - tens of
milliseconds, or perhaps a little more if there are multiple QSCs
for the query to go through before it finds a QSD.  If the response
doesn't arrive pretty quickly (maybe 50 to 100msec), then a packet
has been lost or the query server is dead - so the querier can send
a request to another query server.

This traffic is all local and with pretty short paths, so it has
little cost, little delay and is highly reliable.  This is
completely different from relying on a global query server system
such as LISP-ALT or TRRP in its initial decentralised, form.

--
to unsubscribe send a message to [email-masked] 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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 12 Mar 2008 08:43:15 -0400

Robin,
	I think that you are misunderstanding my point.
Let me try listing some items I take as givens.  Others may disagree.

1) Solving problems that we don't need to solve is going to weaken a 
solution.  (Good solutions will, as Noel seems to like to put it, 
unexpectedly solve additional problems.  But that is different for 
designing to solve a varied selection of problems all at once.)
2) "Mobility" is not a single problem.  In the text I have elided, you 
indicate that you specifically mean mobility over 100s or 1,000s of 
kilometers.  But other folks mean other things.  Solving "Mobility" is 
almost meaningless, given the range of problems.
2') My personal opinion is that the value in addressing the long range 
mobility problem is extremely small.  The end station rarely if ever 
needs to preserve its connectivity when moving between arbitrary 
connectivity points separated by 1,00s of km.  There are cases where 
special infrastructure and special needs require such, but you cope with 
those in other ways.  There are cases where local moves are not 
topologically local.  (And various groups have looked at properties that 
help address those cases.)
2'') Yes, mobility can be thought of as just another change.  But it has 
very different characteristics than the changes caused either by 
re-homing or by failure / recovery.  So treating it as identical will, 
in my opinion, likely hurt both the base solution and the mobility handling.
3) Every approach to a problem has limits.  And we should assume that 
those limits are going to be lower than we expect.  As one member of 
this community said to me on many occasions "The difference between 
theory and practice is even larger in practice than it is in theory." 
[1]  And we know from experience which way that difference will go.

So, given that all the solutions will be less capable than we expect, 
and given that reducing the problems to be addressed generally gives one
more head-room in any solution, it seems to me to be a really good idea 
to NOT solve problems we don't need to solve.

That doesn't mean that we should refrain from looking at interesting 
ideas, like your fast-push.  It just means that we should evaluate them 
against the alternatives for the problems that we need to solve, rather 
than choosing a mechanism based on a problem we don't need to deal with.
We have all recognized that the rate*state (or churn, or whatever 
characterization matters most) is an important factor in the complexity 
of the problem.  Mobility, even bounded subsets of the mobility problem, 
adds to that measure.  So unless there is some driving need, I would 
prefer to keep those factors out.

Yours,
Joel M. Halpern

[1] Steve Crocker

> You seem very committed to the idea that mobility is impossible to
...

---

From: "Tony Li" <[email-masked]>
Date: Wed, 12 Mar 2008 09:26:06 -0400

|Others may disagree.

I'll take you up on that.

|1) Solving problems that we don't need to solve is going to weaken a 
|solution.  (Good solutions will, as Noel seems to like to put it, 
|unexpectedly solve additional problems.  But that is different for 
|designing to solve a varied selection of problems all at once.)

No matter what you and I say, some folks will try to use the routing
architecture to provide mobility (e.g. Connexion
http://en.wikipedia.org/wiki/Connexion_by_Boeing).  As a result, we have no
choice but to deal with mobility, if only to bound the amount of damage that
is inflicted as a result.

If you don't want to deal with it under the label of mobility, then we can
change it to "the maximum amount of churn that any single player can
inject".

|2) "Mobility" is not a single problem.  In the text I have elided, you 
|indicate that you specifically mean mobility over 100s or 1,000s of 
|kilometers.  But other folks mean other things.  Solving "Mobility" is 
|almost meaningless, given the range of problems.

I submit that the range of the mobility is a total red herring.  As always,
we care about topological changes, not geographical ones.  From a
topological perspective, you can cause a 'mobility' event simply by
disabling one interface on your laptop and enabling another.  For a zero
physical distance move, you could, conceptually, change your topological
association completely.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Thu, 13 Mar 2008 00:35:56 +1100

Hi Joel,

> designing to solve a varied selection of problems all at once.)

I think this is not necessarily the case.

Multihoming service restoration and portability both can be done
best by the end-user deciding which ETR to use, in their own way,
and having fast control of the world's ITRs to implement that
decision.  The other proposals add a lot of complexity to the ITRs
or Default Mappers trying to do what the designers imagine the
end-user would want to do.  But with a fast push system with notify,
the designers don't need to try to anticipate end-user's desires -
the system lets the end-user control the mapping in real time.

This is the best arrangement for multihoming etc. and it so happens
that this arrangement also supports a new form of mobility.

I didn't design Ivip to do this, but by adding TTRs, you can make it
do a great new kind of mobility.  TTRs can be added to any map-encap
system - they behave to the rest of the system like ETRs.  They
can't be prevented either.  They could be added to LISP, APT or
TRRP, even without protocol standardisation or permission by the IETF.

> almost meaningless, given the range of problems.

Well, I have written more expansively than simply "Mobility" on what
Ivip would provide:

including what it wouldn't provide and which aspects of mobility
access networks could provide better than Ivip.

> connectivity points separated by 1,00s of km.  

This is like saying in the early 70s that there really isn't a great
need for mobile telephones.

Sure, we get on fine without globally portable, mobile, IP addresses
now.  But if we had them, everyone and their dog (Aussie expression)
would want one, and would be prepared to pay for it.

> There are cases where

Once you have a global system of ITRs, all you need to do is control
them in "real-time" and people will of their own accord create TTRs
and provide the powerful mobility I am describing.

Since we need to build this network, we might as well do a proper
job of it, I think.

Having your own IP address which you keep on your cellphone always
sounds like overkill now, but it would be easier than mucking around
with DNS, restarting sessions etc.  The path lengths would be close
to optimal, and the correspondent hosts can be ordinary computers
anywhere.

> in my opinion, likely hurt both the base solution and the mobility

In that case, you should be able to point out where in my proposals,
the extra provisions for mobility cause some detriment to the
initial purpose of achieving multihoming and portability of
addresses in a scalable fashion.

Actually, nothing at all is added to Ivip's fast-push system or the
ITRs.  Its just that you can use this system with TTRs acting like
ordinary ETRs, and do this new form of mobility.

> So, given that all the solutions will be less capable than we
> expect, and given that reducing the problems to be addressed
> generally gives one more head-room in any solution, it seems to me
> to be a really good idea to NOT solve problems we don't need to
> solve.

You are so sure that by doing mobility I must be compromising
multihoming or scalability etc. that you don't feel the need to read
and criticise my actual proposal?

It is not necessarily true that a solution will be less capable than
we expect.

IPv4 is a good example - I can't imagine its designers really
expected it to do what it does so well today.

I didn't design Ivip to do mobility - I just discovered that with a
simple addition, which doesn't affect the basic Ivip system in any
way, it does it.  The system promises to be more capable than I
planned it to be.  This is partly a result of the modular approach I
took - splitting off the failure detection and ETR selection
decision and expecting the end-users to do this.

> than choosing a mechanism based on a problem we don't need to deal with.

I am not saying Ivip's mobility capability be a justification for it
doing anything else less capably.

Ivip is less capable in one sense, in that it doesn't have
explicitly load sharing.  But by splitting the traffic over multiple
IP addresses and having real time control over the ETR used for each
such address, or micronet of addresses, you may be able to achieve
better load sharing than by BGP or than by LISP, APT or TRRP.

That is a result of simplifying the mapping data and the ITR - it is
not a compromise prompted by anything I had to do to support
mobility.  I changed nothing - I just invented the idea of a TTR.

Hybrid push-pull is the only way to eliminate delay (apart from a
few tens of milliseconds) apart from the unscalable full-push of
NERD.  So in terms of no delay vs delay of initial packets, it is
APT and Ivip vs LISP-ALT and TRRP.

ALT and TRRP can scale to endless EIDs, but as far as I can see,
neither would stimulate users to generate more than a few tens or
hundreds of millions - since neither can do mobility.  So it is no
benefit that ALT or TRRP could easily scale to a billion EIDs.

If NERD, ALT, APT or TRRP was built, pretty soon, folks would be
trying to add fast push to it, to do mobility.  The result would be
far uglier than a system like Ivip which was designed to do fast
push with reliable, fast, local pull and notify.

> prefer to keep those factors out.

OK - I understand you have generalised reasons for pessimism, based
on long experience.  I regret that I haven't yet prompted you to
actually read and critique my proposal.

  - Robin

---

From: <[email-masked]>
Date: Wed, 12 Mar 2008 21:00:29 +0200

Routing and mobility act on different time scales. 5 - 10s handovers are
not acceptable in any working system. 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. 

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?

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.

There are a number of active WGs addressing the various aspects of the
mobility, shouldn't we co-ordinate with them?

But now the routing part of the problem is escaping me!

Regards Hannu 

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext Robin Whittle
>Sent: Wednesday, March 12, 2008 15:36
>To: Routing Research Group
>Cc: Joel M. Halpern
>Subject: [RRG] Re: Supposed impossibility of scaling for mobility
>
>Hi Joel,
>
>Multihoming service restoration and portability both can be 
>done best by the end-user deciding which ETR to use, in their 
>own way, and having fast control of the world's ITRs to 
>implement that decision.  The other proposals add a lot of 
>complexity to the ITRs or Default Mappers trying to do what 
>the designers imagine the end-user would want to do.  But with 
>a fast push system with notify, the designers don't need to 
>try to anticipate end-user's desires - the system lets the 
>end-user control the mapping in real time.
>
>This is the best arrangement for multihoming etc. and it so 
>happens that this arrangement also supports a new form of mobility.
>
>I didn't design Ivip to do this, but by adding TTRs, you can 
>make it do a great new kind of mobility.  TTRs can be added to 
>any map-encap system - they behave to the rest of the system 
>like ETRs.  They can't be prevented either.  They could be 
>added to LISP, APT or TRRP, even without protocol 
>standardisation or permission by the IETF.
>
>
>Well, I have written more expansively than simply "Mobility" 
>on what Ivip would provide:
>
>including what it wouldn't provide and which aspects of 
>mobility access networks could provide better than Ivip.
>
>
>This is like saying in the early 70s that there really isn't a 
>great need for mobile telephones.
>
>Sure, we get on fine without globally portable, mobile, IP 
>addresses now.  But if we had them, everyone and their dog 
>(Aussie expression) would want one, and would be prepared to 
>pay for it.
>
>
>> There are cases where
>> special infrastructure and special needs require such, but you cope 
>> with those in other ways.  There are cases where local moves are not 
>> topologically local.  (And various groups have looked at properties 
>> that help address those cases.)
>
>Once you have a global system of ITRs, all you need to do is 
>control them in "real-time" and people will of their own 
>accord create TTRs and provide the powerful mobility I am describing.
>
>Since we need to build this network, we might as well do a 
>proper job of it, I think.
>
>Having your own IP address which you keep on your cellphone 
>always sounds like overkill now, but it would be easier than 
>mucking around with DNS, restarting sessions etc.  The path 
>lengths would be close to optimal, and the correspondent hosts 
>can be ordinary computers anywhere.
>
>
>> 2'') Yes, mobility can be thought of as just another change.  But it 
>> has very different characteristics than the changes caused either by 
>In that case, you should be able to point out where in my 
>proposals, the extra provisions for mobility cause some 
>detriment to the initial purpose of achieving multihoming and 
>portability of addresses in a scalable fashion.
>
>Actually, nothing at all is added to Ivip's fast-push system 
>or the ITRs.  Its just that you can use this system with TTRs 
>acting like ordinary ETRs, and do this new form of mobility.
>
>
>> and given that reducing the problems to be addressed generally gives 
>> one more head-room in any solution, it seems to me to be a 
>really good 
>> idea to NOT solve problems we don't need to solve.
>
>multihoming or scalability etc. that you don't feel the need 
>to read and criticise my actual proposal?
>
>It is not necessarily true that a solution will be less 
>capable than we expect.
>
>I didn't design Ivip to do mobility - I just discovered that 
>with a simple addition, which doesn't affect the basic Ivip 
>system in any way, it does it.  The system promises to be more 
>capable than I planned it to be.  This is partly a result of 
>the modular approach I took - splitting off the failure 
>detection and ETR selection decision and expecting the 
>end-users to do this.
>
>
>> ideas, like your fast-push.  It just means that we should evaluate 
>> them against the alternatives for the problems that we need 
>to solve, 
>> rather than choosing a mechanism based on a problem we don't 
>need to deal with.
>
>I am not saying Ivip's mobility capability be a justification 
>for it doing anything else less capably.
>
>explicitly load sharing.  But by splitting the traffic over 
>multiple IP addresses and having real time control over the 
>ETR used for each such address, or micronet of addresses, you 
>may be able to achieve better load sharing than by BGP or than 
>by LISP, APT or TRRP.
>
>That is a result of simplifying the mapping data and the ITR - 
>it is not a compromise prompted by anything I had to do to 
>support mobility.  I changed nothing - I just invented the 
>idea of a TTR.
>
>Hybrid push-pull is the only way to eliminate delay (apart 
>from a few tens of milliseconds) apart from the unscalable 
>full-push of NERD.  So in terms of no delay vs delay of 
>initial packets, it is APT and Ivip vs LISP-ALT and TRRP.
>
>ALT and TRRP can scale to endless EIDs, but as far as I can 
>see, neither would stimulate users to generate more than a few 
>tens or hundreds of millions - since neither can do mobility.  
>So it is no benefit that ALT or TRRP could easily scale to a 
>billion EIDs.
>
>If NERD, ALT, APT or TRRP was built, pretty soon, folks would 
>be trying to add fast push to it, to do mobility.  The result 
>would be far uglier than a system like Ivip which was designed 
>to do fast push with reliable, fast, local pull and notify.
>
>
>> characterization matters most) is an important factor in the 
>> complexity of the problem.  Mobility, even bounded subsets of the 
>> mobility problem, adds to that measure.  So unless there is some 
>> driving need, I would prefer to keep those factors out.
>> 
>> Yours,
>> Joel M. Halpern
>> 
>> [1] Steve Crocker
>
>OK - I understand you have generalised reasons for pessimism, 
>based on long experience.  I regret that I haven't yet 
>prompted you to actually read and critique my proposal.
>
>  - Robin
>
>
>--

---

From: "William Herrin" <[email-masked]>
Date: Wed, 12 Mar 2008 17:30:38 -0400

On Wed, Mar 12, 2008 at 8:43 AM, Joel M. Halpern <[email-masked]> wrote:
>  solution.

I'm with Robin on this one. If our solution solves the routing portion
of the mobility problem, it will by its nature solve the multihoming
and system capacity problems as well.

At least as important: the new capability that didn't previously exist
and doesn't otherwise exist will give operators a reason to deploy it
beyond reducing the cost of a DFZ router. Folks aren't real good about
spending more money now in order to spend less later. Damn lousy at it
actually. A valuable new feature like mobility could get us over that
hump.

And for the record, I take my laptop back and forth to work every day.
You probably do too. When I do so, it travels between and through
networks which are administratively and topologically distant. It
would be awfully nice if it could keep its "number" the same way my
cell phone does without the nasty routing inefficiencies that had to
be introduced into the telephone network... Nice enough that I could
see buying service from companies who could do it in preference to
those who couldn't.

As I'm sure you gathered from the above, I'm much more interested in
working on solution trees which also address the routing portion of
the mobility problem than I am in working on solution trees which
don't.

Regards,
Bill Herrin

-- 
William D. Herrin [email-masked] [email-masked]
3005 Crane Dr. Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: "William Herrin" <[email-masked]>
Date: Wed, 12 Mar 2008 17:43:48 -0400

On Wed, Mar 12, 2008 at 3:00 PM,  <[email-masked]> wrote:
>  not acceptable in any working system. \

Hi Hannu,

Is "handover" a necessary part of a mobility system?

What about an add/drop model where a mobile device adds a new base
station when it comes into range and later drops an old base station
that's leaving range? Is it impossible to design a system where the
mobile device can normally determine 10 seconds ahead of time that its
leaving the coverage area of a given base station? Need a mobile
station receive on only one channel at a time?

Regards,
Bill Herrin

---

From: Robin Whittle <[email-masked]>
Date: Thu, 13 Mar 2008 15:31:17 +1100

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:

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

---

From: <[email-masked]>
Date: Thu, 13 Mar 2008 12:04:50 -0000

Hi
 
  Whilst I agree that if you have a new feature, it will aid deployment, I am very unsure that global mobility is it. I think this because there is a lack of global mobility within the voice world, and I have a suspision that this is partly due to the time to build security associations making handover (as opposed to portability) technically dificult, and partly due to a business model that holds customers to you - the easier you make handover the easier it is for someone to start using a different network
 
What I would really like though is to understand what the trade-offs are - if we support mobility what will it add in terms of system complexity or cost. 
 
and also a better definition of mobility - if we are looking at several seconds, are we really talking "portability" ie no session continuation across the mobility event, even if the IP address stays the same some session types will drop with that type of time lag - I know I hit reload on a web page if it seems sluggish to respond and I suspect I only wait a few seconds; are the mobility events being essentially quite rare (crossing borders) ? The idea of holding your IP address whilst going between home and work raises a load of associated questions about security and accountability. 
 
Also intersting to ask why the phone networks chose to use "nasty routing inefficincies" Also interesting to wonder why, if mobility is that important to you, you dont use existing solutions? 
 
Louise

________________________________

From: [email-masked] on behalf of William Herrin
Sent: Wed 12/03/2008 21:30
To: Joel M. Halpern
Cc: Routing Research Group
Subject: Re: [RRG] Re: Supposed impossibility of scaling for mobility

Regards,
Bill Herrin

---

From: <[email-masked]>
Date: Thu, 13 Mar 2008 12:22:40 -0000

Robin
 
you are describing exactly how mobility works in IPv4 
Provided the node stays within the local network (equivalent to the the edge network) then its IP address does not change. We have a system on site of interconnected WLANs and you can move around and keep the IP address. You only change when you head off into Ipswich, when you need to use the global mobility mechanism - MIPv4 or some other method of updating your whereabouts (dynamic DNS if you dont care about trying to hold up a session)
 
The tunnel edge router is acting as the CoA - it decapsulates the packet and forwards it to the real destination based on EID (inner header)
 
fast MIP then ensures that tunnels are established between the old and new access routers (which here are tunnel end point routers) 
 
What is different is that 
1) instead of having a fixed HA, you could pollute the entire global routing system with the mapping update information
2) The biggest issues in MIP have always been to do with security associations and these are not addressed yet
 
Louise

From: [email-masked] on behalf of Robin Whittle
Sent: Thu 13/03/2008 04:31
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [RRG] Re: Supposed impossibility of scaling for mobility

Hi Hannu,

 - Robin

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Mar 2008 09:22:37 -0400

> is inflicted as a result.

Yes but it's a cart and horse question.  The routing and addressing
architecture is fundamental.  It should take mobility into
consideration, but that doesn't mean that a solution to mobility
problems should be incorporated *into* the routing architecture, just
that it should *support* mobility.  People will actually use all sorts
of unexpected clever hacks to support mobility based on whatever
routing architecture we provide.  Our job is to make that easier, but
we should not constrain what they can do.

> If you don't want to deal with it under the label of mobility, then
> we can change it to "the maximum amount of churn that any single
> player can inject".

or *should* inject.  There is a tradeoff here.  Supporting churn by
individual nodes is one dimension along which to evaluate an
architecture.  The routing architecture, as a whole, may be
significantly more robust by cutting off the churn it allows at some
threshold.  (But you know that)

> I submit that the range of the mobility is a total red herring.  As
> always, we care about topological changes, not geographical ones.
> From a topological perspective, you can cause a 'mobility' event
> simply by disabling one interface on your laptop and enabling
> another.  For a zero physical distance move, you could,
> conceptually, change your topological association completely.

Yes.

---

From: <[email-masked]>
Date: Thu, 13 Mar 2008 15:23:59 +0200

Hello Bill

See answers below.

Regards Hannu 

>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of ext William Herrin
>Sent: Wednesday, March 12, 2008 23:44
>To: Flinck Hannu (NSN - FI/Espoo)
>Cc: [email-masked]
>> Routing and mobility act on different time scales. 5 - 10s handovers 
>> are  not acceptable in any working system. \
>
>Hi Hannu,
>

Yes. Otherwise it is not a mobile system, but wireless extension of
fixed access. Right? 

>What about an add/drop model where a mobile device adds a new 
>base station when it comes into range and later drops an old 
>base station that's leaving range? 

Not sure what do you mean by adding a base station. Do you mean that
mobile device discovers a base station and adds that into its own
configuration? Or does the terminal itself become a base station
starting to offer services to others? Or adds the base station to the
global mapp encap database.

Is it impossible to design 
>a system where the mobile device can normally determine 10 
>seconds ahead of time that its leaving the coverage area of a 
>given base station? 

Proactive solutions have their limitations. It depends on the cell size
and speed of the MS. Also how do the cell sizes overlap if not at all.
Moreover the mobile node needs to know about the network coverage. There
have been various dynamic solutions to learn the coverage and
neighboring base stations, but as far as I know no-one is using them. 

Need a mobile station receive on only one 
>channel at a time?

No, but this depends the type of the radio and the coding used.

But how do these questions relate to the scalability and how the mapping
data is distributed?

>3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 
>22042-3004
>

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Mar 2008 09:39:52 -0400

> see buying service from companies who could do it in preference to

You elicit a couple of questions here.

  - What your cell phone provides is "session continuity".  That is,
    you're talking and as you change locations you can continue
    talking.  I assume that when you go to your office you close your
    laptop, and you don't have any sessions continuing.  This is
    sometimes called "nomadicity" as opposed to "mobility".  What
    exactly are you looking for?  

  - Even if you want full mobility, why do you assume the only way to
    get it is to have the same IP address the whole time?  See HIP and
    higher layer session continuity mechanisms.

> best by the end-user deciding which ETR to use, in their own way,

Why do you believe that?  Most end users only care about their
subjective experience, and if they have to be involved in the
complexity of how it's delivered, they feel burdened.

> decision.  

An ITR will maintain state on millions of flows going through it, as
to which ETR it wishes to be sent to?

---

From: Robin Whittle <[email-masked]>
Date: Fri, 14 Mar 2008 02:46:43 +1100

I am replying to 2 messages from Louise and 1 from Scott.

Below is another attempt at explaining Ivip's approach to mobility,
further to previous messages in this thread and to:

I describe how this form of mobility it could be done with any other
map-encap scheme (LISP, APT or TRRP) - only not so well as with Ivip.

I discuss how there are 3 layers of mobility system at work:

1 - Within the access network, such as switching between base
    stations, but always retaining the one IP address, which is
    used as a care-of address by the mobile host.

2 - Between the one TTR and the multiple care-of addresses of
    multiple access networks in the one city - really in the one
    1000km area or whatever, but also temporarily at least from any
    access network.

3 - The map-encap scheme using a mapping change to select a new
    TTR, which typically only needs to occur after travelling
    1000km or whatever.

Hi Louise,

Thanks for your messages, in which you wrote:

> Whilst I agree that if you have a new feature, it will aid
> deployment, I am very unsure that global mobility is it.  I think
> this because there is a lack of global mobility within the voice
> world, and I have a suspision that this is partly due to the time
> to build security associations making handover (as opposed to
> portability) technically dificult, and partly due to a business
> model that holds customers to you - the easier you make handover
> the easier it is for someone to start using a different network

The failure of the telcos to provide seamless mobility for voice has
various causes, including difficulties agreeing on air interface,
radio frequencies etc. so a single global handset could be built.
GSM and 3G has security arrangements, involving the SIM talking to
the central server of the home network before the phone can do
anything.  It is impressive how they make this work when roaming on
the other side of the globe.

Just because the telco's couldn't do it with cellphones doesn't mean
it can't be done with IP.

Anyway, this failure makes a genuinely portable IP address or subnet
of IP address space all the more valuable because it would be a
seamless, international, platform for voice communications, without
the fuss of adapting to new IP addresses, fighting through NAT etc.

> What I would really like though is to understand what the
> trade-offs are - if we support mobility what will it add in
> terms of system complexity or cost.

There is no extra architectural complexity for the main Ivip system
which provides scalable multihoming and portability (and a simple
yet real-time controllable form of TE, without explicitly load
sharing).  This architecture involves simple ITRs tunnelling to a
single ETR for each micronet, with no reachability stuff or
multihoming service restoration decision making in the system at
all.  The end-user provides that, with whatever sophistication they
like.  The key to this is fast push, essentially real-time control
of the world's ITRs.

If Oprah is geared up to do a webinar to 800,000 users:

http://event.oprah.com/videochannel/event/event_landing.html?promocode=HP11

and since our fabulous Internet can delivery packets halfway round
the world in 0.18 seconds, I reckon we should be able to use the Net
to achieve close to real-time control of the world's ITRs.  I am
aiming for 5 seconds latency.

It makes no sense to push to all those ITRs (NERD), and a global
query server system is too slow (ALT - or TRRP unless radically
souped up with integrated anycast sites) and plagued by bottlenecks.

So we need a system with some pull, and a "Notify" system to get
changed mapping to ITRs which need it.  So Ivip uses fast push (paid
for by end-users, per update) to wherever operators want to place
their full database query servers (and full database ITRs), with the
operators using pull with Notify from there to however far in their
network they want to place ITRs.

This gives end-users whatever control they want of the ITRs, rather
then forcing them to use the limited options available in LISP, APT
or TRRP - each ITR detecting failure on its own (actually APT is a
little different from this) and each making its own decision about
which of a list of ETRs to use.

This has nothing to do with mobility.

Mobility can be added to any map-encap scheme - LISP, APT, Ivip or
TRRP - by adding Translating Tunnel Routers.  There is no way of
preventing this by the architecture of the map-encap scheme.  To an
ITR, a TTR is indistinguishable from an ETR.

TTRs don't absolutely need to be standardised, other than that they
must behave like IETF-standardised ETRs.  Five different TTR
companies could have five different global networks of TTRs, and
each company could have its customers install a different set of
software for tunnelling to the TTRs, and for enabling the company's
management system to figure out where the mobile device's care-of
address(es) are.

However:

1 - Ivip would be much better for this than the other map-encap
    schemes, because the end user can select a new TTR within
    seconds, while the others have very slow push times (APT and
    NERD), or necessarily slow caching times with no Notify system
    (ALT and TRRP).

2 - I intend that Ivip include standards for the way TTRs and
    mobile devices interact, so there won't need to be a bunch of
    incompatible protocols in wide use between mobile devices
    and TTRs.

The extra bits in Ivip for mobility will all concern TTR <--> mobile
device communication.  That doesn't compromise or burden the rest of
the system with any extra complexity.

In terms of costs, there are some extra costs due to mobility - but
these all arise from the greater use of the mapping system, not due
to the cost per usage being any higher.

Lets say without mobility there are 100M end-users with 200M
micronets, generating 10M updates a day - a small number of
multihoming service restoration changes and the rest due to a small
number of end-users making lots of real-time changes to their load
sharing.  (So a lot of the cost of the fast push system is paid for,
quite happily, by these few intensive end-users who are saving a lot
of money due to the new kind of load-sharing control.)

With mobility, there are 2 billion end-users with 2.2 billion
micronets (most mobile end-users will have cellphone/computers
whatever, and only need a single micronet).  Since they only
generally change their mapping when moving large distances, such as
1000km, they add another 10M changes a day.

So the cost to all networks is that their full database ITRs and
query servers (ITRDs and QSDs) now need to deal with twice the rate
of updates and 22 times the number of micronets.  The storage is not
a prohibitive problem (terabyte hard drive or probably RAM or FLASH
by the time this level of adoption occurs), and the traffic cost of
the updates will be pretty small, by the standards of the day.
(This is 2020 or so.)

But . . . the value of the Internet to those networks which
themselves have no mobile end-users is higher, because the Internet
in general is better due to the ease and utility of being able to
communicate reliably and without fuss with all those mobile devices.

It could be argued that if the entire uptake of these mobile devices
was in a single country, and the people who used them never left
that country or communicated with anyone outside that country, then
the rest of the world would be paying a higher price for their full
database ITRs and query servers just to get all these updates and
micronets which in fact do them no good.

In reality, people all over the world will be using mobility, and
they will be communicating freely with all the other non-mobile
people, so almost everyone benefits from mobility - making these
extra costs not such a problem.

> and also a better definition of mobility - if we are looking at
> several seconds, are we really talking "portability" ie no session
> continuation across the mobility event, even if the IP address
> stays the same some session types will drop with that type of time
> lag - ....

As I have tried to describe before, this kind of mobility is not
like what you are used to with existing mobile IP systems.

The 5 second or whatever lag in tunnelling traffic to a new TTR does
not imply lost connectivity.  The idea is the mobile host sets 2-way
tunnels to two TTRs, changing the mapping to the new one while it
still has a tunnel to the old one.

The global ITR system with its essentially real-time control system
(fast hybrid push-pull with Notify) enables the end-user (or more
likely the company who provides their TTR services) to tunnel
packets from all correspondent hosts to one TTR or another, with a 5
second or so latency.

This tunnelling is generally along optimal paths, since there are
ITRs everywhere (as needed for the basic map-encap functions of
scalable multihoming etc.) and the TTRs are located close to, or
within, access networks all over the world.  "Access network" means
anywhere a mobile device could gain a care-of address, either via
plugging the device in via an Ethernet cable, via 3G, WiFi, WiMax or
whatever.  So "Access network" means pretty much any ISP, university
network, business network etc. as well as any network with 3G, WiFi,
WiMax etc.

No matter what sort of care-of address the mobile host gets, it can
create a 2-way encrypted tunnel to a nearby TTR.  The TTR company's
global control system and the software in the mobile host work
together to determine which close TTRs are best to tunnel to.

The mobile host tunnels to TTR-A from its (Care of Address) CoA-A it
got via a 3G network.

Then, while the 3G link is operating, it gets a WiFi or a cabled
Ethernet link to some other network, and establishes CoA-B.  From
there, it can make a second 2-way tunnel to TTR-A.  This may be a
longer tunnel than from CoA-A, but it works.

The TTR can send incoming packets down both tunnels, so if one fails
(say the 3G system has a glitch, drops out or ends the session,
terminating use of the CoA-A address) the mobile host still get the
packets from TTR-A via the WiFi link.  Likewise, outgoing packets
can be sent up both links for redundancy.  (The TTR and the mobile
host need some software to avoid duplicate packets getting to the IP
stack, or being forwarded out of the TTR to the rest of the Net.)

So the mobile host can move from access network to access network,
keeping up at least one tunnel at all times to the TTR.  This gives
it full connectivity - with no mapping changes.

The mobile host can move to another city, even on the other side of
the world, gaining care of addresses CoA-C, CoA-D etc.  From each of
these it can make a 2-way tunnel to TTR-A, retaining connectivity.

However, now the path lengths are not optimal when the new access
network is in the UK and the original access networks and TTR-A are
in Australia.  So it would be best if the mobile host found a nearby
TTR - in the UK - and set up a 2-way tunnel to that.  Then it would
be best to change the mapping (actually the TTR company would
probably be orchestrating this, rather than the mobile host) to
tunnel packets to the new TTR near the new access network.

Mapping changes are not needed when changing to a new access
network.  They are desirable when the new access network is a long
way from the original access network - because to ensure optimal
path lengths (and therefore low delays, minimal packet losses etc.)
it is necessary to choose a TTR nearby and so change the mapping to
point to that.  "Nearby" probably means within 1000 km, unless
perhaps you are doing a really large amount of data for a long time
in one city, with hosts in that city, and it makes sense to choose a
TTR in that city, rather than one 200km away.

> .... I know I hit reload on a web page if it seems sluggish to
> respond and I suspect I only wait a few seconds; are the mobility
> events being essentially quite rare (crossing borders) ?

I hope the above explanation makes it clear that most of this
mobility stuff happens between the mobile host and the TTRs, which
have nothing at all to do with the main Ivip system.

Overall, there are three levels of mobility at work:

1 - Within a radio access network, layer 1 and 2 (I think) mobility
    concerning different base-stations, access points etc.  The
    result of this is that the mobile host retains a single CoA.

    In the above examples, there are often two or perhaps more
    separate access networks in use at once, each providing a
    different CoA.

2 - Between various CoAs of the various access networks and the one
    TTR.  This is the business of the TTR companies and the software
    in the mobile host.  Ideally this would be IETF standardised,
    but it need not be, since it doesn't really concern the
    map-encap scheme.  The only thing the map-encap scheme sees is
    the TTRs, which must behave the same as ETRs.

    As long as this activity works with the one TTR, then there
    is no need to change mapping.

    To reduce path length, reduce delay, improve performance and
    to reduce packet losses, it is best if the TTR is close to
    wherever the access network is.  "Close" typically means less
    than 1000 km or something like this.

3 - When the mobile node selects a new TTR - which will typically
    be because it has moved to an access network which is more than
    1000km or whatever from where it was when it set up a 2-way
    tunnel with the first TTR - then this is a time to change
    the mapping.  There is no break in connectivity, since the
    incoming packets go to either the old or the new TTR.

    This is the part of the total mobility job which is performed
    by the map-encap scheme.  The map-encap scheme gets packets
    to the current TTR with typically optimal paths, because it
    is already designed to do this for any other kind of ETR -
    for the purposes of scalable multihoming etc.

    Any map-encap scheme could do this, but only one with
    essentially real-time control of mapping (Ivip) can really
    serve the mobile user well.  They reasonably want to change
    their mapping to a new TTR in a few seconds - even if they
    only do it every few weeks.  Even if they are travelling
    internationally by jet, they will probably only want to
    change their mapping every few hours.

    It could be done with LISP-ALT, but only by shortening
    caching times in order to improve response times to
    the end-user's mapping change.  The cost of that, for all
    operators of ITRs which happened to be sending packets
    to that end-user's EID, would be more frequent requests for
    new mapping data.

> The idea of holding your IP address whilst going between home
> and work raises a load of associated questions about security and
> accountability.

Sure - no-one has to do it.

Your PC/phone or whatever could have two IP addresses at all times,
via two micronets, and you could switch from one IP address to the
other with the PC itself.

Actually, your micronet could be for two IP addresses.  Then when
your PC sets up a 2-way tunnel to a TTR it is for both IP addresses.
 The TTR gets packets tunnelled to it from 2 micronets - one is your
personal one and the other is your work one.  So every time you
change TTR, you need two mapping changes rather than one.  But you
only change TTR when you travel 1000km or more.

> Also intersting to ask why the phone networks chose to use "nasty
> routing inefficincies"

Phone companies tend to suck in the way the charge for every
conceivable thing and their marketing and mobile charging plans seem
deliberately designed to confuse.  While their technology has been
bedevilled by incompatible standards, the global phone system does
work and I think it is most impressive.

> Also interesting to wonder why, if mobility is that important to
> you, you dont use existing solutions?

With mobile IPv4, you can't get optimal paths unless you have fancy
new host software in all correspondent hosts.  This will not happen.

Using standard IPv4 hosts, you are bound to send all packets to the
one, fixed, Home Agent router, which may be nowhere near the
correspondent host or the mobile host - so you are stuck with
inefficiencies, delays and higher rates of packet loss.

With the Ivip approach to mobility, correspondent hosts (IPv4 and
IPv6) have absolutely no changes - no mobility software.  The path
lengths are optimal, due to the proximity of ITRs and due to the
mobile host choosing TTRs which are pretty close to whatever access
network they are using.

Likewise with mobile IPv6, you need mobile software in the
correspondent hosts, unless you are happy to send everything on
typically longer paths via the fixed home agent router.  Traditional
mobile IPv6 with optimal path lengths seems more promising due to
the ease with which one can conceive of new OS software in IPv6
hosts in the future - but this is primarily because so few IPv6
hosts are actually used today.

Also, note that the access networks used by the mobile host in the
Ivip model are completely bog standard and have no mobility routers
etc.  No access network which gives you Internet access in any form
- including behind multiple layers of NAT - can prevent the mobile
host from finding a nearby TTR and setting up a 2-way encrypted
tunnel to that TTR.  It can do this to any TTR, to multiple TTRs at
once.  Then the map-encap scheme tunnels packets on generally
optimal paths to the TTRs.

There needs to be no technical or business coordination between the
access network and anyone, other than to the extent that the
end-user gains an IP address.

The TTR company doesn't need any special relationship with the
access networks.

The end-user chooses one of potentially many TTR companies.

The TTR companies don't need any special relationship with the
RUASes which fast push the mapping updates.

The end-user needs a micronet of address space, probably just a
single IPv4 address or a /64 of IPv6 space.

The end-user needs a business relationship with the TTR company, and
probably needs to give the TTR company the username and password
which enable mapping changes for their micronet to be given to the RUAS.

So the end-user needs:

  Mobile device.
  Micronet of address space.
  Relationship with TTR company, and to install their software.

Then, whenever their device can get connectivity, it will find a
nearby TTR (probably the one it has been using for days, unless the
end-user has moved a long distance) and so provide full connectivity
for the end-user's micronet.  This could be completely automated.

The TTRs forward outgoing packets from the mobile host to the Net -
and would typically integrate a TTR within themselves, so there are
no other dependencies when the correspondent host is using Ivip
mapped addresses.  So the access network doesn't have to worry about
forwarding packets with the source address being the end-user's IP
address.  The TTR company's TTRs have that job.

Hi Scott,

You wrote, quoting Bill Herrin:

>> And for the record, I take my laptop back and forth to work every
>> day.  You probably do too. When I do so, it travels between and
>> through networks which are administratively and topologically
>> distant. It would be awfully nice if it could keep its "number"
>> the same way my cell phone does without the nasty routing
>> inefficiencies that had to be introduced into the telephone
>> network... Nice enough that I could see buying service from
>> companies who could do it in preference to those who couldn't.
>
>   - What your cell phone provides is "session continuity".  That
>     is, you're talking and as you change locations you can
>     continue talking.  I assume that when you go to your office
>     you close your laptop, and you don't have any sessions
>     continuing.  This is sometimes called "nomadicity" as opposed
>     to "mobility".  What exactly are you looking for?

I think Bill wants his SSH sessions and everything else to run
continually, week after week, as he lugs his laptop around.
Ideally, they would continue by some magic even when there is no
connectivity.  Some protocols won't do that, but if the laptop
software knows it "owns" its IP address, then it could be configured
not to clobber that address and all applications which are using it
merely because it has no Ethernet cable, or wireless link to the
outside world.

The OS would simply treat this as 100% packet loss, with a return to
normal operation as soon as the laptop found some access network and
set up a tunnel to the TTR it has been using for weeks.  There are
no mapping changes in this.

As long as he stays around the Virginia, DC, Maryland and probably
PA, NY etc. area, he will be fine with the one TTR.   When he goes
to LA, he will use another TTR, and so generate one mapping change.

(I will write a message about travelling round the globe with a
laptop using an aircraft-based WiFi system and keeping the same IP
address all the way, without loss of connectivity.)

>   - Even if you want full mobility, why do you assume the only way
>     to get it is to have the same IP address the whole time?  See
>     HIP and higher layer session continuity mechanisms.

The Ivip approach is not the only way, but if you require that the
mobility solution involve no new features in the correspondent hosts
(that is, you want to use the Internet as it is today and for the
foreseeable future), and if you require that there be generally
optimal path lengths (no home agent) then as far as I know, the Ivip
approach is the only way.

> complexity of how it's delivered, they feel burdened.

I think end-users now and into the long-term future will have
desires which they can better achieve via real-time control of their
mapping than by whatever pre-ordained options you provide them with
via LISP.  Those options involve simple, fixed, constructs and rely
on each ITR making its own decisions, independently of other ITR and
without actually asking the end-user what they want.

End users might suddenly decide they want their EID mapped someplace
different than what they put into the LISP system half an hour ago.
 Ivip can do whatever the end-user might wants.  LISP, ALT and TRRP
can't.

End users generally won't be doing this stuff manually - they will
have their own software systems to automatically balance incoming
traffic, or their own system (or more likely that of a TTR company,
as described above) to manage their mapping to achieve mobility
and/or multihoming failure detection and service restoration.

> An ITR will maintain state on millions of flows going through it,
> as to which ETR it wishes to be sent to?

Most ITRs will be caching ITRs.  Even a full database ITR will be a
caching ITR in terms of its FIB, with an integrated full database
query server.  There's little difference between that and a caching
ITR with a direct Ethernet link to a full database query server in a
separate server.

  - Robin

---

From: "William Herrin" <[email-masked]>
Date: Thu, 13 Mar 2008 12:06:53 -0400

Hi Hannu,

I don't think so, no.

Handover is the routing technology which enables mobility in a
circuit-switched network. Circuit-switched networks are necessarily
single-homed: your voice channel can only take one path at a time. The
mobility routing challenge is amounts to this: how do I re-terminate
the tail of my circuit from this base station (wireless tower) to that
base station while minimizing bit errors on the circuit's continuous
stream? We give this re-termination process the name "handover."

If those pre-conditions (circuit switched, single homed) don't hold
then handover may be a suboptimal or even non-functional way of
implementing mobility. Clearly those preconditions don't hold for
TCP/IP: it's packet-switched and is as happy multihoming as
singlehoming.

>  global mapp encap database.

Base station = wireless tower.

* Recast mobility as a granular multihoming problem rather than a
circuit re-termination problem. *

A mobile TCP/IP device need not associate with only one tower. It can
associate with as many towers as are in range if desired so long as
it's hardware allows it to receive from all of those towers
simultaneously. This drastically changes the character of the
multihoming problem.

In a packet-switched network, mobility can be recast as a granular
multihoming problem rather than a circuit re-termination problem.
Suppose we make the mobile device's EID reachable through multiple
network paths leading to towers that may be topologically and
administratively distant from each other. Typical multihoming, in
other words.

When the mobile device detects a new tower in range, it authenticates
itself to that tower and then adds the tower to its multihoming set.
This change in multihoming state propagates through the routing system
after which the device is reachable from the new tower as well as from
all of the other towers in its current multihoming set.

When the mobile device notices that the signal is getting weaker for
one of the towers in its multihoming set, it announces a routing
change saying that tower is no longer offers a valid path for packets
addressed to the mobile device. That routing change propagates through
the routing system after which nobody attempts to conact the mobile
device via that tower.

The delay characteristics in what I'm calling the "multihoming
add/drop" mobility model are _very different_ from the handover model.
Delay is nearly irrelevant for an "add." For a "drop," the routing
change has to completely propagate between the time that the mobile
device notices that the tower's signal is getting weaker and the time
that the mobile device loses the tower's signal. That need not be
anywhere close to the instantaneity required by the "handover" model.
If the device can reliably detect that it's losing the tower's signal
10 seconds before it actually does lose the signal then it's perfectly
acceptable for the routing change to take 10 seconds to propagate.

>  But how do these questions relate to the scalability and how the mapping

If mobility can be recast as a granular multihoming problem with a
modest propagation speed but a high churn rate, would it not it be a
good idea to see if our mapping system can support granular
multihoming with a high churn rate? Surely mapping approaches which
support granular multihoming with a high churn rate should then be
viewed favorably versus those which do not.

Regards,
Bill Herrin

---

From: Scott Brim <[email-masked]>
Date: Thu, 13 Mar 2008 13:10:58 -0400

> stream? We give this re-termination process the name "handover."

RFC3775 (mobility support in IPv6) says:

   L2 handover

      A process by which the mobile node changes from one link-layer
      connection to another.  For example, a change of wireless access
      point is an L2 handover.

   L3 handover

      Subsequent to an L2 handover, a mobile node detects a change in
      an on-link subnet prefix that would require a change in the
      primary care-of address.  For example, a change of access router
      subsequent to a change of wireless access point typically
      results in an L3 handover.

Essentially an L3 handover is an event that requires your IP address
to change.

---

From: "William Herrin" <[email-masked]>
Date: Thu, 13 Mar 2008 15:13:33 -0400

>  Essentially an L3 handover is an event that requires your IP address

Scott,

  I don't offer "multihoming add/drop" as an implementation of
mobility described in any RFC I'm aware of. Quite the contrary: those
designs are deficient. They're based on limitations in the routing
system's capability which we have an opportunity here to change.

  Instead, I offer a possible re-envisioning of the mobility problem
in light of a non-monolithic map-encap routing system (such as TRRP).
If correct, that re-envisioning eliminates mobility's hardest problem.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Thu, 13 Mar 2008 18:18:32 -0400

|Excerpts from Tony Li on Wed, Mar 12, 2008 09:26:06AM -0400:
|> No matter what you and I say, some folks will try to use the routing
|> architecture to provide mobility (e.g. Connexion
|> http://en.wikipedia.org/wiki/Connexion_by_Boeing).  As a 
|result, we have no
|> choice but to deal with mobility, if only to bound the 
|amount of damage that
|> is inflicted as a result.
|
|Yes but it's a cart and horse question.  The routing and addressing
|architecture is fundamental.  It should take mobility into
|consideration, but that doesn't mean that a solution to mobility
|problems should be incorporated *into* the routing architecture, just
|that it should *support* mobility.  People will actually use all sorts
|of unexpected clever hacks to support mobility based on whatever
|routing architecture we provide.  Our job is to make that easier, but
|we should not constrain what they can do.

Let me see if I can rephrase the discussion.  The mapping function will
necessarily operate at a given maximum granularity and maximum churn rate.
Whatever levels we choose to support in the architecture, the Connexion
example shows that people *will* use things for some form of
mobility/portability/migration.  Given that a defined mapping needs to
define the granularity and churn rate, that completely bounds how much
mobility can be supported directly by routing.  

Or, in other words, we should drop the mobility discussion for now, deal
with the granularity and churn issues, and then see if we are happy with the
bounds that that imposes on mobility.

|> If you don't want to deal with it under the label of mobility, then
|> we can change it to "the maximum amount of churn that any single
|> player can inject".
|
|or *should* inject.  There is a tradeoff here.  Supporting churn by
|individual nodes is one dimension along which to evaluate an
|architecture.  The routing architecture, as a whole, may be
|significantly more robust by cutting off the churn it allows at some
|threshold.  (But you know that)

Indeed.  In fact, I would argue that the architecture should have a
well-defined, strongly enforced churn rate, for safety reasons alone.

Tony

---

From: "William Herrin" <[email-masked]>
Date: Thu, 13 Mar 2008 19:09:32 -0400

>  bounds that that imposes on mobility.

Hi Tony,

Do we have a consensus on what target numbers for granularity and
churn could support mobility directly in the routing system? If not, I
submit that we should continue our tangent long enough to get them.

While we might or might not want to support mobility directly in the
routing architecture, it would be very informative if we could say:
yes, this proposal meets the target criteria for mobility in the
routing architecture and no, that proposal does not.

Regards,
Bill Herrin

---

From: "Tony Li" <[email-masked]>
Date: Thu, 13 Mar 2008 23:58:21 -0400

Bill,

|Do we have a consensus on what target numbers for granularity and
|churn could support mobility directly in the routing system? If not, I
|submit that we should continue our tangent long enough to get them.

No, we do not.  I would like to make them the focus of the discussion.

|While we might or might not want to support mobility directly in the
|routing architecture, it would be very informative if we could say:
|yes, this proposal meets the target criteria for mobility in the
|routing architecture and no, that proposal does not.

That seems to be producing a rathole, and thus I'm asking that we come at it
from the other direction.  Let's see what we can reasonably do, and then
we'll come back and look at the mobility requirements.

Tony

---

From: Robin Whittle <[email-masked]>
Date: Fri, 14 Mar 2008 16:32:43 +1100

Short version:   Churn rates:  Some mapping systems involve charges
                 per update, so the system will naturally finance
                 itself and push the technical limits and costs so
                 there is never a situation where excess mapping
                 changes adversely impact someone.

                 (While this is unlikely to be absolutely true,
                 it could be true to a substantial extent.)

                 High churn rates are more a problem for a
                 system where each change creates burdens for
                 others which the generator of the change never
                 pays for - for instance with BGP and APT.

                 So perhaps the concept of maximum churn rate
                 could be left more open for a scheme which promises
                 to largely fund the cost of the churn by a fee
                 per update for end-users.

                 Granularity: single IP addresses should be the
                 technical limit, even if the scheme is not intended
                 to be used in this way.

Hi Tony,

You wrote, in part:

> Let me see if I can rephrase the discussion. The mapping function
> will necessarily operate at a given maximum granularity and
> maximum churn rate.

LISP, APT, Ivip and TRRP could all go down to single IP addresses or
/64s in IPv6 without any fuss.  While I don't support going further
than /64 in IPv6, I agree with Brian Carpenter that the protocols,
mapping data specification etc. should not preclude specifying the
size of a micronet (EID prefix) down to single IPv6 addresses.

While I think there could be a variety of perspectives on the finest
granularity a map-encap scheme should be used at, I can't imagine
any perspective being strong enough to preclude the mapping data
being specified down to single IPv4 or IPv6 addresses.

Also, no matter what people may think now, I am convinced that a
very common use of a successful map-encap scheme will be to provide
single IPv4 addresses and single /64s in IPv6 for end-users.  Those
may be networks of a business or organisation, or they may be for a
single laptop, cellphone etc.

Regarding granularity, I believe the system should and will be used
for single IPv4 addresses and /64s.

> Whatever levels we choose to support in the architecture, the
> Connexion example shows that people *will* use things
> for some form of mobility/portability/migration.

The Boeing Connexion geosynchronous satellite in-cabin WiFi system
is well described here:

   http://www.nanog.org/mtg-0405/pdf/abarbanel.pdf

and its unfortunate demise is discussed at:

   http://www.slate.com/id/2144186/

Yes - end-users will use the map-encap scheme for mobility too!
Even if the finally deployed scheme is nowhere near as suitable for
mobility as I intend Ivip to be.

> Given that a defined mapping needs to define the granularity 
> and churn rate, that completely bounds how much mobility can
> be supported directly by routing.

I understand the desire to set some upper limit on the churn rate,
but I think there may be an assumption in that discussion that the
system has no way of charging for each update.  BGP, APT and
probably LISP-ALT and TRRP have no such mechanism, because the
mapping changes are injected into the system from all over the
place.  These systems (APT at least, see message 746) may also
suffer from problems authenticating the change messages.

The churn rate doesn't matter with ALT or TRRP since they are pure
pull systems - unless these schemes add some kind of Notify system
(carefully directed push) or unless the churn rate leads to very
short caching times forcing ITRs to continually re-request mapping
information.

Ivip and perhaps NERD has a more centralised source of mapping - so
there is a readily available means of centralising the
authentication of mapping changes, and also for charging for each
update.

With Ivip, I aim for a fast, efficient, push system - to as far into
networks as operators choose to place their full database ITRs and
query servers.

The idea is that the end-user will pay, one way or another, per
update - and probably in other ways for their mapped address space.
 The idea is firstly that the fast push system is efficient and
highly scalable, and secondly that whatever number of updates it is
carrying (the high churn rate) it does so on a profitable basis.

So as the system grows to massive volumes of updates (massive churn)
it remains functional and viable at all times, with no end-user
placing an unreasonable burden on any other party.  If the technical
limits are really pushed, then the price goes up (or at least
doesn't continue to fall) so people think more carefully before
changing their mapping.  Then the churn rate automatically remains
within reasonable technical and commercial bounds.

I can't tell you what the maximum update rate the Ivip fast-push
system would cope with in 20 years time.  I do have some WAGs about
it not needing to be more than a few hundred updates a second, even
with billions of end-users, most of them using the system for
mobility.  Although this is more than BGP's current rates, this
seems perfectly practical, since it is far more streamlined system
and involves simpler data than BGP advertised routes being
propagated from one router to another.

If the Ivip system is also used intensively by a small number of
high-traffic end-users for real-time TE on a 5 second by 5 second
basis, that is great too - those people will be paying for the
changes and so will help to finance the fast push system.

So when considering churn rate, I think it is important to
distinguish between a BGP-like or APT-like flooding system with no
revenue per change - which suffers from the exact same free-rider
problem we are trying to overcome with the bloat in the DFZ routes
and updates today - and a system such as Ivip where the end-user
making the update does pay partially or entirely for the burden they
place on the mapping distribution system.

> Or, in other words, we should drop the mobility discussion for
> now, deal with the granularity and churn issues, and then see if
> we are happy with the bounds that that imposes on mobility.

I agree with Bill:

> churn could support mobility directly in the routing system? If
> not, I submit that we should continue our tangent long enough to
> get them.

I think it is productive to continue to explore how a map-encap
scheme could be used for new approaches to mobility.

A global map-encap system is an extraordinarily powerful tool which
has not been anticipated by the mainstream mobile IP folks.

My previous messages in this thread argue that mapping changes do
not need to be used in the most obvious manner: changed mapping each
time there is a new care-of address.  Anyway, those CoAs will often
be behind NAT, and so can't be reached by the ITR.

I have also tried to show that there is no extra architectural
complexity to support mobility in Ivip.  The mobile component of the
churn rate will however affect the update volume and workload of
full database query servers and ITRs.

The map-encap scheme enables a new form of mobility which involves
relatively few mapping changes - so one shouldn't assume mobility
opens the floodgates to billions of devices needing a mapping change
every time the device moves from a WiFi system in a cafe back to the
more expensive 3G system in the street.

So I think it is best to discuss mobility and its potentially lower
than expected demands on the churn rate, while discussing churn
rates and whether the proposed system supports per-update charging.

> well-defined, strongly enforced churn rate, for safety reasons alone.

As long as updates pay their way in the mapping distribution system,
I am not sure we need to set a maximum update rate now.  We need to
anticipate what the rates may grow to, but as long as the system
pays for itself, then the costs and rates will nicely match the
technology of the day.

 - Robin