Subject: Re: [manet] DLEP Lite? (Teco Boot)

From: "Viberg, Neil" <[email-masked]>
Date: Fri, 9 Nov 2012 11:08:05 -0700

Folks,

I hadn't heard the security argument for DLEP Lite before but, having
some limited exposure to red-black boundaries, I can understand the
desire/need for a one-way protocol.

I have colleagues who would like a DLEP Lite for a different reason.
They see it as a way to reduce development cost along with cpu and
communication load on the modem side of the information flow.

Another situation where DLEP Lite would be sufficient is with a modem
that isn't sophisticated enough to determine its neighbors but could
give basic information about its transmission state. DLEP Lite would
offer an extremely lightweight and standardized way to learn about the
modem and its basic capabilities.

A few things to consider:
 
1. having a DLEP Lite does not lessen the work the router has to do.
Whether the modem thinks it has a session or not, the router will need
to treat the flow of data from the modem as a session except without any
well known points at which failure can be detected. I think that the
router's response to failed modems will be slower, in general, with a
DLEP Lite.

2. users of DLEP Lite would need to carefully balance the modem savings
with the system cost. With DLEP Lite the amount of messaging towards the
router will need to have a rate that is a function of the number of
modem neighbors, rate of significant change of link parameters *and* the
probability that a specific DLEP message can be lost. DLEP Lite moves
the information model to a pure soft state approach while the original
DLEP model is much closer to a hard state model. This implies that the
consistency of router state depends on the flow of information from the
modem to overcome the packet loss rate *but* there is no communication
from the router back to the modem so it is very difficult for the modem
to estimate packet loss rate. If one has a strong desire for consistent
state in the router and the modem has a large number of neighbors and/or
volatile links then the messaging rate may be considerably higher than
the ACKed exchange of a straight DLEP implementation.

3. DLEP Lite would need to be a required part of the router and the
modem would be able to implement either the full DLEP or DLEP Lite.

Cheers,
Neil Viberg
Network Architect
C3ISS Business Unit
General Dynamics Canada

P.S. I personally tend to use the generic term bearer rather than modem
because the modem is just one of many components in every device I've
worked with. 

-----Excerpt from manet Digest Vol 102 Issue 117-----

----------------------------------------------------------------------

Message: 1
Date: Fri, 9 Nov 2012 13:59:39 +0100
From: Teco Boot <[email-masked]>
To: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [manet] DLEP Lite?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="windows-1252"

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

Op 8 nov. 2012, om 20:00 heeft Ivancic, William D. (GRC-RHN0) het
volgende geschreven:

> 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]
>> https://www.ietf.org/mailman/listinfo/manet
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

The information contained in this e-mail message is PRIVATE. It may contain confidential information and may be legally privileged. It is intended for the exclusive use of the addressee(s). If you are not the intended recipient, you are hereby notified that any dissemination, distribution or reproduction of this communication is strictly prohibited. If the intended recipient(s) cannot be reached or if a transmission problem has occurred, please notify the sender immediately by return e-mail and destroy all copies of this message. 
Thank you.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 9 Nov 2012 19:29:29 +0000

One (of many) things that confuses me about DLEP-Lite is the notion that the modem (or radio, or bearer) would "strobe" packets to "some address" (let's say some sort of site-local scoped multicast address) and not know (or care) about responses. What if, in that case, I put multiple routers "behind" the modem that can hear the strobes? Pretty easy to get the link overloaded, just as before… so, I'm not seeing any general benefit, unless some assumptions are made as to the overall structure of the network.

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Fri, 9 Nov 2012 20:45:38 +0100

Which link gets overloaded? I cannot see why there would be any difference. Routers are passive, radio just send its info for other peers.

But, on other side of RF link, there is info for each router on this side. Info is per MAC address. In fact, MAC addresses could be for a router or a host.

If you had flow control in mind, that is another story. This doesn't meet my requirements, as stated before a couple of times.

Should I open a ticket for this?

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 9 Nov 2012 19:51:50 +0000

> But, on other side of RF link, there is info for each router on this side. Info is per MAC address. In fact, MAC addresses could be for a router or a host.

How? How did the far-end radio get the MAC information on its routers? Because I assume that it, too, is in "send only" mode, therefore, it knows *nothing* about the router or routers on its end (just as the "local radio" knows nothing about local devices)…. that's part of the whole point on DLEP.

And no, no ticket required.

Stan

---

From: "Viberg, Neil" <[email-masked]>
Date: Fri, 9 Nov 2012 13:39:18 -0700

Stan,

Good point. I personally would find it a bit odd to just add a bearer
into a situation where multiple routers could each view it as "their"
link and I haven't encountered that situation but others might.

Neil

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: Friday, November 09, 2012 12:29 PM
To: Viberg, Neil
Cc: <[email-masked]>
Subject: Re: [manet] DLEP Lite? (Teco Boot)

One (of many) things that confuses me about DLEP-Lite is the notion that
the modem (or radio, or bearer) would "strobe" packets to "some address"
(let's say some sort of site-local scoped multicast address) and not
know (or care) about responses. What if, in that case, I put multiple
routers "behind" the modem that can hear the strobes? Pretty easy to get
the link overloaded, just as before... so, I'm not seeing any general
benefit, unless some assumptions are made as to the overall structure of
the network.

Regards,
Stan

> to treat the flow of data from the modem as a session except without 
> any well known points at which failure can be detected. I think that 
> the router's response to failed modems will be slower, in general, 
> with a DLEP Lite.
> 
> 2. users of DLEP Lite would need to carefully balance the modem 
> savings with the system cost. With DLEP Lite the amount of messaging 
> towards the router will need to have a rate that is a function of the 
> number of modem neighbors, rate of significant change of link 
> parameters *and* the probability that a specific DLEP message can be 
> lost. DLEP Lite moves the information model to a pure soft state 
> approach while the original DLEP model is much closer to a hard state 
> model. This implies that the consistency of router state depends on 
> the flow of information from the modem to overcome the packet loss 
> rate *but* there is no communication from the router back to the modem

> so it is very difficult for the modem to estimate packet loss rate. If

> one has a strong desire for consistent state in the router and the 
> modem has a large number of neighbors and/or volatile links then the 
> messaging rate may be considerably higher than the ACKed exchange of a
straight DLEP implementation.
> P.S. I personally tend to use the generic term bearer rather than 
> modem because the modem is just one of many components in every device

> I've worked 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

> 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.
>> 
> functions addressed in this draft.  The modem would simply provide 
> link states out via multicast or unicast UDP datagrams (DLEP-Lite)."
>> 
> accommodate systems that are multiple hops away from the modem. 
> Upstream notification would be a simple modification to DLEP (I
think).

> 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
>>> 
> The information contained in this e-mail message is PRIVATE. It may
contain confidential information and may be legally privileged. It is
intended for the exclusive use of the addressee(s). If you are not the
intended recipient, you are hereby notified that any dissemination,
distribution or reproduction of this communication is strictly
prohibited. If the intended recipient(s) cannot be reached or if a
transmission problem has occurred, please notify the sender immediately
by return e-mail and destroy all copies of this message.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Fri, 9 Nov 2012 22:49:46 +0000

Neil, 

Thanks. While it's on my mind, and just to keep the conversation going, I think there's another assumption with ModemLPA that's confusing me - having this radio link potentially multiple hops away. The assumption there is that the RF link, by definition, is the bandwidth bottleneck. There's no slower link between the router and the modem. Hence, traffic gated at the speed of the modem is the right thing to do. But, I don't think that assumption would hold in all cases…

To the DLEP-interested parties in general - is there something I'm missing here?

Regards,
Stan

---

From: "Viberg, Neil" <[email-masked]>
Date: Fri, 9 Nov 2012 16:44:41 -0700

Stan,

I had a similar reaction to the ModemLPA assumption of the radio link
multiple hops away from the router but I remember toying with the idea
in a system design a few years ago. The problem was the radio link
wasn't "good" enough to be hooked into the general network but it was
sometimes "needed" (a system requirement) for specific data transfers.
The design would have worked whether the data link was the bottleneck or
not.

One would hope that the route metric would reflect the cost of getting
to the data link.

Regards,
Neil 

-----Original Message-----
From: Stan Ratliff (sratliff) [mailto:[email-masked]] 
Sent: Friday, November 09, 2012 3:50 PM
To: Viberg, Neil
Cc: <[email-masked]>
Subject: Re: [manet] DLEP Lite? (Teco Boot)

Neil, 

Thanks. While it's on my mind, and just to keep the conversation going,
I think there's another assumption with ModemLPA that's confusing me -
having this radio link potentially multiple hops away. The assumption
there is that the RF link, by definition, is the bandwidth bottleneck.
There's no slower link between the router and the modem. Hence, traffic
gated at the speed of the modem is the right thing to do. But, I don't
think that assumption would hold in all cases...

To the DLEP-interested parties in general - is there something I'm
missing here?

Regards,
Stan

On Nov 9, 2012, at 3:39 PM, Viberg, Neil wrote:

> One (of many) things that confuses me about DLEP-Lite is the notion 
> that the modem (or radio, or bearer) would "strobe" packets to "some
address"
> routers "behind" the modem that can hear the strobes? Pretty easy to 
> get the link overloaded, just as before... so, I'm not seeing any 
> general benefit, unless some assumptions are made as to the overall 
> structure of the network.
> 
> Regards,
> Stan
> 

> transmission problem has occurred, please notify the sender 
> immediately by return e-mail and destroy all copies of this message.
>> Thank you. 
>>

---

From: Teco Boot <[email-masked]>
Date: Sat, 10 Nov 2012 16:12:01 +0100

Op 9 nov. 2012, om 20:51 heeft Stan Ratliff (sratliff) het volgende geschreven:

> How? How did the far-end radio get the MAC information on its routers?
This is data plane. What about a hello packet?

> Because I assume that it, too, is in "send only" mode, therefore, it knows *nothing* about the router or routers on its end (just as the "local radio" knows nothing about local devices)…. that's part of the whole point on DLEP.
If router is not powered, you are correct.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Sat, 10 Nov 2012 18:35:55 +0000

> This is data plane. What about a hello packet?

And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, then you aren't using (and don't need) DLEP.

> If router is not powered, you are correct.

I don't understand that response. 

Stan

---

From: Henning Rogge <[email-masked]>
Date: Sat, 10 Nov 2012 19:53:21 +0100

> And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, then you aren't using (and don't need) DLEP.

