Subject: Re: [manet] Metric TLVs for DLEP

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

Henning,

I agree with your separation of 'attached radio' metrics from 'neighbour link' metrics, but I don't see the reason for reporting RF-style metrics, such as channel mid-point.  From my understanding DLEP is about reporting link/modem metrics *of use to a router*.

When defining a mandatory set of metrics for DLEP, I would consider it most appropriate to concentrate on metrics such as Current Data Rate and Latency, leaving RF metrics such as channel midpoint frequency as vendor specific extensions.

>From my experience with radios and DLEP: Most software defined radios supply a debug interface where such RF information can be retrieved, and some radios do not even have a concept of a channel midpoint.

Network identifier metrics: I like the idea, but I am not sure what use such metrics provide to an attached router.

In conclusion:

Separation of Radio/Modem metrics and Link metrics: +1

'RF' metrics, e.g. channel frequency, bandwidth: -1 : Keep the core metrics to router-relevant metrics.

Rick Taylor

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Henning Rogge
> Sent: 20 November 2012 09:32
> To: [email-masked]
> Subject: [manet] Metric TLVs for DLEP
>
> 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

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: "Taylor, Rick" <[email-masked]>
Date: Wed, 21 Nov 2012 11:04:27 +0000

I have raised this before, but failed to explain it clearly, so I'll try again:

With meshed radio networks, such as 802.11s, the definition of a DLEP neighbour is not clear in relation to the current draft.

Does a 'Neighbour' refer to: A) a radio attached to the network that directly receives packets from the sending radio, or is it B) any radio that can receive packets *even if they are passed via other radios within the mesh*?

If the answer is A) then the draft needs to be updated to reflect this, and I imagine many people will object to this definition as being too strict.

If the answer is B) then there must be some way for the radio to report how many lower-layer hops are involved between the sender and the neighbour.  My proposal would be to add a hop-count metric TLV to the link metric set.  This will allow the mesh to alter its topology and inform connected routers via a Neighbour_Update.

There might be an argument, if the definition is B), to add a 'Path' or 'Via' metric that describes the (Layer < 3) path between source and neighbour, but it is currently unclear to me how this might be encoded within a TLV of reasonable length for a big mesh.

Please do not confuse my proposal with any particular routing protocol hop-count, it is unrelated.

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Wed, 21 Nov 2012 13:08:03 +0100

Am 21.11.2012 11:39, schrieb Taylor, Rick:
> Henning,
>
> I agree with your separation of 'attached radio' metrics from
> 'neighbour link' metrics, but I don't see the reason for reporting
> RF-style metrics, such as channel mid-point.  From my understanding
> DLEP is about reporting link/modem metrics *of use to a router*.
>
> When defining a mandatory set of metrics for DLEP, I would consider
> it most appropriate to concentrate on metrics such as Current Data
> Rate and Latency, leaving RF metrics such as channel midpoint
> frequency as vendor specific extensions.
>
> From my experience with radios and DLEP: Most software defined radios
> supply a debug interface where such RF information can be retrieved,
> and some radios do not even have a concept of a channel midpoint.

Debug interfaces are not really useful, because they are device (and 
sometimes even firmware-release) specific.

The channel midpoint might not make sense for radios in frequency 
hopping mode.

The bandwidth of a channel tells the router something about the 
'spectral effiency'.

If you have two radio channels, both without packet loss and both with a 
link-speed of 10 MBit/s, both seem to be similar to the router.

But if you know that one of them is 10 MHz wide and one of them 40 MHz 
wide, its might be better to take the 10 MHz wide one.

> Network identifier metrics: I like the idea, but I am not sure what
> use such metrics provide to an attached router.

Its more a help to the autodiscovery part of DLEP, because it allows the 
Router to present the user with a short information what the new radio 
is attached to.

> metrics to router-relevant metrics.

MIC-metric is one example of a "collision domain aware" metric for MANET 
that use the frequency of a link to decide if it will interfere with 
other links or not.

Parameters like frequency and bandwith are relevant for MANET routing 
metrics. If the radio knows them, we should provide ways to deliver them 
to the router.

Henning Rogge

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