Subject: Re: [Manet-dt] Unknown TLVs - > A Command Packet Format

From: Ian Chakeres <[email-masked]>
Date: Wed, 28 Sep 2005 20:17:05 -0700

Charlie and I were recently discussing a common packet format. We are
examining how DYMO and OLSRv2 messages could be mapped to a common
format and what type of message and address tlvs DYMO would need.

We like the modularity of the packet format, but are worried about the size.

Hopefully we'll formalize our thoughts soon. I am waiting until we
fully populate the manet-dt list to really start the discussion.

Ian

_______________________________________________
Manet-dt mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet-dt

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 29 Sep 2005 09:27:41 +0100

> but are worried about the size.

I think there's a tradeoff between intelligence
(software skills and processing power) and size.
What I mean is that with careful juggling of
addresses in the address block, at least two
TLVs per block can use continuous ranges and
just be entered once. The size could be better
than a conventional non-TLV approach. (The
address block compression is, separately,
definitely a space saver, for IPv6 in particular.)
I suspect that in typical use, even for IPv4, an
OLSRv2 message is likley to turn out to be smaller
than the equivalent OLSRv1 message, but I can't
prove that (or even have any real evidence yet).

It's also worth considering the systems of interest.
For 802.11, layer 2 overheads are such that (within
reason) packet sizes are very much secondary to how
many packets are sent in overall overhead. But this
may not be the case in all systems.

If you really wanted to go overboard, we currently
have a bit flag in the OLSRv2 TLV type (multivalue).
[We actually have two, user/standard, but that's
not relevant here.] I did write up something on how
to introduce two or three more bit flags to save a
a few more bytes (I could dig it out, but I doubt
it's worth it.) We decided against it (the concept,
not the specific proposal) on the grounds of not
enough gain for too much complexity except the
multivalue bit which has potentially large savings
for some possible extensions.

The one place we definitely have unnecessary bytes
is the two zero indices in each TLV in the message
TLV block, which are essentially there for regularity.
These could be removed for a small overhead gain and
added complexity of explanation.

It's also worth making one final point, which is the
fixed 12 (for IPv4) byte message header which is
unchanged from OLSRv1, deliberately for possible
backward compatibility and interworking, but is
less common or flexible.

********************************************************************
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.
********************************************************************