[Manet-dt] Re: [manet] Re: DYMO Unknown Type Handling Bits

["Ian Chakeres" <[e-mail]>]

Here is some text I put in the newest dymo draft. Please respond with comments.

Ian

=====
5.6.1.  Receiving Packets

   When a packet is received, its PktTLV are first examined.  Next each
   message is examined and processed in order.

   Each message's headers are first examined.  Next, the MsgTLV are
   examined.  Finally, each message is processed according to its
   MsgHdr.type.

5.6.2.  Processing Unknown Message and TLV Types
(Should be 5.6.2.  Processing Unknown Types)

   To allow future extensions, DYMO uses bits from the semantics fields
   of PktTLV, Message, MsgTLV, and AddTLV [I-D.ietf-manet-packetbb].
   Note [I-D.ietf-manet-packetbb] does not currently support this
   functionality.

   The semantic bits have the following names and characteristics for
   nodes that do not understand the type.

   Remove
      If the Semantics.Remove-bit is set, this information SHOULD be
      removed from the message.

   Discard
      If the Semantics.Discard-bit is set, this message SHOULD not be
      processed further and it should not be propagated.  In the case of
      PktTLVs if the Semantics.Discard-bit is set, no messages from the
      packet should be processed or propagated.








On 6/8/06, Dearlove, Christopher (UK) <[e-mail]> wrote:
>
> > There is an useful functionality missing on this list, that was
> present
> > in previous DYMO drafts.  Namely, we had a bit in the main header
> > that indicated whether a node had ignored an extension.
>
> I don't think that bit ever made it into any OLSRv2/packetbb draft,
> only discussion. But that's not important.
>
> There's a complication here that I think needs better understanding of
> the philosophical position of DYMO by the OLSRv2 camp and vice versa.
>
> The OLSRv2-inspired model is that a node receives a message (it receives
> it in a packet, but a packet is a temporary one hop encapsulation
> mechanism that we can ignore for the moment) and (a) may process it, and
> (b) may forward it. But (a) and (b) are independent, they can be done in
> either order, or even (if you have that sort of hardware/software) in
> parallel, and the decisions whether to do each are separate and all four
> do/don't options are possible. (Note that the reason some information is
> in the message header rather than being tucked away in TLVs is that this
> is precisely the information needed to make both do/don't decisions.)
> This means that a forwarded message is (apart from hop limit/count
> changes) exactly that received. This has a number of advantages, the
> separation of processing and forwarding has distinct software
> advantages,
> the immutability of messages has distinct security advantages (to name
> just one, end to end verified signature of messages is possible).
>
> Now DYMO, as I understand it, has much more fluid messages, and
> forwarding
> is distinctly an aspect of processing. In fact that a message is
> forwarded
> is a philosophical point, as the things that most obviously make two
> different collections of bits "the same message" using the packetbb
> structure are the message originator address and sequence number, and
> these parts of the message header are (as allowed as a design option)
> not used by DYMO. So is DYMO forwarding a message (after changing it
> - both additions and subtractions I believe) or sending a new message
> incorporating material from the old message. "On the wire" both look
> the same.
>
> So I think that whatever we do here (and this I think is a related, but
> not quite the same, concept as what I think Ian was meaning - which is
> why I think we should be discussing functionality, with specific
> required
> use cases, rather than implementation details) we need things which fit
> both models, without breaking either. Actually if DYMO messages are
> fluid,
> there's nothing to stop DYMO defining a message TLV which may be added
> to
> signal this sort of information when it's at the message level. But I
> appreciate that this may be undesirable - and it doesn't work at the TLV
> level, where we have no "TLV TLVs" (although it would be possible to
> define a TLV with such semantics, it would be - to put it mildly -
> ugly).
> We do have the possibility of reserving one or maybe two bits in the
> various semantics bit vectors (packet, message, TLV) as "protocol
> specific"
> pushing the problem off to the protocols. This I think should form part
> of
> a wider discussion we know we need about packetbb and related namespace
> organisation.
>
> Finally, note that packetbb is currently syntax only, the only semantics
> is that "this conveys that piece of information"). (There's an exception
> in that the intended ue of hop limit/count is indicated, but even that
> could be ignored.) It's a much better fit if we have things of the form
> "this bit means such and such" than "if this bit is set, do such and
> such"
> when - as is the point here - different protocols have quite different
> models of how things are done.
>
> Christopher Dearlove
>
>
> ********************************************************************
> 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 mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/manet
>

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