Even with Hello-Packets on layer-3, ARPs (maybe with a transparent
cache on the radio) and IPv6 ND you would still need DLEP to get
access to the layer-2 data of the radio.

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: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Sat, 10 Nov 2012 23:13:56 +0000

> access to the layer-2 data of the radio.

My point is that any layer 2 information you get is useless, because you can't correlate the two with this "one way, no responses" mode of operation. Assume there are 3 router/modem setups -  A, B, and C. Router/modem A can see both B and C. The RF path between A and B is at 40Mbps; the path between A and C is only 6Mbps…. All three modems are "strobing" in this one-way communications mode back to their respective routers. So all that router A knows is that there are a couple of potential partners "out there" - and with HELLO packets, and IPv6 ND/ARP, router A can actually find them. But how does A know that the path to B os 40Mbps while the path to C is only 6? There's no correlation - since the modems are operating in bridge mode, there's no indication whatsoever as to which router (B or C) is on which radio. Because there was no "radio-to-MAC" correlation, because the radios don't want to hear anything from the routers. Unless, of course, the radios are surreptitiously snooping the traffic coming in off of their wired connections, looking for things like this. But that seems a lot more complex to me. 

This mode of operation *only* works if you make assumptions about the structure of the network. Assumptions I don't believe we should be making. Like, there's *only* 1 router behind each radio. And that the RF link is the smallest in terms of bandwidth (or latency, or whatever metric you wish to key on). And in the case I describe above, the assumption is that the bandwidth to *all* stations across the RF is the same - which isn't true, and if it is, why do we need dynamic metrics in the first place?

Stan

---

From: Teco Boot <[email-masked]>
Date: Mon, 12 Nov 2012 06:51:53 +0100

> And if you're going to rely on HELLO packets, and ARP, and IPv6 ND, then you aren't using (and don't need) DLEP.

Please explain. I never heard of one of the mentioned protocols can provide link metrics.
There is code out there that provides the link metrics *in addition* to routing protocols and ARP/ND. It is needed. I use it.
 
> I don't understand that response. 

If router does not send packets, bridges do not learn routes for MAC forwarding, nor do radios learn link metrics for it.

Teco

---

From: Teco Boot <[email-masked]>
Date: Mon, 12 Nov 2012 07:00:34 +0100

Op 11 nov. 2012, om 00:13 heeft Stan Ratliff (sratliff) het volgende geschreven:

> My point is that any layer 2 information you get is useless, because you can't correlate the two with this "one way, no responses" mode of operation. Assume there are 3 router/modem setups -  A, B, and C. Router/modem A can see both B and C. The RF path between A and B is at 40Mbps; the path between A and C is only 6Mbps…. All three modems are "strobing" in this one-way communications mode back to their respective routers. So all that router A knows is that there are a couple of potential partners "out there" - and with HELLO packets, and IPv6 ND/ARP, router A can actually find them. But how does A know that the path to B os 40Mbps while the path to C is only 6?
With DLEP :-)

> There's no correlation - since the modems are operating in bridge mode, there's no indication whatsoever as to which router (B or C) is on which radio.
Router A only has to know the cost of the link to B and to C. Or the cost from B and from C. 
This *to* / *from* is another quite important open issue. Open ticket for it?

> Because there was no "radio-to-MAC" correlation,
??

> because the radios don't want to hear anything from the routers.
??????

> Unless, of course, the radios are surreptitiously snooping the traffic coming in off of their wired connections, looking for things like this. But that seems a lot more complex to me. 
Each 802.1D bridge *has* to do this. I don't get your point.

> 
> This mode of operation *only* works if you make assumptions about the structure of the network.
No.

