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

["Dearlove, Christopher (UK)" <[e-mail]>]

Based on comments made on the generalised OLSRv2 packet/message
format, I (and here I'm just speaking for me) would make the
following points.

(a) Message TLV indices. I think that these are likely to go in
    the next version, as the saving in complexity isn't quite
    enough to justify them.

(b) Message semantics bits. We only have 8 of these. 2 are used,
    and 1 we have a plan for (not finalised, so not in the draft).
    This makes them a scarce resource. This informs the following
    comments.

(c) There are four items in the optional part of the message
    header, using a single bit to indicate whether they are
    present or not. They actually divide into two. First is
    the originator address and message sequence number. These
    are used for duplicate detection and management. The
    second is the TTL and hop count, which are used for
    forwarding. (Forwarding by flooding needs both.) I could
    see some logic in using one more message semantics bit
    to include these two independently. I can't see that any
    finer control is appropriate, given the limited number
    of semantics bits. Given that the message sequence number
    must be originator specific, so having the former without
    the latter is not appropriate, this means that worst case
    is 2 unwanted bytes in one case, plus 1 unwanted byte
    (more likely hop count than TTL) in the other case. This
    is not really significant.

(d) There are conflicting, but both legitimate, requirements
    on the one hand to modify messages as they are forwarded
    (for various possible reasons) and on the other hand for
    immuatable - except for TTL/HC - messages (for reasons of
    end to end signature/authentication). Either or both of the
    following two semantic bit suggestions might help with this.
    (For example a signed message could be sent with "do not
    modify", or a received signed message with "has been
    modified" would be known to be unverifiable - with whatever
    consequences are chosen.)

(e) We could use a semantic bit to control whether a message
    may or may not be modified when forwarded. In the latter
    case an intermediate node would then either forward
    unchanged (whenever possible) or discard the message
    (when not). This would be a SHALL/MUST I think.

(f) We could use a semantic bit to indicate whether the message
    has been modified since it was originated. Obviously this
    would be sent unset, a later node might set it.

(g) TLVs are more difficult. We have used two bits of the TLV
    type, for multivalue and for user. [Note: we want the
    packet/message parsing code to be type independent, which
    it currently is. Having the multivaluedness type dependent
    in an unknown way breaks this, which is not acceptable.
    In addition note that we may have single and multivalue
    versions of the same type, which we have imposed rules on
    to make certain simplified parsing options - which some
    members of the OLSR community want - possible. This also
    applies to various other possibilities.] There are many
    good things we could do with more bits (for example 0, 8
    or 16 bit value lengths - the first of these for where the
    type is the information - sub-octet values in multivalue
    fields, control options for unknown TLVs - ignore, remove,
    discard message). Putting aside the complexity and value
    tradeoffs of such options, there's a major problem of not
    having the bits. We just might manage one more bit, but
    after that, based on the number of options just for OLSR
    that have been proposed, it starts getting tricky. I do
    have one idea what to do here, with (as ever) pros and cons,
    but I want to think about it a bit more before deciding if
    it's a candidate.



********************************************************************
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt