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

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

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

> 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),

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>
> to have a "tail" option like the address blocks do if that is desired
> for a protocol using this message construction?

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.

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

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

_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt