Subject: [Int-area] Re: draft on network-based mobility management

From: Henrik Levkowetz <[email-masked]>
Date: Tue, 09 May 2006 23:33:21 +0200

Hi Hesham,

  This is becoming rather long, but I still prefer (barely) not to
start snipping.  I've tried to be lucid and concise in the comments
inline, below:

on 2006-05-09 02:18 Soliman, Hesham said the following:
> 
>> >> 	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?

This could be handled by MPLS, IP-in-IP, ethernet switching or whatever
makes sense for the deployment case.  Personally I'm for defining the
protocol so that it is able to use any of these, and more.

> 
> 
>> >        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.

If you mean to do that in order to handle the same local mobility domain,
I would agree.  I could however easily imagine cascading these, so
a small area would be handled by one, and a larger area by another,
each invisibly to the other.

And I'd strongly maintain that your statement above:
  "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."
is clearly incorrect.

The proposal of using host-based mobility and network-based mobility
together in the manner proposed by NetLMM, with host-based mobility
handling global mobility and NetLMM (where deployed) handling local
mobility makes a lot of sense, and I haven't seen convincing arguments
to the contrary.

>> > 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. 

Oh! Oh, I see.  This is not at all what I got from reading the draft.
What I understood was an attempt at arguing against network-based local
mobility support, in absolute terms, not relative to host-based *local*
mobility support.

>    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.

This is not at all clear!

(Well, I should say that to me it was not at all clear ;-)

>> > 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.

Please check my first response above.  You said:

   "...scheme makes this a difficult problem. How would a network based
   mobility management system know which flows to move to which link?"

To which I said:

	"It wouldn't.  And, more to the point, nobody has claimed that
 	it would or should!"

So either you accept this statement, in which case I don't see that
we have a disagreement, or you don't accept this statement, in which
case it would be good to understand why.  I simply couldn't understand
what you meant with what you actually did say:

   "Same answer. Check the definition of local mobility. Not 
   my definition!"

>> >> 	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.

Aha.  I've seen (and designed software for) systems which correlate
movement with roads and statistics of traffic flow, and from this
together with knowledge of radio lobes from the base station predict
where and when a handover is possible / desired.  This can fairly
easily be done on the network side, but not as easily on the MN side.

> 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.

This can be a concern, certainly.

>   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.

No, I don't think that's a given.  I see alarms going off if a
normally busy AP suddenly has no traffic, while the traffic
of neighbour APs are higher than normal.  This is complex, but there's
nothing obvious about a statement that the MN always knows more
about everything.

>> 
>> 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.

Right. Thank you.

>> > 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. 

So maybe it's time to lay those old argument to the side, and
acknowledge that both network-based and host-based mobility support
can bring good things to the table?

>> > 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. 

Right.  What I was trying to say was 'Send comments about specific
text in of the problem statement to the netlmm list, to discuss it
there and try to improve it'.  I think that is a more profitable
road for all...

>> > 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.

No, no, no.  There is no reason why you can't set up these in advance,
and have N SAs in each anchor point, and M SAs in each AR, permanently.
N here is thousands, and M probably less than ten.

The SAs are preconfigured and predicted easily. A network operator knows exactly how many ARs he has, gives each of them a shared secret and scales
the AAA infrastructure accordingly. The SA is set at bootstrap and not on
the fly during handover time.

>  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.

Again, not so.  There is one SA needed in the anchor for each AR, not
for each MN.  An operator able to handle SAs for millions of MNs should
be able to handle SAs for thousands of ARs...

Regards,

	Henrik

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 9 May 2006 15:47:02 -0700

=> Thanks! I think we can close some of the points as it seems that we're
at least seeing where we agree and disagree. 

=> Well, that might be possible in some cases, but I'm questioning the need for two
mechanisms to begin with. I'm afraid that the root of my problem here has 
not been addressed. I.e. the problem statement. I don't expect you to answer
that; I'm trying to get a collective understanding of what the problem is. I don't
think there is one. If there is, it's certainly not documented in the PB draft. I think
that document is well below average in terms of logic, of course that's my opinion. 

=> Well, it's inaccurately worded, I agree. I meant host-based LMM
and network-based LMM.

