Re: [6tisch] 6LoRH: compression of the inner destination

[Xavier Vilajosana <[e-mail]>]

Dear Pascal,

thanks for your answer this is very clear, but could we address stateless
address compression if the inner and outer source addresses share the same
IID? I can think in cases where we do not have a context but we can infer
the IID of the source in the inner header from the IID of the source in the
outer header.

regards,
Xavi

2016-02-04 13:12 GMT+01:00 Pascal Thubert (pthubert) <[e-mail]>om>:

> Hello Xavi:
>
>
>
> Let me propose the following update to the draft to clarify this:
>
>
>
> “
>
>
>
>
>
>
>
> Inner LOWPAN_IPHC Compression
>
>
>
> 6LoWPAN ND {{RFC6282}} is designed to support more than one IPv6 address
>
> per node and per Interface Identifier (IID), an IID being typically derived
>
> from a MAC address to optimize the LOWPAN-IPHC compression.
>
>
>
> Link local addresses are compressed with stateless address compression
> (S/DAC=0).
>
> The other addresses are derived from different prefixes and they can be
> compressed
>
> with stateful address compression based on a context (S/DAC=1).
>
>
>
> But stateless compression is only defined for the specific link-local
> prefix as
>
> opposed to the prefix in an encapsulating header. And with stateful
> compression,
>
> the compression reference is found in a context, as opposed to an
> encapsulating
>
> header.
>
>
>
> It results that in the case of an IP-in-IP encapsulation, it is possible to
>
> compress an inner source (respectively destination) IP address in a
> LOWPAN_IPHC
>
> based on the encapsulating IP header only if stateful (context-based)
> compression
>
> is used. The compression will operate only if the IID in the source
> (respectively
>
> the destination) IP address in the outer and inner headers match, which
> usually
>
> means that they refer to the same node . This is encoded as S/DAC = 1 and
> S/AM=11.
>
> It must be noted that the outer destination address that is used to
> compress the
>
> inner destination address is the last entry in the last RH3-6LoRH header.
>
>
>
> “
>
>
>
> Is that any clearer now?
>
>
>
> Take care,
>
>
>
> Pascal
>
>
>
> *From:* 6lo [mailto:[e-mail]] *On Behalf Of *Pascal Thubert
> (pthubert)
> *Sent:* jeudi 4 février 2016 11:10
> *To:* Xavier Vilajosana <[e-mail]>du>; [e-mail]
> *Cc:* [e-mail]
> *Subject:* Re: [6lo] [6tisch] 6LoRH: compression of the inner destination
>
>
>
> Hello Xavi:
>
>
>
> Yes, this deserves more clarification, thanks for pointing it out.
>
>
>
> Your question applies so source and destination, and is really whether we
> can compress the address in the IPHC based on what is found in a 6LoRH
> header.
>
>
>
> The short answer
>
>
>
> a)      you cannot do that statelessly (damn sad, need to fix), and
>
> b)      you can do a little something statefully if
>
> 1) you have a **context** and
>
> 2) the source (and / or destination) in the inner IP header and that in
> the outer header refer to **the same node**,  in which case the source
> (and / or destination) in the inner header can be fully compressed.
>
>
>
> I can add text if that helps.
>
>
>
> The long answer:
>
>
>
>
>
> RFC6282 is geared to support more than one IPv6 addresses, one that is
> link local (S/DAD=0) for use within radio range, and then several ones
> derived from different prefixes using context information (S/DAC=1). All
> these address are expected to have with a same IID, derived from the MAC
> address (twice that if you have a short and a long MAC address). This
> compression allows for a node to be the destination of an outer IP
> encapsulation with one prefix, and the destination of an inner  IP header
> with another prefix, both addresses based on the same IID. This can make
> sense for a LLN border router, for instance.
>
>
>
> Sadly RFC6282 does not allow stateless compression based the encapsulating
> IP header. IOW, stateless only works with the link-local prefix as opposed
> to the prefix in the encapsulating header. Since encapsulating a link-local
> address is useless, we could have specified stateless a bit differently,
> e.g. that the implicit prefix is the FE80:: if and only if IPHC is used for
> an outermost IP header, and that it is the prefix from the encapsulation
> otherwise. But that is another discussion, since it involves an update of
> RFC6282 which would have to be a separate document. If we want to pursue
> that other discussion we’ll have to follow up as a different thread / draft
> at 6lo. Let me know if you think there is interest there (I do).
>
>
>
> So: with the current specs, you can compress an inner (source/destination)
> IP address in the LOWPAN_IPHC **based on the encapsulating IP header****
> in a 6LoRH-encoded header if and only if the address is:
>
> -        an exact match with a context entry for the prefix length
> associated with that context,
>
> -        and then the remainder from the corresponding
> (source/destination) IP address in the encapsulating header matches that of
> the encapsulated header, which in 6LoWPAN networks can be interpreted as
> “same node” though in the IPv6 theory it does not have to be.
>
>
>
> So for now the only thing you can do is have a context. One context would
> be for the root.
>
>
>
> An example: If all the addresses in the LLN derive from the prefix of the
> root with a /112 and the short MAC address. If there is a context where
> that prefix/length is encoded, and that is signaled implicitly or
> explicitly in the LOWPAN_IPHC.  If there is an IP-in-IP encapsulation
> encoded with IP-in-IP-6LoRH, and the final destination in the IPHC is the
> same as the last entry in the last RH3-6LoRH, then the destination address
> in the IPHC can be fully elided by using DAC=1 and DAM=11. The packet will
> reach the destination in the encapsulated form, and then the packet will be
> decapsulated before going up the stack.
>
>
>
> I hope this helps : )
>
>
>
> Pascal
>
>
>
> PS This discussion leverages RFC 6282 says this:
>
>
>
> SAM: Source Address Mode:
>
>
>
> If SAC=1:
>
>
>
> <...>
>
>
>
>          11:  0 bits.  The address is fully elided and is derived using
>
>             context information and the encapsulating header (e.g.,
>
>             802.15.4 or IPv6 source address).  Bits covered by context
>
>             information are always used.  Any IID bits not covered by
>
>             context information are computed from the encapsulating
>
>             header as specified in Section 3.2.2 <https://tools.ietf.org/html/rfc6282#section-3.2.2>.  Any remaining bits
>
>             are zero.
>
>
>
>
>
> <...>
>
>
>
> DAM: Destination Address Mode:
>
>
>
> <...>
>
>
>
> If M=0 and DAC=1:
>
>
>
>
>
>          11:  0 bits.  The address is fully elided and is derived using
>
>             context information and the encapsulating header (e.g.
>
>             802.15.4 or IPv6 destination address).  Bits covered by
>
>             context information are always used.  Any IID bits not
>
>             covered by context information are computed from the
>
>             encapsulating header as specified in Section 3.2.2 <https://tools.ietf.org/html/rfc6282#section-3.2.2>.  Any
>
>             remaining bits are zero.
>
>
>
>
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
> *From:* 6tisch [mailto:[e-mail] <[e-mail]>] *On
> Behalf Of *Xavier Vilajosana
> *Sent:* mercredi 3 février 2016 11:49
> *To:* Pascal Thubert (pthubert) <[e-mail]>om>; [e-mail]
> *Subject:* [6tisch] 6LoRH: compression of the inner destination
>
>
>
> Dear Pascal,
>
>
>
> There is something it is not clear to me.
>
> How do we compress the inner header destination address assuming we have
> 6LoRH RH3.
>
>
>
> could you please clarify that?
>
>
>
> regards,
>
> X
>