+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
