Hi Pascal, Jonathan, For addresses I see an issue with a few scenarios: - dest multicast, source global non compressable (SAM does not define 128 bits format) - some dest multicast are not in either of the 4 DAM cases, e.g FF3E:0040:aaaa:a:a:a:1:1 (address based on prefix aaaa:a:a:a::/64, with 32 bit group id = 1:1)
Pascal, can you clarify the DDF = 01 case I tried to make my ideas clear by listing all current multicast scenarios , based on http://www.iana.org/assignments/ipv6-multicast-addresses and RFC 3306 + 3956 (unicast prefix based multicast addresses) A 128, not compressed B FF02::XX 1 byte needed C FF0X::00XX:XXXX 4 bytes needed D FF0X::00XX:XXXX:XXXX 6 bytes needed E unicast prefix based address, not embedding rendez vous point: 5 bytes needed F unicast prefix based address, embedding rendez vous point: 6 bytes needed A covers unicast prefix based multicast addresses with prefix not in context B covers most useful link local cases (see IANA) e.g. LL all nodes, FF02::1 C covers longer well known cases (see IANA) e.g. all-dhcp-servers FF05::1:3 D covers solicited node and node information queries FF02::1:FFXX:XXXX and FF02::2:FFXX:XXXX E covers format defined in RFC3306, when the prefix used is in the default context. | 8 | 4 | 4 | 8 | 8 | 64 | 32 | +--------+----+----+--------+----+----------------+----------+ |11111111|flgs|scop|reserved|plen| network prefix | group ID | +--------+----+----+--------+----+----------------+----------+ Here flags are 0011 (e.g. not embedding rendez vous point, unicast prefix based, non permanently assigned) We only need to send flags, scope, group ID (5 bytes) F covers format defined in RFC3956, when the prefix used is in the default context. | 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 | +--------+----+----+----+----+----+----------------+----------+ |11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID | +--------+----+----+----+----+----+----------------+----------+ Here flags are 0111 (e.g. embedding rendez vous point, unicast prefix based, non permanently assigned) We only need flags, scope, reserved + RIID, group ID (6bytes) Questions: - do we want to support all this? - do we want to group some cases: we could group C and D, E and F, then we have 4 cases only - what do we do for dest multicast, source non compressable. - Do we keep unspecified support? - do we afford one more bit (this would be 7 bits for addresses) and use dispatch e.g. 1101xxxx? - do we keep src and dest encoding linked. For now we have 2 bits common to src and dest (DDF), plus SAM and DAM. This makes 16 cases for both src and dest, 32 in total. Cheers, Julien -----Original Message----- From: Jonathan Hui [mailto:[EMAIL PROTECTED] Sent: jeudi 9 octobre 2008 01:50 To: Pascal Thubert (pthubert) Cc: Julien Abeille (jabeille); [email protected] Subject: Re: hc-01 Hi Pascal, I think this looks great. It covers the cases we care about (unicast and multicast) without using any extra bits that my initial proposal. The small thing I would change is moving the "DDF" field to bits 10-11 (shifting TF and NH 2 bits to the left). Then TF would not span a byte boundary. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ -- Jonathan Hui On Oct 8, 2008, at 4:31 PM, Pascal Thubert (pthubert) wrote: > Hi Julien: > > I think you're right, we need to dig a little bit more. > > So starting from Jonathan's encoding, maybe we can refine was was CTX > > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > | 0 | 1 | 0 | 0 | 1 | DDF | TF |NH | HLIM | SAM | DAM | > +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ > > - Dispatch: 8-15 > - DDF: Destination dependant fiels > - 00: Destination is global (or ULA), no context byte after the HC > field > - 01: Destination is global (or ULA), one byte context byte after the > HC field > - 10: Destination is Link local > - 11: Destination is multicast scoped address > > - TF: Traffic Class, Flow Label > - 00: 4-bit Pad + Traffic Class + Flow Label (4 bytes) > - 01: ECN + 2-bit Pad + Flow Label (3 bytes) > - 10: Traffic Class (1 byte) > - 11: No Traffic Class and Flow Label > > - NH: Next Header compression > > - HLIM: Hop Limit > - 00: uncompressed > - 01: 1 > - 10: 64 > - 11: 255 > > When destination is link local: > ------------------------------- > prefix is FC80::/64 when compressed > > - SAM: Source Address Mode - prefix is link-local, when compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > - DAM: Destination Address Mode - prefix is link-local, when > compressed > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > > When destination is multicast: > ------------------------------- > prefix is FF02::/64 when compressed > > - SAM: Source Address Mode > - 00: 0 bits, unspecified address > - 01: 64 bits, prefix is link local > - 10: 16 bits, prefix is link local > - 11: 0 bits, derived from the IID, prefix is link local > - DAM: Destination Address Mode - prefix is link-local, when > compressed > - 00: 8 bits, prefix is compressed, suffix is 7 octets of zeroes, > then this octet > - 01: 24 bits, prefix is compressed, suffix is 4 octets of zeroes, > then one octet 0xFF then this octet > - 10: 16 bits. 4 bits flags, 4 bits scope, 1 byte suffix. > Prefix as defined in RFC 4291, suffix is 7 octets of zeroes, then this > suffix octet > - 11: 24 bits 4 bits flags, 4 bits scope, 2 bytes suffix Prefix as > defined in RFC 4291, suffix is 6 octets of zeroes, then those suffix > octets > > When destination is ULA or global: > ------------------------------- > The prefix is found from the context table. > If there is no context octet after the HC field then this is the > default prefix. > > - SAM: Source Address Mode > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > - DAM: Destination Address Mode > - 00: 128 bits > - 01: 64 bits > - 10: 16 bits > - 11: 0 bits > > Notes: > > With this change, the 16 bits format of Link local and ULA and global > really means the last 16 bits ( apposed to 15 in > http://tools.ietf.org/html/draft-ietf-6lowpan-hc-00 > 2.2. IPv6 Unicast Address Compression. > > With this change, we have the most useful mcast cases covered: > DAM of 00 compresses FF02::XX, so you get all routers on link, etc... > DAM of 01 compresses FF02::FFXX:YYZZ, sollicited node mcast address > DAM of 10 and 11 compress all permanently-assigned multicast addresses > defined today for all scopes > > What do you think? > > Pascal > ________________________________________ > From: Julien Abeille (jabeille) > Sent: mercredi 8 octobre 2008 17:51 > To: Jonathan Hui > Cc: Pascal Thubert (pthubert) > Subject: hc-01 > > Hi Jonathan, > > I send unicast because my thought will not be clear, and to make a > quick presentation and bind it to "cisco sensor team". > I did my master thesis in 2005 at Cisco in Sophia Antipolis. My > project manager was Patrick Wetterwald (IPSO president) and I worked > with Pascal on tree discovery and bubbles protocols. I joined Cisco as > employee in july last year, and have been working on sensors with > Patrick as project manager, Pascal and a few others as engineers. I > met JP Vasseur a year ago and we have frequent calls and meetings, as > he recently moved 150km from switzerland where my office is. I work > most closely with Mathilde Durvy whom you met for IPSO interop calls. > > after discussion with Pascal about address compression, I try to > clarify my thoughts: > - 64 last bits compression in unicast address compression is only > feasible if last 64 bits are based on IID (either 64 bit MAC address > or PAN ID+0+16bit address). I thought it would be nice to be able to > compress as well addresses with bytes 8 to 13 = 0. (e.g. a::1) > - could be nice as well to compress the IID only when the prefix is > not compressable? > - for multicast address compression, i thought stateless compression > could be nice. This works well with permanently assigned addresses > (Pascal, the link i promissed: > http://www.iana.org/assignments/ipv6-multicast-addresses) > , as many bytes are 0 after the two first ones > - for multicast again, it would be nice to be able to compress > addresses with more than 9-bit non 0 (a few permanently assigned ones > apply there, like all-dhcp-agents) > - regarding the 16-bit compressed format, i would prefer not having > one bit or more in the compressed field with a special meaning (first > bit 0 = unicast, 3 first bits 101 = multicast), but keep all these > bits in the encoding > - I was wondering if assuming flags are 0 cannot be an issue. > > These are just thoughts, as i am not extremely clear on the important > scenarios where we want to compress (e.g. solicited node multicast > compression might not be needed as with ND optimizations, there will > not be many NS), and am not clear either about multicast addresses > except permanently assigned ones. More preciely i do not know if we > want to support unicast prefix based multicast addresses or rendez > vous point addresses, and what they look like. > > hope this helps in the discussion, > regards, > Julien > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
