draft on network-based mobility management

 
 > >> 	This description is in part incorrect:
 > >>  	1. The mobility anchor point *does not* act
like a home agent.
 > > 
 > > Well in the sense that it binds one relatively
stable address to
 > > another. 
 > 
 > No.  It does *not* bind one address to another.  It
updates the
 > routing rules for an IP address - there's no two
addresses here to
 > bind together.

=> See my answer below.

 > 
 > > Of course it's not exactly an HA. 
 > 
 > Right.  Except it seems you're still sticking to the
idea that it's
 > 'kind of' an HA.  But again: it's not.
 > 
 > > Again, it's a simple analogy to the anchoring
mechanisms in MIP.
 > > I'd rather not delve into a terminology debate
at this 
 > point, I think
 > > we both understand the overall picture of the
NETLMM 
 > approach described
 > > in
 > > the charter.
 > 
 > Sorry, Hesham.  From the whole content of the draft,
the 
 > basic problem
 > I see is that it seems you don't understand the
overall picture.  So
 > please don't try to dodge this as you do above - I
think you need to
 > take a second look at this, and re-evaluate the
'simple 
 > analogy to the
 > anchoring mechanisms in MIP'.

=> Like I said, I didn't think it's the real issue in
the draft but 
since you persist, and since I don't like to be a
"dodger" I took a 
second look at the charter since I'm not aware of any WG
doc. 
Here's an excerpt:

  The network-based localized mobility management protocol
will conform 
  to the following framework. Mobility anchor points within
the backbone

  network maintain a collection of routes for individual
mobile nodes. 
  The routes point to the access routers on which mobile
nodes currently

  are located. Packets for the mobile node are routed to and
from the 
  mobile node through the mobility anchor point. When a
mobile node 
  moves from one access router to another, the access
routers send a 
  route update to the mobility anchor point.

So, it's an anchor point that "forwards" the
MN's traffic to the AR.
If the MN moves to another AR then a "route
update" is sent. Since this 
anchor sends the MN's traffic to an AR that I presume is
potentially
several
hops away, is there some kind of encapsulation going on
here? IP in IP
perhaps?
Is there some binding between the outer address and the
inner address? 
If there isn't then how does this "forwarding"
happen?


 > >        As for the reliable manner,
 > >>  	reliability is related to quality and
determinism, and if the
 > >>  	link quality is made part in the
evaluation, this may also be
 > >>  	covered.  WHAT IS NOT given is that the
resulting choice is
 > >>  	*optimal* from a user viewpoint.  But
consider that given the
 > >>  	posited availability of both network-based
and 
 > >> host-based mobility
 > >>  	support, the mobile may very well have the
option of 
 > >> establishing
 > >>  	a different ID for the different access
types, and use host
 > >>  	mobility to switch between these...
 > > 
 > > So you're jumping over many assumptions here.
You're assuming that
 > > both host and network mobility can coexist. On
the surface 
 > this sounds
 > > conciliatory and ideal, but I'm afraid 
 > > it's not practical.
 > 
 > Heh!  As I've seen it in action, you'll have hard
time sweet-talking
 > me into closing my eyes to this.  I've seen the
benefits of running
 > both in parallel.  If you want to close your eyes to
the 
 > mere possibility,
 > go ahead, but don't expect me to agree.  It is indeed
*very* 
 > practical.

=> It depends on what you mean by "both in
parallel". I'm 
comparing a *host-based LMM mechanism* to an exclusively
*network-based
LMM mechanism*. Have you run those two in parallel? I don't
think it
would make sense to do that.

 > > Having NETLMM *excludes* the host's ability to
 > > communicate with a local anchor. Hence, when you
say host 
 > mobility is 
 > > possible you must mean a host-HA relationship.
This isn't efficient
 > > enough
 > > for the types of handovers, flow movement or
multihoming 
 > decisions that 
 > > a host might make. This also assumes that the
overhead of 
 > having the
 > > remote
 > > HA is acceptable. It's not acceptable in many
cases.
 > 
 > Oho!  Please be very aware that here you're *not*
arguing host-based
 > mobility versus network-based mobility; you're
arguing one particular
 > type of local mobility-support versus another type.  

=> Of course I am! I'm raising concerns against
network-based
LMM and my reference is the existing host-based LMM. 


   THIS can be a
 > very interesting discussion indeed, but it is *not* a
host-based
 > mobility versus network-based mobility discussion,
which is what
 > your draft seems to be about.

=> Host-based LMM Vs NETLMM. The entire draft addresses
LMM
exclusively.

 > > I really think you should reconsider this
assumption. You seem
 > > to assume that an inter-access technology
handover is host-based 
 > > while not limiting the definition of a mobility
domain to a single
 > > access technology. You can't have it both ways

 > 
 > Of course I can.  There are more degrees of freedom
here than can be
 > captured in the simple view that 'since A is able to
handle inter-
 > access mobility, B has lost the freedom to handle
it'.  Both the set
 > of possible radio technologies, and the set of
potential providers
 > of such are open-ended, and provide for much richer
possibilities
 > than that.

=> So let's discuss those possibilities. 

 > >> 	It wouldn't.  And, more to the point,
nobody has claimed that
 > >>  	it would or should!
 > > 
 > > Same answer. Check the definition of local
mobility. Not 
 > > my definition!
 > 
 > I don't know what you want to say with this.
 > 
 > I'm trying to show that your fears about NetLMM is
largely 
 > unfounded, and
 > it seems to me that you're wed to your fears, and
won't let 
 > go of them
 > even if they're unfounded.

=> I'm not talking about fears, I'm raising technical
concerns. 
If they are unfounded then tell me why. Simply saying that
they're
wrong or negating them without explanation doesn't help.
For example,
my answer above refers you to the definition of "local
Mobility", which
says nothing about whether the handover is within the same
access tech
or a different one. Your response talks about my unfounded
fears. That's

not progressing a discussion.

 > >> 	I don't see that this follows.  What would
make it quicker,
 > >>  	when it has less predictive ability than
the network, and
 > >>  	longer signalling paths?
 > > 
 > > It's quicker because of most link layers the
mobile knows
 > > first what it's best candidate will be. The
mobile
 > > is in the best position to measure signals from
other basestations
 > > to itself. So of course it will know first.
 > 
 > What you're describing here is not predictive
capability, 
 > but reactive:
 > measuring what is.  For the access technologies *known
to 
 > it* a network
 > may be predictive, where a mobile node has a harder
time of 
 > it.  

=> I don't see how it is possible that the network can
predict
better than the mobile since every link I've seen that is
capable 
of this prediction bases such prediction on the information
received
from the mobile. My point in that particular paragraph was
about 
the uncertainty of movement during handovers and how the
mobile 
node can react quickly to those changes. The handover itself
is 
predictive because actions are taken before the mobile
moves. However,
I was concerned with reactions to certain changes in signal
strength, 
availability ...etc that can happen later in the handover
process, i.e.
potentially after the network had already decided that the
mobile is 
moving to a particular link.

  Of course,
 > for access technologies outside those known to a
network, it 
 > will know
 > nothing (unless the mobile tells it about those).

=> Sure, but whether an access network is
"known" is itself 
another big question. "known" should mean
"known and functional".
An AP might be present, responds to pings, but it's radio
isn't 
functioning. So a server in the core would certainly know
less 
about the state of the radio than a mobile which can detect
whether
an AP is funtional, available, limited ...etc.

 > 
 > So, my question above stands:
 >  	I don't see that this follows.  What would make it
quicker,
 >  	when it has less predictive ability than the
network, and
 >   	longer signalling paths?

=> I tried to answer above.

 > > It was a spoken motivation that I heard for many
many people
 > > over the last 5 years. So it's not something I
made up. 
 > 
 > Since the NetLMM work is *much* younger than 5 years,
I don't know
 > what other efforts you're overloading on the current
one here.

=> Ah, the WG is very new of course, the culture of
"network control"
is very old and we had these discussions for many years in
MIP. Some 
of "no mobile involvement" approaches are even
reflected in certain
modes of FMIPv4 and v6. 

 > > All I'm asking for is a clear and coherent
problem statement that
 > > justifies what you claim above. The claims in the
current statement
 > > are frankly well below the average engineering
common 
 > sense. I really
 > > hope someone can show me how these claims make
any sense 
 > or are backed
 > > by
 > > any data. Simply saying that "each approach
has its 
 > problems" is not
 > > good
 > > enough or technical enough for me to agree.
 > 
 > Fine.  So comment on the problem statement.

=> There is a whole section on it in the draft. 

 > > I don't think this is feasible in a practical
deployment. 
 > I've worked
 > > on and seen these networks deployed. Imagine a
situation 
 > where you have 
 > > a 100 - 200 local agents and 10 - 20 K
basestations, each 
 > containing an
 > > AR. Now 
 > > try to manually configure SAs between all ARs and
all anchors and
 > > maintain
 > > those SAs, i.e. roll the keys ....etc I don't
think you'll 
 > find many
 > > people wanting
 > > to manage things this way.
 > 
 > No.  Of course you don't want to manually manage 20 K

 > base-stations' SAs.
 > But that doesn't mean that you can't pre-configure
the relationships
 > using other means than manually handling each of them.
 The point is
 > that you wouldn't do it ad-hoc.

=> Not sure what you mean by "ad-hoc". You
can certainly pre-config
with Certificates ...etc but the point raised in the draft
was two
fold (assuming that you agree manual config is not
practical):
 A. You don't want SA establishment during handover because
it adds
    time. Since we don't want permanent NxM SAs (no of ARs
times number
    of anchors), we have a timing problem. This is specific
to NETLMM.

 B. It's not easy to deduce how many SAs are needed in the
anchor based
    on the number of MNs it can support. This is a
dimensioning
challenge
    which only exists in NETLMM.

Hesham

_______________________________________________
netlmm mailing list
netlmmngnet.it
https://vesuvio.ipv6.cselt.it/mailman/listinfo/netlmm