> Assumptions I don't believe we should be making.
Agreed :-)

> Like, there's *only* 1 router behind each radio.
???

> And that the RF link is the smallest in terms of bandwidth (or latency, or whatever metric you wish to key on). And in the case I describe above, the assumption is that the bandwidth to *all* stations across the RF is the same - which isn't true, and if it is, why do we need dynamic metrics in the first place?

I am completely lost in your response. Can we assume 802.1D bridging?

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 13 Nov 2012 19:27:12 +0000

>Because there was no "radio-to-MAC" correlation,

IMO, correlation concept not understood, but understand that we don't need
bridge mode. However, still waiting for the respond to Teco question,

AB
On Mon, Nov 12, 2012 at 6:00 AM, Teco Boot <[email-masked]> wrote:

> >>> And if you're going to rely on HELLO packets, and ARP, and IPv6 ND,
> then you aren't using (and don't need) DLEP.
> >>
> > My point is that any layer 2 information you get is useless, because you
> can't correlate the two with this "one way, no responses" mode of
> operation. Assume there are 3 router/modem setups -  A, B, and C.
> Router/modem A can see both B and C. The RF path between A and B is at
> 40Mbps; the path between A and C is only 6Mbps…. All three modems are
> "strobing" in this one-way communications mode back to their respective
> routers. So all that router A knows is that there are a couple of potential
> partners "out there" - and with HELLO packets, and IPv6 ND/ARP, router A
> can actually find them. But how does A know that the path to B os 40Mbps
> while the path to C is only 6?
> With DLEP :-)
>
> > There's no correlation - since the modems are operating in bridge mode,
> there's no indication whatsoever as to which router (B or C) is on which
> radio.
> > Unless, of course, the radios are surreptitiously snooping the traffic
> coming in off of their wired connections, looking for things like this. But
> that seems a lot more complex to me.
> > And that the RF link is the smallest in terms of bandwidth (or latency,
> or whatever metric you wish to key on). And in the case I describe above,
> the assumption is that the bandwidth to *all* stations across the RF is the
> same - which isn't true, and if it is, why do we need dynamic metrics in
> the first place?
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 13 Nov 2012 20:31:11 +0100

> bridge mode. However, still waiting for the respond to Teco question,

What do you mean with "we don't need bridge mode" ?

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 13 Nov 2012 20:38:20 +0000

I mean I understand from discussions that Stan's reply to Teco that he does
not beleive to use bridge mode,

AB

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Nov 2012 13:15:03 +0100

Attempt to make thinks clear.

Radio is L2 device, could be 802.1D bridge or repeater. Device is 
self learning. It has MAC addresses and probably an IP address. 
Routers are connected to radio with ethernet or equivalent.
Routers have a sub-IP connection with each other via the ethernet - RF
- ethernet sub-IP link. Connection is based on 802.1 MAC addresses.
Radio has the task to deliver router originated frames to destination,
based on destination MAC address. Could be L2 multicast or broadcast.
With DLEP, radios have the task to keep track of link properties between
each connected device. Could be *any* connected ethernet NIC, as long as 
it has an 802.1 address and it sends a packet every now and then. All 
radios in the sub-IP network automatically learn the existence of each 
connected sending node, as required by 802.1D. DLEP shall be 100% 
compatible with this widely deployed mechanism. It shall provide link
metrics for far end connected MAC addresses to locally connected nodes.
It shall work this way for single- and multi-hop sub-IP networks.

Teco

Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het volgende geschreven:

> I mean I understand from discussions that Stan's reply to Teco that he does not beleive to use bridge mode,
>  
> AB
> 
> On Tue, Nov 13, 2012 at 7:31 PM, Henning Rogge <[email-masked]> wrote:

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 14 Nov 2012 15:34:12 +0000

> It shall work this way for single- and multi-hop sub-IP networks.

I think we're talking past each other. DLEP has not assumed 802.1D support in the radios, so all of your "shall" verbiage doesn't make sense. The only assumption DLEP makes (at least as of now) is that the radios operate in transparent bridge mode - that the destination MAC is that of the far-end router, not any of the intervening devices. And without some flows from router *to* radio, your "one-way only" communication mode doesn't work, because you can't correlate a router to it's attached RF device. And I'm not OK with *requiring* that level of functionality in the radio. 

Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Nov 2012 16:55:36 +0100

Op 14 nov. 2012, om 16:34 heeft Stan Ratliff (sratliff) het volgende geschreven:

> I think we're talking past each other. DLEP has not assumed 802.1D support in the radios, so all of your "shall" verbiage doesn't make sense. The only assumption DLEP makes (at least as of now) is that the radios operate in transparent bridge mode - that the destination MAC is that of the far-end router, not any of the intervening devices.
As is in 802.1D.

