Subject: Re: [Seamoby] Comments on the requirements draft

From: "Hemant Chaskar" <[email-masked]>
Date: Sun, 24 Mar 2002 20:40:57

Hi James:

Some comments inline:

>From: "James Kempf" <[email-masked]>
>To: <[email-masked]>, <[email-masked]>,        
><[email-masked]>
>Subject: Re: [Seamoby] Comments on the requirements draft
>Date: Sat, 23 Mar 2002 20:50:00 -0800
>
>As per SteveD's presentation in the Minne-apple, the MN must be able to
>make the decision on its own, particularly for intertechnology.

[HC] I agree that MN's requirements MUST always be considered during CAR 
discovery. I guess, that is why we have a requirement that: "MN's 
requirements MUST be made available to CAR discovery protocol." CAR 
discovery is about "comparing MN's requirements with capabilities of GAAR to 
identify CARs." As said in problem statement, CAR discovery does not make 
any decisions about handoffs or target access routers. It simply identifies 
CARs from GAARs by comparing MN's requirements with GAAR capabilities. 
Decisions are made by TAR selection which may reside in MN or in network or 
in both of them. TAR selection is outside the scope of CAR discovery. But 
the following additional requirement may help "Output of CAR discovery MUST 
be available for TAR selection algorithms wherever they are implemented (MN, 
network or hybrid)."

>
>The MN must also be able to get the information through any interface,
>even one that is currently not up. This allows the MN to keep an
>interface powered down until it knows there is an active wireless
>network in the area == power savings.

[HC] How will MN receive information over interface that is down? It has to 
receive trigger over another interface to first wake up the sleeping 
interface.

>
>If the latter were not so, the MN could just use standard Router
>Discovery on the interface and there would be no need for CAR discovery.

[HC]Even when other interface is awake, the capability discovery via Router 
Discovery is not always efficient and it is also time and power consuming. 
For this, MN needs to acquire link layer connectivity, then IP-layer 
connectivity and then receive capabilities over the new connection. You have 
to do this for every AP beacon that you hear. While MN is doing that its old 
connection may actually go down (moving into basement of building from 
cellular coverage) thereby causing disruption of service. Also, if the new 
access router does not meet MN's requirements, all this capability discovery 
effort (and associated power spent) goes waste. These can be avoided by 
doing AR_current-assisted CAR discovery while still considering MN's 
requirements.

BR,
Hemant

>
>             jak
>
>----- Original Message -----
>From: <[email-masked]>
>To: <[email-masked]>; <[email-masked]>
>Sent: Friday, March 22, 2002 11:55 AM
>Subject: RE: [Seamoby] Comments on the requirements draft
>
>
> > Hi Teemu,
> >
> > see comments inline.
> >
> >
> > 3.5 FORMAT OF CAPABILITIES
> >
> > - The format of describing the capabilities MUST be
> >   extendable and flexible in a way that they support
> >   future needs that cannot be exactly defined
> >   at this stage.
> >
> > [DOT] in addition to this, though not a requirement as such just
> > recalling what I said in MPLS, we should evaluate what descriptions
> > are on the table (as standards/research/products), and how they could
> > fit into the problem space. This would prevent the re-invention of
> > the wheel.
> >
> > 3.X SCALABILITY
> >
> > - CAR/GAAR discovery MUST be scalable. In the future, there
> >   might be geographical locations with several (hundreds)
> >   of overlapping access points, especially when PANs emerge.
> >   This kind of situation might lead into problems when the
> >   ARs behind these APs have to constantly update their
> >   knowledge of their GAARs.
> >
> > [DOT] I certainly agree with scalability, just some comments to
> > the number of several hundreds of overlapping access points. Even
> > when I consider PANs, I can hardly think of scenarios where actually
> > hundreds of coverage areas overlap. Bluetooth coverage areas are not
> > large enough, and I doubt that we had so many WLAN APs. But even then,
> > what counts is the number of ARs that have overlapping APs with APs of
> > other ARs. I don't quite see that this number would reach several
>hundreds.
> > Maybe you could elaborate a bit on the scenarios you have in mind.
> >
> > 3.X INTEROPERABILITY
> >
> > - Interoperability MUST exist with non-CAR ARs.
> >
> > [DOT] How do you mean this? If a non-CAR is (due to the lack of
>identification
> > and capability knowledge through CAR) not considered as a CAR, it
>should still
> > be possible to handover to this AR? This is indeed true but not within
>the scope
> > of CAR discovery. Since CAR discovery only gives you a set of CARs
>(which need to
> > be identified for that), it should be ok that a CAR solution does not
>include
> > these non-CAR ARs (one reason might be that the non-CAR AR did not
>allow the
> > CAR solution's GAAR identifitication - another reasons might be that
>the non-CAR
> > did not reveal capabilities). However, if the MN (or the AR) would
>find any other
> > means to identify this non-CAR AR, and the MN (or the AR) makes the
>decision to
> > handoff to this non-CAR AR, that's fine and still possible. But this
>is TAR
> > selection, which is not within the scope of CAR discovery. CAR
>discovery only
> > gives you a list of CARs (i.e., ARs that match MN's requirements),
>which is ONE
> > input to TAR selection (wherever latter is implemented). Another input
>might be
> > the detection of non-CAR ARs which you might consider in your TAR
>selection algorithm
> > as well.
> >
> >
> > 3.X PERFORMANCE
> >
> > - CAR/GAAR protocol MUST NOT add to handover times in
> >   cases when the connection to the old AR is lost and there
> >   are ongoing communication waiting for network access. In
> >   those cases the MN must get a new AR as fast as possible,
> >   not spending much time on the TAR algorithm.
> >
> > [DOT] How do decide whether it is worthwhile to spend time on CAR or
>not?
> > If you have a TAR selection scheme that resides in the MN, it is
>fairly
> > easy to do so. If your signal strength fades for instance too fast,
>you just
> > skip CAR discovery and select one of the AR from which you receive a
>current
> > beacon. But again, this is TAR selection and not within the scope of
>the problem.
> > But if you choose to do CAR (wherever it is implemented), it will
>always add
> > to your handover time since you have to run certain mechanisms. How
>this tradeoff
> > can be determined is not clear to me and looks like an implementation
>issue in
> > the entity that runs the TAR selection (which again use CAR discovery
>as an input).
> >
> > General thoughts:
> >
> > How can an AR recognize its GAARs without the help of the MN
> > or the link-layer protocols?
> >
> > This means that the amount of packets sent over the air necessarily
> > increases, doesn't it? I mean, if the AR doesn't get the information
>about
> > GAARs from the MN, then it must somehow sense the GAARs presence
>through
> > the APs. But the latter is of course impossible between APs of
>different
> > link layers.
> >
> > [DOT] Good question ;-) But is it mentioned somewhere that the
> > identification of GAARs must not be a combined job between AR and MN?
>Or it
> > might even be entirely based in the MN? Certainly, the AR-only
>solution
> > sounds kind of impossible for me, too.
> >
> > Best Regards,
> >
> >
> > Dirk
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
>
>
>_______________________________________________
>Seamoby mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/seamoby

_________________________________________________________________
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: Sun, 24 Mar 2002 16:25:27 -0800

> receive trigger over another interface to first wake up the sleeping

It doesn't get info over a down interface, it gets it over the up
interface. The protocol tells the MN what's available, including if the
MN brought up the down interface. It avoids having to bring up the
interface if there is nothing there.

If the interface is always up, then the MN can just do standard IPv6
Neighbor Discovery and there is no need for CAR discovery.

> doing AR_current-assisted CAR discovery while still considering MN's

CAR discovery is completely irrelevent if the MN brings up the
interface. Neighbor Discovery is fine for discovering routers - the MN
solicits router adverts, the routers send them. What's the problem?

The only reason for CAR discovery is so that the MN doesn't need to
bring up the interface to discover what's available. The sooner we can
agree on that, the sooner we can get to the hard questions, like how to
do it.

            jak

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

---

From: "James Kempf" <[email-masked]>
Date: Sun, 24 Mar 2002 16:25:27 -0800

jak