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

From: kempf <[email-masked]>
Date: Sun, 22 Apr 2001 11:20:47 -0700 (PDT)

Hi Karim,

>We have been trying to identify what applications require multiple
>levels of local agents (MAPs) linked to each other. This requirement
>is still not clear to me, but I wouldn't rule out that we can
>agree on reasons with more discussion.
>

I think we could talk about various reasons for several months and
not agree that any of them were compelling enough, from your point
of view, to include hierarchy. 

The strongest reason I can see is one of trying to avoid suprise.
If we do not include hierarchy and it becomes necessary during deployment, then 
we end up having to recycle to proposed standard, delaying adoption. On the 
other hand, if we do include hierarchy and it doesn't get used, then there
is just a feature there which nobody uses. Naturally including hierarchy makes 
the design somewhat more complex, but I think that can be minimized if the
design is done properly. This is what I was trying to get at at the
WG meeting in Minneapolis, but, unfortunately, wasn't able to clearly
articulate it.

I'm actually speaking from experience here, having been involved in
a standard that needed to be so recycled.

>What I would not like to see is a design which is made more
>complex (and introduces multiple points of failure) solely to be
>optimised for a special case of a hierarchy in which one BU is passed
>on between mobility agents (MAPs). At least, this is what I'm
>questioning.

I presume you are referring to the RRv6 design? I don't think anybody
is proposing that this design be normative for the hierarchy
requirement. If you like, we can adopt a requirement concerning the
interaction between multiple levels that rules out extraneous signalling. 

>In fact the current WG draft (HMIPv6) does not rule out a
>MAP hierarchy, but considers mostly a MN using one MAP. The v4 WG
>draft (Regional Reg) also considers a 2-level hierarchy (one GFA
>with one level of FAs below it) but allows multiple levels. Of
>course, in v6 there can be multiple levels of ARs between MN and local
>agent. As Raj wrote in a previous email, it is possible to have agents
>(MAPs) located at different "levels" and the MN can use or be made to
>use the appropriate one. These can be, but do not have to be necessarily
>linked to each other. If packets need to be forwarded between local
>agents, the MN can send appropriate BUs to the individual agents and
>create a MAP hierarchy. This is allowed in the current draft and we can
>work on further optimisations. It's need however is still being discussed.
>I just wanted to clarify this point.
>

OK.

		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Tue, 24 Apr 2001 23:44:08 +0200

One more thing to consider. Is the need for multi-level
hierarchy specific to MIPv6 ? Because this is not 
the case in MIPv4. So why is this any different ?

Hesham

> -----Original Message-----
> From:	James Kempf [SMTP:[email-masked]]
> Sent:	Wednesday, 25 April 2001 1:55
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L ocalized Mobility Management Requirement s)
> 
> Hi Erik,
> 
> >> Ulimately, the issue is one of deployment. The worst possible case
> >> is we cycle an LMM protocol without multiple levels of hierarchy
> >> to proposed and discover during deployment that we need it. 
> >
> >Jim,
> >
> >You are stating the design philosophy that leads to kitchen sink
> >protocols - put in as much as possible to make sure nothing we can
> >ever imagine has been left out.
> >
> >I much prefer the opposite philosophy - only include what we know for 
> >sure will be needed.
> >
> 
> 
> Actually, no. I'm saying that we have had at least three people who
> have given good arguments, IMHO, as to why multiple levels of
> hierarchy might be needed. On the other side, those arguments
> are refuted by two people who think that no hierarchy is needed.
> Neither side is going to convince the other, both sides have
> good arguments.
> 
> The kitchen sink results when somebody says "let's put in this neat
> feature," then somebody else says "let's put in this neat feature,"
> and the group iterates on this for several rounds with nobody 
> really coming up with good arguments for or against the feature except
> that it was X's idea.
> 
> What I'm saying is that we have some arguments the feature is needed,
> so let's put it in. From Karim's last email, it sounds like we can
> probably accommodate his concerns about multiplying failure possibilities.
> If we don't put it in and deployment proves that we need it, as I and
> at least two other people on the list think will likely be the case, we
> are stuck with going back through proposed standard. 
> 
> 		jak

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 25 Apr 2001 00:00:36 +0200

Hi James, 

Fair enough. However, I don't really believe that stating 
an opinion is enough, the reasons should be discussed. 
But I guess you would say that this was already done. 

What gets me though is why these arguments are only 
raised in the context of MIPv6 ?

Anyway 5 or 6 people can hardly represent a WG so let's 
hear what people think. 

Hesham

> Sent:	Wednesday, 25 April 2001 7:47
> Hi Hesham,
> Thanx for your response, but I think we've been through these
> points a number of times, we really don't need to rehash them again. Charlie, 
> Theo, myself, and one other person (whose name I've forgotten) have spoken up 
> for a requirement to support hierarchy. You and Karim have spoken up against it, 
> and Raj, expressing a preference for simplicity, has an inclination
> against it.
> 
> Anybody else out there in SMTP-land want to express a preference?
> 
> Phil, any ideas about how to proceed?
> 
> 		jak
> 
> 
> >From: "Hesham Soliman  (ERA)" <[email-masked]>
> >To: "[email-masked]'" <[email-masked]>
> >Subject: RE: Multiple Levels of LMM agents (was: RE: [mobile-ip] Revised L 
> ocalized Mobility Management Requirement s)
> >Date: Tue, 24 Apr 2001 23:34:56 +0200
> >
> >
> >	=> I'm not sure who you mean by the "two" people, there is definitely 
> >	more (at least the authors of HMIP are) but anyway
> >	after reading the discussion it really seems to me like the only 
> >	two (understandable IMHO) reasons are:
> >
> >	1.  In future there may be a need for multi-level hierarchy. That need 
> >	is not explained really. To me this is not a good reason for including
> >	any feature. Ithink it makes a lot of sense of scope the problem to
> >	what we know without "guessing" what might happen in future
> >	and how theuse of MIP can be changed dramatically. No one 
> >	knows that this is true.
> >
> >	2. Multi-level hierarchy localises the signalling. Let's try to 
> understand 
> >	what this really means. A MAP domain is as large as the amount 
> >	of traffic that a MAP can handle, regardless of the number of 
> >	levels of hierarchy. The signalling will always be local to that
> >	domain. So I'm not really clear on the significant advantage here. 
> >	We're certainly not expecting any inter-continental mobility 
> >	management using HMIPv6. So careful placement of the MAP 
> >	using network engineering skills and common sense is 
> >	sufficient. 
> >
> >	=> At a cost. The beneft MUST outweigh the cost. This is not 
> >	the case here IMO.
> >
> >> If we don't put it in and deployment proves that we need it, 
> >> 
> >	=> This is exactly point one above. 
> >
> >	Hesham

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Wed, 25 Apr 2001 14:47:53 +0200

Hello James and Erik

>are stuck with going back through proposed standard.

I agree with Erik's point. If putting another requirement on local
mobility gets us to produce optimised solutions for it without knowing
if it is needed that's IMO not a good idea. On this point I agree that
we should include what we know is needed and keep the solution simple.
However, my previous comment was that in this particular case we can probably get the basic linked local agents functionality for free in
the solution. At least that's what we have now, even though I'm not
convinced this functionality will be useful.

Regards
/Karim

---

From: "Martin, David P" <[email-masked]>
Date: Wed, 25 Apr 2001 10:02:12 -0400

I've been following the discussion, and since you've asked I'll give you an
opinion.

It seems that Hesham's main point is that the speed of the fixed network (or
"wired") is so much greater than that of the wireless network that the
benefits of hierarchy are minimized.

I'm not sure I would agree that the speed of the fixed network will *always*
significantly outstrip that of the mobile network.  I don't feel I have a
good enough grasp of all the issues to weigh in on one side or the other,
but did want to highlight an assumption I don't feel comfortable with.

> From: Phil Roberts [mailto:[email-masked]]
> Sent: Tuesday, April 24, 2001 5:59 PM
> To: [email-masked]'
> Subject: RE: Multiple Levels of LMM agents (was: RE: 
> [mobile-ip] Revised
> L ocalized Mobility Management Requirement s)
> 
> 
> How to proceed?  Good question.  It would be really good if 
> some other folks
> weighed in on the issue.  Does anyone who hasn't commented on 
> this so far
> care to add anything?  care at all?
> 
> Phil
> 
> 
> > From: James Kempf [mailto:[email-masked]]
> > Sent: Tuesday, April 24, 2001 5:47 PM
> > Subject: RE: Multiple Levels of LMM agents (was: RE: 
> > [mobile-ip] Revised
> > L ocalized Mobility Management Requirement s)
> > 
> > 
> > Hi Hesham,
> >

---

From: [email-masked]
Date: Wed, 25 Apr 2001 14:07:49 -0500

James,

>Raj,
--snip-----
>
>I guess I don't understand your response. Nobody's proposing an IN like
>solution. 

I did not mean to say IN in the traditional sense of IN. What I meant
to say was that we should not be building additional intelligence in
the routing infrastructure via LMM agents (or multiple LMM agents :)
and the like to handle mobile nodes in an efficient manner. 

>The RR proposal has hierarchy, it is not all that much
>more complicated than HMIP, IMHO.
>

My statement had no relevance on any specific solution. 
But HMIP allows you to have a hierarchy as well, does'nt it?

>All that we're asking for is that the requirements state that the
>solution SHOULD (not MUST) support multiple levels of LMM agents.

No problem from my perspective with this requirement. I think we have
debated enough on this topic. I propose that we leave the requirement
in there and let deployments decide on the levels of LMMs required.

>The reason is so that if a network operator has a deployment situation
>where the signalling lines get long, they can deploy an upper level
>agent to keep the external CoA fixed.
>
>People are reading too much into "LMM" and "hierarchy" as words.
>
>		jak

-Basavaraj

---

From: James Kempf <[email-masked]>
Date: Wed, 25 Apr 2001 13:52:27 -0700 (PDT)

Hi Phil,

OK, it is clearer. Comments below.

>I think I made this argument once in the MM design team about 6 months
>ago but I don't feel like digging through all the archives, so let me take
>another shot at it.
>
>The handoff destination LMM (if hosted in a router) is routable from the
>source LMM even if it is in a different subnet right?  So as far as CT (and
>setting up a temporary tunnel) why do I care about crossing a subnet
>boundary?  I already stated that the neighboring LMM hosts will "know"
>about each other so their security associations are ideally pre-configured
>thus contributing no additive latency (also the assumption is they have
>routes to each other - something I have called "sidehaul" in a prior life).
>Sidehaul does add overhead, but only while the "backhaul" pipe is
>re-pointing itself at the destination LMM.
>

Basically, the MN comes up, gets an IP address on the local subnet.
When the MN moves across a subnet boundary, rather than getting
a new CoA, the AR on the old subnet sets up a bidirectional tunnel
with the new AR to forward packets for that IP address, which does
not change. This goes on for some period of time until, presumably,
the tunnels get too stretched and the MN abandons the old IP address
and gets a new one (at which time it had better not have an open
TCP connection).

This sounds alot like the UTRAN Iur interface, and the abandonment
of the old IP address is alot like SRNS relocation, but I don't
think it is mobile IP. 

			jak
			
PS: I do kind of like it, though.

---

From: James Kempf <[email-masked]>
Date: Thu, 26 Apr 2001 09:24:16 -0700 (PDT)

>Since this is an ENGINEERING organization I'd expect an argument for
>"do it this way because it is more optimal" would actually contain some
>engineering: example topologies, numbers showing signalling volume and
>signaling latency with and without an hierarchy.
>I frankly haven't seen any engineering rigor in any arguments for or against
>a hierarchy. (Thesis topic anyone?)
>
>Instead we are operating in a mode where some folks (including me)
>arguing that without hierarchy things are simpler and others arguing that
>hirarachy is more general and flexible.
>Neither argument has anything to do with ENGINEERING.
>

I think you are being unrealistic, Erik.

The fact of the matter is that the current HMIP proposal was made
a working group draft without any of the kind of hard evidence
you are asking for. It was made a working group draft because 
of the following:

	1) There were three individual draft proposals given at IETF 48.
	2) Two of them were similar, and they were combined.
	3) The other one was slightly more complex, and people had
	some questions at the meeting on it.
	4) The working group chairs asked for comments on the list
	about making the combined draft a working group draft and, since 
	nobody was paying attention at that time, there were none
	and the draft became a working group draft.
	
There was no discussion of requirements, and as we are seeing now,
there is wide disagreement about what the requirements are. There
was absolutely no studies of the kind you are asking for, nothing
anywhere near it.

I think it is unrealistic, and frankly unfair, to demand now that
people come up with detailed engineering studies during a post-hoc requirements
phase to justify a decision that was made on rather thin engineering
evidence in the first place.

If you want this kind of evidence, I suggest we drop working group
status for HMIP and make a concerted evidence to get it.

		jak
		
PS: With regards to arguments from topologies, etc., please see my
previous email giving an example of a particular deployment
situation where performance would suffer if there is no possiblity
to limit the number of full-BU-sending handovers.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 26 Apr 2001 19:35:40 +0200

> but did want to highlight an assumption I don't feel comfortable with.
	=> Maybe I can give some factual figures here to help. 
	If the delay over the air is 60-80 ms (80 being the worste case
	scenario) and routers are forwarding at wire speed, or let's 
	say there is a 1 ms delay per router. Is the fixed network
	delay still of any significance ? 

	Hesham

> > > [mobile-ip] Revised L 
> > > >	knows that this is true.> 
> > > >

---

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Thu, 26 Apr 2001 19:42:05 +0200

Hi James

> status for HMIP and make a concerted evidence to get it.

You are making a simple thing complicated. HMIPv6 provides the same basic
local home agent functionality as in Regional Registrations for
MIPv4. The same overall reasoning applies. Are you questioning the whole
hierarchical/regional work? What I actually understand from your email
above is that you'd prefer an item to be dropped rather than having it
if it does not support the requirement you have put forward. Why?

Also, I can't understand what HMIPv6 has to do with this. If you have
technical problems with HMIPv6 please bring them up. You definitely seem
to have something against it. You have already made these comments against
HMIPv6 and I replied to your email with the 4 reasons you have copied above.
As a side note, I see you've changed a few points: 3) went from a security
problem to "slightly more complex". I thought you had said you didn't
know what happened in this discussion, but now I'm confused.

Anyway, let's get back to the requirements discussion and not waste
our time on these issues.

> to limit the number of full-BU-sending handovers.

I think I've replied to this one. Why do you want to have an interconnect
ISP implement a _local_ MIPv6 agent? Doesn't seem to be the right place
to put a LMM. One LMM per cloud and handoffs between clouds are fine.
You won't handoff between ISP clouds continuously since a LMM is expected
to handle a significant area and number of MNs. It's a local HA after all.

Regards
/Karim

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 26 Apr 2001 21:45:10 +0200

Gopal, 

Great summary. Makes a lot of sense to me. 
Hopefully slow routing will not be fashionable :)

Hesham

> Advantages:
> 
> 1. Localizes  signalling (Localizing signalling does not mean reducing 
> signalling)  For localizing signalling one level of hierarchy is enough, if 
> we assume that the cost to send a message within a domain is the the same 
> irrespective of the nuber of routed hops.
> 
> 2. Could potentially reduce handoff delay. Handoff delay consists of two 
> components that are relavent to this discussion
> 1) transimssion delay  2) processing delay. Unless over a low speed link 
> transmission delay is not a major factor. Processing delay
> is what will hit you the most.  Multiple levels of hierarchy add to the 
> processing dealy and so could actually increase the handoff delay.
> 
> 3. Reduces the need to update the caches in the CN or change the VPN tunnel 
> endpoint. For this also one level of hierarchy is enough.
> 
> Disadvantages of LMMs or LMAs
> 
> 1. The amount of processing for the data path increases. Every data packet 
> has to traverse these hierarchies. so multiple levels of hierarchies are 
> not necessarly good.
> 
> 2. The points of failure increases. Increases in the levels of hierarchies 
> are not necessarly good.
> 
> So multiple levels of hierarchy may not be needed if the cost of 
> transmitting/packet is not affected significantly by the number of routed 
> hops it traverses (who knows one day slow routing might be back in fashion).
> 
> I am not against multiple hierarchies, if the simplicity of the solution is 
> not comprimised. I personally think it is very
> easy to have muliple levels of hierarchy (see 
> draft-dommety-mobileip-lma-ipv6-02.txt).
> 
> 
> 
> Thanks
> Gopal
> 
> 
> 
> 
> 
> 
> 
> 
> 
> At 02:46 PM 4/24/2001 -0700, James Kempf wrote:
> >Hi Hesham,
> >
> > >       2. Multi-level hierarchy localises the signalling. Let's try to> 
> >understand

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 26 Apr 2001 21:57:51 +0200

> Hesham >> The size of the domain is something that is not cast in stone. It is expressed as the
> Hesham >> growth in network infrastructure that maps to an individual ISP. The world expects
> Hesham >> that ISPs will grow larger in that sense by populating the routing fabring with more
> Hesham >> and more routing elements...
> Hesham >> 
> Hesham >	=> The size of a LMM domain (or MAP domain or GMA domain) is 
> Hesham >	restricted to how much traffic the top LMM agent can handle.
> Hesham >	This is orthogonal to how big an ISP is. There is no need 
> Hesham >	to assume that an ISP domain = LMM domain. Actually for a
> Hesham >	very large ISP this is probably not possible.
> Hesham >
> Hesham >> yes you "guessed" right....SCALABILITY...
> Hesham >> 
> Hesham >	=> Could you explain scalability of what ?
> Hesham >	It's certainly not the scalability of the amount of state
> Hesham >	kept in the routers.
> Hesham >
> Hesham >	Hesham
> 
> As I have experienced the scalability benefit of the LMM, it will allow
> scalability in the number of MNs moving within the domain through the
> reduced signaling.
> 
	=> That's not correct. The amount of signals sent by the MN is 
	exactly the same whether you have one level or more. Unless 
	you are referring to different signals.

	Hesham

---

From: James Kempf <[email-masked]>
Date: Thu, 26 Apr 2001 13:06:16 -0700 (PDT)

Hi Karim,

>if it does not support the requirement you have put forward. Why?

I'm questioning the process that went into blessing HMIP as 
a working group draft. It looks more like sausage making than
engineering to me. :-)

A requirements phase (which is what I interpreted PhilR's email of two weeks
ago to have started) is supposed to define what the protocol should
do, not provide an ex post facto justification for selecting
a particular protocol. As the name "local mobility management" should
imply, the point of the exercise is to gather requirements for
local mobility management, not for hierarchical or regional or
any other kind of solution to local mobility management, and especially
not for a particular protocol design. So if the working group is
not going to open up the protocol selection process again, there
is little point in going through a requirements discussion. We
should just rubber stamp HMIP and get on with our lives.

>know what happened in this discussion, but now I'm confused.

To the extent that HMIP statisfies the working group requirements
for localized mobility management, it is as good a solution as
any other. In my mind, it does not satisfy several important
requirements around reducing the frequency of handover related signalling 
latency in certain deployment situations, but I will most definitely
NOT go through these again, because I'm sure you or Hesham will
have some argument about why my concerns in this area are irrelevant,
and I feel we've wasted enough intercontinental bandwidth on these
issues. 

		jak

---

From: Phil Roberts <[email-masked]>
Date: Fri, 27 Apr 2001 14:51:50 -0400

We've been collecting them on the mailist list so far.  Here's a copy:

Seems like we're converging apart from the multiple levels of hierarchy
discussion.  Here's what has emerged:

1. LMM shall be introduced to minimize the signalling traffic to the home
agent or correspondent nodes for intradomain mobility.
(One comment - how constrained is "domain" here?  Certainly administrative
domain but can it be more constrained than that?  Didn't see any other
suggestions.)
2. LMM shall be secure from malicious behavior.
3. Connectivity to the mobiles should be minimized (MUST) or eliminated
(strive for this) in the presence of failure of LMM agents.
(A couple of comments is that this should be restated to be "in the presence
of topological changes" where failure of an LMM is a particular instance of
this.  There was some dissent on this alternative.)
4. LMM shall be compatible with fast handoffs.
5. LMM shall scale to support millions of nodes.
(Comment had been that this was too broad but only other suggestion was:
"LMM shall scale so that the number of LMM agents scale linearly or
sublinearly with the number of deployed subnets, not the number of mobiles."
Unless there is more support for the revision we'll stay with the original)
6. LMM shall not increase the number of messages between the MN and the LMM
agents.
7. Any additional header overhead caused by LMM should be eliminated by
compression and transfer of compressor state on movement should be possible
so as not to introduce any perceived service disruption.
(This depends on work in other groups (ROHC and Seamoby))
8. LMM shall not require changes to the HA and the CNs.
9. LMM should provide the same level of mobility management support as in
the basic MIPv6 spec.
10. LMM should support autoconfig.

Unless there is some strong objection to these they will be requirements.
We may or may not add one on multiple levels of hierarchy depending on the
other discussion.

Phil

> From: Karann Chew [mailto:[email-masked]]
> Sent: Friday, April 27, 2001 2:45 PM
> Subject: Re: Multiple Levels of LMM agents (was: RE: 
> [mobile-ip] Revised
> Could somebody please give me a pointer to the file/draft 
> which describes
> these "L ocalized Mobility Management Requirement s"?
> 
> Many thanks.
> 
> 	Karann
> 
> ++++++++++++++++++++++++++++++++++++++++++
> Karann Chew   
> Mobile Communications Research Group
> Centre for Communication Systems Research
> University of Surrey
> Guildford
> Surrey GU2 7XH
> United Kingdom
> Tel: +44 (0) 1483-879488
> Fax: +44 (0) 1483-876011
> ++++++++++++++++++++++++++++++++++++++++++
> 
> 
> On Thu, 26 Apr 2001, Phil Neumiller wrote:
> 
> > Arthur,
> > 
> > Please take a look at the OBAST paper at 
http://federalmobility.com/.  I think this
> will explain how to do this with CDMA macro-diversity selection.  The
paper
> describes a way to put macro-diversity into a BTS thus allowing BTSs,
SDUs,
> and RNCs to all be co-located at the edge of the network and function
peer-to
> peer.  What I have been describing in digestable chunks to the MIP list is
> essentially OBAST.  Others have called it MIPv6, some have called it
> MIPv4 fast handoff, but none of those address the CDMA issues (and
therefore
> 3G issues) that you have brought up, except for OBAST.
> 
> Thanks,
> 
> Phil
> 
> ----- Original Message -----
> From: "Arthur Ross" <[email-masked]>
> To: <[email-masked]>
> 
> 
> > The attachment points may be multiple and simultaneous, with
time-varying
> > performance that will exhibit high raw error rates. From a
comm-theoretic
> > standpoint, you will almost always do better in bad link conditions if
the
> > network can use whatever transceiver resources are available, i.e.
listen
> > from multiple transceivers & diversity combine them in the network;
> > transmit from multiple transceivers & diversity combine them in the MN.
> > This is what "soft handoff" in the CDMA air interfaces is all about.
> >
> > This leads to the need to distinguish between the addresses of the
access
> > transceivers (which may or may not be one-to-one with access routers),
and
> > physical radio comm link addresses (spreading code, or whatever). The
> > physical addresses may be MN-permanent, BTS-permanent, dynamically
> > assigned, or something as yet to be defined. That is a question in
itself.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 28 Apr 2001 22:45:35 +0200

Hi Tom, 

> > > There is little to argue against this clear benefit.
> > > This benefit, in the end, results in *better scalability* as Theo and
> > > others have already said.
> > >
> >         => Scalability of what ? How can you possibly claim that
> >         keeping more state in the network scales better ?
> >         Please explain this to me.
> > 
> >         Hesham
> 
> Could you elaborate with examples, what increased amount of state
> information are you referring to? State information per LMM entity?
> State information in the highest LMM agent? Routing state information
> (mobility bindings)?
> 
	=> I was referring to the amount of state on each level of the 
	hierarchy. If you have multiple levels agents, each level keeps 
	a certain amount of state (ie. Binding cache entries).
	The top level clearly keeps the most amount. Hence you end 
	up with a tree of agents and a number of single points 
	of failure that is equal to the number of levels in the hierarchy. 

	The lower agents in the hierarchy will clearly keep a subset
	of the entries in the top agent. This is true whether your
	hierarchy is hidden or visible to the MN. Hence, more 
	(unnecessary IMHO) state is kept within the domain
	resulting in more single points of failure. To make these
	agents redundant, the cost would also be N times 
	the cost of keeping one agent redundant. Where N is 
	the number of levels in a hierarchy.

> If we keep the number of MNs (k) within the domain as constant as well
> as the traffic numbers of useful and signaling data per MN, and only add
> LMM agents and levels into the hierarchy, then it seems to me that the
> amount of state information in the highest LMM agent is the same with 2
> levels than with Q (Q > 2) levels. Of course, the total amount of state
> information is higher in the deeper hierarchy, but what does it matter
> as long as the information is distributed? 
> 
	=> Actually the amount is duplicated. The lower agents 
	keep a subset of the amount of state in the top agent.
	It does matter, because you're introducing single points
	of failure. Hence a less robust network.

> In this scenario (k and other
> parameters being constants) the benefit of localized signaling in deeper
> hierarchies is still achieved compared to 2 level hierarchies.
> 
	=> The signalling is always local to a domain. Where
	you place the LMM agent is a matter of network engineering.

	Regards,
	Hesham