On 06/25/10 05:50 AM, Daniel Gavelle wrote:
If there were a fixed number of options with a fixed length and order,
the packet would be very simple to parse as the data fields would be at
the same offset in the buffer each time.
That would not necessarily be the case, because in many cases the
options are optional, and/or there can be zero or more of them included
in a packet.
For example the PIO and 6CIO are of the latter form.
And ABRO is optional AFAIK.
There could be a MTU option in RAs.
Etc.
Erik
The receiver could check the option type, length and other unchanging
bytes at their fixed offsets and if anything doesn't match the fixed
values, reject the packet.
I think this would save several hundred bytes and make testing simpler.
There would need to be two types of e.g. NS, host to LR and LR to LBR
but it would be easy to distinguish these.
Any future options could be added after the ones that are mandated in
the current specification.
Daniel.
Richard Kelsey wrote:
From: Ralph Droms <[email protected]>
Date: Thu, 24 Jun 2010 15:52:07 -0400
How, exactly, would specifying the order make any difference to an
implementation in terms of:
* code size and complexity
If two options interact in any way, the code to process them
is simpler if they appear in a fixed order. The degree to
which a fixed order simplifies the code depends on the
degree of interaction between the various options.
* processing time
No appreciable difference.
* interoperability
Sending the options in the right order, and testing that
they are sent in the right order, is trivial. Testing
that the order in which they appear in incoming messages
is irrelevant is much harder.
Seems to me such a requirement would reduce interoperability with
existing implementations.
Absolutely. This only makes sense if there are there no existing
deployments. Given the freshness of 6LoWPAN ND
I am not sure that this is an issue.
-Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
