Re: [6tisch] Clarification on MSF-06

Tengfei Chang <> Fri, 11 October 2019 13:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 81079120073; Fri, 11 Oct 2019 06:40:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RSdK17VLTi20; Fri, 11 Oct 2019 06:40:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D4004120090; Fri, 11 Oct 2019 06:40:52 -0700 (PDT)
Received: by with SMTP id j11so4504489plk.3; Fri, 11 Oct 2019 06:40:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oKDu1RucBWbrGOUmfOFFk2gkk98R7PTdEjmeChCZ+P8=; b=kfkGJj07vioOWQIgiu0GJbM0lLzTIziCYmGOYAZ+V7vckXMie68BKU9Pytge/VEydx WDbM0zzGjjaO7AqBp0ZAzntlc7yhI17QNcjnw5Vb6IDtSQLTq5T3S4zTD1j8btCWvhFl wc7Q2ODCt3HgZj45c7fjmGL3d03YjUwRScuzRbc7/3vVDC4jxsQJeJktRouxAJRIjqH7 bpWHVTVzmF7mUe4QOsdLCnxvtMKME2WWQvzTEXmGwcVRc2LYbr2PYx8ev4IvcFFFEiBf XndK7rNyWJYY8I/aGnjmFOFoF/5mEoNzZqVcjF/6uELItCPgJ4r6oYBZ91KimqLRCl6B QU6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oKDu1RucBWbrGOUmfOFFk2gkk98R7PTdEjmeChCZ+P8=; b=gVWXP2TzQ/idr2QXRsklec3OHoC8LeVQ88d+lZt4RVrfWneht7CMvVlf1irsoo+HXo 0hKD87ffRL43qHJ8P3JQcBtbNqcAeTfhYZqdNrOBG+XK99+q8wAKahWu++Zqq80pjQKo buuynXixZO+xCH+VqxdVQoSlwY5CRUClSvKwT3iMofQB3O5zpWDDl2Pb2sJZjVoPPr9I utZ/Bbx75zUqP8aXmcT4Lu8RU+6czxlb3Riwv4OSiwejkKQpxKJXicsmB73NhwB4+WR4 JvNXzQicNmYq/IkvUInLSTPUcYlLfshkxLJs7LRRw0lN+pFxjd3/nSkFnj7Rc7gRsWeP 7QLQ==
X-Gm-Message-State: APjAAAXQp661Nr4ztZLxHkhYRESY0lvdx3iVCRmJp5+opb8LFGEaxDyl IAqG99oEfXVj0bdo4NamRMxtus+JF4rqIynlBzc=
X-Google-Smtp-Source: APXvYqwOa0/f+0VUDZ2T/vRf02pYZHwjlQaV/ru/87ZpCLkvjm0mxKqvSZP7xqKMWg37IX5wZI7hINcThsMHCrHmgA8=
X-Received: by 2002:a17:902:ac98:: with SMTP id h24mr15456142plr.128.1570801252076; Fri, 11 Oct 2019 06:40:52 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Tengfei Chang <>
Date: Fri, 11 Oct 2019 15:40:41 +0200
Message-ID: <>
To: Christian Hopfner <>
Cc: "" <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000a48fce0594a2aa02"
Archived-At: <>
Subject: Re: [6tisch] Clarification on MSF-06
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" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 Oct 2019 13:40:56 -0000

Hi Christian,

Thanks for pointing this issue out!
The neighbor polling section is removed at 03 version. Can't remember why
we removed it.

I re-edited this sections to fit the current content of MSF draft. I paste
it below. It will the be last step of boot behavior after it starts sending
EB and DIO.

   The node SHOULD send some form of keep-alive messages to all its
   neighbors it has negotiated cell with.  The Keep-Alive (KA)
   mechanism is detailed in [RFC7554
<>].  It uses the keep-alive
   to its preferred parent to stay synchronized.  It MAY use the keep-
   alive messages to other neighbors to have statistics on link quality.
   It MAY use the keep-alive messages to its children to ensure the
   child is still reachable.  The RECOMMENDED period for sending keep-
   alive messages is KA_PERIOD.

   If the keep-alive message to a child fails at the link layer (i.e.
   the maximum number of link-layer retries is reached), the node SHOULD
   declare the child as unreachable.  This can happen for example when
   the child node is switched off.

   When a neighbor is declared unreachable, the node MUST remove all
   negotiated cells with that neighbor from its own schedule.  In
   addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at
   the link-layer). The node MAY be removed from the neighbor table.

If this is good for you, I will update the MSF to 07 with this change and
propose WGLC right after.


On Fri, Oct 11, 2019 at 1:09 PM Christian Hopfner <> wrote:

> Hi authors,
> I may raise a clarification question before issuing WGLC for this draft.
> In the past there was a section in the draft dealing with neighbor polling
> which seems to me beeing an important topic in terms of schedule
> consistency.
> In the latest version I don't see a mechanism which explains how a parent
> keeps its schedule clean after some children silently disappeared (e.g..
> batteries are gone). As per my understanding in such a case the negotiated
> RX cell towards the child remains in the schedule forever right?
> Previously this was handled by neighbor polling. Which required the parent
> to send KA packets in a periodic manner to its childset. (This could be
> identified by evaluation of the neighbor set where a negotiated RX cell was
> scheduled to)
> What is the idea now how to deal with that issue?
> Mit freundlichen Grüßen I Best regards
> Christian Hopfner
> ------------------------------
> Developer | TPI F&E Plattform Informatik
> Endress+Hauser SE+Co. KG | Hauptstrasse 1 | 79689 Maulburg | Germany
> Phone: +49 7622 28 1883
> |
> ------------------------------
> Endress+Hauser SE+Co. KG
> Registergericht: Amtsgericht Freiburg i.Br. HRA 670225
> Sitz der Gesellschaft: Maulburg
> Persönlich haftender Gesellschafter: Endress+Hauser Administration SE
> Sitz des persönlich haftenden Gesellschafters: Maulburg
> Registergericht: Amtsgericht Freiburg i.Br. HRB 717326
> Vorstand: Dr. Peter Selders
> Aufsichtsratsvorsitzender: Matthias Altendorf
> ------------------------------
> Gemäss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflichtet,
> Sie zu informieren,
> wenn wir personenbezogene Daten von Ihnen erheben.
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis
> <> nach.
> ------------------------------
> Endress+Hauser SE+Co. KG
> Register Court: Local Court of Freiburg i.Br. HRA 670225
> Registered Office: Maulburg
> General Partner: Endress+Hauser Administration SE
> Registered Office of General Partner: Maulburg
> Register Court: Local Court of Freiburg i.Br. HRB 717326
> Chief Executive Officer: Dr. Peter Selders
> Chairman of the Board: Matthias Altendorf
> ------------------------------
> According to the General Data Protection Regulation,
> we are obliged to inform you when collecting your personal data.
> We comply with this information duty with the following Data Protection
> Statement
> <>
> ------------------------------
> Disclaimer:
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential, proprietary, and/or
> privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities
> other than the intended recipient is prohibited. If you receive this in
> error, please contact the sender and delete the material from any computer.
> This e-mail does not constitute a contract offer, a contract amendment, or
> an acceptance of a contract offer unless explicitly and conspicuously
> designated or stated as such.
> _______________________________________________
> 6tisch mailing list


Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria