Subject: RE: [Manet-dt] fmt default handling bits

From: "Luke Klein-Berndt" <[email-masked]>
Date: Wed, 18 Jan 2006 15:44:08 -0500

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.

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.

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.

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. 

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Ian Chakeres
Sent: Sunday, December 18, 2005 2:43 PM
To: [email-masked]; 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet-dt

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

---

From: Ian Chakeres <[email-masked]>
Date: Sat, 21 Jan 2006 13:24:11 -0800

Comments inline.

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

Ian

> In the Message header, <msg-semantics> bit 1 seems to be the same as H bit

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

> message before it in a packet that is causing a packet not to finish its

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

> set it if we ignore a header.

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

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