Re: [Manet-dt] fmt default handling bits

[Ian Chakeres <[e-mail]>]

Comments inline.

FYI: I am working on dymo-04-pre.  Hopefully I will have something to
review in the next few weeks.

Ian

On 1/18/06, Luke Klein-Berndt <[e-mail]> wrote:
> I thought I would try to re-charge up these discussions by adding my $.02 to
> some of these questions.
>
>
> In the Message header, <msg-semantics> bit 1 seems to be the same as H bit
> 0.

Yes, there is some duplication. Hopefully we can unify this before DYMO-04.

> So right now we can duplicate this functionality with the current message
> format.
>
> For H == 11, is this even possible without the current format? Should it be
> possible to have one message stop the processing of the entire packet? This
> shouldn't be a per protocol decision. Some general MANET extension might
> make assumptions based upon not receiving a packet when it is really the
> message before it in a packet that is causing a packet not to finish its
> traversal.

Agreed, the =11 (like operation) would become drop the message.

> We also have to decide the value of having an I bit set to let a receiving
> node know whether the message had been previously ignored.  I could go
> either way on this. If we want to include this and we do not need the H ==
> 11 state, we could use the <msg-semantics> bit 2 as an I-bit and just always
> set it if we ignore a header.

I think the I-bit warrants additional discussion. I'll start it up.

> If we need more space for bits, maybe we can steal it from the message size.
> It is already count in octects( Bytes? ) right? With a 16 bit field, that
> allows for ~64kb. Seems a little big, but I know you Pro-Active guys really
> like your large messages... :)
>
> As far as TLVs go, it doesn't look like there is anywhere to easily hide
> those bits. There is the question though, if they are really needed in TLVs.
> I am not quite sure. It seems like the default behavior of simply skipping
> to the end of the message when you encounter an unknown TLV would work. TLVs
> are tied directly to the Message type, right? So if you understand a message
> you should be able to understand the key TLVs. If you need for the node to
> understand newer "key TLVs" simply use a new message type.

TLVs are not tied to message type, though a message type may require
particular tlvs.

I think we want to make things extensible without requiring a new
message type. For example if you want to add link metrics, why create
a new message type?  Why not just (using the tlv) identify whether
nodes should forward or drop the messages that include link metric
information?

> However I defiantly think we could steal a few bits from the tlv-length.
> Since the message header length is 16 bits and that length has to include
> the message header, there are not many case where there could be a full
> length TLV that would need all 16-bits.
>
> But of course processing a 15 or 14 bit field is not fun...
>
> Luke Klein-Berndt
> NIST OLES
> 301-975-8021
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Ian Chakeres
> Sent: Sunday, December 18, 2005 2:43 PM
> To: [e-mail]; Thomas Heide Clausen
> Subject: [Manet-dt] fmt default handling bits
>
> For type fields I think we should define default handling behavior,
> for nodes that don't  understand the type.
>
> In DYMO here are the unknown handling behaviors (using two MSB of
> type field) and their meaning:
>
>     o   If H == 00 skip the element and continue as if the packet did
> not
>        contain this element.
>
>     o  If H == 01 remove the unsupported element (using the Len field)
>        from the packet and continue as if the packet did not include
> this
>        element.
>
>     o  If H == 10 set the ignored bit (I-bit) skip this element and
>        continue, as if the packet did not contain this element.
>
>     o  If H == 11 drop the packet without processing any other DYMO
>        elements.
>
> Can we built the same functionality into the common format message-
> type and tlv type?
>
> Ian
>
>
> _______________________________________________
> 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