Subject: RE: [mobile-ip] LMM Requirements

From: [email-masked]
Date: Thu, 3 May 2001 12:23:50 -0500

Hello James,

>James wrote:
>Hi Raj,
-------cut--------
>>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? 
>>
>
>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.

>>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. 
>
>If it's in an idle or dormant state, then it doesn't have any outstanding
>CNs, right? 

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.

>It could get paged by a new one, but that's a whole
>other topic that Seamoby is dealing with.
>

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.  

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

>>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?
>>
>
>Sure, if there are alot of them.
>
>>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?
>>
>
>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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 03 May 2001 12:50:05 -0400

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?

--
Behcet