Re: [6tisch] Proposed improvement in RH3-6LoRH

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 20 January 2016 20:46 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 C16F51ACE66; Wed, 20 Jan 2016 12:46:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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 WBeIAEV-6FM4; Wed, 20 Jan 2016 12:46:20 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515911ACE57; Wed, 20 Jan 2016 12:46:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=116331; q=dns/txt; s=iport; t=1453322774; x=1454532374; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3FniZL4qikTlahK5WWL/oVwF3zNUuzJUFAG47LM4s8c=; b=AoWy5uCpXR39V/Q/XVHidx8FPohEZSbws05m3ojyCsIuSblhAX94sEGl gOEl9/cFaWD6Ige0zWtuMqF/dhVTUlYDlmKPL9xS/HSJJMXIc3f5B20x4 PhtLCWvmS5I9JAsQSqCddUX4uUEGJzD4vi2vqBQF/g+cAOi9zP/iiV+zc o=;
X-Files: image001.png : 56662
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1AgCr8Z9W/4wNJK1dgm5MUm0GiFGvM?= =?us-ascii?q?oMMDoFkhg8CgUg4FAEBAQEBAQF/C4Q0AQEBBAUgAgYBSxACAQgRBAEBBgEBARg?= =?us-ascii?q?BBgcCBRABDgwUCQgBAQQOBAEGAgaIDb4WAQEBAQEBAQEBAQEBAQEBAQEBAQEBD?= =?us-ascii?q?QiGOoR0hDVShAUBBIdWiymEBQGEXQGIeY8HjkABHgFDgXwDGIFQaoYWfAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,322,1449532800"; d="png'150?scan'150,208,217,150";a="63328975"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2016 20:45:55 +0000
Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u0KKjtRf032485 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Jan 2016 20:45:55 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 20 Jan 2016 14:45:54 -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; Wed, 20 Jan 2016 14:45:54 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Proposed improvement in RH3-6LoRH
Thread-Index: AdFSGKgSUfjCV02CR1+kaxeIZh+TPABjTKXg
Date: Wed, 20 Jan 2016 20:45:33 +0000
Deferred-Delivery: Wed, 20 Jan 2016 17:16:55 +0000
Message-ID: <25ea5ac533564b189c6e26935e680a7c@XCH-RCD-001.cisco.com>
References: <efa57b85d5174e579bc553ff1ad3af63@XCH-RCD-001.cisco.com>
In-Reply-To: <efa57b85d5174e579bc553ff1ad3af63@XCH-RCD-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.66.235]
Content-Type: multipart/related; boundary="_004_25ea5ac533564b189c6e26935e680a7cXCHRCD001ciscocom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/6tisch/QUM3ZVAcOX8pBPPBGGY-QzGEIQA>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [6tisch] Proposed improvement in RH3-6LoRH
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: Wed, 20 Jan 2016 20:46:25 -0000

Dear all

The current text in 6LoRH lacks explanation for the process illustrated below.

Is the following correct?


## Coalescence {#RH3-6LoRH-coalescence}

An IPv6 compressed address is coalesced with a reference address by overriding
the N rightmost bytes of the reference address with the compressed address,
where N is the length of the compressed address, as indicated by the Type of the
RH3-6LoRH header in {{RH3LoRHtype}}.

The reference address MAY be a compressed address as well, in which case
it MUST be compressed in a form that is of an equal or greater length than
the address that is being coalesced.

A compressed address is expanded by coalescing it with a reference address. In
the particular case of a Type 4 RH3-6LoRH, the address is expressed in full and
the coalescence is a complete override as illustrated in {{RH3Coalesce}}.

~~~~

RRRRRRRRRRRRRRRRRRRR reference address, may be compressed or not

              CCCCCCC compressed address, shorter than or as reference

 RRRRRRRRRRRRRCCCCCCC Coalesced address, same compression as reference
~~~~
{: #RH3Coalesce title='Coalescing addresses.'}



## Popping Headers {#RH3-6LoRH-popping}

Upon reception, the router checks whether the address in the first entry of the
first RH3-6LoRH one of its own addresses. In that case, router MUST consume that
entry before forwarding, which is an action of popping from a stack, where the
stack is effectively the sequence of entries in consecutive RH3-6LoRH headers.

Popping an entry of an RH3-6LoRH header is a recursive action performed as
follows:
If the Size of the RH3-6LoRH header is 1 or more, indicating that there
are at least 2 entries in the header, the router removes the first entry and
decrements the Size (by 1).

Else (meaning that this is the last entry in the RH3-6LoRH header), and
if there is no next RH3-6LoRH header after this then the RH3-6LoRH is removed.

Else, if there is a next RH3-6LoRH of a Type with a larger or equal value,
meaning a same or lesser compression yielding same or larger compressed forms,
then the RH3-6LoRH is removed.

Else, the first entry of the next RH3-6LoRH is popped from the next RH3-6LoRH
and coalesced with the first entry of this RH3-6LoRH.

At the end of the process, if there is no more RH3-6LoRH in the packet, then
the processing node is the last router along the source route path.


## Forwarding {#RH3-6LoRH-forwarding}

When receiving a packet with a RH3-6LoRH, a router determines the IPv6 address
of the current segment endpoint.

If strict source routing is enforced and thus router is not the segment endpoint
for the packet then this router MUST drop the packet.

If this router is the current segment endpoint, then the router pops its address
as described in {{RH3-6LoRH-popping}} and continues processing the packet.

If there is still a RH3-6LoRH, then the router determines the new segment
endpoint and routes the packet towards that endpoint.

Otherwise the router uses the destination in the inner IP header to forward or
accept the packet.

The segment endpoint of a packet MUST be determined as follows:

The router first determines the Compression Reference as discussed in
{{RH3-6LoRH-coalescence}}.

The router then coalesces the Compression Reference with the first entry of the
first RH3-6LoRH header as discussed in {{sig-comp-ref}}. If the type of the
RH3-6LoRH header is type 4 then the coalescence is a full override.

Since the Compression Reference is an uncompressed address, the coalesced IPv6
address is also expressed in the full 128bits.

~~~~

Packet as received by node A
----------------------------
  Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA AAAA
  Type 1 RH3-6LoRH Size = 0                  BBBB
  Type 2 RH3-6LoRH Size = 1             CCCC CCCC
                                        DDDD DDDD

 Step 1 popping BBBB the first entry of the next RH3-6LoRH
Step 2 next is if larger value (2 vs. 1) the RH3-6LoRH is removed

  Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA AAAA
  Type 2 RH3-6LoRH Size = 1             CCCC CCCC
                                        DDDD DDDD

 Step 3: recursion ended, coalescing BBBB with the first entry
Step 4: routing based on next segment endpoint to B
Packet as received by node B
----------------------------
  Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA BBBB
  Type 2 RH3-6LoRH Size = 1             CCCC CCCC
                                        DDDD DDDD

 Step 1 popping CCCC CCCC, the first entry of the next RH3-6LoRH
Step 2 removing the first entry and decrementing the Size (by 1)

  Type 3 RH3-6LoRH Size = 0   AAAA AAAA AAAA BBBB
  Type 2 RH3-6LoRH Size = 0             DDDD DDDD

Step 3: recursion ended, coalescing CCCC CCCC with the first entry
Step 4: routing based on next segment endpoint to C
Packet as received by node C
----------------------------

  Type 3 RH3-6LoRH Size = 0   AAAA AAAA CCCC CCCC
  Type 2 RH3-6LoRH Size = 0             DDDD DDDD

Step 1 popping DDDD DDDD, the first entry of the next RH3-6LoRH
Step 2 the RH3-6LoRH is removed

  Type 3 RH3-6LoRH Size = 0   AAAA AAAA CCCC CCCC

Step 3: recursion ended, coalescing DDDD DDDDD with the first entry
Step 4: routing based on next segment endpoint to D
Packet as received by node D
----------------------------
  Type 3 RH3-6LoRH Size = 0   AAAA AAAA DDDD DDDD

Step 1 the RH3-6LoRH is removed.
 Step 2 no more header, routing based on inner IP header.


{: #RH3fwd title='Forwarding packets with RH3-6LoRH.'}


Cheers,

Pascal

From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 18 janvier 2016 18:54
To: 6lo@ietf.org
Cc: 6tisch@ietf.org; Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [6tisch] Proposed improvement in RH3-6LoRH

Dear all

The picture below illustrates how the RH3 6LoRH works with draft 03 in a case like Root -> A -> B -> C -> leaf

[cid:image001.png@01D153AE.96CBF960]

The first 6LoRH is expected to be a full address (128 bits) to set up a reference and the next 6LoRH are expected to be smaller and just override the rightmost bits which form the delta from the reference.

Proposal: we could consider that the 128bits source of the IP header before the RH3 is the reference to start with.

With that even the first hop could be compressed the same way as the other hops. With RPL, the root is the encapsulator if IP in IP in used. Good thing, in that case the root is totally elided with the IP-in-IP 6LoRH.

So this simple proposal saves up to 16 octets (that's in the case with a single subnet and all addresses differ only by the last 2 bytes). I'm willing to add it in the next revision.

Any opposition?

Pascal