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

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 2 May 2001 00:11:39 +0200

>         => 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. 
> 
> 	[MJ]  I know that fast handoff solution is built around that assumption, and I am questioning that very basic assumption. I am saying that it is LMM solution's forte to decide whether handing over to new AR should involve new address assignment, especially within an AD. Hence, fast handoff solution should be flexible in handling this situation. The question is why fast handoff always assume change of address?
> 
	=> Well That's what MIP does. MIP manages the change in CoA.

> 	Now, instead of always assuming new address assignment it can provide in its signaling following options: 
> 
> 	1. No new address assignment 
> 2. Autoconfiguration, hence asking new AR to run DAD on behalf of MN 
> 3. Stateful address assignment 
> 
> 	This will make fast handoff solution quite flexible and capable of being defacto standard handover signaling for any LMM. 
> 
	=> I think it already works with LMM. Both scenarios 
	in the Fast Handoff draft can work with an LMM solution.
	At least with HMIPv6 I don't see any problem. Based on this 
	requirement we were going to add a section in the draft 
	to show that this interworking is possible. But I'm not 
	sure what the aim of fixing the address is. Anyway, my 
	point is if you're saying this to make it easier for FH to 
	work with LMM, I think both cases would work whether 
	the address changes or not.

> Although, I am making this statement but with one caveat that I don't know how fast handoff and CT will work together. I think this discussion should be moved to fast handoff design team mailing list, but my understanding is that it is closed. 
> 
	=> I think we can discuss it on this list. The design team's 
	list hasn't been used for a long time now.

> BTW, Hesham how did you get this 99.99% reliability number, through some simulation?
> 
	=> No, I was trying to explain that it is a very rare probability that 
	a collision would occur considering the 2^64 different IDs in IPv6 in case
	a random number was used or the probability of an L2 device vendor 
	to reuse the same MAC address. Just making a point, I hope no one 
	starts a simulation on this one too ;)

	Hesham

> 	        Hesham

---

From: "Bill Gage" <[email-masked]>
Date: Wed, 2 May 2001 10:59:22 -0400

>
>
>-----Original Message-----
>From: Phil Roberts [  <mailto:[email-masked]>
mailto:[email-masked]]
>Sent: April 25, 2001 10:37 AM
>Subject: [mobile-ip] Final(?) Cut on LMM Requirements
>
>
>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.)
>
[wg>] I believe it should be an administrative domain. The rationale behind
this is so that we can assume some sort of trust relationship between
elements of the domain and avoid going down ratholes associated with AAA
issues when moving between access points. Issues associated with domains
that cover wide geographical areas should be covered by scalability
requirements.

>
>2. LMM shall be secure from malicious behavior.
>
[wg>] I assume you mean malicious behaviour by entities outside the
(visited) administrative domain (i.e. MN, CN, HA) on the assumption that
entities inside the AD either trust each other or have their own
intra-network security mechanisms.

>
>3. Connectivity to the mobiles should be minimized (MUST) or
>eliminated(strive for this) in the presence of failure of LMM
>agents.
>
[wg>] I assume this is a Freudian slip and should be "disruption to
connectivity" ...

>(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.)
>
[wg>] I prefer the alternate wording. The original wording only deals with
failure of the LMM agents but there may be other network failures that
disrupt the communications between a MN and LMM agents.

>
>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)
>
[wg>] I prefer the alternate wording -- it avoids arguments like "of course
it will support a million nodes ... you just have to add 5 gig of memory to
every routing table".

>
>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))
>
[wg>] I don't like this linkage of LMM to areas beyond its scope (i.e.
header compression, context transfer). I suggest that it be replaced by
something more stringent (e.g. "LMM protocols will not add additional header
overhead to messages between the MN and LMM agents.")

>
>8. LMM shall not require changes to the HA and the CNs.
>
[wg>] Like others have said, MUST not.

>9. LMM should provide the same level of mobility management support
>as in the basic MIPv6 spec.
>
[wg>] What does this mean?

>
>10. LMM should support autoconfig.
>
[wg>] Autoconfig of what? Does this include auto reconfiguration of DNS
servers, gateway routers, subnet masks, applications servers, etc. etc.

Cheers ...

---

From: Phil Roberts <[email-masked]>
Date: Wed, 2 May 2001 11:00:16 -0400

[Phil Roberts] Hah!  Well, the stated requirement *is* much easier to meet.
The challenge is how to do it elegantly, wouldn't you say?

---

From: "Muhammad Jaseemuddin" <[email-masked]>
Date: Wed, 2 May 2001 15:14:18 -0400

Hi Charlie:

> From:	Charles E. Perkins [SMTP:[email-masked]]
> Sent:	Monday, April 30, 2001 12:30 PM
> To:	[email-masked]
> Subject:	Re: [mobile-ip] Final(?) Cut on LMM Requirements
> 
> Hello Muhammad,
> 
> You suggest that the fast handover draft for Mobile IPv6
> should either de-emphasize, or eliminate entirely, the
> mechanism for assignment of a new care-of address at the
> new access router's network.  I have two observations about
> this.
> 
	[MJ]  I did not mean to eliminate entirely, and I wouldn't even call
my proposal de-emphasizing. Rather my suggestion is to make fast handover
more flexible to inter-work with any LMM solution.

> 1) Mobile IP deals with binding a care-of address to
>    a home address, and tunnel management.  A protocol
>    for which the node's care-of address is not relevant
>    does not necessarily have to be developed within
>    the mobile-ip working group.
> 
	[MJ]  I am not suggesting to develop any such solution here. This
argument needs to be revisited in the new situation where LMM is being
discussed as a solution for especially within an administrative domain. I
think that we should provide more flexiblity to an operator to deploy a
solution of its choice. Hence, fast handover that involves end-systems (MN
and potentially CN and HA) should not assume that LMM always require change
of address. In this way it becomes a standard handover signaling while
potentially protecting LMM to involve these end systems. As I mentioned
previously the fast handover should work both with LMM and also in the
absence of LMM with Mobile IP. Currently it is working fine with the later,
but by adding this little change in fast handover make it very flexible to
work with any LMM solution. Now, I make out after reading requirement 1 and
9 that LMM solution is only for intra-domain and must interwork with Mobile
IP for interdomain. So, by allowing fast handover to also include this
option of not acquiring new address during handover does not break
interworking with Mobile IP.

	Currently, fast handover allows use of old COA in different
situations, e.g. in the absence of not receiving Fast Binding Ack. There is
another place where it allows use of old COA, but its not clear in which
situation. Let me quote from the draft:

	Page 15: Description (of Proxy Router Advertisement)

	...
	A Proxy Router Advertisement with Code 1 is sent if handover to the
New Attachment Point, as indicated by the New Attachment Point Link Layer
address in the corresponding RtSolPr message, does not require change of
COA.
	...

	I am not sure if that was intended to provide the option I talked
about, but then it is missing from the rest of the design.

> 2) The care-of address is used for routing.  If the routing
>    changes, but the care-of address does not change, then
>    more host routes are needed to handle the exceptional
>    nature of routing to a care-of address on the "wrong"
>    access network.
> 
	[MJ]   You are right. I refrain from discussing any such solution
because my understanding is that it is outside the scope of Mobile IP WG.

> Of course, these arguments are not absolute in nature.  They
> only serve to provide design guidelines.  You can make packets
> arrive at a mobile node in quite a few different ways.  It's
> an engineering decision about whether to disseminate more, or
> fewer, host routes to accomplish the job.
> 
	[MJ]  With the current decomposition of problem space - Mobile IP +
LMM + Fast Handover - perhaps we should make different engineering decisions
for different spaces. It does not mean that I am intended to disrupt the LMM
work here. The LMM solution within Mobile IP WG is constrained by using
Mobile IP tunneling mechanism.

>  Regards,
> Charlie P.
	[MJ]  I am working on minimal changes in fast handover and will
submit to the group soon for consideration, which will hopefully be
acceptable to the design team and the WG.

	Regards,

	- Muhammad Jaseemuddin

> > Muhammad Jaseemuddin wrote:
> > 
> > Hesham:
> > 
> >      From:   Hesham Soliman (ERA) [SMTP:[email-masked]]
> >      Sent:   Thursday, April 26, 2001 4:08 PM
> >      To:     [email-masked]'
> >      Subject:        RE: [mobile-ip] Final(?) Cut on LMM Requirements
> > 
> >              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.
> >      [MJ]  I know that fast handoff solution is built around that
> assumption,
> >      and I am questioning that very basic assumption. I am saying that
> it is
> >      LMM solution's forte to decide whether handing over to new AR
> should
> >      involve new address assignment, especially within an AD. Hence,
> fast
> >      handoff solution should be flexible in handling this situation. The
> >      question is why fast handoff always assume change of address? It
> can
> >      easily provide this flexibility that if an address change is
> required
> >      then it would happen. Let us look the jobs being done by fast
> handoff:
> > 
> >      1. It signals new AR about imminent handover
> >      2. It arranges new address assignment at the new AR (either
> >      autoconfiguration or stateful)
> >      3. It established temporary tunnel to forward in-flight packets
> > 
> >      Now, instead of always assuming new address assignment it can
> provide in
> >      its signaling following options:
> > 
> >      This will make fast handoff solution quite flexible and capable of
> being
> >      defacto standard handover signaling for any LMM. Although, I am
> making
> >      this statement but with one caveat that I don't know how fast
> handoff and
> >      CT will work together. I think this discussion should be moved to
> fast
> >      handoff design team mailing list, but my understanding is that it
> is
> >      closed. BTW, Hesham how did you get this 99.99% reliability number,
> >      through some simulation?
> > 
> >      Cheers,
> >      - Muhammad Jaseemuddin
> > 
> >              Hesham

---

From: "Muhammad Jaseemuddin" <[email-masked]>
Date: Thu, 3 May 2001 10:44:09 -0400

> Sent:	Tuesday, May 01, 2001 6:12 PM
> assumption, and I am questioning that very basic assumption. I am saying
> that it is LMM solution's forte to decide whether handing over to new AR
> should involve new address assignment, especially within an AD. Hence,
> fast handoff solution should be flexible in handling this situation. The
> question is why fast handoff always assume change of address?
> > 
	[MJ]  Which COA? If LMM is deployed then MIP will manage RCOA not
LCOA (I am using HMIP jargon). Hence, within an LMM domain no address
assignment by FH doesn't mean that there is an FH-MIP interworking problem.
	 
> provide in its signaling following options: 
> > 
> being defacto standard handover signaling for any LMM. 
> > 
	[MJ]  Indeed it works with HMIPv6 if that is the only conceivable
LMM solution we can think of. HMIPv6 requires MN to register LCOA, hence the
MN has to first get LCOA and FH facilitate that process. But, if an LMM does
not require MN to register a new LCOA, then FH doesn't work in that
situation. Please read my comments to Charlie's email. I beleive that with
small changes in FH will make it flexible enough to interwork with a variety
of different LMM solutions.

> > Although, I am making this statement but with one caveat that I don't
> know how fast handoff and CT will work together. I think this discussion
> should be moved to fast handoff design team mailing list, but my
> understanding is that it is closed. 
> > 
	[MJ]  I hop so too.

	- Muhammad Jaseemuddin