Re: [Autoconf] updated draft on aspects of multi-hop wireless communication
Thomas Heide Clausen <ietf@thomasclausen.org> Wed, 25 February 2009 12:45 UTC
Return-Path: <ietf@thomasclausen.org>
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 163EA3A6900 for <autoconf@core3.amsl.com>; Wed, 25 Feb 2009 04:45:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 8fhaZZlhplbE for <autoconf@core3.amsl.com>; Wed, 25 Feb 2009 04:45:11 -0800 (PST)
Received: from mho-01-bos.mailhop.org (mho-01-bos.mailhop.org [63.208.196.178]) by core3.amsl.com (Postfix) with ESMTP id 285953A688A for <autoconf@ietf.org>; Wed, 25 Feb 2009 04:45:11 -0800 (PST)
Received: from aste-genev-bois-153-1-76-71.w86-203.abo.wanadoo.fr ([86.203.162.71] helo=[192.168.147.109]) by mho-01-bos.mailhop.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from <ietf@thomasclausen.org>) id 1LcJ8k-000PM1-8l; Wed, 25 Feb 2009 12:45:30 +0000
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 86.203.162.71
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18VHXWx4E2PjXt7W4eG2wUy
In-Reply-To: <002b01c9971f$42efec50$c8cfc4f0$@nl>
References: <be8c8d780902230203k5f0ffb38m97d817aff9d95554@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D135@SC-VEXCH2.marvell.com> <be8c8d780902230501n2fb2f0b7jb9e4b9278144c9f9@mail.gmail.com> <7BAC95F5A7E67643AAFB2C31BEE662D01489D23A@SC-VEXCH2.marvell.com> <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: <6F272E51-6C0E-4E99-8215-00487C30343B@thomasclausen.org>
Content-Transfer-Encoding: 7bit
From: Thomas Heide Clausen <ietf@thomasclausen.org>
Date: Wed, 25 Feb 2009 13:47:15 +0100
To: Teco Boot <teco@inf-net.nl>
X-Mailer: Apple Mail (2.753.1)
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 12:45:12 -0000
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
- [Autoconf] updated draft on aspects of multi-hop … Emmanuel Baccelli
- Re: [Autoconf] updated draft on aspects of multi-… Paul Lambert
- Re: [Autoconf] updated draft on aspects of multi-… Emmanuel Baccelli
- Re: [Autoconf] updated draft on aspects of multi-… Charles E. Perkins
- Re: [Autoconf] updated draft on aspects of multi-… Alexandru Petrescu
- Re: [Autoconf] updated draft on aspects of multi-… Charles E. Perkins
- Re: [Autoconf] updated draft on aspects of multi-… Thomas Heide Clausen
- Re: [Autoconf] updated draft on aspects of multi-… Paul Lambert
- Re: [Autoconf] updated draft on aspects of multi-… Paul Lambert
- Re: [Autoconf] updated draft on aspects of multi-… Charles E. Perkins
- Re: [Autoconf] updated draft on aspects of multi-… Rex Buddenberg
- Re: [Autoconf] updated draft on aspects of multi-… Charles E. Perkins
- Re: [Autoconf] updated draft on aspects of multi-… Rex Buddenberg
- Re: [Autoconf] updated draft on aspects of multi-… Thomas Heide Clausen
- Re: [Autoconf] updated draft on aspects of multi-… Teco Boot
- Re: [Autoconf] updated draft on aspects of multi-… Teco Boot
- Re: [Autoconf] updated draft on aspects of multi-… Teco Boot
- Re: [Autoconf] updated draft on aspects of multi-… Teco Boot
- Re: [Autoconf] updated draft on aspects of multi-… Teco Boot
- Re: [Autoconf] updated draft on aspects of multi-… Thomas Heide Clausen
- Re: [Autoconf] updated draft on aspects of multi-… Teco Boot
- Re: [Autoconf] updated draft on aspects of multi-… Emmanuel Baccelli
- Re: [Autoconf] updated draft on aspects of multi-… Emmanuel Baccelli
- Re: [Autoconf] updated draft on aspects of multi-… Alexandru Petrescu
- Re: [Autoconf] updated draft on aspects of multi-… Thomas Heide Clausen
- Re: [Autoconf] updated draft on aspects of multi-… Emmanuel Baccelli
- Re: [Autoconf] updated draft on aspects of multi-… Charles E. Perkins
- Re: [Autoconf] updated draft on aspects of multi-… Charles E. Perkins
- Re: [Autoconf] updated draft on aspects of multi-… Teco Boot