Re: [6tsch] report flow contents

Qin Wang <qinwang@berkeley.edu> Fri, 13 September 2013 14:55 UTC

Return-Path: <qinwang@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 5E09F11E81F2 for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 07:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=x tagged_above=-999 required=5 tests=[]
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 SAwUA5TD2PuI for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 07:55:04 -0700 (PDT)
Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEF111E8180 for <6tsch@ietf.org>; Fri, 13 Sep 2013 07:55:03 -0700 (PDT)
Received: by mail-ie0-f171.google.com with SMTP id at1so2805192iec.30 for <6tsch@ietf.org>; Fri, 13 Sep 2013 07:55:03 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=upU1Etc4Vu9gATgWk/G6llYSqs4sjBiArxhd9MVEUlk=; b=WXrZKA/+I9h+UFOP6qUJ0SEuEASjFSJsWeBGB64IEHugo/LiRQQJNvBWjvnV8WhSbV mh6erf1ELwI5T03xLSB1/Ll1zIFi671XLNkJpPyg0JufEMkDkKX++4elCbN4uuyuNool muZiJES5PvziV/4sTdfKk3TiSrLyK6y3/chx/mO17pDJkhAANQIRuCOM60uLk0bbP3ki 0OOQ1ToBELHDsXqZm5hYVLCFZnBn3p4BrcvJaJinSYWceQkW2iS6Jyke3zsFVL5+hXxP 2TUu7Xm9r37FYlRWgjdcc6BMx+pfWr1icW1uQ8eK8pXdjewcm+vimFqqTH2WuBXRohNH INaw==
X-Gm-Message-State: ALoCoQnSFVz0/x9Y+Sqzjb6kSYU8lbKZK/bwFKb80/nvJo++4LkrKeg0ZIxLQleC8PdHkHQNeakh
MIME-Version: 1.0
X-Received: by 10.50.73.41 with SMTP id i9mr1502157igv.30.1379084103002; Fri, 13 Sep 2013 07:55:03 -0700 (PDT)
Received: by 10.64.139.234 with HTTP; Fri, 13 Sep 2013 07:55:02 -0700 (PDT)
In-Reply-To: <CAH7SZV9-KaAiWOGxstDX3j5exL2EUC=4O_-pfm6tJMwe3kYOhA@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> <CALEMV4b4rfoLBWSOW8=wWR2xWy32V_uCXEzJ=5vaebL6g+LpbQ@mail.gmail.com> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7BC47@EXMBX23.ad.utwente.nl> <52316e72.c7380f0a.73cf.ffffc7a5@mx.google.com> <CADJ9OA9p2jihyn_o2XtLi7X7EBRQFMEADFjW8upKzgD70h3WOg@mail.gmail.com> <CAAzoce4Up5ar80n-1zr-Opq10QOBVDcvNApBBgPKr+g6UjDENw@mail.gmail.com> <CAH7SZV9-KaAiWOGxstDX3j5exL2EUC=4O_-pfm6tJMwe3kYOhA@mail.gmail.com>
Date: Fri, 13 Sep 2013 22:55:02 +0800
Message-ID: <CAAzoce7FBnDhmAp=00DLmOtipDtJADQc16RCr9JGRxrpeTGXFQ@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Content-Type: multipart/related; boundary=089e013a0270134ad604e6450aba
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] report flow contents
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: Fri, 13 Sep 2013 14:55:04 -0000

Hi Diego,

Comparing the per-frequency report with the RSSI/LQI in the per-neighbor
report defined on
https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents, I think the
first one refers to the radio condition in a area, not specific to a
neighbor; and the second one likely focuses on the average  RSSI/LQI of all
frequencies applied in a cell/bundle, not specific to a radio frequency.
Make sense?

Thanks
Qin



On Fri, Sep 13, 2013 at 10:23 PM, Prof. Diego Dujovne <
diego.dujovne@mail.udp.cl> wrote:

