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

"Teco Boot" <teco@inf-net.nl> Wed, 25 February 2009 14:24 UTC

Return-Path: <teco@inf-net.nl>
X-Original-To: autoconf@core3.amsl.com
Delivered-To: autoconf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDF5928C1AC for <autoconf@core3.amsl.com>; Wed, 25 Feb 2009 06:24:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.586
X-Spam-Level:
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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOCzhAHOUTwh for <autoconf@core3.amsl.com>; Wed, 25 Feb 2009 06:24:43 -0800 (PST)
Received: from hpsmtp-eml17.kpnxchange.com (hpsmtp-eml17.KPNXCHANGE.COM [213.75.38.117]) by core3.amsl.com (Postfix) with ESMTP id A112328C1BE for <autoconf@ietf.org>; Wed, 25 Feb 2009 06:24:42 -0800 (PST)
Received: from cpsmtp-eml103.kpnxchange.com ([213.75.84.103]) by hpsmtp-eml17.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 15:24:58 +0100
Received: from M90Teco ([86.83.9.22]) by cpsmtp-eml103.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 25 Feb 2009 15:24:57 +0100
From: "Teco Boot" <teco@inf-net.nl>
To: "'Thomas Heide Clausen'" <ietf@thomasclausen.org>
References: <be8c8d780902230203k5f0ffb38m97d817aff9d95554@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <be8c8d780902230501n2fb2f0b7jb9e4b9278144c9f9@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D23A@SC-VEXCH2.marvell.com> <002b01c9971f$42efec50$c8cfc4f0$@nl> <6F272E51-6C0E-4E99-8215-00487C30343B@thomasclausen.org>
In-Reply-To: <6F272E51-6C0E-4E99-8215-00487C30343B@thomasclausen.org>
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: autoconf@ietf.org, 'Emmanuel Baccelli' <Emmanuel.Baccelli@inria.fr>
Subject: Re: [Autoconf] updated draft on aspects of multi-hop wireless communication
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=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
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:ietf@thomasclausen.org]
|Verzonden: woensdag 25 februari 2009 13:47
|Aan: Teco Boot
|CC: 'Paul Lambert'; autoconf@ietf.org; '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