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 protected]
https://www1.ietf.org/mailman/listinfo/int-area
