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
