Subject: [manet] Metric TLVs for DLEP

From: Henning Rogge <[email-masked]>
Date: Tue, 20 Nov 2012 10:32:29 +0100

Hi,

as discussed during the IETF, here a few thoughts about additional 
metric TLVs.

I think that including a larger set of metric TLVs (like Relative Link 
Quality, Current/Maximum Datarate, ...) is a good thing, because it 
allows radio/router implementors to choose from a larger set of 
standardized TLVs, which increase the chance of interoperability between 
the products.

There are two kinds of metric TLVs, one of them contain information 
about the network the radio is attached to and one of them contain 
information about the link of the radio to a target.

Network specific metric TLVs
----------------------------

* network-id

A binary identifier of the network the radio is attached to (1-16 octets 
binary)

* network-description

A text identifier of the network the radio is attached to (1-80 octects 
ascii)

* supported-rates

An array of datarates supported by the radio on the current network 
(array of 8 octet values in bit/s)

* last-active

Time since the last data was sent or received over the radio (4 octet 
value in milliseconds)

* frequency

Mid-Frequency of the current radio channel (8 octet value in Hz)

* bandwidth

Amount of spectrum a radio channel uses (8 octet value in Hz)

Neighbor specific metric TLVs
-----------------------------

* maximum-datarate

This one already exists in DLEP, but doesn't report both incoming and 
outgoing maximum link speed, which could be different.

* current-datarate

Same as maximum datarate, incoming and outgoing speed can be different.

* traffic

Amount of bytes sent and received with the neighbor (8+8 octet value)

* packets

Amount of IP packet sent and received with the neighbor (8+8 octet value)

* frames

Amount of layer-2 frames sent and received with the neighbor (8+8 octet 
value)

* tx-retries

Number of linklayer retransmissions for IP packets (8 octet value)

* tx-fails

Number of failed linklayer transmissions

* last-active

Time since the last data was sent or received with this neighbor (4 
octet value in milliseconds)

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

The traffic and packet TLVs become important when you have multiple 
routers of hosts attached to a DLEP capable radio, because they cannot 
track the traffic on their local interface anymore.

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: Henning Rogge <[email-masked]>
Date: Tue, 20 Nov 2012 10:51:40 +0100

> Network specific metric TLVs

I forgot the signal strength for neighbors:

* signal-strength

Incoming power of the last frame from this neighbor (2 octet value in 
1/100 dBm)

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 20 Nov 2012 14:18:45 +0000

Hi Henning,

I understand the advantages of your proposal. Regarding Mid-frequency and
BW, is it better to let it to be defined or not specified in value? I think
if we make it fixed to values in Hz we should not ignore the radio links
and interface limitations,
AB
On Tue, Nov 20, 2012 at 9:32 AM, Henning Rogge <
[email-masked]> wrote:

> Hi,
>
> as discussed during the IETF, here a few thoughts about additional metric
> TLVs.
>
> Quality, Current/Maximum Datarate, ...) is a good thing, because it allows
> radio/router implementors to choose from a larger set of standardized TLVs,
> which increase the chance of interoperability between the products.
>
> There are two kinds of metric TLVs, one of them contain information about
> the network the radio is attached to and one of them contain information
> about the link of the radio to a target.
>
> An array of datarates supported by the radio on the current network (array
> of 8 octet values in bit/s)
>
> * last-active
>
> Time since the last data was sent or received with this neighbor (4 octet
> value in milliseconds)
>
> ----------------------
>
> mailto:henning.rogge@fkie.**fraunhofer.de<[email-masked]>
> http://www.fkie.fraunhofer.de
>
>
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet
>
>

---

From: Henning Rogge <[email-masked]>
Date: Tue, 20 Nov 2012 15:23:39 +0100

> and interface limitations,

I am not sure what you want to say about Mid-frequency and bandwidth. 
Both are values that are measured in Hz, so if the radio want/can supply 
these values, what else should it use?

Henning Rogge

GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 20 Nov 2012 15:21:25 +0000

On Tue, Nov 20, 2012 at 2:23 PM, Henning Rogge
>
>
> I am not sure what you want to say about Mid-frequency and bandwidth. Both
> are values that are measured in Hz, so if the radio want/can supply these
> values, what else should it use?
>
> Yes frequencies are in Hz, but I ment the TLV does not have to specify the
Hz value it can be defined related to modem used with its limited dynamic
link frequencies,

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 20 Nov 2012 16:36:10 +0100

> Hz value it can be defined related to modem used with its limited dynamic

" (8 octet value in Hz)"

okay, maybe the word "integer" is missing.

"8 octet long integer, containing a value measured in Hz" sounds like
a good specification.

Henning
-- 
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: Abdussalam Baryun <[email-masked]>
Date: Tue, 20 Nov 2012 18:42:33 +0000

Hi Henning,

Do you think your proposal can be for the Metric as extension as suggested
in the section 5 (that extensions specified in another draft)?
AB
On Tue, Nov 20, 2012 at 9:32 AM, Henning Rogge <

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 21 Nov 2012 09:21:46 -0800

... hints on where to look.  IEEE 802.16 and TIA LTE (the two
standards are very much alike, no accident) have a set of about four
dozen MAC messages that are exchanged between BS and SS (and do not pass
above layer 2, except indirectly as MIB values).  Included in this set
of MAC messages are ranging messages that appear to be very similar to
what you're describing below.  Mining that set might save you some
reinvention.