Re: [6tsch] mechanism to config Report

Thomas Watteyne <> Tue, 10 September 2013 18:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CD99D11E8121 for <>; Tue, 10 Sep 2013 11:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.212
X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[AWL=0.765, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hvUDemlUEcKk for <>; Tue, 10 Sep 2013 11:30:26 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c03::233]) by (Postfix) with ESMTP id C269311E811B for <>; Tue, 10 Sep 2013 11:30:26 -0700 (PDT)
Received: by with SMTP id lf1so8170268pab.10 for <>; Tue, 10 Sep 2013 11:30:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=YzKvJs+UTmNFlV7WDGl9PLNGTPAgBbbMgXgO95X/2l4=; b=gTdm/fQqdXZos3fUBsjjQC07E22QK/sVreTrpJeNJc+55N7BHcy/+LMFFpfVt/zu+G G4tYuKu5HoMpTW1eggj+p/mrqLriEaXOaY4Kj/Xu+MYnU+943pUBxyZcJur7OZMfODDH JSxYWJca1CNwOXkExYYT2+C54fDu42+vDYA7SfVDtdJoivQGAAI3w8wd0WNsjDmd9pch qoS2ckxAxWpNvg3yT52CjSr0gJ0LzaXYWxPbVKP1pO3iN6Y6VUq4Lx/zrRu4zM5c2dRT dDERhXTdBQfGJACrEUZSigaANOEcjLrsTzs0nupvR2ocFpJxnSlj422tNAZb/HUeJF// yEOw==
X-Received: by with SMTP id pl9mr3480604pac.187.1378837826443; Tue, 10 Sep 2013 11:30:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Tue, 10 Sep 2013 11:30:06 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Thomas Watteyne <>
Date: Tue, 10 Sep 2013 11:30:06 -0700
X-Google-Sender-Auth: 8iNVQ3_QVHbP4mivGlHcBdmkpb0
Message-ID: <>
To: "" <>
Content-Type: multipart/alternative; boundary=047d7b5da81fd91f7f04e60bb23a
Subject: Re: [6tsch] mechanism to config Report
X-Mailman-Version: 2.1.12
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: Tue, 10 Sep 2013 18:30:27 -0000


I fully second the idea of being able to configure the reporting.

There are many possible metrics that can be reported (see There
should be a mechanism to configure the report rate of multiple at the same
time. Maybe we could use the notion of URI and (sub)resources. That is,
issuing a CoAP POST to /6top/r will configure all reporting, but only the
neighbor when issuing it to /6top/r/n. Just an idea.

The contents of the POST would contains the criteria and value. We might
define a number of generic criteria (period, lessThan, greaterThan,
equalTo, onAdd, onDelete), and leave some open for "exotic" uses that only
apply to specific metric. For example, "only when more than 3 neighbors".


On Tue, Sep 10, 2013 at 7:32 AM, Qin Wang <> wrote:

> Hi all,
> We have had a lot of discussion in thread "report flow contents". As you
> see, there are many items, but I believe not all of them will be needed in
> same time base or under same criteria. Thus, a mechanism to config Reports
> by PCE via Action flow is needed. Here is sort of solution I want to
> propose.
> (1) think the contents listed by Xavi in thread "report flow contents" as
> a part of MIB, and add a configuration field to each attribute, denoted as
>  ReportCriteria.
> (2) define ReportCriteria as a tuple (Criteria, CriteriaValue) . For
> example,
> Criteria =TIME, CriteriaValue=500, means reporting in every 500ms.
> Criteria = Index of RSSI attribute, CriterValue = some Threshold, means
> reporting when RSSI is worse than the Threshold.
> (3) In implementation, the ReportCriteria field in MIB will implemented as
> events which drive Report Flow and Event Flow.
> What do you think? Any input is welcome.
> Thanks
> Qin
> _______________________________________________
> 6tsch mailing list