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

Xavier Vilajosana <xvilajosana@eecs.berkeley.edu> Sat, 06 February 2016 04:55 UTC

Return-Path: <xvilajosana@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B490D1A90C8; Fri, 5 Feb 2016 20:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fxu9a894npzA; Fri, 5 Feb 2016 20:55:16 -0800 (PST)
Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 239441A90BB; Fri, 5 Feb 2016 20:55:16 -0800 (PST)
Received: by mail-wm0-x231.google.com with SMTP id r129so51485571wmr.0; Fri, 05 Feb 2016 20:55:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=tMsxjdnssIEjqCPBxGCjoRk9JF7AogeY8/WLAlv2Bbc=; b=ADLFFsUoV1yCliy5jP8rujuxrvlFApPWv2I8nZjeQ2wKu5NzCHsPWRCs4FOruM14Tp TMzjwckp2A6jRQ6gQTOCo8nzUvBj4aW0yoZ8nOKOFUCdy7Z0EorufnowULvVasRZMTnx vZT5Az2jdkvCr2/I/xSb1jCutCDR1GJCBitCItsnn05DBIkAnQ/PA1WVJHfq5nsSVWnd jbj0l1XzwG/IGJxECCvBPEYZSTfsShCRMJwwL4+hx1XkCseMg/z0iIbk43crJkWUY4B6 OOcxka5mS/CvO2jN0zCo9Kd4gGjL5Cd09PlOxLpepwEE5RgQXLfnEmogfe374iPbxK+j zSbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tMsxjdnssIEjqCPBxGCjoRk9JF7AogeY8/WLAlv2Bbc=; b=EPzA8/gGKdZGnGhGkTtxvoRj9PgUM4vaUsdwfsorDApgjR3b7peekX8e5vAnMOBkv9 fal7tlNcfFMh7e9Rp8fplZdlcsOzGoL3RyQOZl9oOSor/PIPMkTEXeoHb/ExG7cjTGlX u/0w+Mcvg3T+IflXMix97W6srVzwVSHjkuX4Xo9MgN2Gvpgbqny1DPx3VeRSC4NMPGDT p9MuRriLalKKKlS4cwEGhZ+AygXcIcal1h5nJYyuchs6d5j+f2qpJSbSC+nkqqKIxv/n 8EDnOk0GrgCA7hdtDwTtfqVipahfRgj8ohnx/z9JVvbl5ehl8QIOK2m9yGZ2dD8UN8gh DDUQ==
X-Gm-Message-State: AG10YOQxPAol9Cre3/3uw2UIebwwh899I3hs7uZMYsc2O4v2GjVgAqFOCitZ/OcBjU1alcCdFUzQnwljQI+PrQ==
MIME-Version: 1.0
X-Received: by 10.194.79.163 with SMTP id k3mr17025308wjx.117.1454734514722; Fri, 05 Feb 2016 20:55:14 -0800 (PST)
Sender: xvilajosana@gmail.com
Received: by 10.27.51.135 with HTTP; Fri, 5 Feb 2016 20:55:14 -0800 (PST)
In-Reply-To: <d830d6043c0846cabad7ef26b9018f4d@XCH-RCD-001.cisco.com>
References: <CAMsDxWR8tzOFddWSDvPGnAfq_neHt=y=O-7vuHqmTUBttKSKEw@mail.gmail.com> <042e3cd1730c46f3b2d2c7c37569d943@XCH-RCD-001.cisco.com> <d830d6043c0846cabad7ef26b9018f4d@XCH-RCD-001.cisco.com>
Date: Sat, 06 Feb 2016 05:55:14 +0100
X-Google-Sender-Auth: OWpIIzPxOp7yzNSKwh1ctZb_EVs
Message-ID: <CAMsDxWTycoYaOXcd23F_ZCEVHKvBqjm2mE08KYrCzNZWPZ83Jg@mail.gmail.com>
From: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Content-Type: multipart/alternative; boundary="047d7bf0d1e2fe1ec4052b12c531"
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/8eV5Io8kCwWvIlwoo6yhafnXYLg>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Subject: Re: [6tisch] 6LoRH: compression of the inner destination
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 06 Feb 2016 04:55:19 -0000

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) <pthubert@cisco.com>:

> 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:6lo-bounces@ietf.org] *On Behalf Of *Pascal Thubert
> (pthubert)
> *Sent:* jeudi 4 février 2016 11:10
> *To:* Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>; 6lo@ietf.org
> *Cc:* 6tisch@ietf.org
> *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:6tisch-bounces@ietf.org <6tisch-bounces@ietf.org>] *On
> Behalf Of *Xavier Vilajosana
> *Sent:* mercredi 3 février 2016 11:49
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>; 6tisch@ietf.org
> *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
>