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.
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
--
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
