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
- [Manet-dt] fmt default handling bits Ian Chakeres
- RE: [Manet-dt] fmt default handling bits Dearlove, Christopher (UK)
- Re: [Manet-dt] fmt default handling bits Charles E. Perkins
- RE: [Manet-dt] fmt default handling bits Dearlove, Christopher (UK)
- RE: [Manet-dt] fmt default handling bits Luke Klein-Berndt
- Re: [Manet-dt] fmt default handling bits Ian Chakeres