Subject: Re: [mobile-ip] Final(?) Cut on LMM Requirements

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 25 Apr 2001 13:10:51 -0700 (PDT)

> Seems like we're converging apart from the multiple levels of hierarchy

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

I am not  sure if the above requirement means that one LMM shall scale to
support millions of nodes. Or does it mean that LMM could be a cluster of
agent nodes distributing the loads among themselves ?

If LMM  means one node, then I would say 'million nodes' is a strong requirement
or it's inherently assuming multi-level hierarchy :)

I think we need to have a requirement for scalability or load distribution
among the hierarchical mobility agents.

> 8. LMM shall not require changes to the HA and the CNs.

Is this requirement a "must"  or should ?  I agree that no changes
for CN, but are we sure that there can't be any change in HA also 
in the future ? I can't think of any example of the top my head right
now, but wonder, if that is a safe assumption in case we might need
some change in HA to support certain features in LMM (MAP or GMA).

Thanks,
-Samita

---

From: "Muhammad Jaseemuddin" <[email-masked]>
Date: Thu, 26 Apr 2001 10:11:27 -0400

> -----Original Message-----
> From:	James Kempf [SMTP:[email-masked]]
> Sent:	Wednesday, April 25, 2001 4:15 PM
> To:	[email-masked]; [email-masked]
> Cc:	[email-masked]
> Subject:	Re: [mobile-ip] Final(?) Cut on LMM Requirements
> 
> >
> IHMO, this requirement is a MUST. 
> 
> 		jak
> 
	[MJ]  I also think that this requirement is a MUST. LMM is a
solution deployed most likely in an access network, which should not have
any global implication. As a matter of fact in my view this should even be
transparent to MNs. What LMM is supposed to do is to do mobility aware
routing within the domain. It should be decoupled from signaling. Mobile IP
and fast handover should be the two signaling a MN should be aware of and
deal with. Former is for gloabl mobility and the later for local mobility.
End nodes should not dictate which routing solution is deployed within the
network.  This is just my 0.02 cents view. There is no need to discuss
involving MN thread again I guess it was discussed previously.

	- Muhammad Jaseemuddin

---

From: "Muhammad Jaseemuddin" <[email-masked]>
Date: Thu, 26 Apr 2001 10:26:13 -0400

Phil:

> From:	Phil Roberts [SMTP:[email-masked]]
> Sent:	Wednesday, April 25, 2001 10:37 AM
> To:	[email-masked]'
> Subject:	[mobile-ip] Final(?) Cut on LMM Requirements
> 
> 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.
	[MJ]  I agree that it shall be compatible with fast handoff, because
as I posted earlier to me fast handoff provides standard handover signaling
(and solution of course). But we also had a discussion that fast handoff
should also comply with relevant LMM requirements, because its a three tier
solution space we are discussing - Mobile IP then LMM then Fast Handoff. In
this regard I had suggested that fast handoff should not always assume
change of IP address from LMM perspective. Although it might happen that the
LMM solution evolved always does that, but fast handoff signaling should
provide at least the provision otherwise. And if the WG feel comfortable
with that then it should be captured in LMM requriement. I haven't seen any
objection to my previous posting. Or do you think that this issue I should
discuss with the fast handoff design team? Any idea?

> 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))
> 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
> 
	- Muhammad Jaseemuddin

---

From: Phil Roberts <[email-masked]>
Date: Thu, 26 Apr 2001 10:36:18 -0400

4. LMM shall be compatible with fast handoffs. 
[MJ]  I agree that it shall be compatible with fast handoff, because as I
posted earlier to me fast handoff provides standard handover signaling (and
solution of course). But we also had a discussion that fast handoff should
also comply with relevant LMM requirements, because its a three tier
solution space we are discussing - Mobile IP then LMM then Fast Handoff. In
this regard I had suggested that fast handoff should not always assume
change of IP address from LMM perspective. Although it might happen that the
LMM solution evolved always does that, but fast handoff signaling should
provide at least the provision otherwise. And if the WG feel comfortable
with that then it should be captured in LMM requriement. I haven't seen any
objection to my previous posting. Or do you think that this issue I should
discuss with the fast handoff design team? Any idea?

	- Muhammad Jaseemuddin 
[Phil Roberts] 

	I didn't see any response to your post.  Personally speaking I
really don't want these two proposals coupled in any way.  It makes sense to
make sure they are compatible (you can use them at the same time) but it
does not make sense that they should have dependencies on each other.  It
seems reasonable to me that some networks with fast handover enabled will
see little if any need for LMM support.

---

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

> agent nodes distributing the loads among themselves ?
	=> I think one LMM will scale to however many nodes it 
	can support physically. If that number is 10 then it will 
	be 10, if it's a million then be it. I hope people understand
	that the number of levels is completely irrelevant here. 
	The top LMM will ALWAYS keep ALL states regardless
	of how mny levels are below it. 

	Having said that I like your proposal about having more
	than one node serving on the same level. This allows 
	the LMM nodes to share the load. This is exactly 
	what we had in mind for HMIPv6.

> If LMM  means one node, then I would say 'million nodes' is a strong requirement
	=> Well I just think a number is meaningless. 
	But to be honest I can't articulate a god scalability requirement
	right now. 

> among the hierarchical mobility agents.
	=> Agreed. A protocol scalability requiremet.

> some change in HA to support certain features in LMM (MAP or GMA).
	=> Agreed. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 26 Apr 2001 22:23:38 +0200

Hi Phil, 

	Looks good. Just a couple of questions to help understand the last
	requirment.

> 10. LMM should support autoconfig.
	=> I don't understand this one. Autoconfig for the LMM agent ?
	which parameters are we referring to ?

	Thanks,
	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 26 Apr 2001 22:08:04 +0200

Muhammad,

> [MJ]  I agree that it shall be compatible with fast handoff, because as I posted earlier to me fast handoff provides standard handover signaling (and solution of course). But we also had a discussion that fast handoff should also comply with relevant LMM requirements, because its a three tier solution space we are discussing - Mobile IP then LMM then Fast Handoff. In this regard I had suggested that fast handoff should not always assume change of IP address from LMM perspective. Although it might happen that the LMM solution evolved always does that, but fast handoff signaling should provide at least the provision otherwise. And if the WG feel comfortable with that then it should be captured in LMM requriement. I haven't seen any objection to my previous posting. Or do you think that this issue I should discuss with the fast handoff design team? Any idea?
> 
	=> I don't really undersand your suggestion to not change the CoA. 
	The Fast Handoff draft is built around the fact that the MN will 
	change its CoA. There is one case where that fails (DAD for the 
	new CoA) and the MN keeps the same address. But this is 
	an error case and 99.99 % of the time it won't happen. 

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 26 Apr 2001 22:08:04 +0200

Muhammad,

	Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Fri, 27 Apr 2001 14:37:50 -0500

I'm not sure if fast handoff has delved into all of the requirements from an
inter-system perspective.

-----Original Message-----
From: Phil Roberts [mailto:[email-masked]]
Sent: Thursday, April 26, 2001 9:36 AM
To: [email-masked]'
Subject: RE: [mobile-ip] Final(?) Cut on LMM Requirements

	- Muhammad Jaseemuddin 
[Phil Roberts]