Re: [6lowpan] hc-01

["Julien Abeille (jabeille)" <[e-mail]>]

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:[e-mail]] 
Sent: jeudi 9 octobre 2008 01:50
To: Pascal Thubert (pthubert)
Cc: Julien Abeille (jabeille); [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan