Subject: RE: [nemo] mor comments on TD

From: "Pascal Thubert \(pthubert\)" <[email-masked]>
Date: Mon, 30 Aug 2004 12:47:47 +0200

Hi Mattias:

I'm happy that you point this out because it's at the core of the
problem. Note that we started a discussion like this about with John
from 802.21 when came present his work at IETF 59.
> >
> > We have scenarios with 3 or more level of nesting. But nothing says
how
> > we get there. One such example is:
> >  ferry boat <- car <- pan.
> > 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
at
> > all.
> >
> > We have been asked to look at realistic scenarios such as traffic
jams.
> > That's 2000 cars. I did not make up the numbers.
> 
> Now I think you are making a dangerous assumption here. You seem to
say
> that an MR can hear any number of access points (ARs, other MRs'
ingress
> interfaces etc.) _and that it connects to them all on the IP layer_,
so
> that it can hear each and everybody's RA.

All of them is a big word. A number of them is closer to the truth. 

The radio world is far from limited to 802.11, and there are radios
around that allow you to get signals from more then one neighbour. Quite
a good thing in my view, if we want all this MANET thing to work at all.

> 
> This seem to indicate that there are no distinct logical links on top
of
> 802.11 or whatever we run, but rather that there is basically only one
> single logical link where everybody can hear everybody else. This is
> really bad. This is what ad hoc assumes, but I would like to see NEMO
> assuming a bit more _structured_ and _managed_ networks.
> 

Use cases... There's no such a restriction that I know of for NEMO
applicability. I copy Thierry, in case he wishes to provide his view on
this debate.

> If an MR can hear all APs, I guess all MNNs can do the same. They all
> listen to the same channel. An MNN would find itself hearing 2000
> prefixes then and maybe configure addresses from of them all, as long
as
> is it within range.

Now I think you are making a dangerous assumption here :) LFNs could be
wired or connected to the MR using short range techno such as Bluetooth.
Allowing LFNs to listen to other MRs simply kills the whole thing. 

> I say that an MR must first look for APs, then attach to one of them
on
> L2, and finally listen to the RAs on L3.

This is what we do today with 802.11. Basically a blind L2 selects the
AR on behalf of L3. This is very near sighted :(

This is why we asked for a better interface from 802.21. Hopefully,
we'll be able to get all the RAs from all the APs from monitor mode, and
then let L3 (and above) sort out which router it needs to connect to;
and then associate, under L3 control. This is not only good for NEMO/TD.
It applies to draft-ietf-ipv6-router-selection-05.txt for instance.

Pascal

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Aug 2004 14:28:05 +0200

Pascal Thubert (pthubert) wrote:
> around that allow you to get signals from more then one neighbour. 
> Quite a good thing in my view, if we want all this MANET thing to 
> work at all.

Pascal, partially true.

You're saying "there are radios around that allow you to get signals
from more than one neighbour".  As if this was not the case with
802.11b.  Well, it is.

You're saying "if we want all this MANET thing to work at all".  Well, I
do not want this MANET thing to work at all until I know what exactly is
this "MANET thing".  I strongly doubt there is a commonly accepted view
of what this "MANET thing" is other than a very fruitful research topic
and a set of experimental proposals, some more mature than the other.

>> If an MR can hear all APs, I guess all MNNs can do the same.

Yes, this is logic.  But note that with 802.11b an MR can only listen to
RA's from a link on which it is configured with an ESSID and/or a key.

Before listening to RA's, the Client listens to Beacons; the User
selects an ESSID manually and only then does it listen for RA's.

In an area where Client listens to Beacons of two AP's and that send no
ESSID, no key and different RA's, the Client and the AP's have many
problems to talk to each other, see impossible.

>> They all listen to the same channel. An MNN would find itself 
>> hearing 2000 prefixes then and maybe configure addresses from of 
>> them all, as long as is it within range.

Again, this is not an IP problem at all.  You can not have a meaningful
IP configuration in an area where two AP's emit their Beacons without
ESSID, without key and that are connected to different IP wired Ethernet
subnets.  This is like physically connecting together two Ethernet
cables of two totally different IP subnets.

> Now I think you are making a dangerous assumption here :) LFNs could 
> be wired or connected to the MR using short range techno such as 
> Bluetooth. Allowing LFNs to listen to other MRs simply kills the 
> whole thing.
> 
>> I say that an MR must first look for APs, then attach to one of 
>> them on L2, and finally listen to the RAs on L3.
> 
> This is what we do today with 802.11. Basically a blind L2 selects 
> the AR on behalf of L3. This is very near sighted :(

If it were true, it were near sighted.  Pascal, with Linux and Windows
and Mac Clients, it is the _human user_ that selects an ESSID to connect
to (in Windows and MAC there are some preferences that allow for
automation but it's still a human who set those preferences).

The only apparent problem is when preferences are wrongly set, or when
two AP's send Beacons without ESSID's.

It is not true that a blind L2 selects the AR on behalf of L3.

> This is why we asked for a better interface from 802.21.

Sorry, where did you ask for this?  Did they give you anything better
than a MAC-family?  I wouldn't ask for anything different than MAC
because most stacks work on MAC today.

What are you talking about more explicitly here?  What's 802.21 and
what's the relation to NEMO?

> Hopefully, we'll be able to get all the RAs from all the APs from 
> monitor mode,

No no no... I don't want that.  I want the RA to be sent on well
established and meaningful "virtual" L2 cables already established.  I
don't want IP to be adapted to this model.

> and then let L3 (and above) sort out which router it needs to connect
>  to; and then associate, under L3 control. This is not only good for
>  NEMO/TD.

But the current ND has already a good model of local broadcast and local
multicast.  Would this work with this new L2?

Alex

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 31 Aug 2004 12:48:48 +0900

Dear all,

Since I've been asked by Pascal to give my point of view ....

> > >  ferry boat <- car <- pan.

This one is a valid scenario.

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

> applicability. I copy Thierry, in case he wishes to provide his view on

1st, while setting up this WG, we have said that we would assumed that
MNNs within the NEMO are relatively fixed compared to the MR. In
addition to that, a NEMO could be offering access to sub-NEMOs,
therefore forming nested NEMO. There is no limitations in the number of
levels in the nested NEMO, but we have written in the requirement
documents that the solution should accommodate at least 2-3 levels.
Having more would clearly not be efficient, but in such case, I would
assume that people would not form too many levels of nested NEMO only
because it's not efficient (the proportion of payload would be low
compared to the tunnelled headers, and packets could be lost because of
the PMTU limit).

2nd, speaking about RO, according to me, it means all kind of ROs,
including ROs within the mobile network (how to allow to MNNs in the
same nested mobile networks to communicate directly, how to minimize the
overhead of tunneling within the nest).

However, the charter says the following:

The WG will not:
- consider routing issues inside the mobile network. Existing routing
protocols (including MANET protocols) can be used to solve these
problems.

So, we need stay on the right side of the boundary, but RO within the
nested NEMO still need to be studied in the analysis.

> > as is it within range.

> Allowing LFNs to listen to other MRs simply kills the whole thing. 

Agree here. I don't see how Matias had assumed the MNNs would hear APs.
Well, wireless VMNs might, but in such case they would have to decide if
they prefer to join the APs directly, or through the MR. 

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.