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

[Ian Chakeres <[e-mail]>]

Ok, here is the discussion about types.

As Chris mentioned there are currently two bits used in the type field:
bit 7 is the "user" bit
bit 6 is the "multivalue" bit

Could we reduce the "user" space to a smaller portion of the type space?

I've already voiced my question about whether the multivalue bit is
necessary or an optimization (that is supportable) in the email
"-multivaluedness".

Now on to the topic about types. I think it is important that the
default behavior for a particular type be identified by its "type".
For example, if a particular type (type1) requires the processing node
to perform an operation and the node does not understand type1, then
the processing node should know what to do with the message/tlv.

I think that msg-type, msg-tlv-type, and add-tlv-type have similar
needs and I think the behaviors of interest are (tlv/msg):

ignore tlv/forward msg
remove tlv/?
discard msg/discard msg

How do you feel about encoding these default behaviors within the type field?

One common scenario relates to the mutability discussion. Imagine in
the future that for DYMO we define a dymo-security-msg-tlv that
contains security information that can be used to verify that part of
the message has not been modified. Since we want this message to
travel only through nodes that verify its authenticity (and perhaps
add some additional information to the msg-tlv or add-tlv), if a node
receives this message and cannot understand the dymo-security-msg-tlv
we want that node to discard the message.

Alternatively, imagine we have placed information about the quality of
a path into a routing message. If a neighbor cannot process that
information we might want that node to remove the offending tlv-type
but still propagate the message.

I can generate a similar common use case for the ignore tlv & forward
msg handling options.

Please chime in.
Ian

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

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