Subject: Re: [Seamoby] Examples of CAR discovery

From: "Hemant Chaskar" <[email-masked]>
Date: Mon, 25 Mar 2002 22:11:13

Hi James:

Some agreements and some disagreements below, marked as <HC>.

>From: "James Kempf" <[email-masked]>
>To: "Hemant Chaskar" <[email-masked]>
>CC: "Kempf" <[email-masked]>
>Subject: Re: [Seamoby] Examples of CAR discovery
>Date: Mon, 25 Mar 2002 13:23:33 -0800
>
>
> > > > After the CAR discovery discussion in IETF53, it seems that we
>need to
> > > > emphasize certain points about CAR discovery. They are as follows:
> > > >
> > > > - CAR discovery always considers MN requirements while choosing
>CARs
> > >from
> > > > GAARs.
> > > >
> > >
> > >This statement sounds like some other entity beside the MN is doing
>the
> > >choosing (TAR selection).
> >
> > [HC] The statement is about "CAR discovery" (as seen from the first
>two
> > words of the sentence), which is different from TAR selection, as
>stated in
> > problem statement. Then, why would a statement made for CAR discovery
>imply
> > anything for TAR selection?
> >
> > I can't see the relevance of CAR discovery
>
>The relevance is that I would like the requirement to read as follows:
>
>     The CAR discovery protocol MUST provide the MN with enough
>information about GAARs, including information concerning capabilities,
>so that the MN can make a choice of which CAR to select.

<HC> As I already said, this requirements has to be there. I completely 
agree with you. But then, it is also important to unambiguously state that 
"MN requirements MUST be made available for CAR discovery if needed".

>
>No ambiguity about what is doing the selecting.
>
> > [HC] Nobody is denying that MN should be given choice. But that does
>not
> > mean that processor instructions for comparing MN requirements with AR
> > capabilities need to be executed in MN. They could as well be executed
>in
> > AR. Not executing processor instructions in MN does not mean that MN
>does
> > not have choice. What matters is input to execution of instructions.
> >
>
>So explain to me how the AR is supposed to know what kinds of interfaces
>the MN has? I don't know why this is so hard to understand, maybe I'm
>not explaining it well.

<HC> Is it too difficult for MN to tell so to AR? I do not think so. There 
is another possibility of having it in MN's service profile as well.

I can't see how the AR can know what interfaces
>the MN has on any particular day, so I can't possibly see a role for the
>AR in selecting an interface for the MN.
>
> >
> > So I would rephrase this:
> > >
> > >     CAR discovery provides the MN with information on CARs for the
>MN to
> > >choose which TAR it wants to
> > >     hand over to.
> >
> >
> > [HC] That is good. But it is not a "rephrase", it is a "different"
> > statement. What I was talking about is "providing MN requirements to
>CAR
> > discovery module", what you are saying in above statement is
>"providing CAR
> > output to MN". Both are different, but I think both need to be there.
> >
>
>"CAR discovery module" is too ambiguous. I'd like the requirements to
>clearly state that the MN is the one in charge for intertechnology
>handover.

<HC> But then, "being in charge" is very ambiguous too. What does it 
precisely mean form an algorithmic perspective? If it precludes 
network-assisted CAR discovery, then I am not sure. I think network-assisted 
CAR discovery can be useful for certain intertechnology cases too. It does 
not immediately make sense to me to fix such a solution for inter-technology 
case.

>Otherwise, people start proposing complicated AAA transactions
>that are completely unnecessary and likely to fail anyway. See my above
>rewording. The AR *should not* and *cannot* have any role in selecting
>an interface for the MN in an intertechnology handover situation,
>because it *cannot* know a priori what interfaces the MN has.

[HC] That is like fixing a solution. In the requirements phase, we should 
give freedom to designers to design what is the best from performance 
perspective and specific environments. As long as requirements do not 
constrain above solution that you have in mind, what is the concern?

Also, MN can easily tell AR what interfaces it has (send on ICMP message for 
example) or this information can be statically configured in MN's service 
profile.

>
>What I am saying is your proposal for requirement language is likely to
>lead to unrealistic and complicated proposals for implementation, that
>have a high likelihood of failing in many cases.
>
> > >This is too complicated. After solcitiing the new RA, the MN can
>decide
> > >whether to connect or not.
> >
> > [HC] I disagree that this is complicated. It is fairly simple: Listen
>to
> > beacon - grab AP id - send to AR_current - wait for CAR ID. This is
>very
> > time and power efficient, and also, can feed into fast/seamless
>handoff
> > protocols.
> >
>
>Why go through the AR on the other interface when you can simply solicit
>an RA on the new one? This is a standard IPv6 procedure. What's the
>point of introducing an entirely new procedure?
>
>Furthermore, how does the MN know to power up the second interface in
>the first place? The whole point of CAR discovery, IMHO, is to tell the
>MN exactly that. Once it knows, it can simply use standard IPv6/MIPv6
>mechanisms (or IPv4 if the network is a IPv4 network).

[HC] What your are saying here is one solution. I do not think that any of 
the requirements preclude it. But that does not mean that the requirements 
should be formulated around this solution.

>
> > [HC] It hears the new AP (e.g. an RF broadcast channel), not the new
>AR yet.
> > Various things need to happen including many message exchanges over
>wireless
> > before MN can be deemed to be listening to new AR.
> >
>
>One of those things is that it solicits an RA on the new interface. This
>is not "many message exchanges" it is exactly 1, at the IP level. Or wer
>e you thinking of GPRS?

[HC] Sure, just like MN can go from GPRS to WLAN, it can go from WLAN to 
GPRS as well.

>
> > >The current AR doesn't have to be involved if the MN periodically
>polls.
> >
> > [HC] Periodic polling is power inefficient compared to selecting
>awakeing.
> > Also, waking up for WLAN beacons that are not willing to provide you
>service
> > is not efficient.
> >
>
>Hemant, we are talking about sending traffic on which the MN already has
>active IP service, not a dormant mode MN.

[HC]MN already has IP traffic service on one interface. The second one is 
sleeping. Waking it up and sending IP level messages through it (when 
possibly not required) does consume power and takes processor MIPs.

>If you don't like polling, and I agree that it is inefficient, there are
>other ways to do it. We could have an update pushed to the MN when a new
>network medium becomes available, like when it enters a hotspot.

[HC] Yes, I think that is one example of the usefulness of network-assisted 
CAR discovery for inter-technology case. Polling is clearly very 
inefficient.

>             jak

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 09:29:13 -0800

Hemant,

The issue is one of complexity. If the MN knows what interfaces it has,
and which are powered up, then why not simply let it decide?

Perhaps I am missing something, but I cannot see what is gained by
having a complex protocol to communicate MN interface state to the AR.
Can you articulate what the benefits are, and why they are so much
greater than having the MN decide that we should add this complexity?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 09:29:13 -0800

Hemant,

            jak