Subject: RE: [mobile-ip] LMM Requirements

From: Phil Roberts <[email-masked]>
Date: Tue, 1 May 2001 13:41:20 -0400

Hi, it's important that discussion of the requirements does take place on
the list so everyone is informed.

Phil

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 1:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mobile-ip] LMM Requirements
> 
> 
> We've asked Carl Williams to pull together the requirements 
> for LMM that
> have 
> been agreed upon here into an I-D with some explanatory text. 
>  Thanks to
> Carl for
> taking on this responsibility.  We hope to see them in an I-D 
> form in 2-3
> weeks.
> 
> If you would like to provide additional requirements, please 
> feel free to
> send them
> to Carl or to discuss them on the list.
> 
> We would also like some feedback on whether or how having a 
> particular draft
> on LMM
> as a working group item effects the requirements making 
> process.  Are there
> example requirements that might be considered if the HMIP 
> draft were not
> already in place as the working group draft? 
> 
> Basavaraj
> Phil
>

---

From: James Kempf <[email-masked]>
Date: Tue, 1 May 2001 13:27:21 -0700 (PDT)

Hi Raj,

>We would also like some feedback on whether or how having a particular draft
>on LMM
>as a working group item effects the requirements making process.  Are there
>example requirements that might be considered if the HMIP draft were not

Well, certainly the hierarchy requirement, which has been hotly debated,
might be already in place, or, at least, we might have some kind of
compromise language that reflected what the hierarchy requirement is
trying to get at, namely some way of improving signalling latency without
changing the externally visible care of address. The status of this
requirement is still up in the air, and one of the co-authors of
the working group draft has been the strongest opponent. Persumably,
there might be more flexibility shown were the draft not already
a working group item.

		jak

---

From: Phil Roberts <[email-masked]>
Date: Tue, 1 May 2001 16:47:46 -0400

The I-D repository is a little easier to use to find things.  There is
probably also some surrounding context needed and I didn't follow the
standards terminology of MUST, SHOULD, etc. so there is work that is to be
done.

> From: Behcet Sarikaya [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 4:53 PM
> Subject: Re: [mobile-ip] LMM Requirements
> 
> 
> But Phil you already posted the final form of the requirements in
> one of your earlier emails. One can always refer to that 
> online document.
> 
> Theo: I agree but please agree to it that it IS wishful thinking.
> 
> Phil Roberts wrote:
> 
> > The advantage in having an I-D that documents the 
> requirements is that you
> > can easily point to it rather than dragging a thread out of 
> the email
> > archives.
> 
> --behcet
>

---

From: [email-masked]
Date: Wed, 2 May 2001 09:18:32 -0500

Sorry James,

I do not understand what you mean. If we were to develop requirements
for HMIP, then we would probably not even have debated the issue of
multi-level hieararchy.. But since we are having plenty of discussion
on this topic, I do not believe the existence of the HMIP I-D as WG 
doc is limiting the vision on requirements for LMM.

> there might be more flexibility shown were the draft not already

From a requirements perspective, I believe we need to consider the need
for hierarchies. So from a status perspective, I would expect to see this 
requirement being in the requirements draft. 
The solution for the problem that meets these requirements may invalidate 
multi-level hieararchies or may provide solutions for scenarios that need
such
topologies.   
The current WG draft does not rule out hierarchies. So I think you should 
consider the arguments of the co-author as just a debate about the
requirement
(of course I should let the co-author speak for himself). 
Speculatively, I would expect that the co-author would have had the same
position even if the draft was not a WG document but rather a personal I-D
:)

-Basavaraj

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Wed, 2 May 2001 16:46:09 +0200

> (of course I should let the co-author speak for himself). 
	=> Exactly. At least from "this" co-author's point of view
	this is what we've been doing. I don't see how having the 
	draft as a WG draft has anything to do with what I
	think about the requirement. 

	HMIPv6 _will_meet the requirements being discussed
	if the WG agrees on them. The point is we (the WG) clearly 
	haven't converged one way or the other. So I'm not 
	sure that this requirement is representing the WG. 
	This is my opinion and having HMIPv6 as a WG item
	has nothing to do with it.

> position even if the draft was not a WG document but rather a personal I-D
	=> Agreed. At least if that co-author is me :)

	Hesham

---

From: James Kempf <[email-masked]>
Date: Wed, 2 May 2001 07:49:47 -0700 (PDT)

Hi Raj,

I misinterpreted your question. I thought you were asking how the
existence of a working group draft affects the requirements discussion.
My point is that if there is already a working group draft without
a preexisting requirements discussion, then it will tend to reflect
the requirements of the authors, not the working group. So the authors
will tend to argue against any requirements that the working group
brings up, just as they would if a free requirements discussion 
were made prior to the draft. But, since the draft has working group
status, it becomes harder for the working group to make changes because
one has to convince the authors rather than achieve working group
concensus. My impression is that has been the case with the hierarchy
requirement in the current situation. Does that make sense?

		jak

>From: [email-masked]
>Cc: [email-masked], [email-masked]
>Subject: RE: [mobile-ip] LMM Requirements
>Date: Wed, 2 May 2001 09:18:32 -0500 
>
>
>Sorry James,
>

---

From: [email-masked]
Date: Thu, 3 May 2001 11:33:23 -0500

James,

I hope Carl has noted the functional requirement. I can live with
that. Some thoughts though below:

>James wrote:
----cut------------
>
>Actually, no. I much prefer a set of functional requirements as opposed to
>a structural one. Something like:
>
>	The protocol shall support the ability to optimize local signalling
>	paths without changing the externally visible CoA so as to reduce
>	or eliminate frequent end to end BU signalling in cases where
network 
>	engineering or administrative/deployment considerations require
>	small LMM domains.
>

The key problem to be solved with LMM is to reduce the end-to-end BU
signaling caused by change in COA. You cannot avoid doing e2e BUs in
certain cases. So if you have very small LMM domains for reasons that
you state, you will see a lot more BUs to CNs. How big a concern is
that? If a MN and CN have an active data session ongoing, the change
in COA is notified to the CN via a BU in one of the data packets (part
of the active session stream). So there is no real overhead involved
in sending that BU. And there is no urgency to get that BU to the CN
either as the fast HO mechanism should ensure that packets sent to the
pevious COA continue to reach the MN at it's new COA. So if the MN has
active sessions with 'n' CNs, the BUs to all 'n' CNs is carried as
part of the traffic. The only overhead is the BU DO carried in a few
packets. But do we really need to optimize that? 

If the MN is an idle/dormant state and changes it's COA, and as a
result has to notify 'n' number of CNs about the new COA, then it's an
overhead. Ideally (just a thought) a MN should send a binding
cancellation to the CN at the end of an active session and remove it
from it's binding cache. That way the MN would not have to send BUs to
CNs, but just to it's HA. And that's probably not a big deal even if
it has to traverse long undersea cables. It can be a concern if you
have a very large number of MNs changing COAs rapidly and as a result
generating a lot of signaling (BUs) to their espective HAs. That's
where an LMM agent would probably help.

I view the sending BUs to all CNs in an MNs cache as a bigger concern
than sending BUs to an MNs HA. Does that make sense?

But trying to reduce the signaling paths within the local domain? I do
not see much benefit here. Can you elaborate on your view on trying to
limit the signaling path in an LMM environment? Do you really see
strong reasons for doing so?

>	The protocol shall support optimal placement of LMM agents to
>	reduce or elminate additional triangle routing introduced by
>	LMM.
>	
>These leave open exactly how to achieve the required functionality.
>Hierarchy is one way, another way that might work is using edge
>tunnels as PhilN has suggested. There may even be ways to modify
>HMIP to achieve these requirements. 
>
>		jak

-Basavaraj

---

From: James Kempf <[email-masked]>
Date: Thu, 3 May 2001 10:30:52 -0700 (PDT)

Hi Raj,

>
>Not necessarily. Current spec does not require a MN to delete an entry
>from it's binding cache explicitly. So you could have entries for CNs
>in the MNs cache which have not timed out yet when the MN goes into
>a dormant mode; If the MN changes it's COA in the dormant mode, the MN
>would start sending BUs to CNs in it's cache that have not timed out.
>

I don't want to get into a detailed discussion of paging here,
but one of the requirements with the paging DT in Seamoby is
that the MN notify the network when it goes into dormant mode.
The paging protocol is not specific to MIP, but the consequences
of this for MIP would be that the MN send BUs to the CNs to
have them delete their binding cache entries. 

>But if it is being paged, it is an indication to establish a session
>(possibly) and the MN would send a BU once a session is active.  
>

Well, I would imagine for MIP that a page would cause the MN to
reestablish a CoA with it's local AR, then register with HA
at which point it would get the packet that triggered the page.

But this is very MIP specific, and we are not there yet in the
paging DT discussions.

		jak

---

From: Carl Williams <[email-masked]>
Date: Thu, 3 May 2001 10:24:31 -0700 (PDT)

James,

  I will structure the requirements as you suggested.  I am reading
  over the discussions now as well as Phil's start of things.
  
 Carl

X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to 
[email-masked] using -f
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: [mobile-ip] LMM Requirements
Date: Thu, 3 May 2001 11:33:23 -0500 
MIME-Version: 1.0
List-Archive: <http://playground.sun.com/mobile-ip/>
List-Owner: <mailto:[email-masked]>
List-Subscribe: <mailto:[email-masked]?body=subscribe>
List-Unsubscribe: 
<mailto:[email-masked]?body=unsubscribe>

James,

----cut------------
network 

-Basavaraj

---

From: Phil Roberts <[email-masked]>
Date: Thu, 3 May 2001 14:51:09 -0400

Wrong answer for the time being.  We've made an effort to focus MIP issues
on issues pertaining to MIP.

> Sent: Thursday, May 03, 2001 12:50 PM
> Here is a strange discussion.
> Once Alessio said paging is basically routing related therefore paging
> standardization should move to the routing area, i.e. under 
> Mobile IP WG.
> 
> Wouldn't you agree with it?
> 
> [email-masked] wrote:
> 
> > Hello James,
> >
> > >James wrote:
> > >Hi Raj,
> > >
> > -------cut--------
> > >>If a MN and CN have an active data session ongoing, the change
> > >This sounds like an argument against *any* LMM mechanism, or, at
> > >least, any mechanism that involves an agent back in the network
> > >like HMIP or RegReg.
> > >
> >
> > Exactly. Just trying to rationalize the need for LMM.
> >
> > >Actually, I tend to agree with you. By using edge or mesh 
> tunnels, you
> > really
> > >don't need an LMM mechanism like HMIP or RegReg. With low latency
> > >handoff, you can use a mesh tunnel to foward packets from 
> the oAR to
> > >smooth until the BU in the new packets takes effect. You can even
> > >defer CoA change if the MN makes a quick switch to another subnet
> > >or ping-pongs back to the original subnet.
> > >
> > >This is one reason why I'd like to see the protocol selection
> > >opened up again.
> > >
> >
> > Is protocol selection the only way? Let's get the requirements done
> > and then look at what the optimal solution is. Do not let 
> an existing
> > WG document limit your views on requirements and possible solutions.
> >
> > >>overhead.
> > >If it's in an idle or dormant state, then it doesn't have 
> any outstanding
> > >CNs, right?
> >
> > >It could get paged by a new one, but that's a whole
> > >other topic that Seamoby is dealing with.
> > >
> >
> > >>Ideally (just a thought) a MN should send a binding
> > >Well, with mesh tunnels, the MN simply wouldn't change 
> it's CoA until
> > >its movement settled down or it didn't have an active connection up
> > >(and hence had only to signal the HA of the CoA change).
> > >
> >
> > That's one way. But not necessarily true in all types of networks.
> >
> > >I realize I'm now arguing for a particular solution, but the point
> > >I'm trying to make is that the LMM solutions up until now were
> > >designed with a particular viewpoint in mind that other solutions
> > >that have been since proposed don't have.
> > >
> >
> > Let's just step back and discuss requirements.
> >
> > >Sure, if there are alot of them.
> > >
> > >See my business model argument above. One can argue about how
> > >common it may be, of course.
> > >
> >
> > I would prefer to not get into business model arguments on this iEtf
> > list. We can take that offline.
> >
> > >               jak
> >
> > -Basavaraj
> 
> --
> Behcet
>

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 3 May 2001 21:50:14 +0200

James,

> The problem is, as I mentioned in my response to Juergin, that there
> are certain business models that would be harmed from not optimizing signalling
> when LMM domains are small. Suppose there are multiple small wireless
> providers in an area, and they all want to do optimized signalling
> in their domain, but they are peering with a larger ISP who would
> like to set up an LMM domain to allow customers of the smaller providers
> to switch LMM domains without requiring any global CoA signalling
> change. If the protocol doesn't support this, then it becomes difficult.
> 
	=> This can also be done if you place the LMM in the 
	interconnecting ISP. Obviously the same amount of state
	is kept regardless.

	Hesham

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 7 May 2001 15:32:35 -0500

Raj,

In regards to this, I believe it might be better to make them both
sentences. 

"
1. Is support for multilevel hierarchies a requirement for LMM?
2. A single level of hierarchy is sufficient as the requirements for
LMM can be met by engineering the network right.
"