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

Thomas Heide Clausen <> Wed, 25 February 2009 12:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 163EA3A6900 for <>; Wed, 25 Feb 2009 04:45:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8fhaZZlhplbE for <>; Wed, 25 Feb 2009 04:45:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 285953A688A for <>; Wed, 25 Feb 2009 04:45:11 -0800 (PST)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <>) id 1LcJ8k-000PM1-8l; Wed, 25 Feb 2009 12:45:30 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX18VHXWx4E2PjXt7W4eG2wUy
In-Reply-To: <002b01c9971f$42efec50$c8cfc4f0$@nl>
References: <> <> <> <> <002b01c9971f$42efec50$c8cfc4f0$@nl>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <>
Content-Transfer-Encoding: 7bit
From: Thomas Heide Clausen <>
Date: Wed, 25 Feb 2009 13:47:15 +0100
To: "Teco Boot" <>
X-Mailer: Apple Mail (2.753.1)
Cc:, 'Emmanuel Baccelli' <>
Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 25 Feb 2009 12:45:12 -0000

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


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

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