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

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 04 February 2016 10:10 UTC

Return-Path: <pthubert@cisco.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 195051A6F41; Thu, 4 Feb 2016 02:10:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 NyoAgfknN2aG; Thu, 4 Feb 2016 02:10:05 -0800 (PST)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228A71A0354; Thu, 4 Feb 2016 02:10:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36548; q=dns/txt; s=iport; t=1454580605; x=1455790205; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=dh85b9vcaKaD4KEfwaFXgOgkkez/sDijdY0EUJikUeI=; b=Um2DpXNaJLgSUn0PIHdWvLEJ0aK2zkSOBpC3ienYZLESpAe8PeNAyCOB cmG0DkUvwRfENsFmoklV7txF6z2FLJ8BlZPL8VOQKHiOFlw+GZ9aubIHi qUgfaDrusLi7aoAua/NsIY7i4t36oeKyFOBcNQRaZcoJP30x7RYh49Z3J 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgBQAiIrNW/4ENJK1eDoJgTFJtBohVs?= =?us-ascii?q?QuBZiGFbAIcgSI5EwEBAQEBAQGBCoRBAQEBBCMKTBACAQgOAwQBASEBBgMCAgI?= =?us-ascii?q?wFAkIAgQBDQUIiBMOsTGPHQEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhhKEN4RfC?= =?us-ascii?q?YJKgToFkmyEBQGFSId9gWKEQohUhXCEfoNRASIDPYIDGYENO2oBAYcsfAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,395,1449532800"; d="scan'208,217";a="234707240"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2016 10:10:04 +0000
Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u14AA4Wx006917 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 10:10:04 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 4 Feb 2016 04:10:03 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Thu, 4 Feb 2016 04:10:03 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Xavier Vilajosana <xvilajosana@eecs.berkeley.edu>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: [6tisch] 6LoRH: compression of the inner destination
Thread-Index: AQHRXnCR+Lpgqlj7MkGnhe4nmHRA1p8aLKsA
Date: Thu, 4 Feb 2016 10:09:38 +0000
Deferred-Delivery: Thu, 4 Feb 2016 10:09:09 +0000
Message-ID: <042e3cd1730c46f3b2d2c7c37569d943@XCH-RCD-001.cisco.com>
References: <CAMsDxWR8tzOFddWSDvPGnAfq_neHt=y=O-7vuHqmTUBttKSKEw@mail.gmail.com>
In-Reply-To: <CAMsDxWR8tzOFddWSDvPGnAfq_neHt=y=O-7vuHqmTUBttKSKEw@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.217.89]
Content-Type: multipart/alternative; boundary="_000_042e3cd1730c46f3b2d2c7c37569d943XCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/2diHyBu8EWZw5IxjIR9vqnlYI-8>
Cc: "6tisch@ietf.org" <6tisch@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: Thu, 04 Feb 2016 10:10:08 -0000

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>.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>.2>.  Any

            remaining bits are zero.




Cheers,

Pascal

From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Xavier Vilajosana
Sent: mercredi 3 février 2016 11:49
To: Pascal Thubert (pthubert) <pthubert@cisco.com>om>; 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