[DNA] Tree Discovery

["Pascal Thubert (pthubert)" <pthubert@cisco.com>]

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