Re: [Autoconf] updated draft on aspects of multi-hop wireless communication

["Teco Boot" <[e-mail]>]

Inline.

|-----Oorspronkelijk bericht-----
|Van: [e-mail] [mailto:[e-mail]] Namens
|Paul Lambert
|Verzonden: dinsdag 24 februari 2009 16:04
|Aan: Emmanuel Baccelli; [e-mail]
|Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
|communication
|
|
|Hi Emmanuel,
|
|
|>The goal is NOT to write another problem statement, nor to be
|exhaustive
|>regarding issues that AUTOCONF should address.
|>
|>Do you have any comments about the description of the basic aspects
|>presented in the draft?
|
|Well ... if this is not part of the problem statement - I could use a
|pointer or more discussion on what this group wishes to address in the
|new reduced scope charter.
|
|The document you submitted was though provoking for me on it's notion
|asymmetric links.  AS I mentioned before - this is not a consideration
|in any of the IEEE 802 wireless or cellular protocols where I have
|experience.  

I don't understand this statement. I think every wireless or cellular
protocol should pay attention to the aspects described in
draft-baccelli-multi-hop-wireless-communication. For potential asymmetric
links, which is a natural characteristic of wireless links, protocols shall
implement a bi-directionality check.

Using asymmetric links for a uni-directional broadcast channel is something
different. It may be useful and in many cases it is very powerful, but it is
out-of-scope of many (all?) routing protocols. Main reason is the lack of a
return channel. Of course there are protocols (related to routing protocols)
that utilize the broadcast links. And we could think of using these links in
MANET, e.g. using the uni-directional links for flooding.

Anyway, I do not think this is in scope for [Autoconf] right now.



|I can see that there could be some interesting
|applications.  My primary comment was that there are existing ad hoc IP
|address assignment problems that do not have this attribute.
|
|I am starting to see that I may I may be "talking past' members on this
|list ... and perhaps should just go away ...  I notice that in your
|draft it says:
|   All are configured to
|   provide store-and-forward functionality on top of these protocols, as
|   needed to enable communications; consequently, they can be classified
|   as routers in the resulting wireless network.
|
|None of the consumer devices that I'm concerned with (cellphones,
|cameras, printers, etc.) will be routers.  They are connected to a ad
|hoc network and still all need IP addresses.  I'm a big fan of routers
|:-) ... but not all devices on an ad hoc network forward packets.  If
|this group is solely interested in routing protocols ... I should go
|away and create another non-IETF proprietary protocol to solve my
|problem area.

I raised this issue also some time ago (I think Vancouver meeting). The room
responded with large consensus that nodes could easily run the MANET Routing
protocol and still not forward packets. So the node learns neighbors and
topology information, but for some policy do not advertize its links.
Now the definition of "host" and "router" is somewhat troubled. In IETF, we
say a host does not forward packets. But in the routing community working on
protocols for dynamic routing, we say routers run the Routing Protocol.

Maybe IETF missed the point that hosts do need topology information, e.g.
default gateway selection / dead gateway detection, ICMP redirect, failover
etc. Running routing protocols on hosts is being used already (e.g. passive
RIP).


|
|In this context - is there a specific advocate (customers, products,
|markets) for the proposals on this list or is it strictly research
|centric?
|
|If there is need for such a target problem set I would like to suggest
|the specific problem area of 802.11 ad hoc networks with 802.11i (aka
|WPA2) security. If some one is interested in this problem ... let me
|know ... otherwise if this is out of scope I will move to some other
|mailing list.

I am interested. But I do not see the problem right now. I think the IP
layer is on top of the link layer, and 802.11 (including 802.11i WPA2 in
IBSS mode) shall enable communication completely independent of layers
above.

Can you explain the problem a little bit more?


Teco.



|
|Regards,
|
|Paul
|
|
|
|
|
|________________________________________
|From: [e-mail] [mailto:[e-mail]] On
|Behalf Of Emmanuel Baccelli
|Sent: Monday, February 23, 2009 5:01 AM
|To: [e-mail]
|Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless
|communication
|
|Hi Paul,
|
|thanks for your feedback. This document aims at describing "some
|important aspects, experienced over the past decade, of multi-hop ad hoc
|wireless communication between routers", as stated in the abstract.
|
|The goal is to reach a common uderstanding of the basic aspects
|presented in the draft (asymmetry, time-variation, non-transitivity, and
|radio-range aspects of communcation), which we can then refer to when
|discussing further issues, such as the ones you mention, for instance.
|
|The goal is NOT to write another problem statement, nor to be exhaustive
|regarding issues that AUTOCONF should address.
|
|Do you have any comments about the description of the basic aspects
|presented in the draft?
|
|
|Cheers,
|
|Emmanuel
|
|
|
|
|On Mon, Feb 23, 2009 at 11:54 AM, Paul Lambert <[e-mail]> wrote:
|
|Hi,
|
|The draft-baccelli-multi-hop-wireless-communication-01 provides an
|interesting list of issues that might be addressed by this working
|group.
|
|From a quick review it does not appear to address:
| - ad hoc network coalescing.  Coalescing has clear implications for
|  IP address assignment
| - there is no mention of multicast versus unicast issues.  Perhaps
|  since the document makes all links potentially asymmetric and
|  unreliable there is no distinction.  At least for 802.11 ad hoc
|  I find significant implications.
| - it does not address link security establishment
|  The process of setting up the link security is out of scope, but as
|  I've mentioned in earlier emails this has a clear impact on available
|  networking mechanisms.
|  It is also a very important architectural consideration to ensure that
|  IP address assignment has some level of security.
|
|Asymmetric links in all "ad hoc" networks.  Is it possible to partition
|our problem statements so that this is just one of several optional
|attributes that must be addressed?
|
|Most modern wireless MAC layers have reliable unicast.  I can see some
|broadcast only links - like satellite broadcast, but outside military
|applications I am not familiar with broadly deployed commercial wireless
|networking technologies that are based on asymmetric unicast
|transmissions. Perhaps someone on this list could point me to the
|technologies that they are considering for this requirement.
|
|
|Regards,
|
|Paul
|
|
|________________________________________
|From: [e-mail] [mailto:[e-mail]] On
|Behalf Of Emmanuel Baccelli
|Sent: Monday, February 23, 2009 2:04 AM
|To: [e-mail]
|Subject: [Autoconf] updated draft on aspects of multi-hop wireless
|communication
|
|Hi all,
|
|
|following the fruitful discussions about initial version of the
|document, here is an update to the draft describing aspects of multi-hop
|wireless communication:
|
|http://www.ietf.org/internet-drafts/draft-baccelli-multi-hop-wireless-
|communication-01.txt
|
|
|Again, the goal of this document is to identify a consensus about this
|topic, and then use this to move on quicker with the rest of the work...
|
|Please review it, and provide feedback as soon as possible.
|
|
|Cheers
|
|Emmanuel
|
|_______________________________________________
|Autoconf mailing list
|[e-mail]
|https://www.ietf.org/mailman/listinfo/autoconf