Subject: [DNA] Tree Discovery

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 31 Aug 2004 11:11:52 +0200

Hi:

This thread is about 
http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-00.txt
.

> > > >  ferry boat <- car <- pan.
> 
> This one is a valid scenario.
> 
> > > > NEMO does not provide for the PAN to attach to a car (mine in
> > > > particular), for the car to attach to a ferry etc... We could
end up
> > > > having a car joining the ferry and then the hundred other in a
daisy
> > > > chain till the overhead of tunnels is so huge that it does not
work
> 
> Would you explain what you mean by "NEMO does not provide for the PAN
to
> attach to a car" ?  I'm not sure I get it. From my first
understanding,
> I would disagree.

NEMO basic support does not provide tooling for default router
selection. I may be wrong, but I'm afraid that a detecting/building a
multi-hop network attachment is out of scope for DNA as well - copying
Greg and DNA here.

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.

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.

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. Nor me changing my SSID
when I hop in a bus for a few minutes, just to maintain my VOIP call.

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.

> 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.

I wish to discuss that case further. Same question as above. Is this all
AAA based, or do we need to enhance the default Router selection? I
understand there's a need for AAA anyway, but I'm not sure that we can
leave it at that:

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).

...

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Aug 2004 11:57:16 +0200

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.

>  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