[DNA] Re: [nemo] Tree Discovery

[Alexandru Petrescu <Alexandru.Petrescu@motorola.com>]

Pascal Thubert (pthubert) wrote:
> As far as NEMO basic support is concerned, the MR serving my PAN 
> could attach to my wife's PAN which could attach to the neighbour's 
> car which could attach to my car, maybe all cars forming a daisy 
> chain... and maybe a loop, for quite a long time. This is issue 24.

Tell your wife your neighbour's car is not adequate for attaching, or
get control of her laptop.

The apparent ubiquity of wifi cafes and browsing yahoo for everbody does
not mean that _setting up_ networks is a mundane task that mere mortals
could get trapped into.

> You need additional control to establish/maintain the ferry boat <- 
> car <- pan chain quickly and efficiently. I think it was Steve 
> Deering at IETF 54, who asked how we (NEMMO WG) make sure that we do
>  not get the whole ferry boat going out via my PAN... The preference
>  in TD provides for that case.

Make sure that the admin who sets up the TD preferences does it right.
Make sure that the TD preferences do not lead to TD loops.

> That same result can be achieved by manual config (e.g. SSID for 
> 802.11) and AAA, as I understand Mattias is proposing. I do not see 
> firemen playing with SSIDs in front of a fire, though.

I do not see firemen playing with TD preferences in front of a fire.

> Nor me changing my SSID when I hop in a bus for a few minutes, just 
> to maintain my VOIP call.

Well, you don't have to.  If you use the same bus company every day,
just make sure you add it to your Windows preferences and then order
those preferences with the street AP's, and you're all set.

If you take similar trajectories daily, you won't have to manually
change the ESSID, Windows (and associated driver) will do it by your
preferences.

> TD is an extension of ND that improves the default router selection.
>  It is pretty generic and can be adapted for the use cases we want to
>  support. But first, we need to reckon that there is a problem and 
> make sure somebody is looking at it.

I think a better default router selection can be used when several AR-AP
pairs are outgoing routers for the same unique IP link.  Let's first
identify where such cases occur in wireless?

A hotspot deployment in Paris/France (where Cisco is a partner) has
fixed hotspot areas that may overlap each other.  Both AP's have the
same ESSID.  In the small overlapping area a Client may see two AP's,
same ESSID.  However, it can not communicate with both at the same time,
the Client "flips" between the two AP's; in this particular case, the IP
stack can not choose between two default routes, it is only one AP
accessible at a time.

In the same area, the overlapping common physical area, although covered
by two AP's with same ESSID and key, are not actually the same unique IP
subnet.  The IP(v4!) address obtained from one AP/AR and the associated
masks are different than the ones obtained from the other AP/AR.

So this particular deployment does not qualify for an intelligent
default router selection, IMHO.

In order to have a need for a better default router selection, we need
to have a wireless deployment with two AP-AR pairs, same ESSID and same
subnet mask (or IPv6 prefix).  That can be 802.11b or another wireless
with a MAC layer.  Cellular GPRS and UMTS do not apply because GPRS/UMTS
  use ppp and the default route is practically tied to an innterface.

>> But, taking the example of a bus, connected to the Internet via 
>> 802.11 APs deployed in the street, and also offering a 802.11 
>> access to its customers within the bus, I would guess that only MR
>>  would have the credentials to join the street-AP (key, etc), while
>>  the bus-AP icould only be accessed to the passengers who have the
>>  credentials for the bus-AP.

Passengers may have both credentials (for bus and for street).

An existing train deployment, passenger buys credentials for both the
train and the station.  The train is not connected to the station AP's
but to GPRS (and I doubt any bus will roam between hotspot areas, it's
just too fast).  When the passenger is in the train inside the station,
passenger has the choice of AP of this train, or neighbour trains, or
the station's AP.

Passenger has all these choices, but I don't think the IP stack has any
choice once the passengers has chosen one.

> Say I'm a pedestrian in the street. My PAN MR attaches to an AR along
>  the curb. I'm not nested. Now I hop into the bus. Should I keep 
> roaming using curb MRs or should I attach to the bus MR and let the 
> bus do the roaming in a nested fashion? Do I need to change my MR 
> config to do one or the other?
> 
> One good thing could be to do AAA with the ARs regardless on whether
>  I hop via the bus or not (PANA?)
> 
> One other good thing would be to get a CareOf from the bus while I'm
>  in the bus and only while I'm in the bus (not if buses pass by me).
> 
> One other good thing would be that buses do not use my PAN to get to
>  the curb AR.
> 
> One other good thing would be that another PAN might relay my own if
>  I do not have direct visibility to the AR (anonymous relaying).

I think there are many ways in which one would design a wireless hotspot
deployment.  The best way to do better is to pick an existing hostpot
deployment and see where are the problems.

The 2-3 hotspot deployments I've seen, my favourite problems are the
following:
-none uses IPv6.
-none uses Mobile IPv4.
-IPv4 address is changed from hotspot area to the next.
-all are behind NAT.
-none offers continuous applications when changing AP, thus not allowing
  for any physical movement (don't even dream of "fast" movements).

Alex

--------------enig1E3BF25393DC51B43CC051F3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBNEuCMmC0w56zj54RAoKrAKCVh1TRAKHikIRIf8hb/XNy18QUVwCgqQMq
9YCOnC2beTtSi/ug+iCQ0rU=
=Ndx9
-----END PGP SIGNATURE-----

--------------enig1E3BF25393DC51B43CC051F3--