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 >
- Re: [6tisch] 6LoRH: compression of the inner dest… Pascal Thubert (pthubert)
- Re: [6tisch] 6LoRH: compression of the inner dest… Xavier Vilajosana
- [6tisch] 6LoRH: compression of the inner destinat… Xavier Vilajosana
- Re: [6tisch] 6LoRH: compression of the inner dest… Pascal Thubert (pthubert)
- Re: [6tisch] 6LoRH: compression of the inner dest… Pascal Thubert (pthubert)