[6tsch] R: report flow contents

"Alfredo Grieco" <alfredo.grieco@gmail.com> Thu, 12 September 2013 07:34 UTC

Return-Path: <alfredo.grieco@gmail.com>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82A0111E8190 for <6tsch@ietfa.amsl.com>; Thu, 12 Sep 2013 00:34:19 -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 YJBXFAu+FKiQ for <6tsch@ietfa.amsl.com>; Thu, 12 Sep 2013 00:34:19 -0700 (PDT)
Received: from mail-ee0-x231.google.com (mail-ee0-x231.google.com [IPv6:2a00:1450:4013:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8E811E817D for <6tsch@ietf.org>; Thu, 12 Sep 2013 00:34:14 -0700 (PDT)
Received: by mail-ee0-f49.google.com with SMTP id d41so5138890eek.36 for <6tsch@ietf.org>; Thu, 12 Sep 2013 00:34:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=q78ozsRK9b5JAt4apY2vm76geczQFCA3WHj3zdHdVAM=; b=iszwI8ePdT6fXV8MAvzjedR5nHYcmC4qXdLhVLMxmo7UvcGADg9onreWF6pzqe0xG+ bdWxXYlhvc9j/jf6w0Ypr6en2VcykCkix1oLLDtoomBitOq3H36m7O0GApVmJVspEKcw C7BM1GRcPlAjtwX/gr2Ax7dUqcJ3JjO/qigT6YhDhuA/CeHt2wYPjVX6C28PQ07/B18g 0x17P5M0GHkPBBlbcRu2Ik+cf8ivNymkJwYg+wMx6jtRoqy9ljQYqXgx8A4NpT7xN1Pg iMlQa8mMk2SXDniqz5OWDwhEDkc1YvHOZnabZoG3lTdOfLT4m62Jh59sK9OJQteyG16V Oadg==
X-Received: by 10.14.211.195 with SMTP id w43mr922669eeo.57.1378971254056; Thu, 12 Sep 2013 00:34:14 -0700 (PDT)
Received: from GriecoPC (deecom23.poliba.it. [193.204.59.55]) by mx.google.com with ESMTPSA id y47sm3382498eew.12.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 12 Sep 2013 00:34:10 -0700 (PDT)
From: "Alfredo Grieco" <alfredo.grieco@gmail.com>
To: <P.Zand@utwente.nl>, <xvilajosana@eecs.berkeley.edu>, <watteyne@eecs.berkeley.edu>, <6tsch@ietf.org>
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>
In-Reply-To: <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7BC47@EXMBX23.ad.utwente.nl>
Date: Thu, 12 Sep 2013 09:34:06 +0200
Message-ID: <52316e72.c7380f0a.73cf.ffffc7a5@mx.google.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary="----=_NextPart_000_0032_01CEAF9B.3AD592B0"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOqmeRdn+u8+L3JUGYWl1pnrYuVpm3azMAgAA2pACAAAP1gIABFasAgAAfWwCAAGmlgIABKJyAgAYvvkCAAA0/AIAAIEEAgAA8AMCAALlWkA==
Content-Language: en-us
Subject: [6tsch] R: 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: Thu, 12 Sep 2013 07:34:19 -0000

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):
I.	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].
II.	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].
III.	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
a.	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
 
b.	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
 
2.	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
 
3.	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
 
4.	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
 
5.	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
 
6.	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)
 
2.	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