> And without some flows from router *to* radio, your "one-way only" communication mode doesn't work, because you can't correlate a router to it's attached RF device.
It is the RF device that is locally connected. Not the far end RF device. Cannot be mistaken, can it?

> And I'm not OK with *requiring* that level of functionality in the radio.
I didn't read anything here that didn't match 802.1D.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 14 Nov 2012 18:31:41 +0000

> It is the RF device that is locally connected. Not the far end RF device. Cannot be mistaken, can it?

Yes, it can. Given 3 radio/router pairs, each in the "one-way" mode, what MAC address is in the Neighbor Up?

---

From: Teco Boot <[email-masked]>
Date: Wed, 14 Nov 2012 20:03:20 +0100

> Yes, it can. Given 3 radio/router pairs, each in the "one-way" mode, what MAC address is in the Neighbor Up?

The far end router. It doesn't need to be DLEP enabled. Could be a host also, like a laptop for testing.

BTW, I would just send the metric costs. Neighbor up is implicit. Due to RF, signals fade away, Neighbor down is artificial (or result of a disconnect). 

Teco

---

From: "Ivancic, William D. (GRC-RHN0)" <[email-masked]>
Date: Wed, 14 Nov 2012 13:19:53 -0600

> Thanks. While it's on my mind, and just to keep the conversation going, I think there's another assumption with ModemLPA that's confusing me - having this radio link potentially multiple hops away.…

Correct, the assumption would not hold in all cases. It is deployment specific.

- Will

ps.  I had to fix my email box and had not read manet for a few days, so sorry if you were waiting for a response from me.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 14 Nov 2012 19:26:22 +0000

> The far end router. It doesn't need to be DLEP enabled. Could be a host also, like a laptop for testing.

And how does the radio (far-end radio) learn of the MAC address?

---

From: Bo Berry <[email-masked]>
Date: Wed, 14 Nov 2012 14:43:19 -0500

> And how does the radio (far-end radio) learn of the MAC address?

A picture my help (me for atleast as I try to follow).  Two different networks below.

A)
  [ DLEP Enabled]       [ DLEP Enabled]
  [ radio~router]~~~~~~~[ radio|router] 

B)
  [ DLEP Enabled]       [   integrated]
  [ radio~router]~~~~~~~[   radio|host] <such as a handheld unit>

The [integrated radio|host] shares MAC/IP address information via a driver, not DLEP.  In configuration (B) the DLEP Enabled radio must obtain the host MAC address to drive DLEP.  How the DLEP Enabled radio obtains the host MAC is really a function of the DLEP Enabled radio.  Once obtained, the DLEP Enabled radio generates a Neighbor Up and can report metrics associated with the host MAC.  The DLEP Enabled router uses the host MAC in the DLEP messages to adjust/influence routing.

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Nov 2012 07:29:39 +0100

>> And how does the radio (far-end radio) learn of the MAC address?

@Stan:
Assume frames have 4 MAC addresses: SA, DA, TA and RA.
SA: Source Address, sending router
DA: Destination Address, receiving router (far end radio sends frame to locally attached router)
TA: Transmitter Address, radio ID of RF link, sending radio
RA: Receiver Address, radio ID on RF link, receiving radio

I am aware of radio's that reuse the SA/DA for TA/RA, so they do not need the 4-address mode. This has some limitations, in that radio supports only one node (although there could be a work-around). The more enhanced radios use the 4 address mode.

Now your question: radio inspects the frame header, to find out what to do with it. Highly simplified: Is RA its own address? No, then discard. It could update link metrics for TA and all SA behind TA, no reason to ignore available info. For frames for that radio, it refresh forwarding tables: SA is behind TA, this info is required for return frames. Frame is converted or decapsulated and forwarded to DA, could be flooding if unknown outgoing port was unknown.

Side node: when RA != own address, radio could update bridge forwarding table, and relate SA and TA.

>  [ radio~router]~~~~~~~[   radio|host] <such as a handheld unit>

There are more scenario's:

C)
 [ DLEP Enabled]       [ DLEP Disabled]
 [ radio~router]~~~~~~~[ radio|router ] 

D)
                       [ DLEP Enabled]

All should work.

> 
> The [integrated radio|host] shares MAC/IP address information via a driver, not DLEP.
What is "shares MAC/IP address"?
With 4 address mode, SA and TA would be same MAC address.

>  In configuration (B) the DLEP Enabled radio must obtain the host MAC address to drive DLEP.  How the DLEP Enabled radio obtains the host MAC is really a function of the DLEP Enabled radio.  Once obtained, the DLEP Enabled radio generates a Neighbor Up and can report metrics associated with the host MAC.  The DLEP Enabled router uses the host MAC in the DLEP messages to adjust/influence routing. 

