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