RE: [Manet-dt] fmt default handling bits

"Luke Klein-Berndt" <kleinb@nist.gov> Wed, 18 January 2006 20:44 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKAN-0001lV-HA; Wed, 18 Jan 2006 15:44:27 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EzKAM-0001jm-48 for manet-dt@megatron.ietf.org; Wed, 18 Jan 2006 15:44:26 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21939 for <manet-dt@ietf.org>; Wed, 18 Jan 2006 15:42:59 -0500 (EST)
Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EzKIj-0000oN-TI for manet-dt@ietf.org; Wed, 18 Jan 2006 15:53:07 -0500
Received: from p622358 ([129.6.68.38]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id k0IKi7wW015406; Wed, 18 Jan 2006 15:44:10 -0500
From: "Luke Klein-Berndt" <kleinb@nist.gov>
To: "'Ian Chakeres'" <ian.chakeres@gmail.com>, <manet-dt@ietf.org>, "'Thomas Heide Clausen'" <T.Clausen@computer.org>
Subject: RE: [Manet-dt] fmt default handling bits
Date: Wed, 18 Jan 2006 15:44:08 -0500
Organization: NIST
Message-ID: <016001c61c6f$edc5ab20$26440681@campus.nist.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2670
Thread-Index: AcYEC4dvKo5N7kz+Q4CtuJ5tl0NP0gYX+sJA
In-Reply-To: <41C2F2C4-4BA1-4AB9-BFC0-5CFA2919B388@gmail.com>
X-NIST-MailScanner: Found to be clean
X-NIST-MailScanner-From: kleinb@nist.gov
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Content-Transfer-Encoding: 7bit
Cc:
X-BeenThere: manet-dt@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: MANET Design Team <manet-dt.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/manet-dt>
List-Post: <mailto:manet-dt@ietf.org>
List-Help: <mailto:manet-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/manet-dt>, <mailto:manet-dt-request@ietf.org?subject=subscribe>
Sender: manet-dt-bounces@ietf.org
Errors-To: manet-dt-bounces@ietf.org

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




_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt