Subject: [Manet-dt] Generalised OLSR packet/message format comments

From: Brian Adamson <[email-masked]>
Date: Fri, 17 Feb 2006 13:11:09 -0500

Justin, Thomas, Chris, et al

I am wrestling with the fact that certain <msg-semantics> settings 
(e.g. bit 0 not set, but bit 1 set) results in non-32-bit aligned 
<msg-header-info> content ...

This by itself wouldn't be an issue, if there were some option to pad 
the <msg-header-info> to 32-bit alignment ...

Perhaps another unused <msg-semantic> bit could be set to indicate 
whether the <msg-header-info> is padded out to 32-bit alignment, 
regardless of the semantics? (i.e. a "tail" indicator?)

Perhaps I am too hung up on having 32-bit aligned message parsing 
code (i.e. so that TLV's and address blocks end up on 32-bit 
boundaries), but perhaps it would be useful for the <msg-header-info> 
to have a "tail" option like the address blocks do if that is desired 
for a protocol using this message construction?

I am creating a generalized set of C++ classes that implement message 
building and parsing that I will be using for an SMF "hello protocol" 
implementation.  I will be posting this code as part of the open 
source "nrlsmf" code distribution as it is more complete for anyone 
interested.  My current approach with the building/parsing code is to 
provide for 32-bit aligned packet/message construction.  In the 
longer term, I may provide an alternative implementation that doesn't 
require 32-bit alignment of significant packet/message structures 
(e.g. headers, address blocks, tlv blocks, etc), but I thought I 
would go for the "pretty" approach and thus the issue above came to 
light ...

Any comments?

cheers,

-- 
Brian
__________________________________
Brian Adamson
<mailto:[email-masked]>

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 20 Feb 2006 09:09:12 +0000

><msg-header-info> content ...

There's only one thing in the entire format that matters if it is 32
bit aligned, and that's the originator address, and if you add padding
octets after a message then the message header, and hence the originator
address, will be 32 bit aligned. And that's optional, you need to handle
messages from senders who don't do that. Why do I say nothing else
matters?
Because nothing else is a 32 bit (or 128 bit) value to be so aligned.
(OK, minor exception, a single address in an address block, with head
length equal to address length. But that's the exception rather than the
rule, and still doesn't help as noted below.)

> boundaries),

As neither TLVs nor address blocks have lengths that are multiples
of 32 bits, if you want 32 bit alignment there (for no good purpose
that I can see - in the exceptional case I note, if the address block
is 32 bit aligned the address won't be) then you would need to pad
every single address block and every single TLV.

> but perhaps it would be useful for the <msg-header-info>

The tail option on the address blocks isn't for padding, it's for the
multiple least significant bits of addresses. It's not 32-bit aligned.

> would go for the "pretty" approach and thus the issue above came to

You can't have 32 bit alignment and this approach to packet/message
format. Things that are inherently 32-bit alignment unfriendly:
address compression with single head and multiple tails, TLV value
fields that are of variable length that is not always (not usually)
a multiple of 32 bits. So a 32-bit aligned approach isn't going to
work.

I can tell you it's possible to create C++ classes for message building
and parsing of this format, including all the options: I have them.
But they won't be made publicly available I'm afraid.

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