Subject: Re: [Seamoby] Examples of CAR discovery

From: "Govind Krishnamurthi" <[email-masked]>
Date: Tue, 26 Mar 2002 13:16:03 -0500

James,

>We seem not to be connecting.

[Govind] I agree and thats what makes any technical discussion interesting 
:)
> >
> > >
> > >The only place where I can see CAR discovery involved for a single
> > >technology handover is for reverse address translation, as in
>Eunsoo's
> > >note.
> > >
> >
> > [Govind] That CAR discovery is needed for reverse translation is quite
> > obvious from requirement 1 of the current requirement draft. I thought
> > that was the main idea behind the requirement. Anyways, my previous
> > mail was saying this too.
> >
>
>OK.

[Govind] We agree. Good!
>
> > [Govind] I agree that the MN *must* be involved too. The main
>disconnect
> > between us is that you assume that the MN has no role whatsoever
> > if the handover is network controlled. Clearly, the handover can be
> > controlled by the network, i.e., tell the MN when to disconnect etc
>but
> > still take into account all of the MN's preferences. I don't
>understand
> > why we are having to get this point across too!
>
>So here is the basic disagreement:
>
>I don't see the point in a complicated protocol for the MN to "express
>its preferences" to the AR, when the
>AR can just hand over the CAR information to the MN and let the MN
>choose.

[Govind] First, I don't think that it is a "complicated" protocol
as you suggest. As I pointed out it could just be part of the MN's profile. 
Second, pushing capabilities down to the MN for its decision
has power,bandwidth and time considerations which one may want to consider. 
Again, I am not saying that what you say is not an option. But
saying that the MN MUST be the only one deciding the TAR restricts
the field totally which I think is rather pre-mature.

>
> >Regarding the MN
> > only knowing which interfaces are powered on. What big difference does
> > this make?
>
>It makes a big difference! If the interface isn't powered on and the AR
>says to the MN "handover to that interface," the MN has just lost
>network connectivity. Don't you agree?

[Govind] I don't understand, how a "working" TAR selection algorithm which 
has MN reachability information as one input will allow this to happen.

>
> >If the network knows what interfaces the MN has then it can
> > advise it to power on at the appropriate time. If it is already
>powered
> > on the MN just discards this. If not it acts on it. If the card is not
> > inserted then it just discards the message too. What is the difficulty
> > that you see here. Maybe you can explain it.
> >
>

>Please explain to me why you want to do all this complex signaling
>between the network and the MN, when all
>that is required is to simply send the MN the list of CARs and have it
>do the selecting? What does all this
>complexity buy us?

[Govind] First, I disagree that this is complex. All it requires is
match what APs are available in the neighborhood to what the MN has.
What does this buy us as against pushing everything to the MN: saving power 
for the MN. Saving wireless bandwidth is another. But again, the main 
disconnect between you and me is not
disagreeing with what you propose as the solution but your seeming 
disagreement with any other option.
BTW, aren't we transgressing a bit
too much into solution and TAR selection phase. So I propose that we
have this discussion at a later stage, because we are going to have it
then again :)

>
>If we accept your proposal, then we are not just doing a CAR discovery
>protocol but also a protocol for having the MN tell the network what
>interfaces it has and what their current state is.
[Govind] But unless the CAR discovery protocol knows what the requirements 
for the MN are how does it decide what the CARs for the MN
are? If you read the definition of CAR it says GAARs whose capabilities
can satisfy the MN's requirements As I said, telling the MN's interface 
states is not necessary at all.

This is just too
>complicated. The MN knows this stuff, given the right information, it
>can act on it accordingly without having to get the network involved. I
>simply don't see what adding this level of complexity buys us.

[Govind] See above.

>I'm not saying it is infeasible, I'm saying that a rational engineering
>tradeoff between a complex protocol involving signaling MN interface
>state and one letting the MN simply make the choice itself seems, to me
>at least, to go in the direction of the latter.

[Govind] Again without accepting that complexity of the protocol is very
high :), we should also make sure what effect this decision has on the MN 
w.r.t to power and bandwidth.
>
>Can you explain to me what, exactly, sending the MN's interface state
>around buys us that we don't get by simply sending the CAR information
>to the MN and letting it make the choice?

[Govind] See above.

> >
> > >The AAA exchange also might not be accurate. Suppose the MN is a
>laptop
> > >and the user forgot that day to put in their WLAN card. The AAA
>record
> > >might say that the MN's got WLAN, but, in fact, it doesn't. So the AR
> > >could hand the MN over to a medium which the MN can't access.
> >
> > [Govind] I thought reachability information *from the MN *is part of
>TAR
> > selection process. If the MN's WLAN card is not inserted, how do you
> > suppose reachability for WLAN APs are got from the MN. So why do you
>think
> > the network will blindly just handover the MN to a WLAN network?
> >
>
>I don't understand your comment. If the WLAN card isn't in, the MN isn't
>going to initiate a MIP handover to an interface that is not there.
>Thus, if the MN is in control of an intertechnology handover, it won't
>disconnect.
>However, if the AR is in control of an intertechnology handover, how is
>it supposed to know that the card isn't there?

[Govind] No one is arguing that the reachbility information from the MN to 
APs is NOT an integral part of the TAR selection process.  Once this 
reachability information there it does not matter whether the TAR selection 
process resides in the network or the MN as far as your issue
is concerned.

>
>From your comments above, I surmise you would like to see CAR discovery
>include a protocol for communicating the MN's current interface state:
>whether the card is there, whether it is powered on, etc., to the AR.

[Govind] Nope I'm not saying this is necessary. For TAR selection the 
generic statement that the MN's requirements MUST be made known to CAR
discovery is more than enough.

Waking up an already awake device or trying to wake up an non-existent
device too such a requirement will just provide an optimization to
avoid some messages.

>My
>contention is that this is unnecessarily complex and having the MN
>control the handover would provide exactly the same functionality at
>much less protocol complexity cost.
>
>Perhaps I am missing something and there is some large benefit to adding
>this complexity that I do not see. If so, what is it?

[Govind] Please see above.
>
> > >Right, so I am willing to concede that there is a place for reverse
> > >address translation to support fast handovers, but I don't see this
> > >fairly limited use in the requirements. I don't think this involves
>any
> > >capabilities, mobile node preferences, or any other complications of
> > >that sort. It is fairly simple. The Layer 2 trigger on the AR says
>that
> > >the MN is about to move to a new AP or AR and all that the Layer 2
> > >trigger gives is a Layer 2 ID. The AR needs to map that into a Layer
>3
> > >ID, namely an IP address. Simple. It works just like IPv6 ND or RARP.
> >
> > [Govind] I don't understand your point. As I explained earlier,
>Requirement
> > 1 essentially deals with L2 to L3 mapping. Why doesn't MN's
> > preferences come into picture, if there are 10 APs connected to
>different
> > ARs with different capabilities, ofcourse the MN's preferences
> > come into picture.
> >
>
>I think we agree on this, Govind. Let's move on to where we don't.

[Govind] Sure.
>
> >The main point I'm making is that if there are multiple
> > APs available and the MN has to choose among them, then clearly
> > this has more power implications than just listening to the beacon and
> > passively forward it to a AR.
> >
>

>Like I said, the MN, at the IP layer, does not today get to choose in a
>single technology situation. A future L2 might have this capability, but
>I do not see why that means the AR must get involved.

[Govind] Well for this future L2 that you mention, I have explained this 
several times, if the MN has to
connect and disconnect to every AP then get IP connectivity, get capability 
info etc and then decide not to use it is a  waste of time and bandwidth. 
Therefore, to say that a solution that involves the current AR is feasible 
is not ok IMHO.
But again, I suggest lets leave this issue for now and get back to
it later when things are more clearer.

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 12:57:46 -0800

But..but..

How can you push into the MN's profile that on Tues. March 26 Mr. Fu
forget his network card because he had to take his kid to the doctor?

            jak

----- Original Message -----
From: "Govind Krishnamurthi" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, March 26, 2002 10:16 AM
Subject: Re: [Seamoby] Examples of CAR discovery

> Join the world's largest e-mail service with MSN Hotmail.
> http://www.hotmail.com
>
>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 12:57:46 -0800

But..but..

            jak