Re: [6tisch] 6P "design team" session this Friday, same time as interim meeting
Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp> Wed, 14 December 2016 20:21 UTC
Return-Path: <yasuyuki9.tanaka@toshiba.co.jp>
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 9541B129437 for <6tisch@ietfa.amsl.com>; Wed, 14 Dec 2016 12:21:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 9Cvxe1d64nQA for <6tisch@ietfa.amsl.com>; Wed, 14 Dec 2016 12:21:15 -0800 (PST)
Received: from mo.tsb.2iij.net (mo1502.tsb.2iij.net [210.149.48.174]) (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 24DE8126CD8 for <6tisch@ietf.org>; Wed, 14 Dec 2016 12:20:57 -0800 (PST)
Received: by mo.tsb.2iij.net (tsb-mo1502) id uBEKKuDZ029317; Thu, 15 Dec 2016 05:20:56 +0900
Received: from unknown [172.27.153.187] (EHLO tsb-mr1501.hop.2iij.net) by mas1501.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id 8a9a1585.0.292062.00-654.525396.mas1501.tsb.2iij.net (envelope-from <yasuyuki9.tanaka@toshiba.co.jp>); Thu, 15 Dec 2016 05:20:56 +0900 (JST)
X-MXL-Hash: 5851a9a81f2b2a7d-276b49b9cca97a1fa88ea8bf28e9565541df863d
Received: from imx2.toshiba.co.jp (imx2.toshiba.co.jp [106.186.93.51]) by relay.tsb.2iij.net (tsb-mr1501) with ESMTP id uBEKKuPI018078 for <6tisch@ietf.org>; Thu, 15 Dec 2016 05:20:56 +0900
Received: from tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp ([133.199.200.50]) by imx2.toshiba.co.jp with ESMTP id uBEKKubK022182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <6tisch@ietf.org>; Thu, 15 Dec 2016 05:20:56 +0900 (JST)
Received: from tsbmgw-mgw02 (localhost [127.0.0.1]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id uBEKKuVr003153 for <6tisch@ietf.org>; Thu, 15 Dec 2016 05:20:56 +0900
Received: from localhost ([127.0.0.1]) by tsbmgw-mgw02 (JAMES SMTP Server 2.3.1) with SMTP ID 837 for <6tisch@ietf.org>; Thu, 15 Dec 2016 05:20:56 +0900 (JST)
Received: from arc1.toshiba.co.jp ([133.199.194.235]) by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id uBEKKuY9003150 for <6tisch@ietf.org>; Thu, 15 Dec 2016 05:20:56 +0900
Received: (from root@localhost) by arc1.toshiba.co.jp id uBEKKuX7019687 for 6tisch@ietf.org; Thu, 15 Dec 2016 05:20:56 +0900 (JST)
Received: from unknown [133.199.192.144] by arc1.toshiba.co.jp with ESMTP id FAA19686; Thu, 15 Dec 2016 05:20:56 +0900
Received: from mx11.toshiba.co.jp (mx11.toshiba.co.jp [133.199.90.141]) by ovp2.toshiba.co.jp with ESMTP id uBEKKtj8019407 for <6tisch@ietf.org>; Thu, 15 Dec 2016 05:20:56 +0900 (JST)
Received: from spiffy21.isl.rdc.toshiba.co.jp by toshiba.co.jp id uBEKKte5005130; Thu, 15 Dec 2016 05:20:55 +0900 (JST)
Received: from [133.196.17.213] (nm-pptp213.isl.rdc.toshiba.co.jp [133.196.17.213]) by spiffy21.isl.rdc.toshiba.co.jp (Postfix) with ESMTPSA id B495FFF28E; Thu, 15 Dec 2016 05:20:54 +0900 (JST)
To: 6tisch@ietf.org
References: <CADJ9OA8cHEa65fSXMi1HR_AmYiW3a-JzeTA6eVxSixz8+cbMqw@mail.gmail.com>
From: Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp>
Message-ID: <c9f510fa-5352-0f6b-51ba-5231a50e7fd2@toshiba.co.jp>
Date: Wed, 14 Dec 2016 21:21:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
In-Reply-To: <CADJ9OA8cHEa65fSXMi1HR_AmYiW3a-JzeTA6eVxSixz8+cbMqw@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by tsbmgw-mgw02.tsbmgw-mgw02.toshiba.co.jp id uBEKKuY9003150
X-MAIL-FROM: <yasuyuki9.tanaka@toshiba.co.jp>
X-SOURCE-IP: [172.27.153.187]
X-Spam: exempt
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/howTdR0lfymr_dBj1qdJEJ1lYt4>
Subject: Re: [6tisch] 6P "design team" session this Friday, same time as interim meeting
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, 14 Dec 2016 20:21:18 -0000
Thank you, Thomas. Let me add comments on a couple of the ppt slides in advance, which could save time of the coming meeting, I hope...: The ppt sides Thomas provided: https://bitbucket.org/6tisch/meetings/raw/c9bd4d78fa452a0588abefc104d08520d32e0c26/161209_webex/slides_161209_webex.ppt ------------------------------------------------------------------------ (6P unclarities 2 [1/4], slide-19) ppt> Section 4.2.2: [Q] Why must the value of SeqNum increment *by ppt> exactly one* at each new 6P request to a certain neighbor? ppt> ppt> -> Why not? I think "MUST" is too strict. I thought an idea behind that requirement was to try to have different SeqNum to previous requests. If this was true, "incrementing by exactly one at each new 6P request" could be just an example of implementation. In addition, there is no validation defined in the draft to see if the SeqNum of a receiving request is off by one from the previous one. If it was a really "MUST" thing, some validation should be in place, shouldn't it? But, of course, such a validation is not practical at all since a request could be lost in the air. I may be wrong; just wanted to know the reason of the restriction, "MUST increment by exactly one at each new 6P request issued to the same neighbor." ------------------------------------------------------------------------ ppt> [C] I'd suggest listing only valid combinations of CellOption ppt> bits and mentioning others are invalid. ppt> -> isn’t that policy? Indeed, 6P doesn't care about the meanings of bits in CellOptions in its operation. However, the definitions in Figure 11 are RECOMMENDED by the draft. I cannot see any reason to have ineffective CellOptions values separately in the recommendation... draft> 4.2.6. 6P CellOptions draft> (snip) draft> Figure 11 contains the RECOMMENDED meaning of the 6P draft> CellOptions field for the 6P STATUS and 6P LIST requests. In this context, we may have to define a return code to respond to CellOptions invalid to a corresponding SF, something like RC_ERR_CELL_OPTIONS. Or, should RC_ERR (generic error) be returned? In any case, it'd be nice to have some text on checking CellOptions value in Section 4.3. ------------------------------------------------------------------------ (6P unclarities 2 [4/4], slide-22) ppt> [C] I'm not sure typical use cases of the LIST operation. When ppt> does a SF use STATUS and LIST...? I think these commands would be ppt> useful for the purpose of management or administration. But, it's ppt> not within the scope of SF, is it? I'd be nice that a typical use ppt> case of LIST is provided in the text. ppt> -> Recover after reset Such recovery doesn't work due to generation inconsistency. Let's say, there are two 6P nodes, Node A and Node B. Node A resets after having some Add or Delete operations with node B. Now, both of GTX and GRX on Node A are 0b00. At least GTX or GRX on Node B is either 0b01 or 0b10. Then, Node A sends a Status request to Node B for recovery. Node B responds with RC_ERR_GEN since GAB and GBA of the request are zero while node-B has non-zero GTX and/or non-zero GRX. The Status request fails. The same thing will happen to a List request. In the end, Node A cannot recover the cells. Here is an excerpt of Section 4.3.11.3 of draft-03: draft> Upon receiving a 6P message, a node MUST do the following draft> checks: draft> draft> o When node B receives a 6P Request of 6P confirmation from node A, draft> it verifies that GAB==GRX and GBA==GTX. draft> draft> (snip) draft> draft> If any of these comparisons is false, the node has detected a draft> schedule generation inconsistency. draft> draft> When a schedule generation inconsistency is detected: draft> draft> o If the code of the 6P Request is different from CMD_CLEAR, the draft> node MUST reply with error code RC_ERR_GEN. This is related to the topic in the thread of "Handling Inconsistent Allocation in 6P." ------------------------------------------------------------------------ ppt> - Is there any plan for 6P to support the following cells? ppt> ppt> - a cell whose macNodeAddress is a group MAC address or a ppt> 16-bit multicast address ppt> -> No. Use case? A use-case in my mind is allocating cells for IPv6 multicast. RFC 4944 defines the mapping rule between IPv6 multicast address and IEEE 802.15.4 16-bit multicast address. # I'm not sure the exact meaning of "mesh-enabled LoWPAN" in Section 9 # of RFC 4944, though... I think Section 9 could be applied to a # 6TiSCH network. I think this has some potential to enable to dynamically allocate cells dedicated to ff02::1a (all-RPL-node) or ff0X::fc (ALL_MPL_FORWARDERS), for example. Now, I understand this is out of scope of the draft at this point as well as allocating cells for broadcast. I'm a person interested in multicast, by the way ;-) ------------------------------------------------------------------------ ppt> - Is there any plan for 6P to support the following cells? ppt> (snip) ppt> - a dedicated TX cell to multiple recipients ppt> -> IEEE802.15.4e question, multiple cells? Tero told me that such a TX cell is possible as per the IEEE 802.15.4 specification. https://www.ietf.org/mail-archive/web/6tisch/current/msg04909.html mail> > Therefore, in theory, we may have a dedicated (non-shared) TX mail> > cell whose macNodeAddress is the broadcast address. mail> mail> Yes. I.e. you are the only one allowed to send to that link, but mail> there are multiple listeneres in there. So, as it does not have mail> shared bit on, there will not be other transmitters, but there mail> can be multiple listeners on it. ------------------------------------------------------------------------ ppt> - Is there any plan for 6P to support the following cells? ppt> (snip) ppt> - a RX cell shared with multiple senders ppt> -> supported OK, then another question comes up... how is a cell having multiple senders (or multiple recipients) allocated or deallocated? For example, one of senders may request to delete such a cell with a recipient. However, the recipient is not supposed to delete the cell by the request alone since there are other senders on the cell. If it's supported, some explanation would be needed, about how it works, although this kind of detail may be up to SF. This could be related to the topic about what value is set to "macNodeAddress" as a result of 6P Add transaction. ------------------------------------------------------------------------ That's it! Thanks. Best, Yatch
- [6tisch] 6P "design team" session this Friday, sa… Thomas Watteyne
- Re: [6tisch] 6P "design team" session this Friday… Yasuyuki Tanaka
- Re: [6tisch] 6P "design team" session this Friday… Tengfei Chang
- Re: [6tisch] 6P "design team" session this Friday… Qin Wang
- Re: [6tisch] 6P "design team" session this Friday… Simon Duquennoy
- Re: [6tisch] 6P "design team" session this Friday… Prof. Diego Dujovne
- Re: [6tisch] 6P "design team" session this Friday… Qin Wang
- Re: [6tisch] 6P "design team" session this Friday… Xavi Vilajosana Guillen
- Re: [6tisch] 6P "design team" session this Friday… Qin Wang