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

[Thomas Clausen <[e-mail]>]

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.

On 30 Jan 2006, at 10:26, Dearlove, Christopher (UK) wrote:

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

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.

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

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.

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

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>

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


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


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