[6tisch] Timing policy on 6P transactions

Glenn Daneels <glenn.daneels@uantwerpen.be> Wed, 30 November 2016 18:04 UTC

Return-Path: <glenn.daneels@uantwerpen.be>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4184E129955 for <6tisch@ietfa.amsl.com>; Wed, 30 Nov 2016 10:04:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 N4PS44Jq0Awl for <6tisch@ietfa.amsl.com>; Wed, 30 Nov 2016 10:04:18 -0800 (PST)
Received: from mailer07.cde.ua.ac.be (mailer07.cde.uantwerpen.be [143.169.242.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8526129929 for <6tisch@ietf.org>; Wed, 30 Nov 2016 10:04:17 -0800 (PST)
Received: from nsoetens.mosaic.uantwerpen.be ([143.129.76.63]) (authenticated bits=0) by mailer07.cde.ua.ac.be (8.14.4/8.14.4) with ESMTP id uAUI3is3003562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Wed, 30 Nov 2016 19:03:44 +0100
From: Glenn Daneels <glenn.daneels@uantwerpen.be>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BD3862DC-8517-4570-BBD8-A742F56508F9"
Message-Id: <60E751F8-49BE-4098-ABA8-7CB4E5655D05@uantwerpen.be>
Date: Wed, 30 Nov 2016 19:03:44 +0100
To: 6tisch@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Mailer: Apple Mail (2.3096.5)
X-Scanned-By: MIMEDefang 2.71 on 143.169.242.17
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/Kz7yaQo8JvGy5GbgvcLSeBtQeU8>
Subject: [6tisch] Timing policy on 6P transactions
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.17
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, 30 Nov 2016 18:37:31 -0000

Dear all,

I am wondering if there is any policy on when 6P reservations request and responses (the “6P transaction”) should be sent (when e.g. doing neighbor-to-neighbor scheduling). In the 6TiSCH minimal configuration there is not really a need for this because of the static schedule (the one active cell). But when using a dynamic scheduler as SF0, the 6P requests and responses should also be sent. In the "6TiSCH Operation Sublayer (6top)”, it is suggested that 6P can be used with the minimal configuration (https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-04#section-2.2 <https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-04#section-2.2>); it is recommended that two types of slotframes are used: one (SFR0) for the Minimal 6TiSCH configuration and one (SFR1) for 6P to allocate cells from. Should SFR1 then be used for the 6P ADD and RESPONSE messages or is this slotframe only meant to allocate data transmissions cells from (and should the actual ADD and RESPONSE messages be sent somewhere else) or both? What is the current recommended policy for this (if there is any)? Is it for example also possible that 6P messages are sent in between normal data transmissions and thus not in a separate, dedicated slotframe?

I am also wondering if there is a similar policy on which type of cell should preferably be used for 6P ADD and RESPONSE messages (or other 6P commands in general): should one choose for Transmit or Shared cells? For me, the second option looks the more intuitive one as you could have some kind of minor management slotframe in which the motes contend to do 6P transactions (but of course, having such a “shared” management frame could be a bit much in the context of TSCH).

I do not any other information on this topic in the different drafts or mailing list.

As a third and last question, related to those shared cells, I noticed that there is some work done in the 6TiSCH simulator on shared cells by Xavier Vilajosana and Mališa Vučinić. Is the usage of a shared cell fully working or is this work in progress as I see that the commits are very recent?

Kind regards,
Glenn

-- 
Glenn Daneels
IDLab research group
Dept. Mathematics and Computer Science
University of Antwerp - imec
Campus Middelheim, Building G, Office M.G.212
Email: glenn.daneels@uantwerpen.be