Subject: [manet] New TLVs for reactive protocol messages

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 21 Jan 2013 12:00:10 -0800

Hello folks,

As Henning has proposed, it is possible to revise the AODVv2 Address TLV
definitions so that in the base protocol, the AddrBlk addresses do not need
to have any additional position-based semantics.  I have made some
example packet formats and definitions, herewith...

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

"Route Discovery Originator Sequence Number":
     The sequence number for the originating node that triggered
     the RREQ message initiating the Route Discovery operation.

Another TLV for "Route Discovery Target Sequence Number"
     The sequence number for the target node for which a route
     was requested by way of RREQ from the originating router.

The following packet formats look best with fixed-width fonts.
If I didn't get all the RFC 5444 bits correct, please don't shoot
me, but I think they're correct.

Original: SeqNum TLV shown with an example AddrBlk:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   num-addr=2  |1|0|0|0|0| Rsv | head-length=3 |Head(Orig&Targ)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Head (bytes for Orig & Target)|   Orig.Tail   | Target.Tail  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      addr.tlvs-length=6       |  type=SeqNum  |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2  |     Orig.Node Sequence #      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

One Sequence Number: Original Node SeqNum TLV:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      addr.tlvs-length=6       | type=OSeqNum  |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2  |     Orig.Node Sequence #      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

One Sequence Number: Target Node SeqNum TLV:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      addr.tlvs-length=6       | type=TSeqNum  |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=1 | tlv-length=2  |     Targ.Node Sequence #      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Two Sequence Numbers: SeqNum TLV:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      addr.tlvs-length=7       |  type=SeqNum  |0|0|0|1|0|1|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| tlv-length=4  |     Orig.Node Sequence #      | TargNode Seq# |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TargNode Seq# |
+-+-+-+-+-+-+-+-+

Two Sequence Numbers: Originating and Target Node SeqNum TLVs:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      addr.tlvs-length=12      | type=OSeqNum  |0|1|0|1|0|0|Rsv|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index-start=0 | tlv-length=2  |     Orig.Node Sequence #      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| type=TSeqNum  |0|1|0|1|0|0|Rsv| Index-start=1 | tlv-length=2  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Targ.Node Sequence #      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I propose to replace the existing AODVv2 TLVs with the TLVs defined above,
and to move the positional-dependent SeqNum TLV to iRREP specification.

-- 
Regards,
Charlie P.

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jan 2013 15:43:19 +0100

> and to move the positional-dependent SeqNum TLV to iRREP specification.

Even if it costs us a few bytes (I forgot about one type of TLV 
compression), I suggest not doing this.

We are adding information without any type or attribute to a type based 
format. We are wasting a lot of potential of the format with this.

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: Thomas Heide Clausen <[email-masked]>
Date: Tue, 22 Jan 2013 16:18:41 +0100

Agree w. Henning. 

-- 
Thomas Heide Clausen
http://www.thomasclausen.org

"Today's scientists have substituted mathematics for 
  experiments, and they wander off through equation 
  after equation, and eventually  build a structure 
  which has no relation to reality."
 - Nikola Tesla, 
    Modern Mechanics and Inventions, July, 1934

On 22 janv. 2013, at 15:43, Henning Rogge <[email-masked]> wrote:

> Even if it costs us a few bytes (I forgot about one type of TLV compression), I suggest not doing this.
> 
> We are adding information without any type or attribute to a type based format. We are wasting a lot of potential of the format with this.
> 
> Henning Rogge
> 
> -- 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Jan 2013 10:22:31 -0800

Hello Henning,

> compression), I suggest not doing this.

Well, it's 7 bytes versus 12 bytes.

>
> We are adding information without any type or attribute to a type 
> based format. We are wasting a lot of potential of the format with this.

I don't understand this.  Implementations that don't need to save the
space would certainly have the other alternatives available, right?
Plus, I don't exactly understand your point about wasting the potential
of "the format"...?  Which format is being wasted?

-- 
Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 20:01:04 +0100

Hi Charlie,

I did not understand your input proposal and Henning's input as well
(what did he forget?). Your input did not say why you are changing
that TLV, as I always like to know why we do things so we can relate
our actions with reason so I can understand, also not sure what was
exactly henning's proposal mentioned in main-post, because Henning had
many on the list and this was a new thread.

I expect I will have to study this change, not sure what to say.
Regarding Hennings reply, he still not happy with TLV change because
he wants to see the associated attribute of that information, maybe
that is what he ment,

