Subject: [manet] Question about OLSRv2 link metric implementation

From: Henning Rogge <[email-masked]>
Date: Thu, 10 May 2012 09:00:42 +0200

Hi,

I am working on reviving my Freifunk-ETX draft again and thinking about 
to split it into two different drafts. One that discusses the general 
aspects of an ETX metric implementation.

Most times ETX metrics are described as a symmetric metric, where the 
link cost does include both directions of the link, and I think there 
are several link layer designs where combining the packet loss in both 
directions makes sense (not necessarily with the same weight).

For this both sides of the Metric implementation have to communicate 
with each other outside the normal metric TLV described in the OLSRv2-draft.

Do you think it makes sense to ask IANA to allocate a generic "Private 
Link Metric Data" TVL, that will use the same extension types as the 
metric TLV in OLSRv2 and allows a metric implementation to exchange data 
with the other side of the link?

Allocating an "ETX specific TLV" sounds even worse.

Henning Rogge
-- 
Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Neuenahrer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de
GPG: E1C6 0914 490B 3909 D944 F80D 4487 C67C 55EC CFE0

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 10 May 2012 09:08:18 +0000

I'm not a great fan of either. Allocating a whole range of type extensions may include type extensions with no need to communicate. And if link metric type X needs to communicate, it won't necessarily send link metrics as its supplementary information. But as you say, an ETX specific TLV isn't nice either.

I realise that anyone who says "I don't like either" should make a third proposal. Right now I don't have one, though I will think about it. This is really to say if anyone has any alternative suggestions, they would be welcome.

-- 
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 Henning Rogge
Sent: 10 May 2012 08:01
To: [email-masked]
Subject: [manet] Question about OLSRv2 link metric implementation

Hi,

Henning Rogge

********************************************************************
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: Henning Rogge <[email-masked]>
Date: Thu, 10 May 2012 11:21:53 +0200

On 05/10/2012 11:08 AM, Dearlove, Christopher (UK) wrote:
> I'm not a great fan of either. Allocating a whole range of type
> extensions may include type extensions with no need to communicate.
> And if link metric type X needs to communicate, it won't necessarily
> send link metrics as its supplementary information. But as you say,
> an ETX specific TLV isn't nice either.

That's exactly my problem. Both solutions are not nice, but something is 
necessary.

> I realise that anyone who says "I don't like either" should make a
> third proposal. Right now I don't have one, though I will think about
> it. This is really to say if anyone has any alternative suggestions,
> they would be welcome.

Hmm... I just had another "not so nice" thought.

We use a 4 bit header in our metric TLV value to encode the context of 
the metric value (link incoming/outgoing, tc incoming/outgoing).

Could we use the unused 0000 header combination used with HELLO message 
addresses for transferring data between the two link metrics on both 
sides of the link?

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Thu, 10 May 2012 12:04:43 +0200

I do agree with Chris - I've got about 5 other I-Ds taking cycles right now, so I do not have a good idea - but will think about it once they're out the door.

That said, I do think that it is a good initiative, Henning, and I would encourage (and offer assistance on) production of an ETX metric for OLSRv2.

I also would very much encourage documenting "The FunkFeuer Exeperience" in an informational RFC; I believe that as you guys have an operational, large and long-standing MANET running, it'd be valuable information for others deploying such networks. Thus, 100% support from me on that also.

Best,

Thomas

On May 10, 2012, at 11:08 , Dearlove, Christopher (UK) wrote:

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 10 May 2012 10:41:48 +0000

There is one possible (but not documented) existing use of 0000. That is to enable a multi-value TLV to run over a range of addresses, one of which (perhaps a LOST LINK_STATUS) doesn't need a metric, but no harm would be produced if given a 0000 one. Using the one multivalue TLV might be easier/more efficient.

-----Original Message-----
From: Henning Rogge [mailto:[email-masked]] 
Sent: 10 May 2012 10:22
To: [email-masked]
Cc: Dearlove, Christopher (UK)
Subject: Re: [manet] Question about OLSRv2 link metric implementation

Henning Rogge

---

From: "L. Aaron Kaplan" <[email-masked]>
Date: Wed, 16 May 2012 13:25:05 +0200

> I also would very much encourage documenting "The FunkFeuer Exeperience" in an informational RFC; I believe that as you guys have an operational, large and long-standing MANET running, it'd be valu…

Hi Thomas,

this is a job which has been waiting to be scheduled for a long time.
I'll bump up its priority level.

July looks good for sitting down and finally writing it.
I'd be happy to have some reviewers.

Aaron.

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 16 May 2012 14:09:28 +0200

Hi Aaron,

July looks good indeed. I look forward to it - count me in.

Thomas