Re: [Roll] stitching PDAO segments

<> Thu, 25 July 2019 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D6D5120025 for <>; Thu, 25 Jul 2019 04:49:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id egZzsFAFp-LO for <>; Thu, 25 Jul 2019 04:49:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 614CA120019 for <>; Thu, 25 Jul 2019 04:49:25 -0700 (PDT)
Received: by (mx-mo-csw1116) id x6PBnNCK030858; Thu, 25 Jul 2019 20:49:24 +0900
X-Iguazu-Qid: 2wGrOLChpBk2n6mWY5
X-Iguazu-QSIG: v=2; s=0; t=1564055363; q=2wGrOLChpBk2n6mWY5; m=k35ksrcpdflVQnQZieiBWjRkZ0RN2pgotzRzS9kPSYU=
Received: from ( []) by (mx-mr1111) id x6PBnNQa012658; Thu, 25 Jul 2019 20:49:23 +0900
Received: from enc01.localdomain ([]) by with ESMTP id x6PBnMDJ011572 for <>; Thu, 25 Jul 2019 20:49:22 +0900 (JST)
Received: from ([]) by enc01.localdomain with ESMTP id x6PBnMDc029194 for <>; Thu, 25 Jul 2019 20:49:22 +0900
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901;; cv=none; b=S2+EzceXN/w3h2IsSe+3YtA1VM4IN+V82oECQKppFy9N+VrU4i1/NJ3s6/4A6h6tAMqiF4XKiB4gGEstoKe+QLXZtm0MB5Uo8h1rhs5+pc1P2NJM56ql4vDUs0cJW4D9lSh858w5SCwBd67mPT1E09toLZxPsK8yhv4iT3yfJ1QFuqPal5jP2+gzpdIVblEqGOBqHAQMByejLTTWDtCMLJgHf0KBw+sAX7hifBew8f68DiD4NveRneHJ6zkCMQGmPCgS5xf8AinkCk1+x9i8JyVohDR3Rvzke5VsxohUXSbhHd9qOwItXtKdyctoFVYHMY6vtNctStaqdZ6AqE+org==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U1qW0TUhZnAG663s50XNHyo9WLsI4cv/0ystEZs1aCY=; b=AlNb/ZFH2G7Db/1NkPJBIRDR+LMlWk3vRDB89fU85qfEBnyOBnj+Ikny1uhNaUJONvHrMkw0VUGUuB4SnyAFBhAaIKpXQwioJGNQpSkQ1n3zj4WlbP5AFvXGGsZud7yWrJvzglyDLF5Tku6w+Q88JbPTeEmGqyZICPORWEc6NlNbyFX1UVH+77wc5JQ8GBHWd0FDkHWsW3C6jlbGpTUynRDl6HpWGF8DwKBS5LyJ+aXTN6wVZF4LIPIx0I7/0uquO97akOoSS2zwAyXWeX6r/9s0fBE/hUHdF3upv6V4F1+CIsVfmY/tE27vFBQ9Ph0Q5g/LMjBVty7QQbzoFMIULw==
ARC-Authentication-Results: i=1; 1;spf=pass;dmarc=pass action=none;dkim=pass;arc=none
Thread-Topic: [Roll] stitching PDAO segments
Thread-Index: AdVCavf1/y2OVF18Rs6j63tFfNF4zQAIinQAAAG0xvoAElc2IA==
Date: Thu, 25 Jul 2019 11:49:20 +0000
Message-ID: <>
References: <>, <> <>
In-Reply-To: <>
Accept-Language: ja-JP, en-US
Content-Language: ja-JP
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: dec6f717-d8e7-439f-516f-08d710f621bb
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:TYAPR01MB2845;
x-ms-traffictypediagnostic: TYAPR01MB2845:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-forefront-prvs: 0109D382B0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(366004)(376002)(346002)(39860400002)(199004)(189003)(66574012)(6436002)(46636005)(476003)(14444005)(316002)(25786009)(74316002)(53546011)(2906002)(256004)(52536014)(6116002)(7736002)(33656002)(76176011)(3846002)(229853002)(5660300002)(68736007)(7696005)(6506007)(606006)(81156014)(53936002)(446003)(66066001)(86362001)(966005)(6306002)(55016002)(6246003)(76116006)(8936002)(186003)(14454004)(71190400001)(6916009)(99286004)(66556008)(81166006)(66946007)(8676002)(66446008)(66476007)(486006)(9686003)(102836004)(64756008)(71200400001)(54896002)(478600001)(11346002)(236005)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:TYAPR01MB2845;; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None ( does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: ouMGTpTZvjjS0cu2uBHz/eQQMK74alSgeoMz8cXlkA/VpYvsA44m9ERtybzBTCPhXA5iUI2G2UgJolsMT+gP4LAUX7Vyjg9KDmj8UVxShLylCYAyZbgtt20m+s+Zh2nbfCVKZVb5EdvPEGjI2lHGclxMUuSsabFzgvLj8kc6RcurjBBWwoalebLjhzYxkMBicSicF9wrZ6TQcprvK+av+Z3RHkk97LnjYdvy1dmuRUaVOvcHJgZNxO9YJNGBW8hTe5B7tD1AnQ5Uh+U/FA7QRsDiBiVn8/9k///hR777zvLeNvDonXPtOafU/Qv34MCcqcDVlwSEYo6JOi77VoCNSYmszzV2LckC5Yitc12EWyVjO27RrkxzKgLhEjl5+ghcnXkVAOpR7p+v5Ky4hDNUcr4aUihvohFNGwXl2rnp/lo=
Content-Type: multipart/alternative; boundary="_000_TYAPR01MB2383C0639EE876201606E613E5C10TYAPR01MB2383jpnp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: dec6f717-d8e7-439f-516f-08d710f621bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 11:49:20.6140 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2845
MSSCP.TransferMailToMossAgent: 103
Archived-At: <>
Subject: Re: [Roll] stitching PDAO segments
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Jul 2019 11:49:29 -0000

Thanks for explanation, Pascal.

> A 6TiSCH tract is computed by a pce but with RPL the nodes do not care where that logical function is located and simply talk to the root.

That makes sense.

So, if we use Track forwarding, forwarding table for each node is computed by PCE. Then, those forwarding tables are deployed to nodes using RPL, i.e. sending PDAO messages.

From: Roll <> On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, July 25, 2019 11:52 AM
To: Routing Over Low power and Lossy networks <>
Subject: Re: [Roll] stitching PDAO segments

Hello Toshio

6TiSCH provided a generic Architecture in which RPL and qrAW have different role to play.

A 6TiSCH tract is computed by a pce but with RPL the nodes do not care where that logical function is located and simply talk to the root. Either the root hosts a pce or it talks to a pce to get the computation done.

A projected track can be deep in a RPL DODAG.  When deep, a node cannot ask the root to change the path at each hiccup of the radio . This is why a simple serial track can be too limiting and the root may prefer to provide a complex track with redundancy that always works even if some segments fail randomly for split seconds.

RAW if formed would work on optimizing the use of a complex track to limit the waste of energy when the track lots of redundancy. RAW operates at the forwarding level over a track on a short time scale whereas RPL routing decisions are made on statistical time scales orders of magnitude longer.

Do I make sense?


Le 24 juil. 2019 à 22:10, "<>" <<>> a écrit :
Hi Pascal,

I thought 6TiSCH Track forwarding is a completely different forwarding scheme
from RPL/IPv6 forwarding, as implied in

In that case, we don't have to relate DAO projection and Track, I think.
Or, maybe DAO projection is one implementation of Track forwarding, with RPL root playing
the role of PCE?

From: Roll <<>> On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, July 25, 2019 7:10 AM
To: Routing Over Low power and Lossy networks <<>>
Subject: [Roll] stitching PDAO segments

Dear all

Following up on stitching PDAO paths at the meeting today:

As you know, a 6TiSCH Track can be a lot more complex than a sequence of nodes (see
It results that deploying a Track requires stitching segments into a DODAG from source to destination.
What makes the most sense for a 6TISCH Track is probably that each track is defined as a DODAG local instance for the source. All the PDAO segments would be stitched together into that DODAG to form a Track.
The current draft allows for this but a section that explains it all would certainly be useful.

Are we all OK that I propose some text about that?

All the best

Roll mailing list<>