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

"Teco Boot" <> Wed, 25 February 2009 14:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EDF5928C1AC for <>; Wed, 25 Feb 2009 06:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.586
X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sOCzhAHOUTwh for <>; Wed, 25 Feb 2009 06:24:43 -0800 (PST)
Received: from (hpsmtp-eml17.KPNXCHANGE.COM []) by (Postfix) with ESMTP id A112328C1BE for <>; Wed, 25 Feb 2009 06:24:42 -0800 (PST)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 15:24:58 +0100
Received: from M90Teco ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 15:24:57 +0100
From: "Teco Boot" <>
To: "'Thomas Heide Clausen'" <>
References: <> <> <> <> <002b01c9971f$42efec50$c8cfc4f0$@nl> <>
In-Reply-To: <>
Date: Wed, 25 Feb 2009 15:24:53 +0100
Message-ID: <006101c99754$d3468130$79d38390$@nl>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcmXRvMrCIUDhQc3Q1O/CKSNyn8YqQADDvkg
Content-Language: nl
X-OriginalArrivalTime: 25 Feb 2009 14:24:57.0943 (UTC) FILETIME=[D5F52670:01C99754]
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 14:24:47 -0000

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

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.


|-----Oorspronkelijk bericht-----
|Van: Thomas Heide Clausen []
|Verzonden: woensdag 25 februari 2009 13:47
|Aan: Teco Boot
|CC: 'Paul Lambert';; 'Emmanuel Baccelli'
|Onderwerp: Re: [Autoconf] updated draft on aspects of multi-hop wireless
|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-
|		responsibilities;
|	o	an OLSR(v2) router with "Willingness = 0 (zero)" is an "edge
|		providing connectivity only to attached hosts by injecting
|		for these into the routing domain, but otherwise disclaims
|		formation responsibilities
|	o	an OLSR(v2) router with "Willingness > 0" is, if the
|		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?