Re: [6lowpan] hc-01

[Jonathan Hui <[e-mail]>]

Hi Julien,

Your comments are valid. By adding a single bit, I think we can  
support all the cases you mention without compromising any of the  
cases we currently support. So here is a proposed modification:

     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
  - 0: Unicast Destination
  - 1: Multicast Destination

- DAM:
  - When M = 0:
    - 00: 128-bit
    - 01: 64-bit
    - 10: 16-bit
    - 11: 0-bit
  - When M = 1:
    - 00: 128-bit
    - 01: 48-bit (FFXX:XXplen::prefix:XXXX:XXXX)
    - 10: 48-bit (FF0X::XX:XXXX:XXXX)
    - 11: 8-bit (FF02::XX)

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