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

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 23 Feb 2009 11:03:35 +0100

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

---

From: Paul Lambert <[email-masked]>
Date: Mon, 23 Feb 2009 02:54:43 -0800

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: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Baccelli
Sent: Monday, February 23, 2009 2:04 AM
To: [email-masked]
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:

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

Cheers

Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Mon, 23 Feb 2009 14:01:06 +0100

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 <[email-masked]> wrote:

>
> Hi,
>
> The draft-baccelli-multi-hop-wireless-communication-01 provides an
> interesting list of issues that might be addressed by this working group.
>
> 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: "Charles E. Perkins" <[email-masked]>
Date: Mon, 23 Feb 2009 10:21:02 -0800

Hello Paul,

The document isn't intended to suggest a list of work
items for consideration by [autoconf].  Instead, it is just
a description of common properties of radio and other
wireless links.  These properties are not quite universal,
but they are widespread.  Some of them can be alleviated
a bit by mechanisms below the network protocol level.

So we are not suggesting requirements or work items.
Instead, we simply wanted to make as clear as possible
some of the characteristics of the transmission media
whose widespread availability is motivating the work
of [autoconf].

Your list of issues would, I think, all fit best in a
requirements document.  I am almost certain they
should be considered out of scope for the document
under discussion.

Regards,
Charlie P.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Feb 2009 22:55:44 +0100

Emmanuel, AUTOCONFers,

Just a short clarifying point: I think it would be clarifying to
illustrate the routers to have two interfaces.  Routers with only one
interface aren't very typical.

Just a note,

Alex

Emmanuel Baccelli a écrit :
> 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:
> 
> 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...
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 23 Feb 2009 14:01:57 -0800

Hello Alex,

On this point I disagree.  I think it is better to show the
routers with a single network interface -- which is what
they have in real life.  This is also the reason that techniques
like split horizon aren't appropriate.

Regards,
Charlie P.

Alexandru Petrescu wrote:
> [email-masked]
> https://www.ietf.org/mailman/listinfo/autoconf
>
>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 24 Feb 2009 00:20:56 +0100

Hello Alex,

To second Charlie here: in MANETs, routers:

	o	ALWAYS have one MANET interface.
	o	OFTEN they have other (non-MANET) interfaces
	o	OCCASIONALLY have more than one MANET interface

I.e. it is quite common for traffic to be forwarded over the same  
interface as the one on which it was received.

Thomas

ps: and for the record, AFAIK all MANET wg routing protocols support  
all the situations listed above, i.e. a MANET router with a single or  
with multiple MANET interfaces and with or without other non-MANET  
interfaces.

---

From: Paul Lambert <[email-masked]>
Date: Tue, 24 Feb 2009 07:03:57 -0800

Hi Emmanuel,

>Do you have any comments about the description of the basic aspects

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

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.

Regards,

Paul

________________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Baccelli
Sent: Monday, February 23, 2009 5:01 AM
To: [email-masked]
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

Hi,

Regards,

Paul

Hi all,

Cheers

Emmanuel

---

From: Paul Lambert <[email-masked]>
Date: Tue, 24 Feb 2009 08:44:03 -0800

Hi Charlie,

I'm traveling with limited email ... so I just now saw your note.

> I am almost certain they

In looking at the reference in the charter for "ad hoc" (RFC 2501) the defined MANET is a Chimera - a mythical beast made of the parts of many other animals. It is a shame that smaller monsters are out of scope (like 802.11 ad hoc) ...

Paul

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]]
> Sent: Monday, February 23, 2009 10:21 AM
> To: Paul Lambert
> Cc: Emmanuel Baccelli; [email-masked]
> > 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?
> >

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 24 Feb 2009 09:44:09 -0800

Hello Paul,

> In looking at the reference in the charter for "ad hoc" (RFC 2501) the defined MANET is a Chimera - a mythical beast made of the parts of many other animals. It is a shame that smaller monsters are…

I am thoroughly mystified by your reply.  Just because certain
topics are out of scope for the small document by Emmanuel
and me, does not mean they are out of scope for [autoconf].
Isn't it possible to have more than one document?  Shouldn't we
collect requirements in a requirements document instead of every
other document that might be written?

To be explicit, I am wholly in favor of making sure that
the results of [autoconf] are applicable to 802.11 ad hoc.
Did I say anything to imply otherwise?

Regards,
Charlie P.

>>>    It is also a very important architectural consideration to ensure
>>>       
>> that
>>

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 24 Feb 2009 11:02:49 -0800

Charlie,

Paul has a reality check point and its worthwhile understanding this 
because missing the point has made both MANET and autoconf harder than 
they need to be ... IMHO.  It's also made them less relevant to what I 
think I see in the future. 

My background is analyzing information systems in DoD and emergency 
services ... why are they not interoperable (or, in the rare inverse 
instance, why are they interoperable)?

In dealing with some DoD bureaucracy, I'm finding that they don't 
understand the implications of the differences between LANs and WANs.   
And by MANET stating that every end system is also a router, we equally 
obfuscate the point.

Reality today.  Our ships have wired LANs (mostly fast etherrnet and 
gigabit ethernet) within the hull.  End systems (Paul's printers) attach 
to that LAN.  And those end systems don't need more than one entry in 
the routing table and it's not likely to change.  (The analog to your 
LAN at home is good). 

The problem that DoD has is not in the LAN; it's in the radio-WAN.  
Which is the link between the router in Radio Central and that in 
another ship and/or the commsta ashore.  While there's lots of noise in 
the system, this is properly a pure radio-WAN problem -- entirely a 
router-router interconnect one.  No end systems.  This presents MAC and 
QoS control problems.  What's important is that they are isolated from 
the end systems -- other side of the router.

Reality ... not very far in the future.  We have all the technology 
today to extend the internet to a fire truck.  But do we want the WAN to 
reach to all the end systems on the fire truck?  Perhaps in the near 
term, but this is not a long term good idea.  What makes better sense is 
to plant a router on the fire truck and divide the problem into a 
radio-WAN (sometimes slangily known as 'reachback') and the LAN problem 
-- which might be solved by a WiFi splotch around the truck.  Once you 
start thinking about reaching to firefighters inside a burning building, 
this makes more and more sense. 
    And reality ... not much further in the future.  Should such a 
pattern not fit into your automobile?  Instead of the cellphone reach to 
your end system, it reaches to your car-resident router.  And you have 
several end systems within the car that ... attach to a LAN.
    And reality, again not too far in the future.  A Marine infantryman 
has several end systems, or at least potential end systems, as part of 
his combat outfit.  Radionav receiver, PDA/laptop, rifle scope, night 
vision goggles (think webcam), laser rangefinder, VOIP rig.  As soon as 
the list becomes plural, the idea of each end system being its own 
router (which implies it's own radio) ceases to make sense. 

The difficulty I repeatedly find in DoD programs (we're talking $B here) 
is that they try to use wireless-LAN technology in a radio-WAN 
situation.  For example, we see satcom and air-ground specifications 
that persist in using contention access methods, when the Aloha 
experiment 40 years ago showed that was a lousy idea.  The MAC problem 
is orthogonal to the routing problems, but somewhat of a prerequisite: 
if the net has crashed due congestion, then your routing tables are 
likely to be fiction. 

For Paul: is this anything related to your comments?

Charles E. Perkins wrote:
>> In looking at the reference in the charter for "ad hoc" (RFC 2501) 
>> the defined MANET is a Chimera - a mythical beast made of the parts 
>> of many other animals. It is a shame that smaller monsters are out of 
>> scope (like 802.11 ad hoc) ...
>>   
>

-- 
Rex Buddenberg
Senior Lecturer
Naval Postgraduate School
Monterey, Ca 93943
831/656-3576

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 24 Feb 2009 11:24:08 -0800

Hello Rex,

Thanks for the long email.  I think that I do have a good handle on the 
various
kinds of mobile communications scenarios as you have outlined below.

You have raised the particular point that many nodes in an ad hoc network
do not have to be routers.  I certainly agree with this, and agree that 
any work
in [autoconf] needs to be able to configure addresses for wireless nodes in
an ad hoc network that are not routers.  Perhaps Emmanuel and I could better
emphasize this point in our draft, but even non-router nodes can be 
subject to
the problems noted in that draft.  So we have to find better language to
identify the wireless nodes that would be affected other than just calling
them "routers".

However, I still maintain that this document under discussion is _not_ a
requirements document, and that Paul seems to be discussing various
requirements for ad hoc networks.  Don't you agree that requirements
should be located in a separate document?  The only "requirement" that
we have placed in our small document is a need to deal with reality.

I'd also like to point out one somewhat unrelated point.  It is agreed, of
course, that MAC-layer problems can pre-empt the usefulness of
routing protocols.  However, routing protocols can themselves cause
congestion, and any techniques that we can bring to bear that reduce
congestion are likely to increase the overall effectiveness of the MAC
layer protocols also.  Furthermore, I think it is likely that people who
do not have good understanding about the nature of the wireless
medium are more likely to make design decisions for routing protocols
that would increase congestion.

What do you think?

Regards,
Charlie P.

Rex Buddenberg wrote:
> understand the implications of the differences between LANs and 
> WANs.   And by MANET stating that every end system is also a router, 
> we equally obfuscate the point.
>
> gigabit ethernet) within the hull.  End systems (Paul's printers) 
> attach to that LAN.  And those end systems don't need more than one 
> entry in the routing table and it's not likely to change.  (The analog 
> to your LAN at home is good).
> another ship and/or the commsta ashore.  While there's lots of noise 
> in the system, this is properly a pure radio-WAN problem -- entirely a 
> router-router interconnect one.  No end systems.  This presents MAC 
> and QoS control problems.  What's important is that they are isolated 
> from the end systems -- other side of the router.
>
> today to extend the internet to a fire truck.  But do we want the WAN 
> to reach to all the end systems on the fire truck?  Perhaps in the 
> near term, but this is not a long term good idea.  What makes better 
> sense is to plant a router on the fire truck and divide the problem 
> into a radio-WAN (sometimes slangily known as 'reachback') and the LAN 
> problem -- which might be solved by a WiFi splotch around the truck.  
> Once you start thinking about reaching to firefighters inside a 
> burning building, this makes more and more sense.    And reality ... 
> not much further in the future.  Should such a pattern not fit into 
> your automobile?  Instead of the cellphone reach to your end system, 
> it reaches to your car-resident router.  And you have several end 
> systems within the car that ... attach to a LAN.
> vision goggles (think webcam), laser rangefinder, VOIP rig.  As soon 
> as the list becomes plural, the idea of each end system being its own 
> The difficulty I repeatedly find in DoD programs (we're talking $B 
> here) is that they try to use wireless-LAN technology in a radio-WAN 
>>> of many other animals. It is a shame that smaller monsters are out 
>>> of scope (like 802.11 ad hoc) ...
>>>   
>>

---

From: Rex Buddenberg <[email-masked]>
Date: Tue, 24 Feb 2009 13:31:30 -0800

Charlie,

Thanks for note back ... this might be progress.  I was afraid that you 
might mash the 'irrelevant' button.

"However, I still maintain that this document under discussion is _not_ a
requirements document..."

I'm genuinely confused regarding just what the order of business needs 
to be and what the document artifacts that result from that should be. 

I've also been a much more intimate witness on how NOT to do such things 
within DoD than I ever wanted to be.  Are there, perhaps, some parallels?

How to get it backwards:
    1.  Shout  'the acquisition system is broken'.  This bloviating is 
good every four years.  So we apply some bandaids to the bureaucracy.
    2.  Muse that we need an architecture.  But we lack a useful 
definition of the term, so any answer is 'right' and the ones enshrined 
in the system have nothing to do with interoperability, modularity or 
interchangeable parts.
    3.  At this point, the exercise usually peters out, but if it 
doesn't, we have a requirements flailex.  Which tends to look a lot like 
a Dilbert cartoon.
    4.  And nobody seems to get to an observed taxonomy of 
interoperability.  Which is what the scenarios of the previous e-mail 
were hinting at.  (taxonomy, reference model, sorting model, Linnaeus)

Aside from the steps (e.g. #4) that are missing altogether, this is 
exactly the reverse order of business!  We can, and should, build the 
reference model without reference to requirements.  Is that were we are 
agreeing or disagreeing?  Or even on the same page?

Charles E. Perkins wrote:
>
> Hello Rex,
>
> Thanks for the long email.  I think that I do have a good handle on 
> the various
> do not have to be routers.  I certainly agree with this, and agree 
> that any work
>> because missing the point has made both MANET and autoconf harder 
>> than they need to be ... IMHO.  It's also made them less relevant to 
>> what I think I see in the future.
>> entry in the routing table and it's not likely to change.  (The 
>> analog to your LAN at home is good).
>> in the system, this is properly a pure radio-WAN problem -- entirely 
>> a router-router interconnect one.  No end systems.  This presents MAC 
>> into a radio-WAN (sometimes slangily known as 'reachback') and the 
>> LAN problem -- which might be solved by a WiFi splotch around the 
>> truck.  Once you start thinking about reaching to firefighters inside 
>> a burning building, this makes more and more sense.    And reality 
>> ... not much further in the future.  Should such a pattern not fit 
>> into your automobile?  Instead of the cellphone reach to your end 
>> system, it reaches to your car-resident router.  And you have several 
>> end systems within the car that ... attach to a LAN.
>>    And reality, again not too far in the future.  A Marine 
>> infantryman has several end systems, or at least potential end 
>> systems, as part of his combat outfit.  Radionav receiver, 
>> PDA/laptop, rifle scope, night vision goggles (think webcam), laser 
>> rangefinder, VOIP rig.  As soon as the list becomes plural, the idea 
>> of each end system being its own router (which implies it's own 
>> radio) ceases to make sense.
>>
>> experiment 40 years ago showed that was a lousy idea.  The MAC 
>> problem is orthogonal to the routing problems, but somewhat of a 
>> prerequisite: if the net has crashed due congestion, then your 
>> routing tables are likely to be fiction.
>>
>>>>> Subject: Re: [Autoconf] updated draft on aspects of multi-hop 
>>>>> wireless
>>>>> communication
>>>>>
>>>>>
>>>>> Hello Paul,
>>>>>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Tue, 24 Feb 2009 23:06:03 +0100

On Feb 24, 2009, at 20:02 PM, Rex Buddenberg wrote:

> Charlie,
>
> Paul has a reality check point and its worthwhile understanding  
> this because missing the point has made both MANET and autoconf  
> harder than they need to be ... IMHO.  It's also made them less  
> relevant to what I think I see in the future.
> services ... why are they not interoperable (or, in the rare  
> inverse instance, why are they interoperable)?
>
> WANs.   And by MANET stating that every end system is also a  
> router, we equally obfuscate the point.
>

<SNIP>

I think there's a fundamental misunderstanding here. I'll try to  
clarify it, if I can...

In an OSPF-routed network, for all that OSPF cares about, every  
"system is [an OSPF] router".  That doesn't preclude that an OSPF  
router may have interfaces towards other entities, called hosts --  
but as such hosts do not take part in routing (and in the routing  
protocol), they're just not relevant when talking about OSPF.

In a MANET-routed network, all systems that the MANET routing  
protocols care about are.....MANET routers. That doesn't preclude  
that a MANET router may have interfaces towards other entities,  
called hosts -- but as such hosts do not take part in routing (and in  
the routing protocol), they're just not relevant when talking about  
MANETs.

In other words.....it's perfectly fine to hang an Ethernet hub or an  
802.11 access point or whatnot off of a MANET router, assign a prefix  
to that link, hang hosts on that link --  and use the MANET routing  
protocols to exchange that prefix such that these hosts are routable/ 
reachable. It's not just perfectly fine, that's what MANET routing  
protocols are build to do ;)

