Subject: [manet] New DLEP extension draft for WG

From: "Rogge, Henning" <[email-masked]>
Date: Wed, 27 Jan 2021 13:33:21 +0000

Hi,

I finally got to the point where I had time to publish the first parts of my DLEP extensions I would like the Manet WG to adopt. I talked with Ronald and we agreed that I keep the drafts quite "narrow".

https://datatracker.ietf.org/doc/draft-rogge-manet-dlep-radio-band/?

At the moment I plan to do two more drafts about PHY aspects of the radio (signal strength related stuff and channel utilization) before moving to MAC related TLV extensions.

Would you like to keep the drafts that narrow? This will keep them easy to read but it will increase the number of documents... or would you like me to make to drafts more "broad" ?

Henning Rogge

Fraunhofer FKIE

---

From: Rick Taylor <[email-masked]>
Date: Wed, 27 Jan 2021 15:49:22 +0000

Hi Henning,

> 
> I finally got to the point where I had time to publish the first
> parts of my DLEP extensions I would like the Manet WG to adopt. I
> talked with Ronald and we agreed that I keep the drafts quite
> "narrow".

"Narrow" is good, but in my opinion if you have <6 data items that are
all very much in the same context, e.g. Radio Signal Info, it mike make
sense to roll them all up into 1 extension.  I suppose the test would
be that if an implementation supports 1 data item, then it probably
could support the others, but that is a little subjective.

The disadvantage is that you then need to specify which data items MUST
be used by an implementation supporting the extension, and which are
optional.

> 
> https://datatracker.ietf.org/doc/draft-rogge-manet-dlep-radio-band/​
> 
> At the moment I plan to do two more drafts about PHY aspects of the
> radio (signal strength related stuff and channel utilization) before
> moving to MAC related TLV extensions.

I think these radio data items sound like they are logically all part
of the same extension.

I do have a question: As DLEP is primarily about informing layer-3
devices about dynamic layer-2 capabilities, are radio signal metrics
really of use to a router?  To me they sound a lot like layer-1
information, if you get my meaning, and I wonder why a router would
even care?

Can you explain why you think these data items are important to a
layer-3 device?  I think I'm looking for a "rationale" section in the
draft.

I understand that you have done some work before around Airtime Cost
Metrics derived from signal information, so I wonder whether the modem
should be exposing a derived data item (post-processing) rather than
the raw radio signal data items (pre-processing).  My assumption is
that the DLEP protocol is significantly slower than the computation. 

I suppose the counter-argument is that there is really no such thing as
a "useless" metric, and I can imagine some routers in the near future
using AI to predict link behaviour - I expect someone is already doing
a PhD on that right now!

Cheers,

Rick

---

From: Henning Rogge <[email-masked]>
Date: Wed, 27 Jan 2021 18:06:43 +0100

> could support the others, but that is a little subjective.

I will post a the two "lists" of PHY TLVs tomorrow so you can see the
split I plan to do.

> > https://datatracker.ietf.org/doc/draft-rogge-manet-dlep-radio-band/
> >

First option I see is a routing metric that takes the EM spectrum cost
into account...
twice as fast is good... but twice as fast with 10 times the bandwidth
might not be the best choice if you want to maximize the total
capacity of the network.

> layer-3 device?  I think I'm looking for a "rationale" section in the

There is also the option to (re-)use these options together with
"Request Link Characteristics", which could be interesting for
Software Defined Radio.

Last (e.g. for military networks) it might be interesting to determine
if a "jammer warning" in a certain frequency band is relevant to your
radio so you can either use a different link or reconfigure.

I hope this makes sense...

Henning

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

---

From: Henning Rogge <[email-masked]>
Date: Thu, 28 Jan 2021 07:21:26 +0100

On Wed, Jan 27, 2021 at 6:06 PM Henning Rogge <[email-masked]> wrote:
> I will post a list of PHY TLVs tomorrow so you can see the
> split I plan to do.

so here is the promised list:

1) radio bands (frequency/bandwidth/up or downlink capability)
    mostly for metric calculation and easier frequency planning,
potentially also for quick reconfiguration of SDR hardware.
2) signal strength
    a) Signal Strength
    b) SNR
    c) Noise
    Signal Strength is a well known part of wireless metrics... the
problem is that some radios deliver Signal Strength, some deliver
SNR...
    Signal strength could also be used to reconfigure the radio, both
for saving energy and for boosting the reliability of a failing link.
3) Channel utilization (all measured on the local radio)
    a) Channel Active (total time the channel has been active, can
begin with zero at the beginning of the DLEP session)
    b) Channel Busy (time the channel has been blocked by incoming
data that has not been recognized as an incoming frame)
    c) Channel RX (time the channel has spent receiving frames)
    d) Channel TX (time the channel has spent transmitting frames)
    These are quite useful to gather how much "free capacity" a
channel has. Especially because Channel-RX should also increase for
overheard frames between two other radios

My plan was to put each of the three groups into an DLEP extension and
a Draft/RFC of their own.

I could also put them into the same RFC but keep them as three
extensions... or put them in the same RFC AND the same DLEP extension.

Henning

---

From: Henning Rogge <[email-masked]>
Date: Fri, 29 Jan 2021 07:24:19 +0100

On Thu, Jan 28, 2021 at 7:55 PM Rex Buddenberg <[email-masked]> wrote:
>
> Henning,
>
> On first read, this appears very sensible. Raises one question in my
> mind: how closely do these listings parallel MIB variables? Is there
> profit in casting these values as MIB extensions which would allow a
> network management console several hops away to do its job?

(I am replying to the mailing list so that all people can see it)

Hi,

I don't see any parallels with MIBs... I am not even aware of any MIB
for radio configuration at the IETF.

During the last years I have talked and worked with a few Radio
vendors and when asking about how to get metric and runtime data the
topic SNMP never came up. If you are lucky you get a REST interface
(and can point them to IETF standards like RESTCONF/RFC8040), if you
are unlucky you get a proprietary protocol on a proprietary network
socket.

There is also the fact that modern radio systems don't use fixed
values of frequency and bandwidth. Wifi 6 access points (as an
example) can use frequency division multiplexing to talk to several
clients at once... LTE (and earlier cellphone networks) have been
using dynamic time slot and bandwidth allocation for ages. This means
that the values can be neighbor specific, they can change quite often
and there might be radio systems where the router can ask for a better
radio band or more bandwidth.

Henning Rogge

---

From: Henning Rogge <[email-masked]>
Date: Mon, 1 Feb 2021 08:35:46 +0100

So what would be a good next step?

Do we (Manet WG) wait until the next meeting (March)? Or should I post
the other two Drafts I mentioned so we can talk about if we want to
combine them or keep them apart?

Henning Rogge