Subject: RE: [mobile-ip] LMM Requirements

From: James Kempf <[email-masked]>
Date: Thu, 3 May 2001 09:59:18 -0700 (PDT)

Hi Raj,

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

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.

I just don't think it is a good idea to design a protocol with restrictions
about what network engineering would be required to efficiently support
it. The protocol should be designed with reasonable restrictions on
network engineering.

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

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. 

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

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.

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

		jak

---

From: Arthur Ross <[email-masked]>
Date: Thu, 3 May 2001 10:47:09 -0700

>it. The protocol should be designed with reasonable restrictions on
YES! Very important point.

>[snip]
Throughout this debate it has seemed to me that the underlying
architectural abstractions, business, and regulatory models are, to be
charitable, a bit fuzzy ... many different, implicit, unstated mental
views. I realize I'm back at one of those heated exchanges from some weeks
back, but I still believe that these abstractions and models should be
addressed FIRST (more?).

I tend to believe that when the abstractions and the problem are properly
stated, the solution(s) will come rather easily. It's the unstated
(unconcious?) differences in model that underlie a lot of this
fractiousness.

>common it may be, of course.
Some of the LMM motivation has more to do with radio-ish issues than with
signaling load ... like knowledge of where the MN might be, acquired
through means other than network signaling. Comes back to the fact that
wireless connectivity is "soft", with amelioration methods that are best
distributed over the access points.

... and to come back to a point I tried long ago to make to the FCC
regarding true spectrum sharing and cooperation, a la James' business model
point - sometimes the laws of physics FORCE cooperation among service
providers, regardless of what their attorneys, management, and business
models would suggest, as in the real-world example of all those cellular &
PCS calls from Manhattan high-rises that wind up being served by cell sites
in New Jersey and Connecticut, sometimes many miles away; makes for
interesting administrative problems, as well as technical ones.

   -- ahmr

   Dr. Arthur H. M. Ross
   1004 Cottage Way
   Encinitas, CA 92024-5857
   Tel: 760-634-8173 (Res.)
        602-677-1021 (Portable)