Hi Jonathan, all, Sorry for the long email, tell me if not clear:
******************************************************* I agree with the status and the three possibilities: - 6 bits, most important cases compressed - 7 bits, all cases I mentionned compressed - 8 bits, all cases I mentionned compressed, simpler? Time I propose something for 8-bits as you say :-) : ***************************************************** 8 bit proposal: ***************************************************** - about contexts: 3 contexts stored, LL context (00), global prefix context 1 (01), global prefix context 2 (10, used for renumbering) - encoding: | SAC | SAM | DAC | DAM |, 2 bits each, as in initial draft. - meaning SAC: 00 context 00 01 context 01 10 context 10 11 no context SAM: If SAC = 00, 01, 10 prefix fetched from context number "SAC" 00 64 bits compressed 01 16 bits compressed 10 0 bits compressed If SAC = 11 00: unspecified 01: 128 bits inline DAC: 00 context 00 01 context 01 10 context 10 11 no context DAM: If DAC = 00, 01, 10 prefix fetched from context number "DAC" 00 unicast 64 bits compressed 01 unicast 16 bits compressed 10 unicast 0 bits compressed 11 multicast unicast prefix based FFxx::xxxx:plen:prefix:xxxx:xxxx If DAC = 11 00: 128 bits 01: FF02::xx 10: FF0x::00xx:xxxx 11: FF0x::00xx:xxxx:xxxx ****************************************** Comparison of 7 -bit and 8- bit is attached as csv, should open ok in Excel ****************************************** instead of pseudo code, I do the following: - list all cases supported for src and dest formats (A to E for src, 1 to 9 for dest) - tell which combination of both are possible (e.g. A1, A2 ... Because not all combinations are accepted by IP) - for each combination, tell values of CTX and M bit for 7-bit, SAC, SAM, DAC DAM for 8-bit. I group the 64/16/0 IID cases to be more concise. i.e. for src link local unicast and dest link local unicast CTX 00, M 0 - based on this, for each src and dest case splitted again, I give values of CTX, M i.e. if dest is FF0X::00XX:XXXX, CTX is ... What you can see: - with 8 bit, each individual case (A, B,... For src and 1,2... For dest ) corresponds to a unique value of SAC, SAM... - with 7 bits, some src cases corresponds to multiple values because they depend on the dest case, and vice versa For me, merging src and dest context add a lot of complexity. ****************************************** Comparison of 6-bit and 8- bit ****************************************** I does not make a lot of sense on the complexity side, as they do not provide the same features. However, the binding between src and dest context in the 6 bit case creates the same problem as with 7 bit Cheers, Julien -----Original Message----- From: Jonathan Hui [mailto:[EMAIL PROTECTED] Sent: lundi 13 octobre 2008 17:36 To: Julien Abeille (jabeille) Cc: Zach Shelby; 6lowpan Subject: Re: [6lowpan] Fwd: New Version Notification fordraft-ietf-6lowpan-hc-01 Hi Julien, So here's the tension that we have now: From what I saw on the list, most people were happy with just two contexts. Adding support to the *base* encoding (i.e. without need of using a context identifier extension) would require adding yet another bit to the base encoding. This is in addition to whatever bits we may add depending on whether you convince us of those additional cases :-) Regarding 8 bits to encode address compression, I agree with Pascal in that you should compare against what is in ietf-6lowpan-hc-01 (6 bits). If we find need in supporting your cases, then we should compare to what I sent out to the mailing list (7 bits). I think the 7- bit version covers all the cases you were asking for, but maybe I missed some? Anyways, looking forward to see your 8-bit proposal. Thanks. -- Jonathan Hui On Oct 13, 2008, at 1:24 AM, Julien Abeille (jabeille) wrote: > Hi Zach, > > I second your concern > > There was recently a discussion specifically about the number of > contexts needed. > There seemed to be a consensus that multiple contexts was useful for > renumbering only, which is rare, and that 2 contexts was enough. > Was there new input since then which justifies the use of 4-bit > contexts? > > Cheers, > Julien > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Zach Shelby > Sent: vendredi 10 octobre 2008 14:58 > To: Jonathan Hui > Cc: 6lowpan > Subject: Re: [6lowpan] Fwd: New Version Notification > fordraft-ietf-6lowpan-hc-01 > > Hi, > > Here are my comments on hc-01. Overall I think we are quite close with > the comments from Pascal and Julien. > > I found the DDF name confusing. Now it has been renamed CTX in the > latest formats on the list, great. > > As Pascal pointed out, nodes need to be able to decode all these > options. One thing that worries me in having 16 contexts, is that > nodes are forced to store them all. That is worst case 272 bytes of > memory consumption. Worth it? Is it possible that an ultra-simple node > would only have to understand the default context? > > The default context identifier '0000' could be clarified more in the > draft. When CTX is '10' then the default context identifier '0000' is > used. It should be made clear that this is the prefix advertised in > RAs as useable for SAA. > > Regarding the ND for 6lowpan draft, HC-01 means we need to add a 4-bit > context identifier flag to the 6LoWPAN Prefix Information Option. To > make things clear that should always be '0000' if the A flag is '1'? > > - Zach > > > Jonathan Hui wrote: >> >> http://tools.ietf.org/html/draft-ietf-6lowpan-hc >> >> This new version reflects the recent discussions on the list. The >> changes are: >> - HC back to 1 byte by default by stealing a few bits from the >> dispatch field. >> - Added better support for multicast address compression. >> - Fixed alignment for UDP port compression. >> - Better support for Traffic Class and Flow Label compression. >> - Pascal joined as an author. >> >> Happy reading! >> >> -- >> Jonathan Hui >> >> >> >> Begin forwarded message: >> >>> From: IETF I-D Submission Tool <[EMAIL PROTECTED]> >>> Date: October 8, 2008 7:15:35 PM PDT >>> To: [EMAIL PROTECTED] >>> Cc: [EMAIL PROTECTED] >>> Subject: New Version Notification for draft-ietf-6lowpan-hc-01 >>> >>> >>> A new version of I-D, draft-ietf-6lowpan-hc-01.txt has been >>> successfuly submitted by Jonathan Hui and posted to the IETF > repository. >>> >>> Filename: draft-ietf-6lowpan-hc >>> Revision: 01 >>> Title: Compression Format for IPv6 Datagrams in 6LoWPAN > Networks >>> Creation_date: 2008-10-09 >>> WG ID: 6lowpan >>> Number_of_pages: 15 >>> >>> Abstract: >>> This document specifies an IPv6 header compression format for IPv6 >>> packet delivery in 6LoWPAN networks. The compression format relies >>> on shared context to allow compression of arbitrary prefixes. This >>> document specifies compression of multicast addresses and a >>> framework > >>> for compressing next headers. This framework specifies UDP >>> compression and is prepared for additional transports. >>> >>> >>> >>> The IETF Secretariat. >>> >>> >> >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan > > -- > > Zach Shelby > Head of Research > Sensinode Ltd. > Kidekuja 2 > 88610 Vuokatti > FINLAND > > mobile: +358 40 7796297 > > This e-mail and all attached material are confidential and may contain > legally privileged information. If you are not the intended recipient, > please contact the sender and delete the e-mail from your system > without producing, distributing or retaining copies thereof. > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan
hc.csv
Description: hc.csv
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