> Hello Qin,
>               I think that a per-frequency report will help the PCE
> to decide which frequency to use, and maybe temporarily
> black-list them. For example, a dynamic scheme may include
> sampling the blacklisted frequencies every X minutes to re-enable
> them once the interference has disappeared.
>              This will require the node to refresh the RSSI
> and LQI values in a opportunistic way (every time the a cell
> uses that frequency) to save energy.
>
> Any thoughts?
>
>                             Diego
>
>
>
>
>
> 2013/9/13 Qin Wang <qinwang@berkeley.edu>
>
>> Hi Thomas and All,
>>
>> I think the per-frequency report (or called per-channel report in
>> ISA100.11a) is important, because PCE can use it to build black frequency
>> list and update channel hopping sequence. But, I'm not sure if it makes
>> implementation too complex or not.
>>
>> Thought?
>>
>> Qin
>>
>>
>> On Fri, Sep 13, 2013 at 8:48 AM, Thomas Watteyne <
>> watteyne@eecs.berkeley.edu> wrote:
>>
>>> Pouria,
>>> Thanks again for the overview, which complements your first document
>>> nicely.
>>>
>>>  Alfredo,
>>> Could you please elaborate what you mean by in-network processing? Are
>>> you referring to a distributed way for the nodes to "consume" this data,
>>> some fusion as the data trickles up the DAG, or something else?
>>>
>>> Thomas
>>>
>>>
>>> On Thu, Sep 12, 2013 at 12:34 AM, Alfredo Grieco <
>>> alfredo.grieco@gmail.com> wrote:
>>>
>>>> Hi All,****
>>>>
>>>> ** **
>>>>
>>>> Do you think is it feasible to add a bit/flag that allows some form of
>>>> in-network processing ? ****
>>>>
>>>> ** **
>>>>
>>>> This would be very useful to distributed/decentralized scheduling
>>>> techniques and should not cost that much.****
>>>>
>>>> ** **
>>>>
>>>> Any thoughts is welcome.****
>>>>
>>>> ** **
>>>>
>>>> Cheers****
>>>>
>>>> ** **
>>>>
>>>> Alfredo****
>>>>
>>>> ** **
>>>>
>>>> *Da:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *Per
>>>> conto di *P.Zand@utwente.nl
>>>> *Inviato:* Wednesday, September 11, 2013 10:45 PM
>>>> *A:* xvilajosana@eecs.berkeley.edu; watteyne@eecs.berkeley.edu
>>>> *Cc:* 6tsch@ietf.org
>>>> *Oggetto:* Re: [6tsch] report flow contents****
>>>>
>>>> ** **
>>>>
>>>> Thomas,****
>>>>
>>>> I agree with you that "source route failed" and "graph route failed"
>>>> are out of scope of 6TiSCH.****
>>>>
>>>> Regarding to you question about the per-channel report, I think they
>>>> are based on each radio channel supported by the specification (channel
>>>> 11-26 in 2.4GHz in IEEE 802.15.4), not channel offset. And a channel report
>>>> generated for all neighbor.****
>>>>
>>>> Regarding to your first question, let me now explain more. I think both
>>>> of these standard provide a mechanisms to make it possible for
>>>> System/Network Manager to also read (pull) desired attributes (But not all
>>>> the feature in 6TiSCH). For example in WirelessHART [1], by “Report
>>>> Neighbor Health List” request, the network manager might mention the number
>>>> of neighbors to be read in “Number of Neighbor entries read” field.. **
>>>> **
>>>>
>>>> I think, ISA100.11a provides more mechanisms for System manager to get
>>>> the desired attributes from the field devices. And the first two features
>>>> that you mentioned might also be supported by ISA100.11a.****
>>>>
>>>> In ISA100.11a, three mechanisms are provided for reporting diagnostic
>>>> information contained in dlmo.NeighborDiag (described in section 1 later)
>>>> and dlmo.ChannelDiag (described in Section 2 later):****
>>>>
>>>>    1. The health reports concentrator object (HRCO), can be configured
>>>>    to report any attribute in the DL *on a* *periodic basis*.
>>>>    dlmo.NeighborDiag entries (shown in Table 2) and dlmo.ChannelDiag (shown in
>>>>    Table 5) can be reported through that mechanism. Through the HRCO, the
>>>>    system manager can configure the device to report NeighborDiag
>>>>    periodically, such as every 30 minutes. Following each such report, on a
>>>>    per-entry basis, NeighborDiag counts shall be reset to zero. Levels shall
>>>>    use the current value as a starting point for the next period [2].**
>>>>    **
>>>>    2. Diagnostic information can be retrieved at any time by the
>>>>    system manager, by reading the applicable attributes. The system manager
>>>>    can read (poll) NeighborDiag as a read-only attribute *on a
>>>>    per-entry basis*. As in an HRCO report, counts shall be reset to
>>>>    zero when read [2].****
>>>>    3. Diagnostic information can be reported by the DL on *an
>>>>    exception basis*, through the DL_Connectivity alert (Described in
>>>>    section 3(a)). The DL can additionally be configured, through the
>>>>    dlmo.AlertPolicy attribute (shown in Table 6), to report NeighborDiag
>>>>    information when diagnostic values exceed a threshold. Only the row
>>>>    triggering the alert is reported. No values are reset [2]. ****
>>>>
>>>> ** **
>>>>
>>>> In ISA100.11a, the system manager establishes a DL communication
>>>> relationship between a device and its neighbor by adding an entry to the
>>>> device’s dlmo.Neighbor attribute (see Table 1). Each such entry specifies a
>>>> level of diagnostics to be collected, through the field
>>>> dlmo.Neighbor[].DiagLevel. For each neighbor, diagnostics may be collected
>>>> at a baseline level, or a detailed level including clock diagnostics [2].
>>>> This levels are described in Section 1.****
>>>>
>>>> *Table **1. dlmo.Neighbor fields [2]*
>>>>
>>>> *Field name*
>>>>
>>>> *Field encoding*
>>>>
>>>> * Index (16-bit address of neighbor)****
>>>>
>>>> ExtDlUint (used as an index)****
>>>>
>>>> EUI64 (EUI-64 identifier of the neighbor)****
>>>>
>>>> Type: Unsigned64****
>>>>
>>>> …****
>>>>
>>>> …****
>>>>
>>>> *DiagLevel* (selection of neighbor diagnostics to collect)****
>>>>
>>>> Type: Unsigned2****
>>>>
>>>> Bit0 = 1 Collect link diagnostics****
>>>>
>>>> Bit1 = 1 Collect clock diagnostics****
>>>>
>>>> …****
>>>>
>>>> …****
>>>>
>>>> ** **
>>>>
>>>> When the dlmo.Neighbor[].DiagLevel field is set for a particular
>>>> neighbor, the DL shall create corresponding entries in the read-only
>>>> attribute dlmo.NeighborDiag. NeighborDiag values are accumulated from the
>>>> time that the dlmo.NeighborDiag entry is created [2].****
>>>>
>>>> ***1.      ****dlmo.NeighborDiag:*
>>>>
>>>> dlmo.NeighborDiag is an indexed OctetString collection that contains
>>>> diagnostics for a set of neighbors. The attribute is read-only, with rows
>>>> created as needed by the DL [2].****
>>>>
>>>> NeighborDiag entries are instantiated by the system manager, by setting
>>>> dlmo.Neighbor[].DiagLevel bits to non-zero values. Iff (if and only if)
>>>> Bit0=1, then summary diagnostics shall be collected for the neighbor,
>>>> consolidated across all channels. Iff Bit1=1, then detailed clock
>>>> diagnostics shall be collected for the neighbor, consolidated across all
>>>> radio channels [2].****
>>>>
>>>> *Table **2. dlmo.NeighborDiag fields [2]*
>>>>
>>>> Field name****
>>>>
>>>> Field encoding****
>>>>
>>>> * Index****
>>>>
>>>> Type: ExtDlUint (neighbor address, used as an index)****
>>>>
>>>> *Summary*
>>>>
>>>> Type: OctetString (see Table 3)****
>>>>
>>>> *ClockDetail*
>>>>
>>>> Type: OctetString (see Table 4)****
>>>>
>>>> ** **
>>>>
>>>> *Table **3. Diagnostic Summary OctetString fields [2]*
>>>>
>>>> Field name****
>>>>
>>>> Field encoding****
>>>>
>>>> RSSI (level)****
>>>>
>>>> Type: Integer8****
>>>>
>>>> RSQI (level)****
>>>>
>>>> Type: Unsigned8****
>>>>
>>>> RxDPDU (count)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> TxSuccessful (count)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> TxFailed (count)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> TxCCA_Backoff (count)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> TxNACK (count)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> ClockSigma (level)****
>>>>
>>>> Type: Integer16****
>>>>
>>>> ** **
>>>>
>>>> *Table **4. Diagnostic ClockDetail OctetString fields [2]*
>>>>
>>>> Field name****
>>>>
>>>> Field encoding****
>>>>
>>>> ClockBias (level, signed)****
>>>>
>>>> Type: Integer16****
>>>>
>>>> ClockCount (count)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> ClockTimeout (count)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> ClockOutliers (count)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> ** **
>>>>
>>>> **2.      ***dlmo.ChannelDiag*:****
>>>>
>>>> dlmo.ChannelDiag is a read-only dynamic attribute that reports DPDU
>>>> transmit failure rates on each radio channel supported by the
>>>> specification. This enables the system manager to be aware of consistent
>>>> connectivity problems on a per-channel basis, as a diagnostic for spectrum
>>>> management in a subnet [2].****
>>>>
>>>> Two diagnostics are reported for each channel, each indicating a
>>>> different type of failure. **** indicates the percentage of time that
>>>> unicast DPDU transmissions on channel N did not receive an ACK or a NACK.
>>>> **** indicates the percentage of time that unicast DPDU transmissions
>>>> on channel N were aborted due to CCA. [2]****
>>>>
>>>> *Table **5. dlmo.ChannelDiag fields*
>>>>
>>>> Field name****
>>>>
>>>> Field encoding****
>>>>
>>>> Count (Number of attempted unicast transmissions for all channels)****
>>>>
>>>> Type:Unsigned16****
>>>>
>>>> **** (Percentage of time transmissions on channel 0 did not receive an
>>>> ACK)****
>>>>
>>>> Type: Integer8****
>>>>
>>>> **** (Percentage of time transmissions on channel 0 aborted due to CCA)
>>>> ****
>>>>
>>>> Type: Integer8****
>>>>
>>>> …****
>>>>
>>>> ** **
>>>>
>>>> **** (Percentage of time transmissions on channel 15 did not receive
>>>> an ACK)****
>>>>
>>>> Type: Integer8****
>>>>
>>>> **** (Percentage of time transmissions on channel 15 aborted due to
>>>> CCA)****
>>>>
>>>> Type: Integer8****
>>>>
>>>> ** **
>>>>
>>>> ***3.      ****Data link layer alerts*
>>>>
>>>>    1. *DL_Connectivity alert*
>>>>
>>>> DL performance diagnostics are accumulated in the attributes
>>>> dlmo.NeighborDiag for *per-neighbor* diagnostics, and dlmo.ChannelDiag
>>>> for *per-channel* diagnostics. Normally the system manager configures
>>>> the HRCO to report these diagnostics periodically, and the DL automatically
>>>> resets the diagnostic counters whenever these attributes are so reported.
>>>> Between such reports, diagnostics may indicate a problem that needs to be
>>>> reported to the system manager immediately. The DL_Connectivity alert
>>>> provides the mechanism for the DL to report such issues, and the
>>>> dlmo.AlertPolicy attribute enables the system manager to set thresholds for
>>>> such reporting [2].****
>>>>
>>>> The attribute dlmo.AlertPolicy enables/disables the DL_Connectivity
>>>> alert and provides thresholds to control whether alerts are reported.
>>>> dlmo.AlertPolicy is an OctetString containing fields as shown in Table 6
>>>> [2].****
>>>>
>>>> *Table **6. dlmo.AlertPolicy fields*
>>>>
>>>> Field name****
>>>>
>>>> Field scalar type****
>>>>
>>>> Descriptor (Enables or disabled the DL_Connectivity alert.)****
>>>>
>>>> Type Alert report descriptor****
>>>>
>>>> NeiMinUnicast (Minimum number of unicast transactions needed for a
>>>> neighbor report.)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> NeiErrThresh (Report neighbor diagnostic if the percentage error rate
>>>> reaches this threshold )****
>>>>
>>>> Type: Unsigned8****
>>>>
>>>> ChanMinUnicast (Minimum number of unicast transactions on a channel
>>>> needed as a pre-condition for triggering an alert.)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> NoAckThresh (Report ChannelDiag if a NoAck value is greater than this
>>>> threshold)****
>>>>
>>>> Type: Unsigned8****
>>>>
>>>> CCABackoffThresh (Report ChannelDiag if a CCABackoff value is greater
>>>> than this threshold)****
>>>>
>>>> Type: Unsigned8****
>>>>
>>>> ** **
>>>>
>>>>    1. *NeighborDiscovery alert***
>>>>
>>>> The NeighborDiscovery alert provides a mechanism for the DL to report
>>>> the contents of the OctetString in dlmo.Candidates attribute (see Table 7).
>>>> ****
>>>>
>>>> The neighbors in the dlmo.Neighbor attribute are set by the system
>>>> manager, not by the device itself. The DL autonomously builds a list of
>>>> candidate neighbors in the dlmo.Candidates attribute. This list is then
>>>> forwarded to the system manager. The system manager considers the radio
>>>> connectivity that is reported in dlmo.Candidates, but may also consider
>>>> other criteria such as resource constraints, historical performance, or
>>>> subnet topology [2].****
>>>>
>>>> *Table **7. dlmo.Candidates OctetString fields*
>>>>
>>>> Field name****
>>>>
>>>> Field encoding****
>>>>
>>>> N (count of discovered neighbors)****
>>>>
>>>> Type: Unsigned8****
>>>>
>>>> Neighbor1 (16-bit address of first candidate)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> RSSI1 (radio signal quality of first candidate)****
>>>>
>>>> Type: Integer8****
>>>>
>>>> RSQI1 (radio signal quality of first candidate)****
>>>>
>>>> Type: Unsigned8****
>>>>
>>>> etc…****
>>>>
>>>> ** **
>>>>
>>>> NeighborN (16-bit address of Nth candidate)****
>>>>
>>>> Type: ExtDlUint****
>>>>
>>>> RSSIN (radio signal quality of Nth candidate)****
>>>>
>>>> Type: Integer8****
>>>>
>>>> RSQIN (radio signal quality of Nth candidate)****
>>>>
>>>> Type: Unsigned8****
>>>>
>>>> ** **
>>>>
>>>> *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 *Xavier Vilajosana Guillen
>>>> *Sent:* Wednesday, September 11, 2013 8:54 PM
>>>> *To:* Thomas Watteyne
>>>> *Cc:* 6TSCH
>>>> *Subject:* Re: [6tsch] report flow contents****
>>>>
>>>> ** **
>>>>
>>>> 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****
>>>>
>>>> ** **
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
>
> --
> DIEGO DUJOVNE
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> www.ingenieria.udp.cl
> (56 2) 676 8125
>