RE: [Manet-dt] IANA Port & Multicast Addresses

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 29 June 2006 16:48 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzgf-00007w-Qa; Thu, 29 Jun 2006 12:48:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvzge-00007h-6A for manet-dt@ietf.org; Thu, 29 Jun 2006 12:48:16 -0400
Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvzgc-0008Rd-SG for manet-dt@ietf.org; Thu, 29 Jun 2006 12:48:16 -0400
Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id k5TGib8x029927; Thu, 29 Jun 2006 09:44:38 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k5TGib329587; Thu, 29 Jun 2006 11:44:37 -0500 (CDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 09:44:32 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Manet-dt] IANA Port & Multicast Addresses
Date: Thu, 29 Jun 2006 09:44:32 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1017740D4@XCH-NW-7V2.nw.nos.boeing.com>
In-Reply-To: <C1DE3C7469FE5A4D95F9BF0F332D8B8D01EEE606@glkms0008>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Manet-dt] IANA Port & Multicast Addresses
Thread-Index: AcabS23TcWp4K/AiQTi9vmew28NkMgACbDQgABCbuAAAADessAAAnA2w
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Dearlove, Christopher \(UK\)" <chris.dearlove@baesystems.com>, "Ian Chakeres" <ian.chakeres@gmail.com>, <manet-dt@ietf.org>
X-OriginalArrivalTime: 29 Jun 2006 16:44:32.0966 (UTC) FILETIME=[4C573E60:01C69B9B]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Cc:
X-BeenThere: manet-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MANET Design Team <manet-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/manet-dt>
List-Post: <mailto:manet-dt@ietf.org>
List-Help: <mailto:manet-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=subscribe>
Errors-To: manet-dt-bounces@ietf.org

What about a theoretical node that would participate in the
neighbor discovery protocol on a MANET link but not the MANET
routing protocol? That node would be able to form bidirectional 
links with neighboring MANET routers, but all of the traffic
directed to it would have to go through a router. Should we
allow for such a possibility?

Fred
Fred.l.templin@boeing.com

-----Original Message-----
From: Dearlove, Christopher (UK) [mailto:chris.dearlove@baesystems.com] 
Sent: Thursday, June 29, 2006 9:38 AM
To: Templin, Fred L; Ian Chakeres; manet-dt@ietf.org
Subject: RE: [Manet-dt] IANA Port & Multicast Addresses


> We have been discussing this internally too. I think the
> question is, is it possible to have a node on a MANET
> link that is a neighbor of a MANET router but does not
> participate in the MANET routing protocol itself? If so,
> then it might make sense to have an "All MANET Nodes"
> multicast address that is different from "All MANET
> Routers". (And if not, why not?)

I would narrow this further to whether it is possible
using OLSRv2, DYMO or SMF as those are what we are
working on. If it turns out there's a later protocol
(e.g. an autoconf protocol) that this is relevant for
then we can add this later. Either IANA's multicast
addresses aren't running out, so we can wait, or they
are, so we really shouldn't take one we don't absolutely
need.

But ignoring all that and just trying to consider the
question, let's consider a node that is part of the
MANET in the sense that it's similarly wirelessly
equipped but won't participate in a protocol. Then
it will see some broadcast packets - in fact it will
see all of them if flooding is blind, and everyone
transmits every packet, but it won't (in general)
see all of them if flooding is optimised (MPR, CDS,
whatever). It's a definite step below e.g. OLSR
willingness zero nodes that (in OLSRv2, and slightly
simplifying) take part in the HELLO aspects of OLSRv2,
but not the TC aspects. But if the node refuses to
participate at all then the absolute best other nodes
can do is drop back to blind flooding, or else try
some sort of method to deduce such node's existence
based on something they do, which if it became reliable
I'd call participating in a protocol. Or at least that's
the best I can see.

I actually did consider such nodes in some theoretical
idea I played around with once, but there were two
points about that work: I didn't think that aspect of it
was a good idea, and it also was just that - theoretical.


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt