Re: [6tsch] report flow contents

<P.Zand@utwente.nl> Wed, 11 September 2013 20:45 UTC

Return-Path: <P.Zand@utwente.nl>
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 010DA21E80BB for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 13:45:01 -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 c-UbHxicn4l5 for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 13:45:00 -0700 (PDT)
Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id D1C3921E80CE for <6tsch@ietf.org>; Wed, 11 Sep 2013 13:44:56 -0700 (PDT)
Received: from EXHUB02.ad.utwente.nl (130.89.4.229) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 11 Sep 2013 22:44:56 +0200
Received: from EXMBX23.ad.utwente.nl ([169.254.3.13]) by EXHUB02.ad.utwente.nl ([130.89.4.229]) with mapi id 14.02.0328.009; Wed, 11 Sep 2013 22:44:53 +0200
From: <P.Zand@utwente.nl>
To: <xvilajosana@eecs.berkeley.edu>, <watteyne@eecs.berkeley.edu>
Thread-Topic: [6tsch] report flow contents
Thread-Index: AQHOqmeRdn+u8+L3JUGYWl1pnrYuVpm3azMAgAA2pACAAAP1gIABFasAgAAfWwCAAGmlgIABKJyAgAYvvkCAAA0/AIAAIEEAgAA8AMA=
Date: Wed, 11 Sep 2013 20:44:52 +0000
Message-ID: <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7BC47@EXMBX23.ad.utwente.nl>
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>
In-Reply-To: <CALEMV4b4rfoLBWSOW8=wWR2xWy32V_uCXEzJ=5vaebL6g+LpbQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [130.89.12.149]
Content-Type: multipart/mixed; boundary="_021_76EA352C3C95BB42A2C4F2EE6493AD6E4DA7BC47EXMBX23adutwent_"
MIME-Version: 1.0
Cc: 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: Wed, 11 Sep 2013 20:45:01 -0000

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. [cid:image002.png@01CEAF40.860ADE30]  indicates the percentage of time that unicast DPDU transmissions on channel N did not receive an ACK or a NACK. [cid:image004.png@01CEAF40.860ADE30]  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

[cid:image006.png@01CEAF40.860ADE30] (Percentage of time transmissions on channel 0 did not receive an ACK)

Type: Integer8

[cid:image008.png@01CEAF40.860ADE30] (Percentage of time transmissions on channel 0 aborted due to CCA)

Type: Integer8

...



[cid:image010.png@01CEAF40.860ADE30] (Percentage of time transmissions on channel 15 did not receive an ACK)

Type: Integer8

[cid:image012.png@01CEAF40.860ADE30] (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<mailto: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<mailto: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


[cid:image013.png@01CEAF3E.C7C01310](Percentage of time transmissions on channel 0 did not receive an ACK)


4


Integer-8


[cid:image014.png@01CEAF3E.C7C01310](Percentage of time transmissions on channel 0 aborted due to CCA)


...








33


Integer-8


[cid:image015.png@01CEAF3E.C7C01310](Percentage of time transmissions on channel 15 did not receive an ACK)


34


Integer-8


[cid:image016.png@01CEAF3E.C7C01310](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


[cid:image017.png@01CEAF3E.C7C01310]address


0-1


Signed-8


[cid:image018.png@01CEAF3E.C7C01310]


0-1


Unsigned-8


[cid:image019.png@01CEAF3E.C7C01310]


...








0-2


ExtDlUint


[cid:image020.png@01CEAF3E.C7C01310]address


0-1


Signed-8


[cid:image021.png@01CEAF3E.C7C01310]


0-1


Unsigned-8


[cid:image022.png@01CEAF3E.C7C01310]






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> [mailto: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<mailto: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<mailto: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<mailto: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<mailto: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> [mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch



_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch





_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch










_______________________________________________
6tsch mailing list
6tsch@ietf.org<mailto:6tsch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch