Subject: Re: [Seamoby] Examples of CAR discovery

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

James,
So now you agree that the AR can hand over the list of GAARs and
their capabilities to the MN (maybe only pass on those which satisfy
the MN requirements, which is what CAR discovery was originally about).

Which first implies that the network is taking care of CAR discovery.
This seems contradictory to your earlier mails saying that there is
no basis for network based CAR discovery. So are you now agreeing
that network based CAR discovery has its place?

Now to the current issue.
Why cant the AR send over the GAARs and their associated capabilities
to the MN for TAR selection.  This comes into the domain of
TAR selection. What you suggest can be done and has no basis on
where CAR discovery is being done. Similarly I can suggest a scheme,
in which for example,
wherein this final decision can be taken in the network after considering 
the MN's requirements  and the MN can have a veto power
on the decision. There are bandwidth and power considerations in both ( I 
have described this in an earlier mail in detail and hence don't want to go 
into it again).
But again this is out of scope of CAR discovery. All CAR discovery MUST
ensure is that its output is available for TAR selection irrespective
of where the TAR selection process resides.

Regards,
Govind.

>Right, so the AR hands over the list of GAAR and the MN figures out
>where it wants to go. What could be simpler?
>
>             jak
>
>----- Original Message -----
>From: "Govind Krishnamurthi" <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Tuesday, March 26, 2002 2:32 PM
>Subject: Re: [Seamoby] Examples of CAR discovery
>
>
> > James,
> > Because one of the inputs to TAR selection is the reachability
>information
> > from the MN.  Irrespective of what the MN's profile
> > says if the MN does not inform that it can hear to a particular
> > AP (which is of a particular technology) then why will the TAR
> > selection algorithm hand over to the AR which controls that AP?
> > I thought reachability information from the MNs includes what
> > APs it can hear and if a interface is not present why will the MN
> > give information that it can hear an AP of a matching technology?
> >
> > Clearly if the AR clearly intreprets this lack of information
> > from the MN as a signal to hand it over to that very AR then there
> > something wrong in the implementation.
> > There is no need for any complicated protocol. When you look at
> > the issues draft you will see that TAR selection has the reachability
> > information from the MN as one of its input.
> >
> > >
> > >How can the TAR selection algorithm realize the absence of
> > >reachability? If the subscriber profile says that the MN has
> > >a WLAN card in and, in fact, it doesn't, then there either a) there
> > >needs
> > >to be some complicated protocol to tell the AR or b) the AR
> > >will make a mistake and move the MN to a medium that
> > >it currently doesn't have.
> > >
> > >I maintain that a) is too complicated and b) is an error.
> > >
> > >And, no, I don't think this is TBD by the TAR implementation. It
> > >lies at the heart of whether a network-only controlled algorithm
> > >would work for ITHO.
> >
> >
> >
> >
> >
> > _________________________________________________________________
> > Send and receive Hotmail on your mobile device: http://mobile.msn.com
> >
> >
>

_________________________________________________________________
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 15:40:36 -0800

,
> the MN requirements, which is what CAR discovery was originally
about).

No, that it sends all, along with the capabilities. Let me repeat the
requirement I would like to see (and Henrik apparently agrees) so we are
clear on this:

    The CAR discovery protocol MUST provide the MN with GAAR
    information, along with capabilities.

> that network based CAR discovery has its place?

Please see the requirement above. No contradiction. The protocol allows
the MN to discover  the GAAR and capabilities, the MN decides which one
it wants.
Nothing about the AR in control of anything. The MN may use a variant of
IPv6 neighbor discovery, the AR may be involved somehow, but that's a
protocol design, not a requirement, choice. The requirement is clearly
that the MN does the discovery.

We now have two working group members who want this reqirement worded
just this way. Nothing about "as the MN expresses its preferences" or
"by the CAR discovery module" or anything else. And I believe Hesham has
also expressed a preference for this requirement.

Anybody else out there have an opinion on this? Should we include this
requirement instead of requirement 3.4, which has the AR in control?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 26 Mar 2002 15:40:36 -0800

,

            jak

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 00:41:26 +0100

> the MN requirements, which is what CAR discovery was originally about).

Here you seem to assume that one single AR has the full list of GAARs.
I would argue that a flexible and scalable solution would have the final
list of GAARs be composed from sublists provided by multiple ARs and the
MN.

> of where the TAR selection process resides.

It may be technically possible for all Currently Active Access Routers to
transit their GAAR sublist to the MN, who transmit the lot together with
its own GAAR sublist to one particular AR, who runs some algorithm and
returns the result to the MN.

But it certainly doesnt't seem either sensible or optimal to me.

	Regards,
		Henrik

---

From: "Henrik Levkowetz" <[email-masked]>
Date: Wed, 27 Mar 2002 00:41:26 +0100

Regards,
		Henrik