[6tisch] draft-ietf-6tisch-msf-02.txt is published
Tengfei Chang <tengfei.chang@gmail.com> Mon, 11 March 2019 17:53 UTC
Return-Path: <tengfei.chang@gmail.com>
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 DF8121311A1 for <6tisch@ietfa.amsl.com>; Mon, 11 Mar 2019 10:53:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 vGysfGE9IXWn for <6tisch@ietfa.amsl.com>; Mon, 11 Mar 2019 10:53:02 -0700 (PDT)
Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (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 7D309131195 for <6tisch@ietf.org>; Mon, 11 Mar 2019 10:52:57 -0700 (PDT)
Received: by mail-pf1-x433.google.com with SMTP id i20so4231261pfo.6 for <6tisch@ietf.org>; Mon, 11 Mar 2019 10:52:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Tp7hpAB0xnP8czb1noKpPlhxlC1mPciZTkBzNyA1JDs=; b=Lzo63yD/ALNF0PQcBplop5fneemSBY6Z9zBFvV44CSGfAmaWgRDELQnZGDe34zeZZx e8+06nOz0onmFiwK8BB/TE1L04mcEwk61AEbGnUhWKFrQnV3xWXB/L2m9eShXKXXWtNQ L1AgxY4ZjuZ+p/RGJ0caywaJq51L3pK/rRvpUkZJtqCArNMjg6fp2gLLPAgiMcm90B+L +wuh6vXR6rfemSLKnHuf3YDV5ljoBcm3NYnNhgVCoTiDaDbFhxofs9C43owor6C8RZI1 ozq4H6TiXvGmor+vcKhyZrC9tb2rDWwemalI6Nc9e0fTETCKa4W6M+pIL18XdZHX7ME/ 2riw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Tp7hpAB0xnP8czb1noKpPlhxlC1mPciZTkBzNyA1JDs=; b=PbHMuSu4B+qcLsQFxkwgmB7aGcE5sVWGi6pMhvpxJt4n9Uo3zjKjTARDvmIl/3mXBb K4O6HntYmnq3upauJEh/8+APPW0+2MrgxZZzsnPydT88f5EJuehb97Wu+ntgeYcxUCmL RRTGZogPNjn69+92guTGxNTBS9JkH/riDed9Fdh4crOa8BDA/iT0XKFygyRm+0oJzQlx hn899MMpu52aW5p944KkVMUw2zzRvgrdoV0vWqPH0kWvQLCcIoe43ZPHFEg/I+xBIpjY MHeFG+ljYzBQBJt1RQBUdJPegYfzSEviME1GGZOrVCma/A6FgP3HKwFkx7H9c4a5voc0 YMHg==
X-Gm-Message-State: APjAAAXPwoFgKA/FSEihMNrR3H5t8lOiEY4dELDYKEQibDd+pIoZzF+0 40xhcM0lPadTX7/UAJIP2W+fU3p1a54Cj6I0osdlVB+O
X-Google-Smtp-Source: APXvYqxBTnz/uz++wC8VfVindXalnGak3lVSCxOQpdwU4FrM3vNU1qodMZQHKQ+OHv6q0dAd51zRXdh27P6Qg23kv4A=
X-Received: by 2002:a63:ed45:: with SMTP id m5mr9394675pgk.265.1552326776364; Mon, 11 Mar 2019 10:52:56 -0700 (PDT)
MIME-Version: 1.0
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Mon, 11 Mar 2019 18:52:45 +0100
Message-ID: <CAAdgstS-O33+0yVH4Aahknope74GeVZpyqwzp=f-P7QRcGctbw@mail.gmail.com>
To: 6tisch@ietf.org
Content-Type: multipart/alternative; boundary="00000000000014a4160583d53eb3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/w68mMZFumm_b9RRHrEKg2zB-2Cg>
Subject: [6tisch] draft-ietf-6tisch-msf-02.txt is published
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 11 Mar 2019 17:53:15 -0000
Dear all, draft-ietf-6tisch-msf-02.txt is just published. The main changes made in this version are - Resolve the issues in Pending Elements section. - Using autonomous SHARED and non-SHARED cells. - Overall revised the specification. Additional information about how the issues in the pending elecments section are resolved is written below. (issues are separated by "=") Any reviews or comments are welcome! Tengfei Security issue on autonomous cell installation ==================== The autonomous cell to the pledge is installed on the join proxy before the pledge is authorized, which is a security issue. Related discussion: ttps:// mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao [Resolved. During join process, only pledge required to install autonomous SHARED cell to JP, no action required from JP side.] Handling the case when bandwidth allocation exceeds available capacity ==================== When node A initializes a 6top ADD transaction to node B, but node B does NOT have enough bandwidth to allocate. What can node B do to indicate this case in its 6top response, and how should node A handle the packet after receiving the response? Related discussion: https://www.ietf.org/mail-archive/web/6tisch/current/msg06095.html [ToDo. According to 6top RFC8480, SUCCESS return code will be in the 6top response with an empty cellList possibly. For this case, I don't have a prefect solution. One solution I am using is marking the node B as 'no_resource', then updating it's routing table and filtering out the neighbor marked as 'no_resource'. However, this is a layer-violation design.] joining traffic MUST be sent in minimal cell ==================== Joining traffic MUST be sent in minimal cell. Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/11 [Resolved. Joining traffic will be sent on autonomous cell.] NumCellsElapsed shouldn't update on shared dedicated cell ==================== NumCellsElapsed is used to track under/overuse of cells. If we are backing off, i.e. skipping cells, should those skipped cells count towards NumCellsElapsed ? Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/13 [Resolved. The counters are only applied on managed unicast cell.] non-trusted packet shouldn't be accounted for for adapting traffic ==================== Mention that the untrusted packet (e.g. join request/response) shouldn't be counted for adapting the traffic. Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/15 [Resolved. clarified in adapting traffic section.] Customize the backoff exponent on dedicated shared cell. ==================== Use small backoff exponent on dedicated cell since it's only shared by two nodes. Discussion: do we still have this case with the merger of ASF? Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/17 [NotApplied. After ASF is merged, the dedicated shared cell is not used anymore. The autonomous SHARED cell is shared among a set of neighbors hence no need to customize the backoff exponent.] Adapting 6P Timeout ==================== After 6P TIMEOUT, the next 6P transaction should be configured using a larger TIMEOUT. Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/19 [ToDo. I am not sure this is an issue or not with current version. Need to discuss with Malisa and Simon.] Timeout calculation is wrong ==================== The 6P Timeout is calculated as : list style: symbols (1/(C+1))*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR It should be list style: symbols (1/(C+1))*(1/PDR)*SIXP_TIMEOUT_SEC_FACTOR according to the paper: https://arxiv.org/pdf/1507.05810.pdf Related link is at: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/22 [Resolved. The comments are taken and applied in the text.] Separate Cell Counters for TX and RX ==================== NumCellsUsed and NumCellsElapsed counter should be separated between TX and RX. Question: still applies? Related Link is at: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/20 [Resolved. The comments are taken and applied in the text.] Two slotframes ==================== Why are they two slotframes in same length? Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/25 [Resolved. The length of two slotframes are SHOULD be the same, instead of MUST.] Parameters for SAX is missing ==================== It'd be nice to have an example or a test vector in the draft in order to validate a SAX implementation used for MSF. This is critical for interoperability. Related discussion: https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao [Resolved. An appredix of how to implement the sax is added.] Wrong end state statement ==================== In Section 1, one of the end states of the join process is having "one default unicast cell to/from each of its neighbors". It should be an autonomous TX cells to its Join Proxy. Related discussion: hhttps:// mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao [Resolved.Comments are taken and applied in v2.] Dependency on RFC8180 shouldn't be a MUST ==================== Section 2 states "A node implementing MSF MUST implement the Minimal 6TiSCH Configuration [RFC8180], which defines the "minimal cell", a single shared cell providing minimal connectivity between the nodes in the network". MUST here is too strong. Some may want to use MSF with a base schedule other than the one defined in RFC8180, with full understanding on the implications by not following RFC8180. Proposal is to replace MUST by SHOULD. Related discussion: https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao [Resolved. Comments are taken and applied in v2.] DIO can be unicast packet as indicated in RFC6550 ==================== Section 2 states "DODAG Information Objects (DIOs), defined by [RFC6550]. These are broadcast frames." However, the DIO as a response to a DIS is a unicast frame. Related discussion: hhttps:// mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao [Resolved. Comments are taken and applied in v2.] Rules for broadcast frames is out of scope of MSF ==================== In Section 2, the rules for broadcast frames on the minimal cell seem to be an implementation-specific optimization. And it is beyond of the scope of this draft. This idea is about how to use the minimal cell efficiently; it's not directly related to how to use cells scheduled by MSF. Related discussion: https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao [ToDo. I agree with this comment. Should we remove those text or keep them in the draft but mentioned those rules are not a MUST but a RECOMMENDED?] Wrong statement in Step 4 ==================== In Section 4.4 Step 3, the statement "After joining" in the explanation of step 3 should be "After having chosen a JP"? At this step 3, "joining" is not done. Related discussion: https://mailarchive.ietf.org/arch/msg/6tisch/9jcaTddi6vLO5zHqTDNk6yqrNao [Resolved. Comments are taken and applied in v2.] Rephrase NumCellsElapsed to NumCellsElapsed ==================== Rephrase NumCellsElapsed to NumCellsElapsed Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/14 [Resolved. Comments are taken and applied in v2.] Create a list of packets that be able to be sent on minimal cell ==================== The current text enumerates explicitly EBs and DIOs. The other broadcast packets are not mentioned. For example: RPL DIS or application-layer broadcast? It should mention EBs and DIOs but also say "any other broadcast packet". Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/24 [Resolved. Comments are taken and applied in v2.] Clarify term 'dedicated cell' ==================== Terminology: "dedicated" needs to be clarified in MSF. Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/26 [Resolved. dedicated cells are not used in v2. The type of cell used in the specification are autonomous non-SHARED cell, autonomous SHARED cell and managed unicast cell.] text is missing ==================== The text that describes the 6P command with cell options etc. was accidentally removed. Needs adding back somewhere. The text was: Step 5 - 6P ADD to Preferred Parent After having selected a preferred parent, the joined node MUST issue a 6P ADD command to that parent, with the following fields: list style: symbols CellOptions: set to TX=1,RX=1,SHARED=1 CellOptions: set to TX=1,RX=1,SHARED=1 NumCells: set to 1 CellList: at least 5 cells, chosen according to Section 7 /list> After the 6P Transaction is finished, the node MUST synchronize only to its preferred parent. At this point, the node has a dedicated cell which allows for bidirectional communication with its preferred parent. Issues link: https://github.com/twatteyne/draft-ietf-6tisch-msf/issues/29 [NotApplied. This comments is referring to the version before ASF is merged.] -- Chang Tengfei, Pre-Postdoctoral Research Engineer, Inria
- [6tisch] draft-ietf-6tisch-msf-02.txt is published Tengfei Chang
- [6tisch] Comments on draft-ietf-6tisch-msf-02 - R… Yasuyuki Tanaka
- Re: [6tisch] Comments on draft-ietf-6tisch-msf-02… Tengfei Chang
- Re: [6tisch] Comments on draft-ietf-6tisch-msf-02… Yasuyuki Tanaka
- Re: [6tisch] Comments on draft-ietf-6tisch-msf-02… Tengfei Chang