[Nfd-dev] How to handle unrecognized TLVs

[Yingdi Yu]

On Jul 30, 2014, at 3:19 PM, Alex Afanasyev <alexander.afanasyev at ucla.edu> wrote:

> On Jul 30, 2014, at 3:11 PM, Lixia Zhang <lixia at CS.UCLA.EDU> wrote:
> 
>> We discussed this issue during today's NFD call but did not reach a concrete conclusion:
>> 
>> 1/ TLV format allows new types to be easily introduced
>> 
>> 2/ However when a new type is introduced, it is almost guaranteed that some node does not recognize it.  What should the node do in this case?
>> 
>> a) in the current implementation (as I heard form Alex), in certain cases we do drop, in other cases we forward -- decisions embedded in implementation.
>> 
>> b) IETF current practice is to reserve 2 bits in the type field to define the desired action when running into unrecognized types (commonly it is some combination of (a)forward vs drop, and (b)send an error msg or not)
>> 
>> Do we want to do the same (reserving 2 bits in the type field)?
>> If so,
>> - this reduces the number of types for 1-byte type to 32
> 
> Small correction: to 64 types of each "processing type".

I remember we have already used the leftmost bit to indicate whether the TLV is application-specific, so it actually reduces the number of types to 32 if two more bits are used.

>> - where to put these 2 bits?  since type field is variable length, 
>> the best place would be the last 2 bits, but that means renumbering
>> all the defined types :-(

I do not see the problem of using the 2nd and 3rd leftmost bits for this purpose. We have already used the leftmost bit to indicate app-specific tlv:
for 1byte type, 0-127 is NDN-specific, 128-252 is app-specific
for 3byte type, 253-32767 is NDN-specific, >32768 is app-speicific

>> - there is also a question of whether we need to reserve 2-bit, or one bit could do (just define forward/drop)
I wonder when and what kind of error msg will be sent and what the msg would look like. Should it be a data packet that shares the same name (prefix) as the interest? If so, does that mean applications needs to be able to handle error msg? Moreover, who should sign the error msg and how to verify the err msg?

I think the semantic could be much more simplified if we just define forward/drop.

Yingdi

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140731/440a1ccc/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20140731/440a1ccc/attachment.bin>