IETF Logo Mail Archive

Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 21 November 2016 16:10 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 8AF3B129494 for <6tisch@ietfa.amsl.com>; Mon, 21 Nov 2016 08:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.398
X-Spam-Level:
X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, 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 YS4Ww8bQ8R7B for <6tisch@ietfa.amsl.com>; Mon, 21 Nov 2016 08:10:46 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6F4128B38 for <6tisch@ietf.org>; Mon, 21 Nov 2016 08:10:46 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5B8BC203AE for <6tisch@ietf.org>; Mon, 21 Nov 2016 11:27:17 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 39AD8637A8 for <6tisch@ietf.org>; Mon, 21 Nov 2016 11:10:45 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: "6tisch@ietf.org" <6tisch@ietf.org>
In-Reply-To: <336b3bcd-eee8-6b3a-0e31-e8e80988f73d@toshiba.co.jp>
References: <CAAdgstS-_CszQZ-0aDf3sOrj4kuJ1MU6HR2Z97OoiecrPkSGdw@mail.gmail.com> <6f8fff17-2238-8470-7109-9a44b874eb00@toshiba.co.jp> <CADJ9OA8bVu=R+BGaesTZMnziAugs2gx80x15qsWeFeD=wpKepw@mail.gmail.com> <CAH7SZV84FhvZRMkLiStOZnVe+8RaP3aPA+QnRbQQnmSNLt4ttg@mail.gmail.com> <CADJ9OA-2677vjkHr2SiCN6YVCmUmOUQb89c6a=eAw1-eBkC5uw@mail.gmail.com> <CAH7SZV894-=c+v3YSJhfR9KJxCM-TviYcPLcATZi+eCrbZ8Tyg@mail.gmail.com> <CADJ9OA96xSVz+xUwxGYR=n570dkrhwmZMTBE+V6VQ2-P_oP6dg@mail.gmail.com> <76b5474f-ff6e-4c12-170d-658a03b42e5c@toshiba.co.jp> <CADJ9OA9tBTn9rWeVPwBTzq60yXfRp2XJ7W60i+SXhR9GYfGL-A@mail.gmail.com> <336b3bcd-eee8-6b3a-0e31-e8e80988f73d@toshiba.co.jp>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Mon, 21 Nov 2016 11:10:45 -0500
Message-ID: <12721.1479744645@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/6xOiCWcgPg5bQfkK-QMTS6S2x80>
Subject: Re: [6tisch] [6TiSCH] Node Behavior at Boot in SF0
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: Mon, 21 Nov 2016 16:10:47 -0000

Yasuyuki Tanaka <yasuyuki9.tanaka@toshiba.co.jp> wrote:
    >> Sending an explicit CLEAR will speed things up, and avoid for the
    >> previous preferred parent to waste energy listening to those. A CLEAR
    >> wouldn't hurt, right?

    > This is right. But, I don't think it's a SF0 job. The thing is that SF0
    > knows nothing about RPL.

    > If SF0 provided an API to send CLEAR to a particular neighbor, RPL
    > could trigger the CLEAR request to a previous preferred parent on its
    > parent switch, I guess.

Your SF0 layer could provide whatever internal API it wants to your RPL
implementation.  This is hardly a standardization issue or problem; this is a
quality of implementation issue.

The observation of *when* RPL should clear traffic reservation may have some
impact on the SF0 protocol, but I'd think it would be just some
implementation advice.


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.28.0 | Report a Bug | By Email | System Status