Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)

From: [email-masked]
Date: Fri, 20 Apr 2001 12:58:00 -0500

Comments inline:

>James wrote:
>Raj and Erik,
>
>>>Erik:
>>> Basically I see two approaches and I don't know how to resolve them:
>>> 1. A domain might be huge (for whatever reason) hence for 
>>> scaling reasons
>>>    you need to be capable of having a arbirarely deep 
>>> hirarchy of agents.
>>Raj:
>>Why? Would this not work just as well with a single level of hierarchy,
>>but one where there are multiple top level agents, i.e a distributed
>>set of top-level agents which can load balance if that is a concern.
>>
>
>No, because the signalling lines may depend on the depth as well
>as the breadth of the routing topology. So in a large, multicontinental
>routing domain, the signalling for a single per domain agent may be just
>as expensive as signalling directly to the corresponding nodes
>and home agent. 
>

But that would imply that the mobility agent assigned to the MN is
probably not the optimum one. The idea is to reduce signaling and this
can be accomplished if you have a mobility agent closer or at some
optimum level in the network. So there is some engineering about where
the mobility agent resides and I would think that in the case of an
inter-continental routing domain, the mobility agent serving a MN
would be somewhere close to the MN and the signaling would not have to
traverse some undersea cables. And why would you believe there be only
one domain agent in a large routing domain? 

>In addition, changing a single top level agent requires the mobile to
>signal a  
>regional care of address change to the home agent and all
>corresponding nodes. 

But how often do you change a top-level agent? Irrespective of how
many levels of hierarchy you have, if you change the top level agent,
you will need to signal the HA and CNs. So if you are changing your
top level agent every time you perform a hand off, then obviously
there is something wrong with the location of the top-level agent.

>It is therefore a heavyweight solution and
>one that should not often be done, even if there is no reauthentication
>involved. Making it the basis of dealing with load balancing is therefore
>likely to lead to more signalling latency than if multiple levels
>of LMM agents were allowed.
>

Multiple LMM agents are required no doubt, but do we really need
multiple levels of these agents? I do agree with some of the examples
you have provided of not limiting a hierarchy or ruling it out, but
from a deployment perspective, I am not so sure...

>>> 2. Simplicity is good idea and a solution without hirarchy is 
>>> likely to
>>>    be simpler, if not to implement to operate, than one with 
>>> a hirarchy.
>>> 
>>
>>Completely agree here Erik. I know there have been arguments for
>>having a hierarchy, but I still do not totally get it. 
>>
>
>I'm all for simplicity, which is why I would like the requirements
>to preclude preferences or other complex attributes that need
>additional standardization. But, in this case, I think not allowing
multiple 
>levels of LMM agents shuts out possible deployment scenarios that
>I believe are realistic and will directly affect how well the
>solution  fufills the fundamental requirement, namely localizing
>signalling.
>
>		jak
>

I do not think we should rule out multiple levels of LMM agents from
the requirements at this stage, but let's discuss the implications of
a multi-level hierarchy from a routing, deployment, failure-point etc.
perspective. Obviously there are quite a few people who feel quite
strongly about it and to rule it out would be unwise. 

-Basavaraj

---

From: Theo Pagtzis <[email-masked]>
Date: Fri, 20 Apr 2001 12:46:49 -0700

Hi Basavaraj,

some comments below..

> one domain agent in a large routing domain?

carefull here...we need differentiate between optimality over the reduction
of signalling and optimality over the location of the LMM agent. The reason?
the MNs velocity vector...

If you locate too close to the LMM then if the MN is moving with irregular
speeds then you would need to change your LMM too often...so although you
managed to save something on the signalling you threw it in the bin since you
have to perform LMM-agent change more often...

I don't think Jak refered to single LMM agents in a large routing
domain...quite the opposite but the MN is not stationary...the leg between
the LMM agent and the MN will be growing long...reaching base MIPv6 behaviour
(to some extent )...

We definetely need the spine of LMMs (i.e. hierarchy) so that we can traverse
over it and adjust that "leg". I think that is the beauty of multiple-level
hierarchy in an LMM..

> there is something wrong with the location of the top-level agent.

surely not too often....otherwise we mush the LMM protocol...but you still
need that hierarchy...
to optimize the signalling between the LMMs..

> from a deployment perspective, I am not so sure...

IMHO I think that the deployment is what is all about...it may be painfull
(no doubt) to go through it
but I feel that it will pay off..

> strongly about it and to rule it out would be unwise.

Well that is what we have been doing for the last week or so..

Theo

UCL/ Mobile Systems