Re: [manet] Re: [Manet-dt] Review Request

Brian Adamson <adamson@itd.nrl.navy.mil> Mon, 09 April 2007 18:11 UTC

Return-path: <manet-dt-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HayKe-00070u-MK; Mon, 09 Apr 2007 14:11:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HayKd-00070m-UJ; Mon, 09 Apr 2007 14:11:11 -0400
Received: from s2.itd.nrl.navy.mil ([132.250.83.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HayKb-0008Ei-Ja; Mon, 09 Apr 2007 14:11:11 -0400
Received: from smtp.itd.nrl.navy.mil (smtp.itd.nrl.navy.mil [132.250.86.3]) by s2.itd.nrl.navy.mil (8.13.6+Sun/8.12.8) with SMTP id l39IAe96004371; Mon, 9 Apr 2007 14:10:48 -0400 (EDT)
Received: from [192.168.1.201] ([132.250.218.64]) by smtp.itd.nrl.navy.mil (SMSSMTP 4.1.12.43) with SMTP id M2007040914104729909 ; Mon, 09 Apr 2007 14:10:47 -0400
Mime-Version: 1.0
Message-Id: <p06240800c24030257477@[192.168.1.201]>
In-Reply-To: <461543A5.4070400@inria.fr>
References: <200704041705.l34H5iDQ028743@s2.itd.nrl.navy.mil> <461543A5.4070400@inria.fr>
Date: Mon, 09 Apr 2007 14:10:47 -0400
To: Philippe Jacquet <philippe.jacquet@inria.fr>, Justin Dean <jdean@itd.nrl.navy.mil>
From: Brian Adamson <adamson@itd.nrl.navy.mil>
Subject: Re: [manet] Re: [Manet-dt] Review Request
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: 'manet' <manet@ietf.org>, manet-dt@ietf.org
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

I have had some experience with several different 
military systems that work sans unicast routing. 
These have included some multicast VoIP (imagine 
a multi-hop walkie-talkie network) along with 
some other low duty cycle applications (e.g. 
position reporting) that are group scope 
communication (serviceable by SMF) ... there are 
several cases like this where unicast routing 
(and its overhead) may be unnecessary, 
particularly in systems with more limited 
throughput than the wireless LAN link layer 
technologies we are used to playing with.


While in the past, these have been stand-alone 
networks, there is increased interest in 
inter-connecting these networks to backbone or 
infrastructure networks.  Some of these nets may 
be of limited capacity, etc and be dedicated to a 
small set of applications/services that are group 
communications only.   These application might 
tap into multicast data sources from the 
infrastructure/backbone networks and thus the IP 
is useful instead of some proprietary protocol 
suite.  The result may be an SMF edge network, 
multi-hop, but without unicast routing ... You 
might also imagine SMF co-existing with an 
on-demand unicast routing protocol that is used 
somewhat sparingly ... SMF would perform 
proactive neighborhood discovery to support S-MPR 
or whatever and the unicast routing would only be 
invoked upon demand

At 8:44 PM +0200 4/5/07, Philippe Jacquet wrote:
>A network with never a call to unicast routing? 
>Do you have an example of this?
>
>Philippe
>
>Justin Dean a écrit :
>>SMF is designed such that is may run in a stand alone mode where only
>>multicast routing is required or it can be run alongside a unicast protocol
>>(either sharing information or not).  In the past there have been some
>>implementations of OLSR which allow for encapsulating packets and using the
>>s-mpr forwarding tree to disiminate the packets to all nodes in the network.
>>This solution works for some networks but was tied to the running of OLSR.
>>SMF takes away that requirement and allows for multicast routing which can
>>be independent of what unicast routing protocol may or may not be running on
>>the network. 
>>One application which may help understand the usage might be emergancy
>>response teams using wireless VIP to communicate with others who are close
>>without any specific need for point to point communication.
>>
>>Justin
>>
>>-----Original Message-----
>>From: Philippe Jacquet 
>>[mailto:philippe.jacquet@inria.fr] Sent: 
>>Tuesday, April 03, 2007 4:47 PM
>>Cc: 'manet'; manet-dt@ietf.org
>>Subject: [manet] Re: [Manet-dt] Review Request
>>
>>Hello,
>>
>>About SMF, I am asking some questions for clarification
>>
>>I don't understand very well the purpose of the protocol. Maybe this is
>>because I don't have a clear view of its application context.
>>
>>Is SMF intended to be the only routing protocol running in a network or will
>>it run together with a unicast protocol?
>>
>>Best regards,
>>
>>Philippe
>>
>>_______________________________________________
>>manet mailing list
>>manet@ietf.org
>>https://www1.ietf.org/mailman/listinfo/manet
>>
>>
>>_______________________________________________
>>Manet-dt mailing list
>>Manet-dt@ietf.org
>>https://www1.ietf.org/mailman/listinfo/manet-dt
>>
>
>_______________________________________________
>Manet-dt mailing list
>Manet-dt@ietf.org
>https://www1.ietf.org/mailman/listinfo/manet-dt


-- 
Brian

Brian Adamson
<adamson@itd.nrl.navy.mil>

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