Subject: Re: [manet] AODVv2 progress

From: Christopher Dearlove <[email-masked]>
Date: Thu, 11 Sep 2014 12:44:49 +0100

(Changed to send to list, as someone else may find this useful. Or not. Written in a hurry, so apologies for any errors.)

Let me have a bash as Index Start and Index Stop. This will be an NHDP example for convenience.

Let's suppose we have five addresses in a single address block in a HELLO message. Two are local, three are neighbours'.

For the last three we want to associate a LINK_STATUS TLV with them.

Prior to RFC 7188 (which I will get back to) the definitely most efficient way to do this was to put these three addresses together, let's say after the two local addresses. Note that this doesn't violate the "don't use address order" rule, as no meaning is assigned to the position, just ordering allows us to create more efficient messages. We could put those three addresses first, third and fifth for a maximally inefficient message with three LINK_STATUS TLVs if we wanted to.

(As an aside, I have an implementation that is close, if not at, optimum for doing this for standard NHDP/OLSRv2 use. I know Henning has worked on a different approach also aimed at efficient messages, and if I guess right others have worked on this too.)

Anyway, so we now put the three messages in the last three places, numbered 2,3,4 (we number from zero).

So now we might have two cases. In the first, all have the same link status, say SYMMETRIC. We can create a single value LINK_STATUS TLV with two indices (indexes in the RFC, but that's written in American English), Index Start = 2, Index Stop = 4, value field SYMMETRIC. In the second, we create a multivalue TLV with value field (say) SYMMETRIC SYMMETRIC HEARD. That turns out to be more efficient than two single value TLVs doing the same job. (Single value TVs can win with lots of neighbours.)

Now with RFC 7188 we have another option. We could have a LINK_STATUS TLV covering all five addresses, which now no longer gain at all from ordering, but I'll stick to the same ordering for convenience. We need no indices and can have a multivalue TLV with value field UNSPECIFIED UNSPECIFIED SYMMETRIC SYMMETRIC HEARD (in the second example above).

(Actually with that 2+3 pattern, both options are equally efficient. With one more local address or all symmetric, and addresses organised, there's a win in not using UNSPECIFIED.)

Finally, if we want to just associate with a single address in a multiple address block, we can use a single index form with just one index (that is in effect both Index Start and Index Stop).

Some things to note
- The sender can play whatever games it likes in sorting or not, using or not using UNSPECIFIED, single value or multivalue TLVs, one TLV or many. It affects efficiency, but not meaning.
- Whether there are zero, one or two indices, and single or multiple values is signalled in the TLV flags octet.
- The receiver is simpler in that it just reads what's there and interprets it. Position is not used for meaning, except via indices telling you which addresses are covered.
- However, while the sender can choose not to use things, the receiver must be able to interpret whatever it gets. Including RFC 7188.
- The simplest approach is to take addresses as they come (unsorted) simply cover all addresses, not uses indices, use UNSPECIFIED as required, always use a multivalue TLV. Next simplest is that with some optimisation (strip leading trailing UNSPECIFIEDs, use single value if that now works).

In an ideal world, this is another of those things that at least something should be said in the still-intended-but-could-we-have-more-hours-in-the-day-please 5444 usage draft. 

Hope that helps. There s an example HELLO message in RFC 6130. I think it includes indices, but it may not.

On 11 Sep 2014, at 11:49, John Dowdell wrote:

> All
> 
> You already know that the AODVv2 draft is a large and complex document, and judging by the number of tickets and the high volume of discussions on the mailing list, a number of WG participants have a number of issues with the text. I have been working through the draft in recent weeks trying to make it more clear and consistent before trying to apply the comments on the list and the tracker. I'm not at the end of that first sweep yet.
> 
> Trouble is, my cycles are currently limited to an average of 10-20% of my working week (which does not routinely include evenings or weekends) so progress is slow, particularly when my day job has a priority call. I am hoping that this situation will improve in 2015. That is not to say I am not committed to getting the draft finished. It is very unlikely that you will see a document that incorporates all your comments by the next meeting, but please do continue to discuss the content and suggest changes which will be incorporated at the appropriate time. If you are not happy with this situation you are, of course, free to discuss it with the co-chairs.
> 
> I am also new to RFC5444, but I believe I have a reasonably good understanding of that now. If someone could explain to me how Index Start and Index Stop should be used, I'd have a better understanding.
> 
> Thank you in advance for your patience and understanding.
> 
> John