I'd actually make the exact opposite point of the one you're making,  
Rex: every end system is a host -- intermediate systems running MANET  
protocols are routers. Hosts are unaware of if they're hanging off a  
MANET, OSPF, ISIS or other router -- they just see a classic IP link  
and an IP hop and likely a default route. The MANET, OSPF, ISIS or  
other router deals with the "routing stuff", including  
characteristics of links to other routers. Hosts never see that. This  
is as it should be.

Occasionally, a system in a MANET may in the same physical box have a  
logical router and a host  present. This isn't that unusual either  
for non-MANET networks.

So when we talk about systems being routers in MANETs, then it's  
simply because the systems that "we care about" are the routers.  
Hosts are hanging off (some of) these routers just fine, over classic  
IP links -- over which the usual slew of protocols works just fine  
(fortunately -- so we do not have to care about that ;) ).

What MANETs are concerned with are MANET routers and their  
interconnect to other MANET routers. Interconnect from MANET routers  
to hosts is no different from interconnect from a host to, say, an  
OSPF router.

Does this help?

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 25 Feb 2009 08:11:56 +0100

Minor comment:
I would compare an OLSR Router with an OSPF Router with an DYMO Router and
with an RIP Router, just to come up with a few protocols. I would not
compare an OSPF Router with an MANET Router, this doesn't make sense, an
OSPF Router could be a MANET Router.
I think MANET is a term for a category of routing protocols, similar to link
state protocols (but an orthogonal category).

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Thomas Heide Clausen
|Verzonden: dinsdag 24 februari 2009 23:06
|Aan: Rex Buddenberg
|CC: [email-masked]; Emmanuel Baccelli
|Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
|communication
|
|
|On Feb 24, 2009, at 20:02 PM, Rex Buddenberg wrote:
|
|> Charlie,
|>
|> Paul has a reality check point and its worthwhile understanding
|> this because missing the point has made both MANET and autoconf
|> harder than they need to be ... IMHO.  It's also made them less
|> relevant to what I think I see in the future.
|> My background is analyzing information systems in DoD and emergency
|> services ... why are they not interoperable (or, in the rare
|> inverse instance, why are they interoperable)?
|>
|> In dealing with some DoD bureaucracy, I'm finding that they don't
|> understand the implications of the differences between LANs and
|> WANs.   And by MANET stating that every end system is also a
|> router, we equally obfuscate the point.
|>
|
|<SNIP>
|
|I think there's a fundamental misunderstanding here. I'll try to
|clarify it, if I can...
|
|In an OSPF-routed network, for all that OSPF cares about, every
|"system is [an OSPF] router".  That doesn't preclude that an OSPF
|router may have interfaces towards other entities, called hosts --
|but as such hosts do not take part in routing (and in the routing
|protocol), they're just not relevant when talking about OSPF.
|
|In a MANET-routed network, all systems that the MANET routing
|protocols care about are.....MANET routers. That doesn't preclude
|that a MANET router may have interfaces towards other entities,
|called hosts -- but as such hosts do not take part in routing (and in
|the routing protocol), they're just not relevant when talking about
|MANETs.
|
|In other words.....it's perfectly fine to hang an Ethernet hub or an
|802.11 access point or whatnot off of a MANET router, assign a prefix
|to that link, hang hosts on that link --  and use the MANET routing
|protocols to exchange that prefix such that these hosts are routable/
|reachable. It's not just perfectly fine, that's what MANET routing
|protocols are build to do ;)
|
|I'd actually make the exact opposite point of the one you're making,
|Rex: every end system is a host -- intermediate systems running MANET
|protocols are routers. Hosts are unaware of if they're hanging off a
|MANET, OSPF, ISIS or other router -- they just see a classic IP link
|and an IP hop and likely a default route. The MANET, OSPF, ISIS or
|other router deals with the "routing stuff", including
|characteristics of links to other routers. Hosts never see that. This
|is as it should be.
|
|Occasionally, a system in a MANET may in the same physical box have a
|logical router and a host  present. This isn't that unusual either
|for non-MANET networks.
|
|So when we talk about systems being routers in MANETs, then it's
|simply because the systems that "we care about" are the routers.
|Hosts are hanging off (some of) these routers just fine, over classic
|IP links -- over which the usual slew of protocols works just fine
|(fortunately -- so we do not have to care about that ;) ).
|
|What MANETs are concerned with are MANET routers and their
|interconnect to other MANET routers. Interconnect from MANET routers
|to hosts is no different from interconnect from a host to, say, an
|OSPF router.
|
|Does this help?
|
|Thomas
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 25 Feb 2009 08:24:50 +0100

Minor comment on "Aloha experiment being a lousy idea": let's not forget
that this idea is used quite often. Think of old days Ethernet, WLAN and
signaling channel in cellular networks, just to come up with a few examples.

More important: I think we should focus on the IP layer, and stay away from
media access technology and related problems. Not that is not interesting or
important, it is not the focus of IETF in general to work on layer-2 stuff.

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Rex Buddenberg
|Verzonden: dinsdag 24 februari 2009 20:03
|Aan: Charles E. Perkins
|CC: [email-masked]; Emmanuel Baccelli
|Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
|communication
|
|Charlie,
|
|Paul has a reality check point and its worthwhile understanding this
|because missing the point has made both MANET and autoconf harder than
|they need to be ... IMHO.  It's also made them less relevant to what I
|think I see in the future.
|
|My background is analyzing information systems in DoD and emergency
|services ... why are they not interoperable (or, in the rare inverse
|instance, why are they interoperable)?
|
|In dealing with some DoD bureaucracy, I'm finding that they don't
|understand the implications of the differences between LANs and WANs.
|And by MANET stating that every end system is also a router, we equally
|obfuscate the point.
|
|Reality today.  Our ships have wired LANs (mostly fast etherrnet and
|gigabit ethernet) within the hull.  End systems (Paul's printers) attach
|to that LAN.  And those end systems don't need more than one entry in
|the routing table and it's not likely to change.  (The analog to your
|LAN at home is good).
|
|The problem that DoD has is not in the LAN; it's in the radio-WAN.
|Which is the link between the router in Radio Central and that in
|another ship and/or the commsta ashore.  While there's lots of noise in
|the system, this is properly a pure radio-WAN problem -- entirely a
|router-router interconnect one.  No end systems.  This presents MAC and
|QoS control problems.  What's important is that they are isolated from
|the end systems -- other side of the router.
|
|Reality ... not very far in the future.  We have all the technology
|today to extend the internet to a fire truck.  But do we want the WAN to
|reach to all the end systems on the fire truck?  Perhaps in the near
|term, but this is not a long term good idea.  What makes better sense is
|to plant a router on the fire truck and divide the problem into a
|radio-WAN (sometimes slangily known as 'reachback') and the LAN problem
|-- which might be solved by a WiFi splotch around the truck.  Once you
|start thinking about reaching to firefighters inside a burning building,
|this makes more and more sense.
|    And reality ... not much further in the future.  Should such a
|pattern not fit into your automobile?  Instead of the cellphone reach to
|your end system, it reaches to your car-resident router.  And you have
|several end systems within the car that ... attach to a LAN.
|    And reality, again not too far in the future.  A Marine infantryman
|has several end systems, or at least potential end systems, as part of
|his combat outfit.  Radionav receiver, PDA/laptop, rifle scope, night
|vision goggles (think webcam), laser rangefinder, VOIP rig.  As soon as
|the list becomes plural, the idea of each end system being its own
|router (which implies it's own radio) ceases to make sense.
|
|
|The difficulty I repeatedly find in DoD programs (we're talking $B here)
|is that they try to use wireless-LAN technology in a radio-WAN
|situation.  For example, we see satcom and air-ground specifications
|that persist in using contention access methods, when the Aloha
|experiment 40 years ago showed that was a lousy idea.  The MAC problem
|is orthogonal to the routing problems, but somewhat of a prerequisite:
|if the net has crashed due congestion, then your routing tables are
|likely to be fiction.
|
|
|For Paul: is this anything related to your comments?
|
|
|
|
|Charles E. Perkins wrote:
|>
|> Hello Paul,
|>
|> Paul Lambert wrote:
|>
|>>> I am almost certain they
|>>> should be considered out of scope for the document
|>>> under discussion.
|>>>
|>>
|>> In looking at the reference in the charter for "ad hoc" (RFC 2501)
|>> the defined MANET is a Chimera - a mythical beast made of the parts
|>> of many other animals. It is a shame that smaller monsters are out of
|>> scope (like 802.11 ad hoc) ...
|>>
|>
|> I am thoroughly mystified by your reply.  Just because certain
|> topics are out of scope for the small document by Emmanuel
|> and me, does not mean they are out of scope for [autoconf].
|> Isn't it possible to have more than one document?  Shouldn't we
|> collect requirements in a requirements document instead of every
|> other document that might be written?
|>
|> To be explicit, I am wholly in favor of making sure that
|> the results of [autoconf] are applicable to 802.11 ad hoc.
|> Did I say anything to imply otherwise?
|>
|> Regards,
|> Charlie P.
|>
|>> Paul
|>>
|>>
|>>
|>>
|>>> -----Original Message-----
|>>> From: Charles E. Perkins [mailto:[email-masked]]
|>>> Sent: Monday, February 23, 2009 10:21 AM
|>>> To: Paul Lambert
|>>> Cc: Emmanuel Baccelli; [email-masked]
|>>> Subject: Re: [Autoconf] updated draft on aspects of multi-hop
|wireless
|>>> communication
|>>>
|>>>
|>>> Hello Paul,
|>>>
|>>> The document isn't intended to suggest a list of work
|>>> items for consideration by [autoconf].  Instead, it is just
|>>> a description of common properties of radio and other
|>>> wireless links.  These properties are not quite universal,
|>>> but they are widespread.  Some of them can be alleviated
|>>> a bit by mechanisms below the network protocol level.
|>>>
|>>> So we are not suggesting requirements or work items.
|>>> Instead, we simply wanted to make as clear as possible
|>>> some of the characteristics of the transmission media
|>>> whose widespread availability is motivating the work
|>>> of [autoconf].
|>>>
|>>> Your list of issues would, I think, all fit best in a
|>>> requirements document.  I am almost certain they
|>>> should be considered out of scope for the document
|>>> under discussion.
|>>>
|>>> Regards,
|>>> Charlie P.
|>>>
|>>>
|>>> Paul Lambert 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
|>>>>
|>>>>
|>>>>
|>>
|>>
|>>
|>>
|>
|> _______________________________________________
|> Autoconf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/autoconf
|>
|
|--
|Rex Buddenberg
|Senior Lecturer
|Naval Postgraduate School
|Monterey, Ca 93943
|831/656-3576
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 25 Feb 2009 09:01:27 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Paul Lambert
|Verzonden: dinsdag 24 februari 2009 16:04
|Aan: Emmanuel Baccelli; [email-masked]
|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: [email-masked] [mailto:[email-masked]] On
|Behalf Of Emmanuel Baccelli
|Sent: Monday, February 23, 2009 5:01 AM
|To: [email-masked]
|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 <[email-masked]> 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: [email-masked] [mailto:[email-masked]] On
|Behalf Of Emmanuel Baccelli
|Sent: Monday, February 23, 2009 2:04 AM
|To: [email-masked]
|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
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 25 Feb 2009 09:22:41 +0100

Inline.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Thomas Heide Clausen
|Verzonden: dinsdag 24 februari 2009 0:21
|Aan: Charles E. Perkins
|CC: [email-masked]; Emmanuel Baccelli
|Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
|communication
|
|Hello Alex,
|
|To second Charlie here: in MANETs, routers:
|
|	o	ALWAYS have one MANET interface.
|	o	OFTEN they have other (non-MANET) interfaces
|	o	OCCASIONALLY have more than one MANET interface

I think the definition is still not clear.
Is it a requirement for a MANET Router to forward packets?
What is a MANET interface ? (I think I know, but I refer to the endless
discussion in [Autoconf])
Is the MANET a complete set of nodes, including attached hosts and
"classical routers"?

I think the term MANET is quite abstract and attempts to come up with strict
definitions tend to fail. For specifying protocols, we can come up with
strict definitions. We could say:
An OLSR Router:
 o   ALWAYS have one OLSR interface;
 o   OFTEN they have other (non-OLSR) interfaces;
 o   OCCASIONALLY have more than one OLSR interface.

|I.e. it is quite common for traffic to be forwarded over the same
|interface as the one on which it was received.

The attribute that traffic may be forwarded over the same interface as the
one on which it was received is not specific to MANET at all. Think of WLAN
AP, DSL/cable concentrators, FR/ATM/ISDN, dual-hop satcom etc. Sometimes we
use logical interfaces for links, sometimes we don't. Using logical
interfaces introduce problems utilizing layer-2 broadcast for IP broadcast /
multicast.
Please note that I do not suggest having detailed discussions on layer-2
technologies itself.

Teco.

|Thomas
|
|ps: and for the record, AFAIK all MANET wg routing protocols support
|all the situations listed above, i.e. a MANET router with a single or
|with multiple MANET interfaces and with or without other non-MANET
|interfaces.
|
|On 23Feb , 2009, at 23:01 , Charles E. Perkins wrote:
|
|>
|> Hello Alex,
|>
|> On this point I disagree.  I think it is better to show the
|> routers with a single network interface -- which is what
|> they have in real life.  This is also the reason that techniques
|> like split horizon aren't appropriate.
|>
|> Regards,
|> Charlie P.
|>
|>
|> Alexandru Petrescu wrote:
|>> Emmanuel, AUTOCONFers,
|>>
|>> Just a short clarifying point: I think it would be clarifying to
|>> illustrate the routers to have two interfaces.  Routers with only one
|>> interface aren't very typical.
|>>
|>> Just a note,
|>>
|>> Alex
|>>
|>> Emmanuel Baccelli a écrit :
|>>> 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
|>>>  [email-masked] https://www.ietf.org/mailman/listinfo/autoconf
|>>
|>> _______________________________________________
|>> Autoconf mailing list
|>> [email-masked]
|>> https://www.ietf.org/mailman/listinfo/autoconf
|>>
|>>
|>
|> _______________________________________________
|> Autoconf mailing list
|> [email-masked]
|> https://www.ietf.org/mailman/listinfo/autoconf
|
|_______________________________________________
|Autoconf mailing list
[email-masked]
|https://www.ietf.org/mailman/listinfo/autoconf

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 25 Feb 2009 10:16:26 +0100

Thanks for the updated draft.
Here some feedback:

On exposed node: I do not understand what is mentioned here. I think the
exposed node problem is communication from A to B (correct) and C to D
(reverse direction of arrow). With CSMA, transmit from C is delayed because
C noticed carrier busy caused by transmit from A (or CSMA/CA virtual carrier
sense by CTS from B) . The delay was not needed, as C transmission does not
affect B reception of frame transmitted by A.
I think exposed node is more a research problem and less an operational
problem.

On Hidden Terminal: I think this __is__ an operational problem, but handled
in some or many cases by a media access mechanism, like CSMA/CA or TDMA.
Some / many cases implies "not all" cases, e.g. CSMA/CA does not work for
multicast. And multicast may be of large importance in MANETs, e.g. MANET
routing protocol flooding.

I suggest swapping the two problems, mentioning the important one first.

The draft emphasizes problems introduced by limited radio range. Note that
it has also a welcome characteristic, that is spatial reuse. Be positive on
wireless communication one time ? :-)

Once again, I think:
  - We may say that router B is a neighbor of router A. In this
  terminology, there is no guarantee that router A is a neighbor of
  router B, even if router B a neighbor of router A.
is incorrect. B hears A and I would say A is a neighbor of A and A is listed
in B's neighbor table.
Is there a reason not to update the text, as we agreed on before?

Teco.

|-----Oorspronkelijk bericht-----
|Van: [email-masked] [mailto:[email-masked]] Namens
|Emmanuel Baccelli
|Verzonden: maandag 23 februari 2009 11:04
|Aan: [email-masked]
|Onderwerp: [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-
|commun
|ication-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

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 25 Feb 2009 13:47:15 +0100

On Feb 25, 2009, at 09:01 AM, Teco Boot wrote:

<SNIP>

> protocols for dynamic routing, we say routers run the Routing  

I'll speak for the network that I build....

If a node runs a MANET routing protocol, such as OLSR(v2), then that  
node is by [my] definition a router. It can have hosts attached to it  
on non-MANET interfaces, and it will over its MANET interface take  
part in a routing graph.

In OLSR(v2), a router can set its willingness to 0 (zero). That means  
that this router is unwilling to be selected as MPR and so not  
willing to forward traffic destined to *OTHER* MANET routers. It is,  
however, still forwarding traffic to and from the hosts attached to  
it, and so providing connectivity to these through the MANET.

You could consider it such:

	o	a HOST is an endpoint for communications, with no network-formation
		responsibilities;

	o	an OLSR(v2) router with "Willingness = 0 (zero)" is an "edge router":
		providing connectivity only to attached hosts by injecting prefixes
		for these into the routing domain, but otherwise disclaims network
		formation responsibilities

	o	an OLSR(v2) router with "Willingness > 0" is, if the topology  
suggests
		it, a "core router", also participating in the network formation and
		traffic forwarding for other OLSR(v2) routers.

So, to me, any "node running OLSR(v2)" is a router, and it will be  
forwarding traffic -- although potentially only to  the attached host 
(s) by acting as an edge-router.

> etc. Running routing protocols on hosts is being used already (e.g.  

Whatever happens between an OLSR(v2) router and its attached network  
or hosts is, as it should, no different from what happens between an  
OSPF router and its attached network or hosts.

So, while that's an interesting topic and discussion, it probably  
should be taken somewhere more general than AUTOCONF?

Thomas

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 25 Feb 2009 15:24:53 +0100

OK, now we have at least three classes of routers:
1: Core router: 
    - Forward packets
    - Advertize links
    - Advertize stub networks / external networks
    - Learn topology
2: Edge router (example from Thomas):
    - Forward packets
    - NOT advertize links
    - Advertize stub networks / external networks
    - Learn topology
3: My passive RIP example (built quite some time ago...)
    - NOT forward packets
    - NOT advertize links
    - NOT advertize stub networks / external networks
    - Learn topology
The last one is strictly spoken not a router. It is a "host running a
routing protocol".

For a protocol that constantly repeats topology info, a passive listener is
acceptable. 

For protocols that implement ACK based topology flooding (e.g. OSPF), the
node should be part of the hello and flooding mechanisms, but does not have
a requirement to inject links and thus does not forward packets.

Teco.

|-----Oorspronkelijk bericht-----
|Van: Thomas Heide Clausen [mailto:[email-masked]]
|Verzonden: woensdag 25 februari 2009 13:47
|Aan: Teco Boot
|CC: 'Paul Lambert'; [email-masked]; 'Emmanuel Baccelli'
|Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
|communication
|
|
|On Feb 25, 2009, at 09:01 AM, Teco Boot wrote:
|
|<SNIP>
|
|> |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.
|
|I'll speak for the network that I build....
|
|If a node runs a MANET routing protocol, such as OLSR(v2), then that
|node is by [my] definition a router. It can have hosts attached to it
|on non-MANET interfaces, and it will over its MANET interface take
|part in a routing graph.
|
|In OLSR(v2), a router can set its willingness to 0 (zero). That means
|that this router is unwilling to be selected as MPR and so not
|willing to forward traffic destined to *OTHER* MANET routers. It is,
|however, still forwarding traffic to and from the hosts attached to
|it, and so providing connectivity to these through the MANET.
|
|You could consider it such:
|
|	o	a HOST is an endpoint for communications, with no network-
|formation
|		responsibilities;
|
|	o	an OLSR(v2) router with "Willingness = 0 (zero)" is an "edge
|router":
|		providing connectivity only to attached hosts by injecting
|prefixes
|		for these into the routing domain, but otherwise disclaims
|network
|		formation responsibilities
|
|	o	an OLSR(v2) router with "Willingness > 0" is, if the
|topology
|suggests
|		it, a "core router", also participating in the network
|formation and
|		traffic forwarding for other OLSR(v2) routers.
|
|So, to me, any "node running OLSR(v2)" is a router, and it will be
|forwarding traffic -- although potentially only to  the attached host
|(s) by acting as an edge-router.
|
|> 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).
|
|Whatever happens between an OLSR(v2) router and its attached network
|or hosts is, as it should, no different from what happens between an
|OSPF router and its attached network or hosts.
|
|So, while that's an interesting topic and discussion, it probably
|should be taken somewhere more general than AUTOCONF?
|
|Thomas

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 25 Feb 2009 16:44:49 +0100

Hi Teco, inline

> I think exposed node is more a research problem and less an operational

I agree, but it may become more operational as multi-hop ad hoc networks are
more widely deployed. What do you think about this description of the
exposed node issues on wikipedia?
http://en.wikipedia.org/wiki/Exposed_terminal_problem

As for the use of CSMA/CA to cope with this, see my comment below.

> routing protocol flooding.

Yes you are right, most of the time, L2 will cope with these issues.
However, as you mention, not all the time, even with L2 technology that is
aware. For example because of multicast/broadcast, or because of
non-synchronization (common in multi-hop ad hoc networks).

In any case, maybe we should make clearer that this radio range limitation
aspect in multi-hop ad hoc networks causes some problems that force L2 to
use specific mechanisms (you cite CSMA/CA). Similarly it is causing some of
the problems described in Section 3 (and to some extent Section 4) at L3,
which have to be taken into account when designing L3 protocols that can
support such networks.

> I suggest swapping the two problems, mentioning the important one first.

I don't have a problem with reordering this ;)

> Is there a reason not to update the text, as we agreed on before?

I don't follow you here, maybe I misunderstood. If B is a neighbor of A, it
means that A hears B, and B is thus in A's routing table. It does not
necessarily mean that B hears A too, or that A is in B's routing table,
hence it does not mean that A is a neighbor of B too?

Emmanuel

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 25 Feb 2009 16:57:27 +0100

Alex, I think that what Charlie and Thomas want to say is basically:
- A router typically has several physical interfaces
- A router typically has just one MANET interface (although it may have
several)
- A router may have just one physical interface (for instance its MANET
interface)

Emmanuel

On Mon, Feb 23, 2009 at 11:01 PM, Charles E. Perkins <
[email-masked]> wrote:

>>> here is an update to the draft describing aspects of

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Feb 2009 17:06:18 +0100

> - A router may have just one physical interface (for instance its MANET 

Emmanuel, I agree with the first definition in the list.  I think it's 
probably the most widely accepted definition, among the three.

However, the draft pictures a router with only one interface, which is 
only the third in the list.

Alex

> 
> Emmanuel
> 
> 
> 
> On Mon, Feb 23, 2009 at 11:01 PM, Charles E. Perkins 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
> 
>     Hello Alex,
> 
>             following the fruitful discussions about initial version of
>             the document, here is an update to the draft describing
>             aspects of
>              [email-masked] <mailto:[email-masked]>
>         _______________________________________________
> 
>         Autoconf mailing list
>         [email-masked] <mailto:[email-masked]>

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 25 Feb 2009 23:35:28 +0100

On Feb 25, 2009, at 17:06 PM, Alexandru Petrescu wrote:

>> - A router typically has just one MANET interface (although it may  
>> have several)
>> - A router may have just one physical interface (for instance its  
>> MANET interface)
>
> Emmanuel, I agree with the first definition in the list.  I think  
> it's probably the most widely accepted definition, among the three.
>
> However, the draft pictures a router with only one interface, which  
> is only the third in the list.
>

I think that the point is that in a MANET as it is commonly deployed,  
one quite often find routers which have just one physical interface.

Thomas

>> <[email-masked]  
>> <mailto:[email-masked]>> wrote:
>>     Hello Alex,
>>             Again, the goal of this document is to identify a  
>> consensus
>>             about

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 26 Feb 2009 09:11:58 +0100

On Wed, Feb 25, 2009 at 11:35 PM, Thomas Heide Clausen <
[email-masked]> wrote:

> I think that the point is that in a MANET as it is commonly deployed, one
> quite often find routers which have just one physical interface.
>
> Thomas
>

... and if they have several interfaces, they typically have just one
interface of "type" MANET. This is why it make sense to present a
description of what's going on on MANETs reduced to a MANET-centric view,
where nodes typically have one (MANET) interface. However, again, there is
no issue with nodes having several interfaces (ex. HNA in RFC3626 etc.).

Emmanuel

>>> [email-masked] <mailto:[email-masked]>>
>>> wrote:
>>>    Hello Alex,

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Feb 2009 10:02:00 -0800

Hello Teco,

I don't think anyone answered all of your questions yet...

Here are my answers for some of them.

> I think exposed node is more a research problem and less an operational

The picture as drawn is a correct representation of the exposed node 
problem.
RtrC cannot receive packets from RtrD because it's getting interference from
the transmissions sent by RtrA.  So, the point about transmission from C 
is not
relevant.

> I suggest swapping the two problems, mentioning the important one first.

I think that would be a good idea.

> wireless communication one time ? :-)

O.K.  We can mention that.  But the point of the draft is not to
be negative -- only to explicitly point out some of the well-known
realities of radio transmissions.
> Is there a reason not to update the text, as we agreed on before?

I don't remember the previous discussion, but the fact that there is
this disagreement illustrates the real need to identify some unambiguous
and agreeable terminology for us to use during our discussions.

So, if  B hears A either
(i) A is a neighbor of B (your interpretation), or
(ii) B is a neighbor of A (what was in our draft).
I'm happy to settle on either interpretation, but it would
be nice if there were some consensus about it on the
mailing list.  I am assuming one of the two possible
resolutions to the typo in your text.  Maybe it is a moot
point anyway because, if the link is sufficiently
asymmetric, either:
(a) A is a neighbor of B, but A doesn't know it -- or,
(ii) B is a neighbor of A, but A doesn't know it.
So for asymmetric links, the concept of "neighbor" is
really confusing and maybe we should disqualify the
use of that term unless the links are symmetric.
Or, perhaps best, we should include some of these
points directly in the text of the draft instead of just
noting whatever emerges as consensus on the list.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 26 Feb 2009 10:10:31 -0800

Hello Rex,

... following up ...

> to be and what the document artifacts that result from that should be.

I think that our small document on aspects of wireless communication is 
a good first step,
and aims to be quite non-controversial.  Even so, it appears to be 
controversial, which I
take to be a pretty good indicator that it is needed, and needed 
immediately.

> I've also been a much more intimate witness on how NOT to do such 
> things within DoD than I ever wanted to be.  Are there, perhaps, some 
> parallels?
>
> How to get it backwards:
>

...  I'd be curious to find out if you really think these steps are 
representative
of  a way forward that starts with our small "aspects" contribution.

> reference model without reference to requirements.  Is that were we 
> are agreeing or disagreeing?  Or even on the same page?

Yes, this is a good question, but I think the answer would have to come 
from you.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Thu, 26 Feb 2009 21:22:42 +0100

Hi Emmanuel,  inline

Van: [email-masked] [mailto:[email-masked]] Namens
Emmanuel Baccelli
Verzonden: donderdag 26 februari 2009 9:47
Aan: Teco Boot
Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
communication

Hi Teco, thanks for your feedback, please see inline.

On Wed, Feb 25, 2009 at 5:16 PM, Teco Boot <[email-masked]> wrote:

Inline.

Van:  <mailto:[email-masked]> [email-masked] [mailto:
<mailto:[email-masked]> [email-masked]] Namens
Emmanuel Baccelli
Verzonden: woensdag 25 februari 2009 16:45
Aan:  <mailto:[email-masked]> [email-masked]
Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
communication

Hi Teco, inline

OK, this ref depicts the arrow in the right direction.

Maybe one would say some L2 technology solves this completely, e.g. fixed
slot TDMA. Maybe not really ad hoc and limited scalability, but no hidden
terminal probem here J

OK. Note however that for TDMA you need synchronization. It's not so common
in the decentralized, multi-hop environments we are addressing in the draft.
But I agree, we could say something like "some popular L2 technologies have
these aspects/issues, so we need to take that into account at L3".

Teco:

Let's specify the L2 technology, to circumvent confusion.

CSMA/CA (e.g WLAN with RTS-CTS enabled) unicast traffic and TDMA does not
have a hidden terminal problem. 

Plain CSMA, also being used by broadcast and multicast in a CSMA/CA network
has the hidden terminal problem.

Different people may have different opinions on "popular L2 technology".

For the hidden terminal problem: I agree that this L2 problem affects L3.

For exposed node, I don't see this effect. 

Can you explain a little more, why? As far as I can see, we potentially get
the same result: radio signal collision/retransmission. As explained in
http://en.wikipedia.org/wiki/Exposed_terminal_problem 

Teco:

Maybe I have another wiki page as you have.

Can you provide text from wiki with the terms "collision" or
"retransmission"?

My page mentions only "prevented from sending", i.e. delay.

if the nodes are not synchronised the problem may occur that the sender will
not hear the CTS or the ACK during the transmission of data of the second
sender. 

Teco:

This text is on the wiki page I see. It is a special case, where the exposed
terminal problem is not solved. It is not a collision or whatsoever. By the
way, I wonder if 802.11 really circumvents the Exposed Node problem. 

See http://wifi.cs.st-andrews.ac.uk/wifiexposednode.html for a more detailed
explanation. 

Anyways, I agree that it is not the main issue for L3, but again, it is
noteworthy, as an illustration of issues that come from the fact that radio
ranges are limited, and overlapping, a fact that must be taken into account
at L3 in the context of networks such as described in this draft.

Teco:

After having consensus on what the Exposed Node problem is, we can decide on
removing it from the text. 

I would say: remove, as the Exposed Node problem does not affect L3.

[skipped some text]

Once again, I think:

B is member of set S and can hear A.

B will store the received info in the neighbor table.

So from the viewpoint of B, A is a neighbor.

This is still confusing for me, but I guess this is just a matter of
wording. The essential message here is:

B=>A does not imply A=>B, whatever words you want to express the arrow with.

Teco:

The scenario in the draft is: B hears A. Let us use this scenario. OK?

In the draft, which is coherent as far as I can see, we know a priori that B
is a neighbor of A. 

Teco:

Who is "we"? God only knows.

We imply from this that B is in S(A), so that A hears B. And we can't imply
from this that B hears A.

Teco:

Now you are confusing me. What scenario do you have in mind? B is in set S
and can hear A (your draft) or otherwise (above text)?  

If you want translate the arrows in the reverse with the same vocabulary
there is no problem, but I don't see the point really, because it is correct
as is.

Teco:

As replied to Charlie, I prefer the option that corresponds with what
routers tell you and not what God only knows.

[skipped text]

Regards, Teco