I would definitly be in favor of fewer contexts and agree with your reasons. I liked the scheme in HC-00 where you could always use CP or link local. That seems to cover the common case very well.
Steve On Tue, Sep 23, 2008 at 9:43 AM, Jonathan Hui <[EMAIL PROTECTED]> wrote: > > In moving the HC draft from -00 to -01, we added support for multiple > compression contexts so that more than one prefix (other than link-local) > can be compressed. > > The obvious question now is how many contexts are enough? It is clear that > two contexts are useful (one for the 6LoWPAN and another for the common > destination that all nodes may be sending to). But should we add more? > > Some thoughts: > - Fewer contexts allow the HC encoding to use fewer bits in identifying the > context in use. > - Specifying support for X contexts requires nodes to allocate enough > memory to maintain X contexts (ip addresses, timers, etc.). > - Additionally, we cannot simply say that we will change X to some larger Y > at some future date since the nodes that only support X will not be able to > support Y > X contexts. > - One argument for supporting more contexts is that it allows network > renumbering while allowing all nodes to communicate with compressed > addresses. My thought, however, is that renumbering of 6LoWPAN networks > should be rare and when they do occur it is okay to incur some extra cost > and communicate with full addresses during that time. > > So my thought is to keep the number of supported contexts small (2). What > do other people think? > > -- > Jonathan Hui > > > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan >
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
