Subject: [manet] DLEP Lite?

From: "Dowdell, John" <[email-masked]>
Date: Wed, 7 Nov 2012 22:08:32 -0000

@Stan and Will

Can you explain exactly what you mean by DLEP Lite, as mentioned in the
dying moments of the WG meeting? Lite in what respect? I would not
consider DLEP to be particularly overweight, so understanding exactly
what you would intend to remove would be useful.

Also, IMHO it is enough work simply to define one DLEP, so having
another one to choose from is not likely to help the radio manufacturers
along the road to implementation. Having a mandatory core of DLEP, with
optional extras, I can support. Having a further cut down edition means
you then either have to know beforehand whether the radio supports full
or Lite DLEP, or you have to be able to automatically query the radio to
find out (which is a feature I suggested long, long ago, you may recall
....).

Regards

John

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Thu, 8 Nov 2012 13:00:55 -0600

DLEP, at least the last time I read it, which was a month or two ago, is client/server based with sessions setup between radio and router.  ModemLPA simply has the radio (or crypto device or whatever) sending out status packets either periodically or when something changes.  ModemLPA could send either to all routers address, a unicast address, or perhaps a organizationally scoped multicast address.

"It should be possible to use the DLEP message formats without all the signaling 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)."

DLEP is designed to operate only over the local-link and does not accommodate systems that are multiple hops away from the modem. Upstream notification would be a simple modification to DLEP (I think).

  "To handle advertisements beyond the local interface, Internet
   Protocol version 4 (IPv4) organizational-scoped multicast and
   Internet Protocol version 6 (IPv6) site-local multicast MAY be used
   with no explicit configuration in the modem.  Use of IPv4
   administratively-scoped multicast and IPv6 site-local multicast could
   handle both devices that are directly connected to the modem as well
   as hosts and applications that are multiple hops away [RFC2365]
   [RFC2373]."

On Nov 7, 2012, at 5:08 PM, Dowdell, John wrote:

@Stan and Will

Can you explain exactly what you mean by DLEP Lite, as mentioned in the dying moments of the WG meeting? Lite in what respect? I would not consider DLEP to be particularly overweight, so understanding exactly what you would intend to remove would be useful.

Also, IMHO it is enough work simply to define one DLEP, so having another one to choose from is not likely to help the radio manufacturers along the road to implementation. Having a mandatory core of DLEP, with optional extras, I can support. Having a further cut down edition means you then either have to know beforehand whether the radio supports full or Lite DLEP, or you have to be able to automatically query the radio to find out (which is a feature I suggested long, long ago, you may recall ….).

Regards

John

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

---

From: "Ward, David - 0663 - MITLL" <[email-masked]>
Date: Thu, 8 Nov 2012 14:43:51 -0500

Will,

On 11/08/2012 02:00 PM, Ivancic, William D. (GRC-RHN0) wrote:
> DLEP, at least the last time I read it, which was a month or two ago, is
> client/server based with sessions setup between radio and router.
>   ModemLPA simply has the radio (or crypto device or whatever) sending
> out status packets either periodically or when something changes.
>   ModemLPA could send either to all routers address, a unicast address,
> or perhaps a organizationally scoped multicast address.
>
> "It should be possible to use the DLEP message formats without all
> the signaling 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)."
>
> DLEP is designed to operate only over the local-link and does
> not accommodate systems that are multiple hops away from the modem.
> Upstream notification would be a simple modification to DLEP (I think).
>

Please see my earlier message.  I don't think DLEP, or any radio 
interface, is the right place for that.  Perhaps RSVP/NSIS is a better 
starting point for controlling your application traffic, although I 
realize it might not do exactly what you are looking for as-is.

David

>> Can you explain exactly what you mean by DLEP Lite, as mentioned in
>> the dying moments of the WG meeting? Lite in what respect? I would not
>> another one to choose from is not likely to help the radio
>> manufacturers along the road to implementation. Having a mandatory
>> core of DLEP, with optional extras, I can support. Having a further
>> cut down edition means you then either have to know beforehand whether
>> the radio supports full or Lite DLEP, or you have to be able to
>> automatically query the radio to find out (which is a feature I
>> suggested long, long ago, you may recall ….).
>> Regards
>> John
>> [email-masked] <mailto:[email-masked]>
> [email-masked]

-- 
David Ward, Associate Staff
Wideband Tactical Networking Group
MIT Lincoln Laboratory
Office: 781-981-4266
Mobile: 781-999-1925
Fax: 781-981-4583

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Nov 2012 13:59:39 +0100

The reason why I need a one way protocol is that I have to deal with some security mandates. All outgoing traffic from the router port has to be crypted packets, or related to the crypto engine. This piece of code for crypto  and firewall needs to be reviewed and certified. Import of data is less a problem.

During WGLC review, I'll start reading security considerations. When it describes something like "this protocol does not introduce a covert channel", I'll get more interested. As I see it right now, there is a need to split the DLEP protocol draft. The basic mode would be DLEP-Lite, and provide transport from radio to router only. Maybe DLEP-heavy is a better name for it, it could need more lines of code. And more bits on the wire.

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 9 Nov 2012 15:41:45 +0100

Initially as this draft is an experimental draft (not standard track)
I don't mind we have both DLEP and DLEP-lite as long within document,
the requirement difference can be identified.

AB

>> ModemLPA simply has the radio (or crypto device or whatever) sending out
>> status packets either periodically or when something changes.  ModemLPA
>> could send either to all routers address, a unicast address, or perhaps a
>> organizationally scoped multicast address.
>>
>> "It should be possible to use the DLEP message formats without all the
>> signaling 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)."
>>
>> DLEP is designed to operate only over the local-link and does not
>> accommodate systems that are multiple hops away from the modem. Upstream
>> notification would be a simple modification to DLEP (I think).
>>
>>> Also, IMHO it is enough work simply to define one DLEP, so having another
>>> one to choose from is not likely to help the radio manufacturers along
>>> the road to implementation. Having a mandatory core of DLEP, with
>>> ….).