Subject: [Manet-dt] fmt default handling bits

From: Ian Chakeres <[email-masked]>
Date: Sun, 18 Dec 2005 11:42:58 -0800

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 20 Dec 2005 10:20:22 +0000

First I should note that when I indicated there are problems
I'm not saying they are absolute. But they are why when we had
an almost identical proposal within the OLSRv2 DT we put it on
one side to be reconsidered later.

>Do you mean that OLSRv2 will have more than 16 message types?

I've been discussing TLV types (including message TLV types)
rather than message types, which I missed you had also mentioned.
To answer about TLV types, not the base protocol. But if you add
up all the extensions people are interested in, it could get to
that number. (In the case of OLSR I would expect most existing
ideas to be ignore but forward if unrecognised, because that was
the only option in OLSRv1, although at the message level.) For
message types (which I hadn't considered) there's one more bit,
but also perhaps this should be message semantics rather than
type. Which do you regard as more important, whole message or
TLV-level control? (Note that neither of the other two issues
apply to whole messages, which are a lot easier to consider.)

>>(b) At the moment a feature of the message format is that
>>    if processing standard features only you can stop
>>    as soon as you get to a nonstandard feature and not
>>    even bother parsing it. This defeats that objective.

>Could you say more about that?  Do you mean a nonstandard TLV attached
>to a standard message type?

Could be a proprietary extension, or a future standard extension
on a standard message or on a nonstandard but recognised message.
The key point is if you look at the Constraints section of the
packet format document, all of those constaints are there to make
aspects of parsing simpler. In this case let's suppose that an
OLSRv2 TC message can, if not extended, have message TLVs of types,
let's say, 0, 1, 4 or 5 (I'm making those numbers up for this
example) but need not aways be there. Then, on a node which doesn't
recognise extensions, when parsing if you see a type 7 you can
immediately stop parsing the remainder of the message TLVs and
move on to the first address block (you have the complete TLV
block length to facilitate this). This isn't just hypothetical,
there's real interest in this by at least one company (not, at
present, mine).

>>(c) An extension that is likely to be of early interest
>>    to many is the addition of a message signature using
>>    a message TLV. (See for example Secure OLSR paper.)
>>    This interacts badly with TLVs that are added and
>>    removed.

>Abiding by this would eliminate the possibility of any mutable
>TLVs, which is a pretty heavy restriction to put in the current
>design for the whole future life of whatever we are designing.

And not abiding by it puts a heavy restriction the other way.
So it needs careful consideration. We have adopted a policy of
wanting to get something right before putting it in. For
example if you look at the semantics bits we have labelled
bit 2 differently to bits 3 to 7. Why? Because we have an idea
that we think we will use that bit for. But we haven't thought
through all the consequences, so better safe than sorry and
leave it for a future version. In the case of this specific
proposal I for one can't currently see how to satisfy all of
the competing preferences, at least at the moment. Ideas
welcome.

********************************************************************
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.
********************************************************************