Re: [6tsch] report flow contents

<P.Zand@utwente.nl> Wed, 11 September 2013 14:18 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 6301C11E826F for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 07:18:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.097
X-Spam-Level: **
X-Spam-Status: No, score=2.097 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZoY-yETaRAS for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 07:18:38 -0700 (PDT)
Received: from EXEDGE02.ad.utwente.nl (exedge02.ad.utwente.nl [130.89.5.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0A28221F9EDB for <6tsch@ietf.org>; Wed, 11 Sep 2013 07:18:35 -0700 (PDT)
Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE02.ad.utwente.nl (130.89.5.49) with Microsoft SMTP Server (TLS) id 14.2.328.9; Wed, 11 Sep 2013 16:18:37 +0200
Received: from EXMBX23.ad.utwente.nl ([169.254.3.13]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Wed, 11 Sep 2013 16:18:34 +0200
From: <P.Zand@utwente.nl>
To: <watteyne@eecs.berkeley.edu>, <xvilajosana@eecs.berkeley.edu>
Thread-Topic: [6tsch] report flow contents
Thread-Index: AQHOqmeRdn+u8+L3JUGYWl1pnrYuVpm3azMAgAA2pACAAAP1gIABFasAgAAfWwCAAGmlgIABKJyAgAYvvkA=
Date: Wed, 11 Sep 2013 14:18:33 +0000
Message-ID: <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7B88C@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>
In-Reply-To: <CADJ9OA9OpGRvB1A4j-Byho_m8Zp3z1A5krCVi08U7xWP1Ohk+Q@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="_015_76EA352C3C95BB42A2C4F2EE6493AD6E4DA7B88CEXMBX23adutwent_"
MIME-Version: 1.0
Cc: pthubert@cisco.com, 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 14:18:46 -0000

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:image021.png@01CEAF0A.8DEEBC10] (Percentage of time transmissions on channel 0 did not receive an ACK)


4


Integer-8


[cid:image022.png@01CEAF0A.8DEEBC10] (Percentage of time transmissions on channel 0 aborted due to CCA)


...








33


Integer-8


[cid:image023.png@01CEAF0A.8DEEBC10] (Percentage of time transmissions on channel 15 did not receive an ACK)


34


Integer-8


[cid:image024.png@01CEAF0A.8DEEBC10] (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:image025.png@01CEAF0A.8DEEBC10] address


0-1


Signed-8


[cid:image026.png@01CEAF0A.8DEEBC10]


0-1


Unsigned-8


[cid:image027.png@01CEAF0A.8DEEBC10]


...








0-2


ExtDlUint


[cid:image028.png@01CEAF0A.8DEEBC10] address


0-1


Signed-8


[cid:image029.png@01CEAF0A.8DEEBC10]


0-1


Unsigned-8


[cid:image030.png@01CEAF0A.8DEEBC10]




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<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