Agreed in that the DLEP specification shall not assume both sides of link have DLEP enabled, such as with (B) and (C)? 

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 15 Nov 2012 13:56:19 +0100

>   [ radio~router]~~~~~~~[   radio|host] <such as a handheld unit>

What kind of host reporting? I thought we in DLEP are focused to
reporting about routers' links, but now undertanding that some are
interested in reporting about hosts' links also.

> The [integrated radio|host] shares MAC/IP address information via a driver,
> not DLEP.  In configuration (B) the DLEP Enabled radio must obtain the host
> MAC address to drive DLEP.  How the DLEP Enabled radio obtains the host MAC
> is really a function of the DLEP Enabled radio.  Once obtained, the DLEP
> Enabled radio generates a Neighbor Up and can report metrics associated with
> the host MAC.  The DLEP Enabled router uses the host MAC in the DLEP
> messages to adjust/influence routing.
>

IMO, the host MAC and/or router MAC should be specified only for
*enabled DLEP*, if we considering non-enabled DLEP devices, the DLEP
exchange function may become complicated.

AB

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 15 Nov 2012 14:03:25 +0100

> RA: Receiver Address, radio ID on RF link, receiving radio

ok, so the MAC address of sources and destinations are ROUTERs not
HOSTs, I agree to fix the DLEP exchange function with reporting
to/about routers.

>  [ radio~router]~~~~~~~[   radio|host] <such as a handheld unit>

Do you mean should work within DLEP, so you mean that DLEP should
consider devices that don't enable its functions? Why you think the C
and D scenarios are within DLEP scope?

AB

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Nov 2012 14:28:08 +0100

> HOSTs, I agree to fix the DLEP exchange function with reporting

I don't see a reason why the radio connected devices MUST be routers.
They typically are. Can be hosts also.

> consider devices that don't enable its functions?

With C (probably B), DLEP functions could be limited, as there would be 
no exchange of link metrics between radio's. DLEP doesn't specify how
radios interact, that is why it is a should, not a must.

> Why you think the C

Sure.

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 15 Nov 2012 14:55:06 +0000

> Side node: when RA != own address, radio could update bridge forwarding table, and relate SA and TA.

And if the router, for whatever reason or reasons might be appropriate, simply hasn't emitted any frames toward the radio?

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Nov 2012 16:42:08 +0100

> And if the router, for whatever reason or reasons might be appropriate, simply hasn't emitted any frames toward the radio?

Then far-end nodes are not aware the router exists. In my environment, radio silence is a normal mode of operation.

Teco

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Nov 2012 17:02:22 +0100

Teco

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Thu, 15 Nov 2012 16:26:00 +0000

> Then far-end nodes are not aware the router exists. In my environment, radio silence is a normal mode of operation.

I'm not talking about radio silence. Just a router that hasn't emitted any frames. So back to my original comment - this suggestion is making assumptions. It assumes that the radio is snooping/cacheing MAC addresses, and it assumes that the router is forwarding frames to the radio prior to any "Neighbor Up" event. I do not believe that DLEP should be making such assumptions. 

Stan

---

From: Teco Boot <[email-masked]>
Date: Thu, 15 Nov 2012 19:56:17 +0100

Op 15 nov. 2012, om 17:26 heeft Stan Ratliff (sratliff) het volgende geschreven:

> I'm not talking about radio silence. Just a router that hasn't emitted any frames.

OK, I just mentioned I have to deal with silent radios. I guess I am not the only one here.

> So back to my original comment - this suggestion is making assumptions.

Yes, in that standard protocols are being used. Not a bad assumption, I think.
If your DLEP proposal is not built on standards, I prefer staying far away from it. 

> It assumes that the radio is snooping/cacheing MAC addresses,

Yes. It is specified in dlep-03, page 8:
   DLEP assumes that participating modems, and their physical links, act
   as a transparent bridge.
I am not aware of transparent bridges that do not act the way I describe.

> and it assumes that the router is forwarding frames to the radio prior to any "Neighbor Up" event. I do not believe that DLEP should be making such assumptions. 

Are you kidding in that a router does not send packets on an interface, where the routing protocol is enabled?
(leaving PPPoE / VMI out of scope here)

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 21 Nov 2012 10:48:04 +0000

Teco,

I am just trying to understand your difficulty with 'full-fat' DLEP.  Is it:

A) You require unidirectional traffic through your crypto from modem to radio.

Or,

B) You require your radio to sometimes operate in an Rx-only mode.

Or is it both?

>From my perspective: A) can be solved by placing a device between the crypto and the modem that acts as a proxy, rather than a new DLEP-lite protocol.

B) Has been covered by Stan I believe: DLEP (as it currently stands) does not define the communication between radios, only between router and radio.  The methods used by radios to forward packets at Layers < 3 is the manufacturers business, not DLEP's.  The only requirement is that two neighbouring routers shall be able to address packets to each other using the DLEP supplied MAC addresses.

But I might have missed the thrust of your argument.

Rick Taylor

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Teco Boot
> Sent: 15 November 2012 18:56
> To: Stan Ratliff (sratliff)
> Cc: manet; Bo Berry (boberry)
> >>>>>>>>>> I think we're talking past each other. DLEP has not assumed
> 802.1D support in the radios, so all of your "shall" verbiage doesn't make
> sense. The only assumption DLEP makes (at least as of now) is that the
> radios operate in transparent bridge mode - that the destination MAC is
> that of the far-end router, not any of the intervening devices.
> >>>>>>>>> As is in 802.1D.
> >>>>>>>>>
> >>>>>>>>>> And without some flows from router *to* radio, your "one-way
> only" communication mode doesn't work, because you can't correlate a
> router to it's attached RF device.
> >>>>>>>> Yes, it can. Given 3 radio/router pairs, each in the "one-way"
> mode, what MAC address is in the Neighbor Up?
> >>>>>>>
> >>>> I am aware of radio's that reuse the SA/DA for TA/RA, so they do not
> need the 4-address mode. This has some limitations, in that radio supports
> only one node (although there could be a work-around). The more enhanced
> radios use the 4 address mode.
> >>>>
> >>>> Now your question: radio inspects the frame header, to find out what
> to do with it. Highly simplified: Is RA its own address? No, then discard.
> It could update link metrics for TA and all SA behind TA, no reason to
> ignore available info. For frames for that radio, it refresh forwarding
> tables: SA is behind TA, this info is required for return frames. Frame is
> converted or decapsulated and forwarded to DA, could be flooding if
> unknown outgoing port was unknown.
> >>>>
> >>> And if the router, for whatever reason or reasons might be
> appropriate, simply hasn't emitted any frames toward the radio?
> >>
> >> Then far-end nodes are not aware the router exists. In my environment,
> radio silence is a normal mode of operation.
> >>
> >
> > and it assumes that the router is forwarding frames to the radio prior
> to any "Neighbor Up" event. I do not believe that DLEP should be making
> such assumptions.
>
> >>>>> In configuration (B) the DLEP Enabled radio must obtain the host MAC
> address to drive DLEP.  How the DLEP Enabled radio obtains the host MAC is
> really a function of the DLEP Enabled radio.  Once obtained, the DLEP
> Enabled radio generates a Neighbor Up and can report metrics associated
> with the host MAC.  The DLEP Enabled router uses the host MAC in the DLEP
> >>>> Agreed in that the DLEP specification shall not assume both sides of
> link have DLEP enabled, such as with (B) and (C)?
> >>>>
> >>>> Teco
> >>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> BTW, I would just send the metric costs. Neighbor up is implicit.
> Due to RF, signals fade away, Neighbor down is artificial (or result of a
> disconnect).
> >>>>>>>
> >>>>>>> Teco
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>>>> I mean I understand from discussions that Stan's reply to
> Teco that he does not beleive to use bridge mode,
> >>>>>>>>>>>>
> >>>>>>>>>>>> AB
> >>>>>>>>>>>>
The information contained within this e-mail and any files attached to this e-mail is private and in addition may include commercially sensitive information. The contents of this e-mail are for the intended recipient only and therefore if you wish to disclose the information contained within this e-mail or attached files, please contact the sender prior to any such disclosure. If you are not the intended recipient, any disclosure, copying or distribution is prohibited. Please also contact the sender and inform them of the error and delete the e-mail, including any attached files from your system. Cassidian Limited, Registered Office : Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No: 04191036 http://www.cassidian.com

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Wed, 21 Nov 2012 11:55:38 +0000

Do you mean through your crypto from modem to radio? I thought we were discussing a crypto between radio/modem and router?

-- 
Christopher Dearlove
Senior Principal Engineer, Communications Group
Communications, Networks and Image Analysis Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: +44 1245 242194 |  Fax: +44 1245 242124
[email-masked] | http://www.baesystems.com

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87, Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Taylor, Rick
Sent: 21 November 2012 10:48
To: Teco Boot; Stan Ratliff (sratliff)
Cc: manet; Bo Berry (boberry)
Subject: Re: [manet] DLEP Lite? (Teco Boot)

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Keep this in mind if you answer this message.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

Teco,

Or,

Or is it both?

Rick Taylor

********************************************************************
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.
********************************************************************

---

From: Teco Boot <[email-masked]>
Date: Wed, 21 Nov 2012 13:25:31 +0100

