Re: [6lowpan] hc-01

[Jonathan Hui <[e-mail]>]

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
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan