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

[Ian Chakeres <[e-mail]>]

Comments inline.

On 1/30/06, Thomas Clausen <[e-mail]> wrote:
> 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?


DYMO performs an alternative type of duplicate suppression based on
"stale" information. In this case scope delimitation is needed but not
traditional 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).

I have a few comments.

What parts exactly are immutable/mutable? The contents of a message?
How about the packet? How about the TTL and HopCnt fields?

Thomas, I agree - I don't know that this belongs in the msg-semantics.
Chris can you explain a bit more about why it belongs in the
msg-semantics?

I'm going to start up another thread about "-types" which may be related.

One last comment. I would like to see several of the msg-semantic bits
reserved for msg-type specific bits. 4 ideally, but I would probably
settle for 2. For example in DYMO, RREQ messages could use a few of
these bits for its own purpose.

Ian

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