<div dir="ltr">Hi Christian<div><br></div><div><font size="4">protocol in charge</font></div><div>The protocol in charge is determined by the link, not determined by every packet.</div><div>Before an NDNLPv2 packet is processed, the receiver already knows what features are enabled.</div><div>In the normal case, a link cannot be configured to run two fragmentation features at the same time.</div><div><br></div><div>For example, if IndexedFragmentation is enabled on a link:</div><div>The receiver will expect Sequence, FragIndex, and FragCount.</div><div>When Sequence is missing, the packet is dropped.</div><div><div>When FragIndex is missing, it implied value 0 is used.</div></div><div><div>When FragCount is missing, it implied value 1 is used.</div></div><div><br></div><div>When a BeginEndFragBits field is received,</div><div>if the receiver understands B-E fragmentation feature but this feature is disabled on this link, B-E fragmentation feature should define what to do in this situation (typically, either drop or ignore);</div><div>if the receiver does not understand B-E fragmentation feature, the unknown field procedure is used.</div><div><br></div><div>In case some link must run two fragmentation features at the same time, one may define a new fragmentation feature that is a combination of these two. It would be "Indexed + B-E fragmentation". It can either declare a demux field, or dispatch according to what fields are present.</div><div>However, such combination fragmentation feature is not recommended. It's expected for a link to choose at most one fragmentation feature.</div><div><br></div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 10, 2015 at 1:18 AM,  <span dir="ltr"><<a href="mailto:christian.tschudin@unibas.ch" target="_blank">christian.tschudin@unibas.ch</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Junxiao,<br>
<br>
thanks, nice to see this uptake.<br>
<br>
I was (waiting for time to write this up and) thinking about another general comment on the NDNLPv2 spec:<br>
<br>
Currently it seems that the "protocol in charge" is defined implicitely through the presence or absence of some fields. For example, IndexedFragmentation could be defined as<br>
<br>
"needs Sequence plus at least one of the fields FragIndex and FragCount"<br>
<br>
If I introduce a BeginEndFragmentation protocol, the rule would be<br>
<br>
"needs the BeginEndFragBits field"<br>
<br>
and the implicit assumption that the fields present in a packet must violate the previous rules, otherwise the router is confused which protocol is in charge. (see also the note below on the "roles" that a router should adopt).<br>
<br>
<br>
My suggestion: the spec should either spell out these rules (and how new rules have to be formed), or introduce an explicit protocol demux field as is the case with SignatureType.<br>
<br>
The latter approach has the benefit that new protocols can reuse existing fields (and their type values) and that new protocols do not necessarily need a new type-value (to mark their presence).<br>
<br>
What do you think?<br>
<br>
best, christian<br>
<br>
<br>
PS: Here is a link on that question of how to organize the header space, see Bob Braden et al's "From Protocol Stacks to Protocol Heaps - Role Based Architecture" <a href="http://conferences.sigcomm.org/hotnets/2002/program.html" target="_blank">http://conferences.sigcomm.org/hotnets/2002/program.html</a><br>
<br>
which is exactly what TLV permits do to, namely to escape the strict encapsulation. Dropping the header container was one such step in that direction.<div><div><br></div></div></blockquote></div></div></div></div>