AB

---

From: Henning Rogge <[email-masked]>
Date: Tue, 22 Jan 2013 21:18:45 +0100

> Well, it's 7 bytes versus 12 bytes.

No, it might be 49 vs. 54 bytes. Maybe the difference will be even
less compared to the airtime the signal will use up.

> of "the format"...?  Which format is being wasted?

The chance of building MANET protocols with a TLV format... you are
throwing away parts of the advantages of a TLV format.

Henning Rogge

-- 
We began as wanderers, and we are wanderers still. We have lingured
long enough on the shores of the cosmic ocean. We are ready at last to
set sail for the stars - Carl Sagan

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 22 Jan 2013 21:25:40 +0100

We don't need to send through all important information just demanded,
because all potintial info may not be needed, we may use all resources
we got. Did I miss your point, not sure,

AB

---

From: Teco Boot <[email-masked]>
Date: Tue, 22 Jan 2013 22:11:18 +0100

Where 5444 would bring a fairly large compression ratio to NHDP and 
OLSRv2, I wonder if it is helpful for AODV. If not, we can just skip 
5444 or put the message in a TLV.

I didn't follow the long track from AODV to our current work, e.g. 
shortening Sequence Number. Were are we, in terms of message sizes, 
comparing current proposals to 3561? Assume v4 shared /8 and v6 shared 
/64, random mids, no tail.

Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 22 Jan 2013 13:30:11 -0800

Hello Teco,

I think there are many cases where RFC 5444 will be helpful for AODVv2.
In particular, IPv6 addresses are likely to afford quite a bit of address
compression.  Even if there are only two addresses in RREQ, they could
easily share a /56 prefix, saving 7 bytes per transmission.

Anyway, I think we are mandated to use RFC 5444 and we shouldn't
spend too much time on trying to change that mandate.

Regards,
Charlie P.

-- 
Regards,
Charlie P.

---

From: Teco Boot <[email-masked]>
Date: Tue, 22 Jan 2013 23:09:50 +0100

> spend too much time on trying to change that mandate.

I would say: we are guided to use RFC 5444. If it doesn't make sense, ...

I understand the multi protocol scenario. So we are at defining the
AODVv2 message in 5444.

On OrigNode, why not use the <msg-orig-addr> element? OK, no compression. 
But also no TLV needed to point to this address. And msgs without 
<msg-orig-addr> all over the place would break thinks (at least me, using 
wireshark for debugging and my stats tool).

Please help me pointing to an AODVv2 message where an <addr-block> has 
real benefit. If nothing is on the table, I suggest using just a 
<tlv-block>. Compact and straightforward. Nothing wrong with that, isn't 
it?

Teco

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jan 2013 07:41:18 +0100

> easily share a /56 prefix, saving 7 bytes per transmission.

RFC5444 will allow to safe even more space when a node has multiple 
local addresses. Media access is often as expensive as the short 
messages of a MANET itself, so it makes sense to reply with all your 
local IPs (not the linklocal ones of course) to a request on one of them.

Henning Rogge

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 23 Jan 2013 08:30:26 +0100

On Jan 23, 2013, at 07:41 , Henning Rogge <[email-masked]> wrote:

> RFC5444 will allow to safe even more space when a node has multiple local addresses. Media access is often as expensive as the short messages of a MANET itself, so it makes sense to reply with all your local IPs (not the linklocal ones of course) to a request on one of them.
> 

Henning brings up a good point, which was very much taken into account when designing RFC5444.  It would be a mistake to make restrictive assumptions (such as "an interface never has more than a single [more-than-LL-scoped] IPv6 address"), in a protocol design - even though under such a restrictive assumption, an insignificantly more compact format might result.

In IPv4, aggregation is typically of the form of "shared prefix, multiple distinct addresses" (and in that case, representing the prefix only once). In IPv6, an interface may (and often does) have multiple IPv6 addresses, where the structure of these are "different prefixes, same InterfaceID" (in that case, representing the interfaceID once, and listing the prefixes).

I.e. 5444 supports efficient representation of both (and, a clever *generic* 5444 generator will be able to produce such efficient messages, regardless of protocol).

Thomas

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 23 Jan 2013 08:35:18 +0100

> I would say: we are guided to use RFC 5444. If it doesn't make sense, ...

RFC5498 (std. track) section 1 seems to disagree with you here:

	"All interoperable protocols running on these well-known IANA allocations MUST conform
	   to [RFC5444].  [RFC5444] provides a common format that enables one or
	   more protocols to share the IANA allocations defined in this document
	   unambiguously."

 I do think that RFC5498 is right on that point....and the solution is, therefore, simple if a protocol wishes to NOT use RFC5444: it can go ahead and request different IANA allocations. It, probably, would not be a MANET wg protocol, in that case.

Best,

Thomas

---

From: Teco Boot <[email-masked]>
Date: Wed, 23 Jan 2013 08:56:56 +0100

I don't want to spend many cycles on these religious discussions. 

But I read this RFC5498 very different. When a protocol does not use 
[RFC5444], it is not interoperable. When it does, it is. It does in no 
way mandates something. To emphasize: enable != enforce.

So yes, RFC5498 is right on that point.  :-) 

You suggest to throw DLEP out of MANET WG, unless it uses 5444? I *totally* 
disagree. Let's keep thinking and make smart decisions. I hate this black 
and white discussions, real world is grey.

No misunderstanding: I still see advantages using 5444 for reactive.

Teco

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 09:32:21 +0100

The current AODVv2 dymo-25 does confirm to rfc5444, not sure what you
mean, but we must confirm to 5444 only if we use port of MANET,

AB

On 1/23/13, Thomas Heide Clausen <[email-masked]> wrote:
>  I do think that RFC5498 is right on that point....and the solution is,
> therefore, simple if a protocol wishes to NOT use RFC5444: it can go ahead
> and request different IANA allocations. It, probably, would not be a MANET
> wg protocol, in that case.
>
> Best,
>
> Thomas
>
>
>>>>>>> based

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 09:39:06 +0100

> way mandates something. To emphasize: enable != enforce.
I change in statement;

When a protocol does not use
[RFC5498], it is not interoperable with RFC5444 protocols. However,
When it does, it is. I think RFC5498 does mandates use of 5444.

Do you agree,

AB

---

From: Teco Boot <[email-masked]>
Date: Wed, 23 Jan 2013 09:46:26 +0100

> When it does, it is. I think RFC5498 does mandates use of 5444.
If you keep the nuances, I agree.

5498 provides good instruments to build completely incompatible protocols.
Ever seen an IP manet protocol interworking with an UDP manet protocol?

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 09:51:55 +0100

Yes your right thanks,

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 23 Jan 2013 09:54:46 +0100

> Ever seen an IP manet protocol interworking with an UDP manet protocol?

Nitpicking, yes I have: an OLSRv2 router with two interfaces towards different domains, one of which running over UDP, the other over IP directly. Both hiving off packets to the same 5444 parser and OLSRv2 code in the same router, and TC messages crossing seamlessly between the "over UDP" and the "over IP" domains via said router.

The miracle of layers, I know ;)

But, I know what you meant, I think ;)

---

From: Henning Rogge <[email-masked]>
Date: Wed, 23 Jan 2013 10:27:41 +0100

On 01/23/2013 09:54 AM, Thomas Heide Clausen wrote:
>> 5498 provides good instruments to build completely incompatible
>> protocols. Ever seen an IP manet protocol interworking with an UDP
>> manet protocol?
>
> Nitpicking, yes I have: an OLSRv2 router with two interfaces towards
> different domains, one of which running over UDP, the other over IP
> directly. Both hiving off packets to the same 5444 parser and OLSRv2
> code in the same router, and TC messages crossing seamlessly between
> the "over UDP" and the "over IP" domains via said router.

I have even played with transmitting RFC5444 messages with 16 bytes
addresses over IPv4 UDP.

Henning Rogge

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 23 Jan 2013 10:31:58 +0100

On 1/23/13, Thomas Heide Clausen <[email-masked]> wrote:
> directly. Both hiving off packets to the same 5444 parser and OLSRv2 code in
> the same router, and TC messages crossing seamlessly between the "over UDP"
> and the "over IP" domains via said router.
>

I think it is miracle of OLSRv2 interfaces to use same packet format
but different ports,

AB

---

From: Thomas Heide Clausen <[email-masked]>
Date: Wed, 23 Jan 2013 10:33:10 +0100

> I think it is miracle of OLSRv2 interfaces to use same packet format

I assume you do not mean "different ports" but "port and protocol number"?

But no, that is no miracle - that is very much intentional and by design.

Thomas