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
