Re: [6tsch] mechanism to config Report

Thomas Watteyne <watteyne@eecs.berkeley.edu> Tue, 10 September 2013 18:30 UTC

Return-Path: <twatteyne@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD99D11E8121 for <6tsch@ietfa.amsl.com>; Tue, 10 Sep 2013 11:30:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.212
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvUDemlUEcKk for <6tsch@ietfa.amsl.com>; Tue, 10 Sep 2013 11:30:26 -0700 (PDT)
Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id C269311E811B for <6tsch@ietf.org>; Tue, 10 Sep 2013 11:30:26 -0700 (PDT)
Received: by mail-pa0-f51.google.com with SMTP id lf1so8170268pab.10 for <6tsch@ietf.org>; Tue, 10 Sep 2013 11:30:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.66.219.41 with SMTP id pl9mr3480604pac.187.1378837826443; Tue, 10 Sep 2013 11:30:26 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Tue, 10 Sep 2013 11:30:06 -0700 (PDT)
In-Reply-To: <CAAzoce7MLsNXS0Ra3NZph3Y1eovRf13vUOG54kYqG9=cEoWDOw@mail.gmail.com>
References: <CAAzoce7MLsNXS0Ra3NZph3Y1eovRf13vUOG54kYqG9=cEoWDOw@mail.gmail.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Tue, 10 Sep 2013 11:30:06 -0700
X-Google-Sender-Auth: 8iNVQ3_QVHbP4mivGlHcBdmkpb0
Message-ID: <CADJ9OA-XfyDGcqR=-EPNC0RM=rjC941L3399B_zSsoDJO-L_5A@mail.gmail.com>
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary=047d7b5da81fd91f7f04e60bb23a
Subject: Re: [6tsch] mechanism to config Report
X-BeenThere: 6tsch@ietf.org
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" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2013 18:30:27 -0000

Qin,

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

There are many possible metrics that can be reported (see
https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents). 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".

Thomas

On Tue, Sep 10, 2013 at 7:32 AM, Qin Wang <qinwang@berkeley.edu> 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
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>