Re: [6tsch] report flow contents

Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu> Wed, 11 September 2013 18:54 UTC

Return-Path: <xvilajosana@berkeley.edu>
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 5EF6511E8105 for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 11:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.176
X-Spam-Level:
X-Spam-Status: No, score=-1.176 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_50=0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 0EEvqp9PdlZk for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 11:54:23 -0700 (PDT)
Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 038A111E8100 for <6tsch@ietf.org>; Wed, 11 Sep 2013 11:54:22 -0700 (PDT)
Received: by mail-pa0-f46.google.com with SMTP id fa1so14123pad.5 for <6tsch@ietf.org>; Wed, 11 Sep 2013 11:54:22 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=BIa5Y5RBhNZG/lsAaXJ/CMskaSGYud5QkP0OJFyxUfk=; b=O7o5po/8gdLYoSy2x8w40RnZP6ShqY+pmZogRA9sfTEuMo6pG8nWnMzhBaXmzWESj3 zUbbuf92m/U8CsnpPiEschRdTuVaULXYh0RIffmK6IqvUwNoqzxLUQ2x+g4wmFRwIHPK SQppHfeuUPbpB6dD3KeZK+Xso8N2bwCqbRQ1M6qy7h4HR8y6OX31mnz2aXxbGbUbnXDq 9uCj4FWc1OCS2Gb4041NrdiBoxg5m8Wdxrk8suxHIiinRO0kC7qpwzXXdOx1iD8navmA dDhW6JJ6hA3LcLGBK639kTEFAXMLOqW37N2exzdkpQg0DIEopO3sHlk4UN8UMTS7hDRM pZcg==
X-Gm-Message-State: ALoCoQnGWozz2/MTaK9f1YGSCLKun1z5MQrcYw8TkQji9C/lJRcYowQ2Rnxpmz2+2XFiRi1lapYo
MIME-Version: 1.0
X-Received: by 10.66.27.143 with SMTP id t15mr5226337pag.171.1378925662533; Wed, 11 Sep 2013 11:54:22 -0700 (PDT)
Received: by 10.70.34.44 with HTTP; Wed, 11 Sep 2013 11:54:22 -0700 (PDT)
In-Reply-To: <CADJ9OA9qb6aqyqonEmfZpqt3NHqm5EWPK-p2BAQf9C9sw8Cp3A@mail.gmail.com>
References: <CADJ9OA_XeC7Z5hFxyHhFGqD0aFMcBn=iHzDfRq34sL9qPi2P4A@mail.gmail.com> <CALEMV4YN3rA2OXeAV1akOZhdQrMOQvhN0A+t6vsL9RPVV=VMnQ@mail.gmail.com> <CADJ9OA8Cx3ingeiMdr60zUfMMENiay-Nftv0nMFOTD7=YcKgwg@mail.gmail.com> <CALEMV4ZdgWAFMyA=FtRik96evup-qJPQfTcDQEu99sfC0xFwuQ@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD84145CB61@xmb-rcd-x01.cisco.com> <CALEMV4a=azY5MU00jNmcoek022gS=pUeXK1xVnucG+Zy6NTBOA@mail.gmail.com> <CALEMV4a=DCXV9ra832-5zEtiD7moUmj6GYu7tiosDYsD5v4ObA@mail.gmail.com> <CADJ9OA9OpGRvB1A4j-Byho_m8Zp3z1A5krCVi08U7xWP1Ohk+Q@mail.gmail.com> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7B88C@EXMBX23.ad.utwente.nl> <CADJ9OA9qb6aqyqonEmfZpqt3NHqm5EWPK-p2BAQf9C9sw8Cp3A@mail.gmail.com>
Date: Wed, 11 Sep 2013 11:54:22 -0700
Message-ID: <CALEMV4b4rfoLBWSOW8=wWR2xWy32V_uCXEzJ=5vaebL6g+LpbQ@mail.gmail.com>
From: Xavier Vilajosana Guillen <xvilajosana@eecs.berkeley.edu>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Content-Type: multipart/related; boundary=bcaec52bea1949856304e62026d9
Cc: 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] report flow contents
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: xvilajosana@eecs.berkeley.edu
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: Wed, 11 Sep 2013 18:54:30 -0000

Hi Thomas,

my 5 cents.
I agree on adding NACK information and timing differences with other than
time source parent neighbors. I will add to the wiki :-)

As regards to the differences of what we do at 6TiSCH and WHart or
ISA100.11a, our proposal is more flexible and has less cohesion with a cost
of increased complexity (e.g configurable data and reporting period). We
have to analyse carefully what are the implications in terms of protocol
complexity and implementation of that mechanism versus how often they would
be used. Could we maybe define some "templates" or default configurations
so using the 6TiSCH can be done without configuration overhead? Then
configuration can be used for those that are really interested on tuning
their system.

just thoughts..
X



On Wed, Sep 11, 2013 at 9:58 AM, Thomas Watteyne <watteyne@eecs.berkeley.edu
> wrote:

> Pouria,
>
> Wonderful list.
>
> Your document clearly highlights that (1) the "report" flows both in
> WirelessHART and ISA100.11a are strictly periodic and (1) they have a fixed
> format. From what we have discussed so far, the solutions we are developing
> is different in the following ways:
>
>    - 6TiSCH offers a mechanism allowing the PCE to configure what data it
>    want to receive, and configure the trigger for a node to generate from data.
>    - 6TiSCH offers a mechanism allowing the PCE to query the data, on top
>    of having the nodes push the information
>    - In 6TiSCH, the format of the payload is not fixed. In particular, it
>    is possible to add application-specific fields, allowing for extensions.
>    - In 6TiSCH, the transport (CoAP?) and formatting (CBOR?) are
>    IETF-friendly and integrate well in the IPv6 stack and associated mechanisms
>
> Did I get that right?
>
> A couple of questions:
>
>    - the WirelessHART "alarms" correspond to a 6TiSCH "events". Yet, I
>    suppose that a "source route failed" and "graph route failed" are out of
>    scope of 6TiSCH, but rather part of RPL. I would expect those to the ICMPv6
>    messages. Thoughts?
>    - About the per-channel report, I assume this is "per frequency",
>    right? Is a channel report generated for each neighbor?
>    - When comparing your list to *Xavi*'s
>    https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents:
>       - we might want to add a "numNACK" counter to the neighbor
>       information
>       - we might want to keep timing statistics for all neighbors, not
>       just time source parents. That is, when I receive a packet from a neighbor
>       which is not my time source neighbor, I do not change my clock, but I still
>       know the timing error.
>
> Thomas
>
> On Wed, Sep 11, 2013 at 7:18 AM, <P.Zand@utwente.nl> wrote:
>
>>  Dear All,****
>>
>> In the following, I listed the performance metrics reported to the
>> Network/System Manager in WirelessHART and ISA100.11a.****
>>
>> Some reports still need be added, for example the path failure alerts in
>> ISA100.11a.****
>>
>> Pouria****
>>
>> ** **
>>
>> *WirelessHART performance metrics*
>>
>> In WirelessHART[1] network the statistics and events are reported to the
>> Network Manager (act like PCE in 6TiSCH) through the following commands:*
>> ***
>>
>>    1. Report “Device Health” ****
>>
>>  This report is sent periodically toward the Network Manager. The report
>> summaries the communication statistics of a device.****
>>
>> Byte****
>>
>> Format****
>>
>> Description****
>>
>> 0-1****
>>
>> Unsigned-16****
>>
>> Number of packets generated by this device since last report****
>>
>> 2-3****
>>
>> Unsigned-16****
>>
>> Number of packets terminated by this device since last report****
>>
>> 4****
>>
>> Unsigned-8****
>>
>> Number of Data-Link Layer MAC MIC failures detected****
>>
>> 5****
>>
>> Unsigned-8****
>>
>> Number of Network Layer (Session) MIC failures detected****
>>
>> 6****
>>
>> Enum-8****
>>
>> Power Status****
>>
>> 7****
>>
>> Unsigned-8****
>>
>> Number of CRC Errors detected****
>>
>> ** **
>>
>>    1. Report “Neighbor Health List” ****
>>
>>  This report is sent periodically toward the Network Manager. The report
>> includes the statistics of linked neighbors.****
>>
>> Byte****
>>
>> Format****
>>
>> Description****
>>
>> 0****
>>
>> Unsigned-8****
>>
>> Neighbor table index****
>>
>> 1****
>>
>> Unsigned-8****
>>
>> Number of Neighbor entries read****
>>
>> 2****
>>
>> Unsigned-8****
>>
>> Total number of neighbors****
>>
>> 3-4****
>>
>> Unsigned-16****
>>
>> Nickname of neighbor****
>>
>> 5****
>>
>> Bit-8****
>>
>> Neighbor Flags****
>>
>> 6****
>>
>> Signed-8****
>>
>> Mean RSL (Receive Signal Level in dBm) since last report****
>>
>> 7-8****
>>
>> Unsigned-16****
>>
>> Number of Packets transmitted to this neighbor****
>>
>> 9-10****
>>
>> Unsigned-16****
>>
>> Number of Packets received from this neighbor****
>>
>> 11-12****
>>
>> Unsigned-16****
>>
>> Packets received from this neighbor****
>>
>> 13-…****
>>
>> ** **
>>
>> Number of entries based on response byte 1****
>>
>> ** **
>>
>>    1. Report “Neighbor Signal Levels”****
>>
>>  This report is sent periodically toward the Network Manager. The report
>> includes the statistics of discovered (but not linked) neighbors. These
>> neighbors might be discovered when a device has heard the neighbor
>> communication in the discovery links. A device that wish to join a network,
>> send a join request to the Network manager, including this report.****
>>
>> Byte****
>>
>> Format****
>>
>> Description****
>>
>> 0****
>>
>> Unsigned-8****
>>
>> Neighbor table index****
>>
>> 1****
>>
>> Unsigned-8****
>>
>> Number of Neighbor entries read****
>>
>> 2****
>>
>> Unsigned-8****
>>
>> Total number of neighbors****
>>
>> 3-4****
>>
>> Unsigned-16****
>>
>> Nickname of neighbor****
>>
>> 5****
>>
>> Signed-8****
>>
>> RSL of neighbor in dB****
>>
>> 6-8****
>>
>> ** **
>>
>> Repeats (as needed) based on response byte 1****
>>
>> ** **
>>
>>    1. Alarm “Path Down” ****
>>
>>  The alarm is sent upon detecting a path failure. ****
>>
>> Byte****
>>
>> Format****
>>
>> Description****
>>
>> 0-1****
>>
>> Unsigned-16****
>>
>> Nickname of neighbor to which path failure was detected****
>>
>> ** **
>>
>>    1. Alarm "Source Route Failed"****
>>
>>  This alarm is sent upon detecting a source route failure.****
>>
>> Byte****
>>
>> Format****
>>
>> Description****
>>
>> 0-1****
>>
>> Unsigned-16****
>>
>> Nickname of unreachable neighbor in the source route****
>>
>> 2-5****
>>
>> Unsigned-32****
>>
>> Network-Layer MIC (i.e., the MIC generated using the session key) from
>> the NPDU that failed routing****
>>
>> ** **
>>
>>    1. Alarm "Graph Route Failed"****
>>
>>  This alarm is sent upon detecting a graph route failure.****
>>
>> Byte****
>>
>> Format****
>>
>> Description****
>>
>> 0-1****
>>
>> Unsigned-16****
>>
>> Graph Id of the failed route****
>>
>> ** **
>>
>>  ** **
>>
>> *ISA100.11a performance metric*
>>
>> In ISA100.11a[2], the L2 performance metrics are reported to the System
>> Manager (act like PCE in 6TiSCH) and can be classified into (1)
>> DL_Connectivity alert and (2) NeighborDiscovery alert.****
>>
>>    1. DL_Connectivity alert****
>>
>>  The DL_connectivity alert can be classified into (a) Per-neighbor
>> reports and (b) Per-channel reports. ****
>>
>>     - *Per-neighbor report*
>>
>>  Per-neighbor reports are the  performance metrics about the neighbors
>> connection and are reported to the System Manager. These statistics are
>> accumulated in the “dlmo.NeighborDiag” attribute, for each neighbor. This
>> report is similar to “Neighbor Health List” report in WirelessHART. ****
>>
>> Each node in ISA100.11a might be asked to report the following statistics
>> about its neighbor:****
>>
>> ** **
>>
>> Octets****
>>
>> Format****
>>
>> Description****
>>
>> 1****
>>
>> Signed-8****
>>
>> RSSI (level)****
>>
>> 1****
>>
>> Unsigned-8****
>>
>> RSQI (level)****
>>
>> 1-2****
>>
>> ExtDLUint****
>>
>> RxDPDU(count): Number of valid Packets received from this neighbor ****
>>
>> 1-2****
>>
>> ExtDLUint****
>>
>> TxSuccessful (count):Count of successful unicast transmissions to the
>> neighbor ****
>>
>> 1-2****
>>
>> ExtDLUint****
>>
>> TxFailed (count): Number of unicast transmission, without  getting any
>> ACK or NACK****
>>
>> 1-2****
>>
>> ExtDLUint****
>>
>> TxCCA_Backoff (count): Number of unicast transmission aborted due to CCA*
>> ***
>>
>> 1-2****
>>
>> ExtDLUint****
>>
>> TxNACK (count): Number of NACKs received****
>>
>> 2****
>>
>> Signed-16****
>>
>> ClockSigma (level): A rough estimate of standard deviation of clock
>> corrections****
>>
>> ** **
>>
>>     - *Per-channel report*
>>
>>  In addition, in ISA100.11a, several performance metrics are reported
>> based on channel for all neighbors to the System Manager. These statistics
>> are accumulated in the “dlmo.ChannelDiag” attribute. This report is similar
>> to “Device Health” report in WirelessHART.****
>>
>> Byte****
>>
>> Format****
>>
>> Description****
>>
>> 0-2****
>>
>> Unsigned-16****
>>
>> Count (Number of attempted unicast transmissions for all channels)****
>>
>> 3****
>>
>> Integer-8****
>>
>> **** (Percentage of time transmissions on channel 0 did not receive an
>> ACK)****
>>
>> 4****
>>
>> Integer-8****
>>
>> **** (Percentage of time transmissions on channel 0 aborted due to CCA)**
>> **
>>
>> …****
>>
>> ** **
>>
>> ** **
>>
>> 33****
>>
>> Integer-8****
>>
>> **** (Percentage of time transmissions on channel 15 did not receive an
>> ACK)****
>>
>> 34****
>>
>> Integer-8****
>>
>> **** (Percentage of time transmissions on channel 15 aborted due to CCA)*
>> ***
>>
>> ** **
>>
>>    1. NeighborDiscovery alert****
>>
>>  In ISA100.11a, each node sends a report, including a list of candidate
>> (overheard) neighbors, to the System Manager to make a potential new
>> routing decisions. The “dlmo.Candidates” attributed is used to store those
>> information in each node in the L2. This report is similar to the “Neighbor
>> Signal Levels” report in WirelessHART.****
>>
>> Octets****
>>
>> Format****
>>
>> Description****
>>
>> 1****
>>
>> Unsigned-8****
>>
>> N (count of discovered neighbors)****
>>
>> 0-2****
>>
>> ExtDlUint****
>>
>> **** address****
>>
>> 0-1****
>>
>> Signed-8****
>>
>> **** ****
>>
>> 0-1****
>>
>> Unsigned-8****
>>
>> ********
>>
>> …****
>>
>> ** **
>>
>> ** **
>>
>> 0-2****
>>
>> ExtDlUint****
>>
>> **** address****
>>
>> 0-1****
>>
>> Signed-8****
>>
>> **** ****
>>
>> 0-1****
>>
>> Unsigned-8****
>>
>> ********
>>
>> ** **
>>
>> * *
>>
>> *References*
>>
>> **1.       **IEC 62591: Industrial Communication Networks - Wireless
>> Communication Network and Communication Profiles - WirelessHART.****
>>
>> ** **
>>
>> **2.       **IEC 62734: Industrial communication networks - Fieldbus
>> specifications - Wireless systems for industrial automation: process
>> control and related applications - ISA100.11a.****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On
>> Behalf Of *Thomas Watteyne
>> *Sent:* Saturday, September 07, 2013 7:43 PM
>> *To:* Xavi Vilajosana
>> *Cc:* Pascal Thubert (pthubert); 6tsch@ietf.org
>> *Subject:* Re: [6tsch] report flow contents****
>>
>> ** **
>>
>> Xavi,****
>>
>> Great, thanks!****
>>
>> Thomas****
>>
>> ** **
>>
>> On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen <
>> xvilajosana@eecs.berkeley.edu> wrote:****
>>
>> Hi,
>> I created the scratchpad section in the wiki to keep ideas
>> https://bitbucket.org/6tsch/meetings/wiki/Home
>>
>>
>> and added the flow content information here.
>>
>> https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents****
>>
>> have a nice weekend!****
>>
>> X****
>>
>> ** **
>>
>> On Fri, Sep 6, 2013 at 10:43 AM, Xavier Vilajosana Guillen <
>> xvilajosana@eecs.berkeley.edu> wrote:****
>>
>> Hi Pascal, it is a good idea!****
>>
>> I will collect that information and as Thomas put it at the wiki so we do
>> not lose it.
>>
>> :-)****
>>
>> X****
>>
>> ** **
>>
>> On Fri, Sep 6, 2013 at 8:51 AM, Pascal Thubert (pthubert) <
>> pthubert@cisco.com> wrote:****
>>
>>  Hello Xavi:****
>>
>>  ****
>>
>> At the call I mentioned we could use info on tracks and cells as well,
>> probably on demand from the PCE.****
>>
>> For instance, the PCE could observe energy levels over some cells for  a
>> while to make sure they are clean.****
>>
>>  ****
>>
>> What do you think?****
>>
>> Pascal****
>>
>>  ****
>>
>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On
>> Behalf Of *Xavier Vilajosana Guillen
>> *Sent:* vendredi 6 septembre 2013 01:17
>> *To:* Thomas Watteyne
>> *Cc:* 6tsch@ietf.org
>> *Subject:* Re: [6tsch] report flow contents****
>>
>>  ****
>>
>> agreed!****
>>
>> So the fields become:****
>>
>>  ****
>>
>>  ****
>>
>> For each known neighbor:****
>>
>>  -ID****
>>
>>  -AVG RSSI in a running window****
>>
>>  -Latest RSSI****
>>
>>  -AVG LQI in a running window [optional]****
>>
>>  -Latest LQI [optional]****
>>
>>  -Num TX packets (option in case there is communication with that
>> neighbor)****
>>
>>  -Num ACK packets (option in case there is communication with that
>> neighbor)****
>>
>>  -Num RX packets (option in case there is communication with that
>> neighbor)****
>>
>>  -Last ASN when it heart about that neighbor ****
>>
>>  -Bundle: Num links in the Schedule to that neighbor****
>>
>>       -PDR per link [Optional -- or maybe best and worst PDR only]****
>>
>>  ****
>>
>>  -Option Flag (weather there are optional TLV fields on that category)***
>> *
>>
>>    +(TLV objects)* ****
>>
>>  ****
>>
>>  -For each Queue:****
>>
>>     - Avg Queue length in a running window****
>>
>>     - Max Queue length in a running window (peak)****
>>
>>     - Current Queue length (?)****
>>
>>     - ASN of the oldest packet in the QUEUE?****
>>
>>     -Option Flag (weather there are optional TLV fields on that category)
>> ****
>>
>>         +(TLV objects)* ****
>>
>>  ****
>>
>> -Time source parent****
>>
>>     -ID****
>>
>>     -Avg clock drift (correction done) in a running window****
>>
>>     -Latest clock correction****
>>
>>     -Parent changes (counter of how many times I changed my time source
>> parent)****
>>
>>     -Option Flag (weather there are optional TLV fields on that category)
>> ****
>>
>>     +(TLV objects)* ****
>>
>>  ****
>>
>> -Option Flag (weather there are optional TLV fields in other categories)*
>> ***
>>
>>    +(TLV objects)* ****
>>
>>  ****
>>
>> as regards to this:****
>>
>>  ****
>>
>> "Finally, do you envision a generic mechanism whereby the PCE can turn
>> fields on/off, or triggered independently?"****
>>
>>  ****
>>
>> I see it as CoAP Options, where a set of bytes can be used as "clever
>> bitmap" to tell what options are there, the parsing will decode option by
>> option and will read the fields. In that way any combination of fields is
>> supported.****
>>
>>  ****
>>
>> would that work?****
>>
>> X****
>>
>>  ****
>>
>> On Thu, Sep 5, 2013 at 4:03 PM, Thomas Watteyne <
>> watteyne@eecs.berkeley.edu> wrote:****
>>
>> Xavi,****
>>
>>  ****
>>
>> Fantastic!****
>>
>>  ****
>>
>> I believe PDR for each link might be too long to fit in a packet. While
>> the mote will most likely keep that information, we could move that to the
>> query flow, i.e. it is available to the PCE on-demand.****
>>
>>  ****
>>
>> Would you agree that the number of links in a bundle belongs to the
>> neighbor? Of maybe we want a "bundle" category?****
>>
>>  ****
>>
>> In queuing, it might be interesting to see the age of the different
>> packets, to be able to monitor latency.****
>>
>>  ****
>>
>> About LQI, there is no general consensus among vendors on what the
>> definition is, or how exactly it is calculated. I would make it optional.
>> ****
>>
>>  ****
>>
>> Also, it might be good to be able to add arbitrary fields to each
>> category: neighbor, queue, time source neighbor.****
>>
>>  ****
>>
>> Finally, do you envision a generic mechanism whereby the PCE can turn
>> fields on/off, or triggered independently?****
>>
>>  ****
>>
>> Thomas****
>>
>>  ****
>>
>> On Thu, Sep 5, 2013 at 12:47 PM, Xavier Vilajosana Guillen <
>> xvilajosana@eecs.berkeley.edu> wrote:****
>>
>> Hi Thomas, Diego,****
>>
>>  ****
>>
>> I agree that LQI should be there as well. I update here the list with
>> Thomas suggestions. ****
>>
>>  ****
>>
>> For each known neighbor:****
>>
>>  -ID****
>>
>>  -AVG RSSI in a running window****
>>
>>  -Latest RSSI****
>>
>>  -AVG LQI in a running window****
>>
>>  -Latest LQI****
>>
>>  -Num TX packets (option in case there is communication with that
>> neighbor)****
>>
>>  -Num ACK packets (option in case there is communication with that
>> neighbor)****
>>
>>  -Num RX packets (option in case there is communication with that
>> neighbor)****
>>
>>  -Last ASN when it heart about that neighbor ****
>>
>>  ****
>>
>> Other fields****
>>
>>  -Num links in the Schedule to that neighbor****
>>
>>     -For each link PDR****
>>
>>  -For each Queue:****
>>
>>     - Avg Queue length in a running window****
>>
>>     - Max Queue length in a running window (peak)****
>>
>>     - Current Queue length (?)****
>>
>> -Time source parent****
>>
>>     -ID****
>>
>>     -Avg clock drift (correction done) in a running window****
>>
>>     -Latest clock correction****
>>
>>     -Parent changes (counter of how many times I changed my time source
>> parent)****
>>
>>  ****
>>
>> -Option Flag (weather there are optional TLV fields)****
>>
>>    +(TLV objects)* ****
>>
>>  ****
>>
>>  ****
>>
>> Hope this makes sense.****
>>
>> cheers!
>> Xavi****
>>
>>  ****
>>
>> On Thu, Sep 5, 2013 at 11:41 AM, Thomas Watteyne <
>> watteyne@eecs.berkeley.edu> wrote:****
>>
>> *[renamed thread]*****
>>
>>  ****
>>
>> Xavi,****
>>
>>  ****
>>
>> A few thoughts:****
>>
>> - the counters (numTx, etc) will only be present for neighbors the node
>> has communicate with, so they should be optional in the packet.****
>>
>> - you have focused on the topological information (which I think is the
>> right one). It might be useful to gather other data related to
>> synchronization or queuing.****
>>
>> - I couldn't agree more with your suggestion to make it extensible. This
>> does mean that we will need to state somewhere that a device need to ignore
>> silently fields it does not understand.****
>>
>>  ****
>>
>> Thomas****
>>
>>  ****
>>
>> On Thu, Sep 5, 2013 at 11:15 AM, Xavier Vilajosana Guillen <
>> xvilajosana@eecs.berkeley.edu> wrote:****
>>
>> Hello, I guess that flows are getting defined and I started to think on
>> the contents of the messages on that flows. Not sure if this is the right
>> time or I am going way far..****
>>
>>  ****
>>
>> According to the previous discussion I assume that the five flows are:***
>> *
>>
>>  ****
>>
>> ME-6TOP - Query Flow****
>>
>> ME-6TOP - Action Flow****
>>
>>  ****
>>
>> 6TOP - ME - Report Flow****
>>
>> 6TOP - ME - Event Flow****
>>
>> 6TOP - ME - Request BW Flow****
>>
>>  ****
>>
>> I'd like to start defining the content of the messages in the Report Flow:
>> ****
>>
>>  ****
>>
>> The Report Flow: has to deal with the information that a node knows and
>> has to be sent to the ME so the ME can compute the schedule among others.
>> Here I list  the information that we can know in a mote and can be used at
>> the ME to compute the schedule (complete please if I miss something)****
>>
>>  ****
>>
>> For each known neighbor:****
>>
>>  -ID****
>>
>>  -AVG RSSI in a running window****
>>
>>  -Latest RSSI****
>>
>>  -Num TX packets****
>>
>>  -Num ACK packets****
>>
>>  -Num RX packets****
>>
>>  -Last ASN when it heart about that neighbor ****
>>
>>  ****
>>
>> Other fields****
>>
>>  -Num links in the Schedule to that neighbor****
>>
>>     -For each link PDR****
>>
>>  ****
>>
>>  ****
>>
>> Then we need to have some TLV like objects that can be used for
>> ad-hoc/naive/other extensions of the reporting process. In that way we
>> don't constraint the implementation of the scheduling alg. to that
>> information.****
>>
>>  ****
>>
>> what do you think?****
>>
>> X****
>>
>>  ****
>>
>> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <qinwang@berkeley.edu> wrote:*
>> ***
>>
>>   Hi all,****
>>
>>  ****
>>
>> In this thread, we will continue the discussion about Confirmation
>> message. Here is some background information.****
>>
>>  ****
>>
>> Context: e.g.****
>>
>>     - node sends a report and want to know if the report is accepted., **
>> **
>>
>>     - ME sends a action request and want to know if/when the action taken.
>> ****
>>
>> Options:****
>>
>>    (1) Nothing****
>>
>>    (2) Rely on transport mechanism (e.g. confirmable CoAP message)****
>>
>>    (3) App-level ACK type****
>>
>>    (4) Use different flow (i.e. action flow)****
>>
>>  ****
>>
>> IMHO, different control flow may have different requirement for
>> confirmation message.****
>>
>>     (1) Action Flow, needs a App-level confirmation, like Succ/Fail****
>>
>>     (2) Query Flow, automatically has the confirmation, i.e. the message
>> packet corresponding to a specific query.****
>>
>>     (3) Report Flow and Event Flow, option (1)-(3) are OK, but I prefer
>> option (1) and (3), i.e. the confirmation message is an option, but if a
>> confirmation message is needed, it should be App-level Ack, instead of
>> transport layer confirmation, which will give 6top more flexibility.****
>>
>>  ****
>>
>> What do you think?****
>>
>>  ****
>>
>> Thanks****
>>
>> Qin****
>>
>>     ****
>>
>>  ****
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch****
>>
>>   ****
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch****
>>
>>  ****
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch****
>>
>>  ****
>>
>>  ****
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch****
>>
>>  ****
>>
>>   ** **
>>
>> ** **
>>
>> ** **
>>
>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>