[Nfd-dev] review request: NDNLPv2 NACK, Fragmentation, LocalControlHeader

[Junxiao Shi]

Hi Christian

20150608 NFD call decides to take two of your suggestions.

NdnlpHeader wrapper
NdnlpHeader wrapper is eliminated.
Instead, header fields are placed directly under LpPacket element.
TLV-TYPE codes [81:99] and [800:959] are reserved for header fields, and
[960:999] are reserved for trailer fields.

Unknown Fields
I have adopted the idea in
http://www.lists.cs.ucla.edu/pipermail/nfd-dev/2014-July/000282.html
When an unknown header field appears, if its TLV-TYPE is within [800:959]
range, the least significant bit determines whether to drop the packet or
ignore the field. For [81:99] range, the only action is to drop the packet.


The protocol document has been updated to reflect the above (and other)
changes.
http://redmine.named-data.net/projects/nfd/wiki/NDNLPv2

Yours, Junxiao

On Thu, May 28, 2015 at 2:28 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

>
> NdnlpHeader wrapper
> In the full plan NDNLPv2_20150513.pptx
> <http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx> page
> 17-20, we have a header and a trailer. The header wrapper makes it easier
> to define the portion covered by HMAC signature (page 53), and permits a
> padding at the end of header (page 24).
> 2-octet overhead is negligible on the link types mentioned in "Goals"
> section. NDNLPv2 is not designed for 20-octet MTU links; those links need a
> different link adaptation layer protocol.
>
> Unknown Fields
> Excerpt from NDNLPv2_20150513.pptx
> <http://redmine.named-data.net/attachments/download/327/NDNLPv2_20150513.pptx> page
> 27:
>
> Rationale: NdnlpPacket is hop-by-hop. It's feasible to ensure everyone to
> understand all fields.
>
>
> Ignoring an unknown field will cause incorrect operations, see #2520
> note-11.
>
> A vendor-specific extension can claim a TLV-TYPE as "known field but
> relevant feature is disabled".
> This is not a "unknown field".
>
> On Thu, May 28, 2015 at 7:33 AM, <christian.tschudin at unibas.ch> wrote:
>
>> A packet layout question: Isn't the NdnlpHeader wrapper redundant? You
>> can see this in the grammar where no other field can ever follow the outer
>> NDNLP-PACKET-TYPE and -length.
>>
>> Or are there plans for other fields coming before or instead of the
>> NdnlpHeader? Else I guess that this was introduced for parsing speed
>> reasons? But the price is considerable: at least 2 mandatory bytes for
>> every Ndnlp packet for carrying no additional information.
>>
>>
>> - Isn't the statement that "If an incoming NdnlpPacket contains unknown
>>   fields, the receiver MUST drop the packet" evolution-hostile, also
>>   against the old principle of "be liberal in what you accept"?
>>
>>   Or expresses this a stance against the feature interaction problem
>>   and wants to prevent vendor-specific extensions? Asked differently:
>>   Shouldn't there be a type range reserved for experimental and
>>   vendor-specific extensions with an explicit semantics on how to
>>   process such packets with unknown extensions (without dropping the
>>   packet alltogether)?
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20150609/16da846e/attachment.html>