> B) You require your radio to sometimes operate in an Rx-only mode.
I have to deal with A. Not all my radio's have crypto on board, the devices are "black". I use "grey" routers. These are part of my protected network. I use firewall rules, that blocks *all* non-crypted outgoing packets on router interfaces (OK, I permit ARP/ND and required ICMP stuff). I can connect whatever radio on my router port, and use it with VPN tunnels. I have also crypto between grey and red. With a data diode. 

I could use red routers, and connect radio's on black interface of my crypto. This is not what I use today.

I have to deal with B also. This is slightly related to DLEP. Not important here.

> From my perspective: A) can be solved by placing a device between the crypto and the modem that acts as a proxy, rather than a new DLEP-lite protocol.
I have some SWaP requirements. I cannot add devices.

> 
> B) Has been covered by Stan I believe: DLEP (as it currently stands) does not define the communication between radios, only between router and radio.  The methods used by radios to forward packets at Layers < 3 is the manufacturers business, not DLEP's.  
Yes. Although I like standards here. 

> The only requirement is that two neighbouring routers shall be able to address packets to each other using the DLEP supplied MAC addresses.
Strongly disagreed. Current DLEP-03 assumes transparent bridging. Me too.

> But I might have missed the thrust of your argument.

My main point: if the routers are simply cross-connected, shall it work? It has to be. DLEP shall optimize routing and shall not introduce dependencies.

Teco

---

From: Teco Boot <[email-masked]>
Date: Wed, 21 Nov 2012 13:32:33 +0100

> Do you mean through your crypto from modem to radio? I thought we were discussing a crypto between radio/modem and router?

There could be a need to use many of it.
a) VPN: router to router tunnel (or payload encryption, or whatever)
b) Firewall on router interface to radio. With policies that permits what is allowed and let drop everything else (think of a diode)
c) Some security mechanism between radio and router

I have (a) and (b). (c) is not that important, boxes are physically connected and crypto can be avoid. 

Teco

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 21 Nov 2012 13:40:50 +0000

Ooops,

Thanks Christopher, I meant crypto between router and modem!

Rick Taylor

> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: 21 November 2012 11:56
> To: Taylor, Rick; Teco Boot; Stan Ratliff (sratliff)
> Subject: RE: [manet] DLEP Lite? (Teco Boot)
>
> Do you mean through your crypto from modem to radio? I thought we were
> discussing a crypto between radio/modem and router?
>
> --
> Christopher Dearlove
> Taylor, Rick
> From my perspective: A) can be solved by placing a device between the
> crypto and the modem that acts as a proxy, rather than a new DLEP-lite
> protocol.
>
> B) Has been covered by Stan I believe: DLEP (as it currently stands) does
> not define the communication between radios, only between router and
> radio.  The methods used by radios to forward packets at Layers < 3 is the
> manufacturers business, not DLEP's.  The only requirement is that two
> neighbouring routers shall be able to address packets to each other using
> the DLEP supplied MAC addresses.
>
> > >>>>>>>>>>> Radio is L2 device, could be 802.1D bridge or repeater.
> Device
> > is
> > >>>>>>>>>>> each connected device. Could be *any* connected ethernet
> NIC,
> > as long as
> > >>>>>>>>>>> radios in the sub-IP network automatically learn the
> existence
> > of each
> > >>>>>>> The far end router. It doesn't need to be DLEP enabled. Could be
> a
> > host also, like a laptop for testing.
> > >>>>>>
> > >>>> DA: Destination Address, receiving router (far end radio sends
> frame
> > to locally attached router)
> > If your DLEP proposal is not built on standards, I prefer staying far
> away
> > from it.
> >
> > >>>>> The [integrated radio|host] shares MAC/IP address information via
> a
> > driver, not DLEP.
> > >>>>>>>>>> And I'm not OK with *requiring* that level of functionality
> in
> > the radio.
> > >>>>>>>>>>> Op 13 nov. 2012, om 21:38 heeft Abdussalam Baryun het
> volgende
> > geschreven:
> > >>>>>>>>>>>
> > >>>>>>>>>>>>> IMO, correlation concept not understood, but understand
> that
> > we don't need
> > >>>>>>>>>>>>> bridge mode. However, still waiting for the respond to
> Teco
> > question,
> > >>>>>>>>>>>>
> The information contained within this e-mail and any files attached to
> this e-mail is private and in addition may include commercially sensitive
> information. The contents of this e-mail are for the intended recipient
> only and therefore if you wish to disclose the information contained
> within this e-mail or attached files, please contact the sender prior to
> any such disclosure. If you are not the intended recipient, any
> disclosure, copying or distribution is prohibited. Please also contact the
> sender and inform them of the error and delete the e-mail, including any
> attached files from your system. Cassidian Limited, Registered Office :
> Quadrant House, Celtic Springs, Coedkernew, Newport, NP10 8FZ Company No:
> 04191036 http://www.cassidian.com