+1, as soon as there are options, the savings are pretty much gone.
Daniel
Ralph Droms wrote:
+1
- Ralph
On Jun 28, 2010, at 11:41 AM 6/28/10, Don Sturek wrote:
+1. I don't see any benefit to fixed option encoding.
Don
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of Zach Shelby
Sent: Monday, June 28, 2010 7:47 AM
To: Erik Nordmark
Cc: [email protected]
Subject: Re: [6lowpan] Proposal for ND option order
Okay, since I started this thread, let me end it. Thanks for the comments
everyone, I think Erik nailed it down here. The only way this could really
reduce code size is if we would have a fixed set of singular MUST options
for each message - but we don't. So let's just drop this idea.
Zach
On Jun 25, 2010, at 4:19 PM, Erik Nordmark wrote:
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
--
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://zachshelby.org - My blog "On the Internet of Things"
http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet"
Mobile: +358 40 7796297
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
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
