Subject: [manet] DLEP and modem Link Property Advertisements

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Mon, 22 Oct 2012 14:10:27 -0500

A few months ago (time flies), the authors of modemLPA have been in discussion with the authors of
   "Dynamic Link Exchange Protocol (DLEP)" [I-D.ietf-manet-dlep] to
   determine if DLEP will fullfil the needs that ModemLPA is targeted
   at.  DLEP is currently a client/server session oriented protocol that
   provides link layer information to directly connected devices -
   generally routers.  The Modem Link Property Advertisment protocol
   broadcasts link status notifications to directly-attached devices and
   devices or applications that may be multiple hops away from the modem
   (or other sending device).

   It should be possible to use the DLEP message formats without all the
   signalling required for the DLEP client/server session to perform the
   functions addressed in this draft.  The modem would simply provide
   link states out via multicast or unicast UDP datagrams (DLEP-Lite).
   Whether or not this is a good idea, or acceptable to the manet group,
   is yet to be determined.

In the mean time, This modemLPA document was originally submitted to the IRTF mobopts research group as an individual submission draft-ivancic-mobopts-modemlpa-01.  That research group as recently closed down.  I am looking for a new place to put updates until a decision is made on DLEP-Lite. Is the manet group the right place?  I really don't know if this is the right group or if someplace else may be more appropriate.  I see no other working groups or research groups really looking at layer-2 triggers.

Finally:

   A PERL script, modem-LPA-packetgen.pl<http://modem-LPA-packetgen.pl>, has been placed in sourceforge
   as open source software.  The PERL script generates modemLPA packets
   base on the modem link property advertisement draft,
   "draft-ivancic-mobopts-modemlpa-01".

   The script was used to demonstrate modemLPA by controlling the rate
   on a file transfer protocol.  The file transfer protocol used was
   Saratoga and is implemented in a PERL script.  The Saratoga PERL
   script is available on SourceForge.  Search for saratoga and the
   script will be in the directory saratoga-v1-perl.

   This script and the Saratoga implementation currently use a multicast
   address of 226.1.1.2.  The all routers address of 224.0.0.2 is
   suppose to be used, but the particular Linux machines we where
   running on did not want to pass 224.0.0.2 and we did not have
   sufficient time to determine why.

   Eventually, we hope to include code for GNU radios that implement
   modemLPA (Or perhap DLEP-lite).

   Code is available for modemLPA from
   http://sourceforge.net/projects/modemlpa/

   Code is available for Saratoga from
   http://saratoga.cvs.sourceforge.net/viewvc/saratoga/

I am currently planning on attending the IETF meetings in Atlanta.

- Will Ivancic

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Mon, 22 Oct 2012 20:02:10 +0000

Will,

If you have some time, I'd like to meet with you and discuss "DLEP-lite".

Regards,
Stan

On Oct 22, 2012, at 3:10 PM, Ivancic, William D. (GRC-RHN0) wrote:

Finally:

   A PERL script, modem-LPA-packetgen.pl<http://modem-LPA-packetgen.pl/>, has been placed in sourceforge
   as open source software.  The PERL script generates modemLPA packets
   base on the modem link property advertisement draft,
   "draft-ivancic-mobopts-modemlpa-01".

- Will Ivancic

_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/manet

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Oct 2012 09:06:26 +0200

On 10/22/2012 09:10 PM, Ivancic, William D. (GRC-RHN0) wrote:
> It should be possible to use the DLEP message formats without all
> the signalling required for the DLEP client/server session to perform
> the functions addressed in this draft.  The modem would simply
> provide link states out via multicast or unicast UDP datagrams
> (DLEP-Lite). Whether or not this is a good idea, or acceptable to the
> manet group, is yet to be determined.

I have an implementation that does this with a RFC5444 compliant 
protocol (was written in April this year).

> In the mean time, This modemLPA document was originally submitted to
> the IRTF mobopts research group as an individual submission
> draft-ivancic-mobopts-modemlpa-01.  That research group as recently
> closed down.  I am looking for a new place to put updates until a
> decision is made on DLEP-Lite. Is the manet group the right place?  I
> really don't know if this is the right group or if someplace else may
> be more appropriate.  I see no other working groups or research
> groups really looking at layer-2 triggers.

The concept of my "stateless-rfc5444-dlep" was to create a 'core set' of 
functionality that allow simplified use cases like you describe.

In the most simple one, the Radio just sends out two types of messages 
via multicast or unicast in regular intervals. The Router just listens 
to the messages and updates its internal databases according the them.

One message contains information about the network the radio is attached 
to, the second message contains information about the known neighbors of 
the radio.

Henning Rogge

-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Bo Berry <[email-masked]>
Date: Tue, 23 Oct 2012 07:13:58 -0400

Henning,
I've seen the draft, you should submit it to the WG.

-Bo

On Oct 23, 2012, at 3:06 AM, Henning Rogge wrote:

> I have an implementation that does this with a RFC5444 compliant protocol (was written in April this year).
> 
> The concept of my "stateless-rfc5444-dlep" was to create a 'core set' of functionality that allow simplified use cases like you describe.
> 
> In the most simple one, the Radio just sends out two types of messages via multicast or unicast in regular intervals. The Router just listens to the messages and updates its internal databases according the them.
> 
> One message contains information about the network the radio is attached to, the second message contains information about the known neighbors of the radio.
> 
> Henning Rogge
> 
> -- 
> [email-masked]

---

From: Teco Boot <[email-masked]>
Date: Tue, 23 Oct 2012 13:26:39 +0200

I support this DLEP-lite idea. I have to deal security requirements 
with strong border protection, where the inner (red) network would 
benefit form feedback from the outer (black) network. Using data 
diode is more easy to deploy than a secured gateway. So a pure 
uni-directional feed would help getting data through a diode.

Teco

Op 22 okt. 2012, om 22:02 heeft Stan Ratliff (sratliff) het volgende geschreven:

>>    A PERL script, modem-LPA-packetgen.pl
>> , has been placed in sourceforge

---

From: <[email-masked]>
Date: Tue, 23 Oct 2012 14:54:49 +0100

You might also be interested in our related IEEE Aerospace paper on modem link property advertisements, which provides a bit of context

http://personal.ee.surrey.ac.uk/Personal/L.Wood/router-modem-integration/

Lloyd Wood
http://sat-net.com/L.Wood/

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Teco Boot [[email-masked]]
Sent: 23 October 2012 12:26
To: Stan Ratliff (sratliff); Ivancic, William D. (GRC-RHN0)
Cc: <[email-masked]> List
Subject: Re: [manet] DLEP and modem Link Property Advertisements

Teco

---

From: Henning Rogge <[email-masked]>
Date: Tue, 23 Oct 2012 17:37:46 +0200

Okay,

I will publish the draft-00 document in the next days. I think it
could even be more simplified...

Henning Rogge

-- 
Steven Hawkings about cosmic inflation: "An increase of billions of
billions of percent in a tiny fraction of a second. Of course, that
was before the present government."

---

From: Henning Rogge <[email-masked]>
Date: Thu, 25 Oct 2012 08:56:53 +0200

Hi,

I have uploaded my draft document to our eu-project webpage. I cannot 
upload it to the IETF tracker at the moment because of the coming IETF.

'Stateless RFC5444-based Dynamic Link Exchange Protocol' started as a 
document to show how a RFC5444 compliant DLEP specification could look 
like, without using any kind of session mechanism between radio and 
router. The current revision has been written a few weeks before the 
IETF in Vancouver, so it does not contain changes related to DLEP-03.

The protocol in the draft has three components:

   * Metric transport from the radio to the router
   * bi-directional transport of MAC/IP pair between radio and router 
for arp-caching
   * controlling the radio by the router (at the moment a switch to turn 
the radio on/off)

The three components can be used independently of each other, components 
not supported by one side do not disrupt the rest of the protocol.

https://wiki.confine-project.eu/_media/pub:stateless_rfc5444-based_dynamic_link_exchange_protocol.pdf

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 25 Oct 2012 09:57:39 +0100

Thanks, I support the draft, will review,

AB

On Thu, Oct 25, 2012 at 7:56 AM, Henning Rogge <
[email-masked]> wrote:

> like, without using any kind of session mechanism between radio and router.
> The current revision has been written a few weeks before the IETF in
> Vancouver, so it does not contain changes related to DLEP-03.
>
>   * bi-directional transport of MAC/IP pair between radio and router for
> arp-caching
> https://wiki.confine-project.**eu/_media/pub:stateless_**
> rfc5444-based_dynamic_link_**exchange_protocol.pdf<https://wiki.confine-project.eu/_media/pub:stateless_rfc5444-based_dynamic_link_exchange_protocol.pdf>
>
>
> Henning Rogge
> --
> mailto:henning.rogge@fkie.**fraunhofer.de<[email-masked]>
> http://www.fkie.fraunhofer.de
>
>