Re: [6lowpan] hc-01

[Jonathan Hui <[e-mail]>]

Hi Julien,

I realized that the 128-bit case for both unicast and multicast is  
redundant. So I made a minor change to add extra support for multicast  
compression. See below:

>    0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
>  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>  | X | X | X | X |  TF   | HLIM  |NH |  CTX  |  SAM  | M |  DAM  |
>  +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
>
> - CTX (context identifier for both source and destination addrs, if  
> applicable):
> - 00: Link-local
> - 01: Unspecified Address (valid only for source addr with mcast)
> - 10: Global w/ Default
> - 11: Global w/ Context Identifier Extension
>
> - SAM:
> - 00: 128-bit
> - 01: 64-bit
> - 10: 16-bit
> - 11: 0-bit
>
> - M: Multicat Compression
> - 0: Prefix Compression
> - 1: Multicast Compression
>
> - DAM:
> - When M = 0:
>   - 00: 128-bit
>   - 01: 64-bit
>   - 10: 16-bit
>   - 11: 0-bit
> - When M = 1:
>   - 00: 48-bit (FFXX:XXplen::prefix:XXXX:XXXX)
>   - 01: 48-bit (FF0X::XX:XXXX:XXXX)
>   - 10: 32-bit (FF0X::XX:XXXX)
>   - 11: 8-bit (FF02::XX)

--
Jonathan Hui

>
>
> This covers all the multicast cases you care about. It also covers  
> multicast with a global source address. And it covers all the  
> unicast formats that we've supported since the beginning (link- 
> local, global with default context, global with other contexts).  
> Whether or not we want to support all of the cases you outlined is a  
> question, but given that it only adds a single bit to the format, I  
> think it's little added overhead.
>
> How does that look to you?
>
> --
> Jonathan Hui
>
>
>
> On Oct 9, 2008, at 5:45 AM, Julien Abeille (jabeille) wrote:
>
>> 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

_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan