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

"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Thu, 29 June 2006 16:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzYN-0005hP-Tx; Thu, 29 Jun 2006 12:39:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvzYM-0005hF-D7 for manet-dt@ietf.org; Thu, 29 Jun 2006 12:39:42 -0400
Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvzYL-0006sS-0S for manet-dt@ietf.org; Thu, 29 Jun 2006 12:39:42 -0400
Received: from ngbaux (ngbaux.msd.bae.co.uk [141.245.68.234]) by smtp1.bae.co.uk (Switch-3.1.9/Switch-3.1.9) with ESMTP id k5TGcoY4001615 for <manet-dt@ietf.org>; Thu, 29 Jun 2006 17:39:37 +0100 (BST)
Received: from glkas0002.GREENLNK.NET ([10.15.184.52]) by ngbaux.net.bae.co.uk (PMDF V5.2-33 #44998) with ESMTP id <0J1M00C1ERQWRT@ngbaux.net.bae.co.uk> for manet-dt@ietf.org; Thu, 29 Jun 2006 17:42:32 +0100 (BST)
Received: from glkms0002.GREENLNK.NET ([10.15.184.2]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Thu, 29 Jun 2006 17:38:03 +0100
Received: from glkms0008.GREENLNK.NET ([10.15.184.8]) by glkms0002.GREENLNK.NET with Microsoft SMTPSVC(5.0.2195.6713); Thu, 29 Jun 2006 17:38:02 +0100
Date: Thu, 29 Jun 2006 17:38:02 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
Subject: RE: [Manet-dt] IANA Port & Multicast Addresses
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Ian Chakeres <ian.chakeres@gmail.com>, manet-dt@ietf.org
Message-id: <C1DE3C7469FE5A4D95F9BF0F332D8B8D01EEE606@glkms0008>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6556.0
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: quoted-printable
Thread-Topic: [Manet-dt] IANA Port & Multicast Addresses
Thread-Index: AcabS23TcWp4K/AiQTi9vmew28NkMgACbDQgABCbuAAAADessA==
Content-class: urn:content-classes:message
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-OriginalArrivalTime: 29 Jun 2006 16:38:02.0842 (UTC) FILETIME=[63CF0BA0:01C69B9A]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
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

> 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