=> So let me summarise my contrary opinion as follows: I think its important, 
and will continue to be important in future, to be able to get the same features
locally as those we get globally. I don't think we will be able to do that using 
NETLMM. Examples of those features include the ability to select a particular access
technology over another, selecting an AP over another, managing flows over different
paths ....etc. IMO, it is insufficient to rely on Global mobility to do this. We need
to be able to do this *locally*. I know you mentioned some examples of attempts to
do this using NETLMM below but I think they're not practical and I'll respond to them
below. Well, I intended to make this short, but failed again :) 

=> Sorry, I guess that was my hidden plane of reference :)

  Aha.  I've seen (and designed software for) systems which correlate
  movement with roads and statistics of traffic flow, and from this
  together with knowledge of radio lobes from the base station predict
  where and when a handover is possible / desired.

=> Sure, I've seen a significant amount of research on this. However, 
it is certainly more complex and so far it hasn't been close to being 
in products. I believe mainly due to the inaccuracy of such predictablility. 
Remember that you're mapping static information (a map) to a cell. That doesn't
tell u if a bus just stopped infront a mobile and reduced its coverage (giving 
a simple example to illustrate the point). It might work fine if your MR is 
on a train, but certainly not a generic model.

  This can fairly

=> I have to strongly disagree with that. I'm not a radio expert but I work
with those people, as I'm sure you do, and I believe they completely 
disagree with this assumption.

  No, I don't think that's a given.  I see alarms going off if a
  normally busy AP suddenly has no traffic, while the traffic
  of neighbour APs are higher than normal.  This is complex, 

=> Exactly, it's a complex intelligent guess. I think you're willing
to accept it as a viable option because of your statement below:

   but there's

=> This is I think where we come from completely different view points. 
I think it is trivial and more ereliable that the MN is aware of all the surrounding choices
based on its available interfaces and the PHY measurements avaialable on those 
interface. 

> of "no mobile involvement" approaches are even reflected in certain

  So maybe it's time to lay those old argument to the side, 

=> No problem, I'm happy to not mention the old arguments :) 
  
  and

=> I'd be happy to acknowledge that if I thought it were true. I'm willing
to acknowledge, for example, an obvious point: There *can* be less BW consumed
over the air, in some link layers, if MN signalling is eliminated. But I don't
think that's worth all the troubles I see. 

=> Sure. Since netlmm is on this correspondence, I'd like to refer everyone 
to section 2 of the draft which is all I have to say right now on the current
problem statement. If more comments come to mind I'll send them later.

=> Yes, you can do that. But I want to put a real number for M, I'd estimate
for a country like the US, on average, N is about 25K (give or take depending 
on the link layer) and M is more like 200-300. 

  The SAs are preconfigured and predicted easily. A network operator knows exactly how many 
  ARs he has, gives each of them a shared secret and scales
  the AAA infrastructure accordingly. The SA is set at bootstrap and not on
  the fly during handover time.

=> Nice take on my statement :) There is a difference though:
When you have millions of subsribers, you can associate them with different
AAAHs so you can say put 200K subs on each server (again a simplified example). 
But in the netlmm case, you can't put N/100 ARs on each anchor, you need to put 
all ARs on each anchor. I think the scalability here is clearly worse. 

 for each MN.  

=> Sure, I would agree with that.

  An operator able to handle SAs for millions of MNs should
  be able to handle SAs for thousands of ARs...

=> Not so easy with existing products. I looked at this 
for real deployments. 

Hesham

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 9 May 2006 15:52:10 -0700 (PDT)

>    On the surface this sounds conciliatory and ideal, but I'm afraid

In practice local and global mobility schemes co-exist.  For example, MIP 
can co-exist with 802.11 handoff schemes (e.g. 11i, 11r).  So I think that 
it will be required to point out specific co-existence issues, rather than 
asserting that the generic co-existence problem has no practical solution. 

BTW, 11r also has a notion of "initial" contact point, similar to an 
anchor, and I believe it should scale to 100K+ users in a Mobility Domain. 

> mobility makes a lot of sense, and I haven't seen convincing arguments

Neither have I.