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

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Mon, 30 Jan 2006 09:26:55 +0000

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

---

From: Thomas Clausen <[email-masked]>
Date: Mon, 30 Jan 2006 12:06:32 +0100

Chris, All,

I will try to focus this email on the overall design philosophy and the 
message header, leaving the details of the TLVs for another email.

>     the next version, as the saving in complexity isn't quite

I've spent some time playing with both options in an implementation 
context (running code, and all that....), and I agree with Chris and 
the other who've expressed opinions on this issue. The -01 draft will 
be updated to reflect this.

>     This makes them a scarce resource. This informs the following

A more general comment on these message semantics flags, which really 
only serves to confirm what Chris has just said: since we're aiming for 
a general format, these message semantics bits must also be very 
general. Also, I think that we should keep in mind, as we've tried thus 
far, to ensure that the message header (standard or reduced message 
header) suffices for determining any content-independent processing of 
the message. Thus, the semantics-flags should ensure that a node can 
uniquely make forwarding decisions. I think that this translates into 
only defining a set of delivery semantics, which the flags must 
indicate.

My point of view is, somewhat simplified, that the "message header" 
should specify the "transit behavior", whereas the "processing 
behavior" should be indicated by the message type and content 
(including message TLVs).

It'd be an objective to simply write the message handling/forwarding 
code once in a library, then be able to use that for OLSRv2, DYMO, SMF 
etc.

>     of semantics bits.

If we go with the delivery semantics sectioning, we can define this in 
general terms (forgive my affinity for regexp-like expressions):

	- duplicate suppression || no duplicate suppression
	- scope delimitation || no scope delimitation

Which, I think, makes sense since again, this does only address message 
delivery. For OLSR, the first would always be used, whereas the second 
(might) not always be required, although useful for a lot of extensions 
(FSR-like of fuzzy-sighted extensions, for example).

Are there (known) examples where scope delimitation is needed without 
duplicate suppression?

<SNIP>

>     would be sent unset, a later node might set it.

I think that this is an interesting point, which we may want to expand 
on a bit. Generally, there are the following cases, right?

	- immutable || mutable
	- not-mutated || mutated

Other than the semantic usability of this for different protocols, I 
wonder if this feature is general for a "delivery semantics", or if it 
is flags pertaining to the content of the message. I am tempted to say 
the latter since if an intermediate note receives a message, how would 
knowing the "mutability-status" change that nodes behavior?

I agree that receiving this information with a message may change the 
processing behavior at the destination - in which case it could be 
either an artifact of the message type (less desirable since it slices 
away the message type-space) or a message TLV (preferred).

--thomas