Subject: [manet-dlep-rg] DLEP and legacy software defined radios

From: "Taylor, Rick" <[email-masked]>
Date: Thu, 22 Aug 2013 14:12:20 +0000

My contribution on legacy software defined radios... format shamelessly cribbed from Teco

Rick Taylor

===============

DLEP and legacy software defined radios

1. Scope

I shall ignore simple point to point modem links via HF/VHF radios, and look at the more complex case of current generation military data-radios that operate in a one-to-many mode and provide an IP stack.

Most aspects of current radios of this class are closely guarded commercial secrets of the various manufacturers, and so getting definite information on the inner workings of the radio and waveform is difficult.

2. Topology

The current generation of software defined 'combat' radios are advertised by their manufacturers as 'smart-meshing' and 'MANET'.  In reality this means that individual radios provide simultaneous data-links between multiple peers, either by constructing a star topology and electing a leader, or by constructing a routable tree topology, providing multi-hop message delivery, resolving the hidden terminal problem.  Is hall let John Dowdell go into more depth about multi-hop radio systems.

3. Interface to router

Individual radios act as a router forwarding IP packets to other members of the pre-configured subnet.  Some radios have quite specific rules governing the assignment of the routable subnets, such as requiring all devices attached to a radio be a member of a subnet that is a sub-set of the subnet containing the IP address of the individual radios.

Most radios developed for a military market support some kind of 'situational awareness' interface, usually via a serial line or UDP multicast.  This SA data is based on location and identification information, normally in radios it describes the GPS location of each radio in the network, keyed with an identifier, sometimes based on the radio external interface MAC address.  Sometimes a received signal strength indication (RSSI) in negative dBm is attached to the SA data.

4. Network technology

Most combat radios use a variation of TDMA with FEC.  Different complex modulation schemes and waveforms are used to reduce power consumption, increase range and data-rate.

As most combat radios are developed to meet the requirements of various national defence programmes, and these requirements generally specify low bandwidth requirements for the man-pack and vehicle radio systems, data rates are usually in the range of 256Kbits/s to 6MBits/s.  Bandwidth is normally of lower priority than range and power-consumption.

Most existing radios also support analogue voice directly.  Whether this traffic is digitized and transmitted, or mixed into the modulation scheme differs from manufacturer to manufacturer.

Packet MTUs are normally 1500 octets, implying that the radio modem trans-codes packets into its own proprietary over-the-air format.

It is common for the radio to only support unicast IP at layer 3, and have an extremely simple layer 2 implementation, often terminating at the local radio, meaning link-local broadcast and multicast IP are not available between radios.

Some radios will forward IPv6 traffic even if they do not officially support it, as the forwarding occurs at layer-2.

Some software defined radios also implement some kind of cryptographic capability, ranging from waveform obfuscation, channel hopping, to full AES encryption over the air.  This capability is only implemented from source radio to destination radio, and is not designed to provide full end-to-end COMSEC.

Some cryptographic options may prevent radios from operating in a multihop mode.  Also, from a DLEP perspective, a valid neighbour is one that successfully completed any cryptographic negotiation between endpoints.

5. Integrating DLEP with legacy software defined radios

With existing equipment, if a manufacturer intends to add a DLEP implementation, then compliance with whatever is finally published becomes a problem for the radio vendor themselves.  Most software defined radios run an embedded unix-ish operating system internally, so adding another software service that can probe the actual RF components and IP stack for information should be a simple task.

If, however, the manufacturer show no willing to add DLEP functionality to their radio firmware, then a DLEP proxy can be developed (I've had to do this).  Such a proxy can use the situational awareness channel to implement Neighbour_Up and Neighbour_Down, and if link quality information is also available via a debug channel or in the SA data, that can be used to implement Neighbour_Metrics.  The proxy service does however need to implement a SA identifier to router MAC discovery service.  Also, if only simple RSSI (or no link status) information is available, then some kind of approximation will be required to implement DLEP core metric reporting.

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: Henning Rogge <[email-masked]>
Date: Fri, 23 Aug 2013 08:04:50 +0200

On 08/22/2013 04:12 PM, Taylor, Rick wrote:
> 4. Network technology
> It is common for the radio to only support unicast IP at layer 3, and
> have an extremely simple layer 2 implementation, often terminating at
> the local radio, meaning link-local broadcast and multicast IP are
> not available between radios.

This unicast-only/hidden-routing type of radios are really a pain to use.

> With existing equipment, if a manufacturer intends to add a DLEP
> implementation, then compliance with whatever is finally published
> becomes a problem for the radio vendor themselves.  Most software
> defined radios run an embedded unix-ish operating system internally,
> so adding another software service that can probe the actual RF
> components and IP stack for information should be a simple task.

> If, however, the manufacturer show no willing to add DLEP
> functionality to their radio firmware, then a DLEP proxy can be
> developed (I've had to do this).  Such a proxy can use the
> situational awareness channel to implement Neighbour_Up and
> Neighbour_Down, and if link quality information is also available via
> a debug channel or in the SA data, that can be used to implement
> Neighbour_Metrics.  The proxy service does however need to implement
> a SA identifier to router MAC discovery service.  Also, if only
> simple RSSI (or no link status) information is available, then some
> kind of approximation will be required to implement DLEP core metric
> reporting.

The main problem I see is that radios without multicast support (or at 
least "broadcast") are nearly useless for integration into a larger 
routed network, except as edge networks.

We can tunnel packets through the radios to give the user 
router-to-router layer-2 connectivity, but a broadcast would have to be 
split into a number of unicasts, which is very inefficient.

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: Teco Boot <[email-masked]>
Date: Fri, 23 Aug 2013 08:49:13 +0200

> This unicast-only/hidden-routing type of radios are really a pain to use.

Highly depends on what you try to achieve. IP routing over lower layer IP network: I say don't do that.

I see DLEP acting between the HCDR and application layer (some kind of framework tool), providing info for rate selection (media streams) or path selection (message routing). This also would work great for the low rate CNR (25kHz channels, ~64kbps before FEC). DLEP is a User Network Interface (UNI) protocol, where user equipment could be an IP router or end-station and network equiment is "RF radio" or "wired link modem".

My experience on this topic #4: IP CNR (or so called high capacity data radio's) do support broadcast style multicast. Some do support selective delivery. For plug&play, we could inform the router what kind of multicast operation is supported.

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 27 Aug 2013 08:33:06 +0000

>
> Op 23 aug. 2013, om 08:04 heeft Henning Rogge
> <[email-masked]> het volgende geschreven:
>

Agreed, but people will use them, so we can't just discount them.

> I see DLEP acting between the HCDR and application layer (some kind of
> framework tool), providing info for rate selection (media streams) or path
> selection (message routing). This also would work great for the low rate
> CNR (25kHz channels, ~64kbps before FEC). DLEP is a User Network Interface
> (UNI) protocol, where user equipment could be an IP router or end-station
> and network equiment is "RF radio" or "wired link modem".

This is sounding a lot like Link_Characteristic requests, and is worth some thought...

>
> My experience on this topic #4: IP CNR (or so called high capacity data
> radio's) do support broadcast style multicast. Some do support selective
> delivery. For plug&play, we could inform the router what kind of multicast
> operation is supported.
>

I think this is a key point:  There needs to be some 'descriptive' metric in DLEP to announce the availability of IP multicast and/or link-local broadcast.

The main thrust of my piece was: there are some half-baked SDR implementations out there, and DLEP needs some mechanism to announce that this is the case.

Yes, you're right Teco, HCDR is a not a problem, but some of the manpack radios are definitely 'endpoint only' links to use Henning's expression.

I hope to have some further conversations with one of the major SDR manufacturers in the near future, but these things take time to arrange...

I'll keep you all in the loop as much as possible/legally allowed.

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Aug 2013 10:40:10 +0200

On 08/27/2013 10:33 AM, Taylor, Rick wrote:
> I think this is a key point:  There needs to be some 'descriptive'
> metric in DLEP to announce the availability of IP multicast and/or
> link-local broadcast.

I wonder if we already HAVE this in the current DLEP spec. Multicast is
just another possible target... so either the radio does announce a
"multicast/broadcast MAC" target as a known "neighbor" or it doesn't.

Which give us a fine way to differentiate between "no 
multicast/broadcast", "only broadcast but no dedicated multicast MAC" 
and "full broadcast/multicast" radios.

The radio could even tell the router the multicast-ip to multicast-mac 
mapping with the existing mechanisms.

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Tue, 27 Aug 2013 12:50:38 +0000

> mapping with the existing mechanisms.

I agree Henning, a Neighbour_Up message with a multicast/broadcast MAC address is a good way of indicating multicast/broadcast capability.

But, multicast MAC addresses encode the multicast IPv4/6 group address, and I'm not sure having a neighbour up for 33:33:00:01:00:03 and 33:33:00:01:00:04 and 33:33:00:01:00:05 etc... is a good way for advertise IPv6 multicast.

Could we just state:

Neighbour MAC = FF:FF:FF:FF:FF:FF - Broadcast/Link-local multicast supported
Neighbour MAC = 01:00:5E:00:00:00 - IPv4 multicast supported
Neighbour MAC = 33:33:00:00:00:00 - IPv6 multicast supported

Anything else wanders into the realm of too complicated in my opinion...

Also, I have no idea how link-metrics apply to multicast neighbours, perhaps some kind of aggregate value?

I'm not keen on forcing modems to monitor IGMP in order to report aggregated metrics for multicast neighbours based on the (possibly multihop) links to group members...  This sounds like a 'too hard, didn't implement' issue.

Just thinking out loud...

Rick Taylor

---

From: Henning Rogge <[email-masked]>
Date: Tue, 27 Aug 2013 14:56:04 +0200

> Neighbour MAC = 33:33:00:00:00:00 - IPv6 multicast supported

This looks like a nice way to do it.

Henning Rogge

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 27 Aug 2013 20:06:25 +0000

My initial thoughts on MCAST is that the router (or the radio, but probably the router) would announce availability/capability. It would use the created MAC address, *and* (most likely) the MCAST address as well (at least the router should). That way, a radio implementation at least has the chance of declaring bandwidth for a specific MCAST group (address)… I could see the scheme below, but there's no granularity over and above "I can do MCAST".

Regards,
Stan

On Aug 27, 2013, at 8:56 AM, Henning Rogge <[email-masked]>
 wrote:

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

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Tue, 27 Aug 2013 20:16:47 +0000

OK, design team… time to "help a dummy out"… ;-) ;-) ;-) 
On Aug 27, 2013, at 4:33 AM, "Taylor, Rick" <[email-masked]>

> Yes, you're right Teco, HCDR is a not a problem, but some of the manpack radios are definitely 'endpoint only' links to use Henning's expression.

What *is* HCDR?

Regards,
Stan

---

From: Teco Boot <[email-masked]>
Date: Wed, 28 Aug 2013 07:56:38 +0200

HCDR = High Capacity Data Radio.
At least one vendor uses HCDR as a model (225-450MHz UHF, couple of Mbps, multi-hop, some form of priority queuing).
Other vendors have similar radio's and use HCDR also, as type of radio.

So CNR is digital voice, some data. HCDR is data, maybe voice. (no definition at all, many examples would show it doesn't hold...).

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 28 Aug 2013 08:41:23 +0200

> My initial thoughts on MCAST is that the router (or the radio, but probably the router) would announce availability/capability. It would use the created MAC address, *and* (most likely) the MCAST a…

So you suggest that the router sends the radio the MAC/IP combinations 
for broadcast/multicast and the radio (N)ACKs them?

Henning Rogge

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 28 Aug 2013 08:28:28 +0000

> From: Henning Rogge [mailto:[email-masked]]
>
> > My initial thoughts on MCAST is that the router (or the radio, but
> probably the router) would announce availability/capability. It would use
> the created MAC address, *and* (most likely) the MCAST address as well (at
> least the router should). That way, a radio implementation at least has
> the chance of declaring bandwidth for a specific MCAST group (address)... I
> could see the scheme below, but there's no granularity over and above "I
> can do MCAST".
>

Are we combining two unrelated concepts here?

1) Radio announces it has multicast/broadcast capability.
2) Router asks for metrics for a certain multicast group.

I agree that both are useful concepts: 1) can be announced, as I suggested before, with simple MAC neighbour announcements, but I'm not sure 2) 'works' as a neighbour up?

As I understand the DLEP model, Neighbour Up events are signalled by the radio, rather than the router.

Perhaps concept 2 should use an alternate mechanism such as Link Characteristics?

Which makes me think that the Link Characteristics message is becoming a catch-all dumping ground for concepts we want to support but have no better place to put them...  I expect some more thought is required in this area.

Rick Taylor

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Wed, 28 Aug 2013 09:31:40 -0400

I like the idea of having multicast MAC addresses advertised as
"neighbors" and keeping it simple. I'm wondering, however, is there a
1-to-1 mapping between IP multicast addresses and MAC multicast addresses?
Or is something like many IP multicast addresses map to one MAC multicast
address. On some radios, MAC level multicast can be tied to different
transmit power + rate combinations and also frequency hop receiver groups.
If the radio has those capabilities (MAC address A goes to frequency hop
receiver group A, MAC address B goes with certain transmit power + rate,
etc.), is it possible to have multiple Multicast IP addresses mapped to
multiple MAC addresses? And if so, how would this work in DLEP?

With different transmit powers + burst rates as well as different
frequency hop patterns, each node logically "sees" a different set of
neighbors. Is there a way we can capture that?

A few other questions:

1. If we have metrics for certain multicast groups, how would we take into
consideration radios that have subnet routing? Are the metrics combined or
aggregated? Perhaps we need different metrics for group-links vs.
individual neighbors? (as mentioned before, perhaps "neighbor up/down"
does not apply?)

2. How would flow control work with these "multicast group-links"? If we
go with credit-based approach, would credits be decremented across the
board? In the past, when we've done rate-based flow control, we've put a
base rate on the interface, and then made sure the sum of the rates being
sent to each neighbor (from the reported CDR) be less than that. I'm sure
there's a better way though..

We're seeing a lot more radios being used with multicast/broadcast/geocast
(not necessarily IP-mcast) so its important to address this..

-Bow-Nan

On 8/28/13 4:28 AM, "Taylor, Rick" <[email-masked]> wrote:

>I agree that both are useful concepts: 1) can be announced, as I
>suggested before, with simple MAC neighbour announcements, but I'm not
>sure 2) 'works' as a neighbour up?
>
>Which makes me think that the Link Characteristics message is becoming a
>catch-all dumping ground for concepts we want to support but have no
>better place to put them...  I expect some more thought is required in
>this area.
>
>Rick Taylor
>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: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 28 Aug 2013 13:49:33 +0000

On Aug 28, 2013, at 2:41 AM, Henning Rogge <[email-masked]> wrote:

> So you suggest that the router sends the radio the MAC/IP combinations for broadcast/multicast and the radio (N)ACKs them?

Yup. That's exactly why we made the change in earlier versions of the draft allowing either peer (router or radio) to send Neighbor Up/Down.

Regards,
Stan

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 28 Aug 2013 13:54:21 +0000

> As I understand the DLEP model, Neighbour Up events are signalled by the radio, rather than the router.

The way I'm looking at it, Neighbor Up announces that a "logical destination" is available in the network. That "logical destination" can be represented by a MAC address (in which case some Layer 3 address discovery needs to happen), or by a MAC/L3_ADDRESS combination. As such, an MCAST group is a "logical destination". So the question is, what is it that makes an MCAST group "available"? Seems like that would be recognition by the router. So, we changed the spec to allow routers to issue Neighbor Up as well as radios. 

In this case, the radio would ACK (or NACK) the Neighbor Up. If it's an ACK, then the "interesting stuff" would be the metrics associated with that. If it's a NACK, then obviously, we're pretty much done. 

Regards,
Stan

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 28 Aug 2013 14:41:34 +0000

> From: [email-masked] [mailto:manet-dlep-rg-
> [email-masked]] On Behalf Of Cheng, Bow-Nan - 0665 - MITLL
>
> "neighbors" and keeping it simple.

+1 for simple ;-)

I'm wondering, however, is there a
> neighbors. Is there a way we can capture that?

We have previously discussed grouping neighbours+metrics with DiffServ code points, and this sounds like another reason for the grouping.

I'm currently not concentrating on neighbour grouping, but I feel it is certainly something that has to be handled in DLEP.

Does someone else (Teco/Stan?) want to post our current thoughts about grouping?

> individual neighbors? (as mentioned before, perhaps "neighbor up/down"

Hmmm, subnet routing... my gut reaction is to say that is routing and therefore out of scope for DLEP.  For subnet routed unicast I would expect each routable neighbour to have their own metrics, and I'm not sure I understand what you mean by subnet-routed multicast...

> there's a better way though..

Stan, this is definitely one for you, I'm staying well away from credit-based flow control as I (personally) feel it's out of scope, but I know it's popular...

> (not necessarily IP-mcast) so its important to address this..

Agreed!

Rick Taylor

---

From: "Taylor, Rick" <[email-masked]>
Date: Wed, 28 Aug 2013 14:47:04 +0000

> From: Stan Ratliff (sratliff) [mailto:[email-masked]]
>
> On Aug 28, 2013, at 2:41 AM, Henning Rogge
> <[email-masked]> wrote:
>
> Yup. That's exactly why we made the change in earlier versions of the
> draft allowing either peer (router or radio) to send Neighbor Up/Down.
>

I had forgotten Neighbour_Up required/allowed an (N)ACK.  Is it therefore the responsibility of a radio that does not support multicast to negatively ACK any multicast Neighbour Ups?

That feels like mechanism dictating policy.  I would prefer some additional method for a radio to announce its ability to handle multicast/broadcast in general.  After that, routers are ok to announce interest in multicast groups via Neighbour Up.

Rick Taylor

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 28 Aug 2013 15:09:28 +0000

> multiple MAC addresses? And if so, how would this work in DLEP?

IIRC, the MCAST address is "hashed" to create a MAC address. So, there could be multiple addresses that hash to the same MCAST MAC. At least with my current implementation of DLEP, this will cause a minor (but solvable) problem, in that a "Neighbor Up" on an existing MAC is assumed to be a loss of state between radio and router (Neighbor Up is not "additive") - the current session is torn down, and the new session is put in its place. But like I said, that's solvable, especially if it's within the context of MCAST only.

> consideration radios that have subnet routing?

Not sure what you mean here. 

> Are the metrics combined or
> aggregated?

Aggregated to what? I'm assuming that metrics are tied to a "logical destination". As such, the MCAST group would be a "logical destination", and would, therefore, have its own set of metrics. 

> Perhaps we need different metrics for group-links vs.

Well, I disagree that Neighbor Up/Down doesn't apply. As mentioned above, using Neighbor Up/Down creates an environment where you can get group-specific (or rather, MAC-specific) metrics. 

> board?

Since the MCAST group is a "neighbor" (logical destination), it would have its own credits. 

> In the past, when we've done rate-based flow control, we've put a

Ahhh… I've always looked at overcommitting resources as the radio's problem. If a given implementation chooses to do that, then I wish them well… ;-)

Regards,
Stan

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Wed, 28 Aug 2013 11:20:29 -0400

Hi guys,

Responses below:

>Hmmm, subnet routing... my gut reaction is to say that is routing and
>therefore out of scope for DLEP.  For subnet routed unicast I would
>expect each routable neighbour to have their own metrics, and I'm not
>sure I understand what you mean by subnet-routed multicast...

What I mean by subnet-routing is that radios provide some sort of layer 2
multi-hop capability. For unicast, this might be some sub-IP MANET routing
protocol. For multicast, this could either provide multi-hop broadcast or
multi-hop multicast (not everyone receives). So for unicast, I can
understand that each routable neighbor would have their own metrics (even
if its multiple RF hops due to the sub-IP routing). For multicast, how
does one describe a "link quality" or a "current data rate"? Some radios
have good granularity to metrics for 1-hop information, but for
multi-RF-hop info, its harder to aggregate quality or rate (add the rates
along the path? Have some equation for rates?). I guess we could just use
the multicast base rate associated with that group, but I'm thinking about
other metrics.

---

From: "Stan Ratliff (sratliff)" <[email-masked]>
Date: Wed, 28 Aug 2013 15:27:32 +0000

> the multicast base rate associated with that group, but I'm thinking about

The case you describe (multi hop Layer 2) is *exactly* the use case for mesh radios. It's the radio's responsibility - metrics should reflect the overall capability, across all hops. If the radio is incapable of reporting across multiple hops, then it probably shouldn't be using any R2R interface or protocol...

Regards,
Stan

---

From: Henning Rogge <[email-masked]>
Date: Thu, 29 Aug 2013 10:50:36 +0200

On 08/28/2013 05:27 PM, Stan Ratliff (sratliff) wrote:
> On Aug 28, 2013, at 11:20 AM, "Cheng, Bow-Nan - 0665 - MITLL"
> <[email-masked]> wrote:
>> What I mean by subnet-routing is that radios provide some sort of
>> layer 2 multi-hop capability. For unicast, this might be some
>> sub-IP MANET routing protocol. For multicast, this could either
>> provide multi-hop broadcast or multi-hop multicast (not everyone
>> receives). So for unicast, I can understand that each routable
>> neighbor would have their own metrics (even if its multiple RF hops
>> due to the sub-IP routing). For multicast, how does one describe a
>> "link quality" or a "current data rate"? Some radios have good
>> granularity to metrics for 1-hop information, but for multi-RF-hop
>> info, its harder to aggregate quality or rate (add the rates along
>> the path? Have some equation for rates?). I guess we could just
>> use the multicast base rate associated with that group, but I'm
>> thinking about other metrics.
>>
>
> The case you describe (multi hop Layer 2) is *exactly* the use case
> for mesh radios. It's the radio's responsibility - metrics should
> reflect the overall capability, across all hops. If the radio is
> incapable of reporting across multiple hops, then it probably
> shouldn't be using any R2R interface or protocol...

I agree,

if a radio delivers multi-hop linklayer transmission, it should also 
deliver the metrics for these multi-hop routes. If it only allows 
single-hop linklayer, it delivers the metrics for single-hop routes.

Henning Rogge

---

From: "Cheng, Bow-Nan - 0665 - MITLL" <[email-masked]>
Date: Fri, 30 Aug 2013 15:54:19 -0400

>single-hop linklayer, it delivers the metrics for single-hop routes.

I think my concern is that when we've defined metrics in the past, they
make sense for single hops (relative link quality, current data rate,
etc.).. But when you go multiple hops, I'm not sure what it means. Is
relative link quality an average of the link quality on all the hops? Or
is bounded by the minimum? Is current data rate the average of the data
rate along the path? Or the limiting data rate?

I don't have a problem having radio manufacturers fit things into the
metrics, but what we do end up seeing is that everyone does it different
if its not explicitly stated. When we work in a heterogeneous radio
environment, its important to compare apples-to-apples for metrics. CDR
for one radio should have the same notion as CDR for another radio. Or
else how can we make routing decisions if you have to know very specific
things about every radio? I understand some radios will have
radio-specific metrics, but for the metrics we're planning to standardize
in DLEP as the "big 5" (or however many), it should be radio agnostic.

My hope is that we *can* define metrics that also capture what it would
mean if there is a multi-hop mesh routing feature in the radio.

-Bow-Nan