Re: [6tsch] report flow contents

[Thomas Watteyne <[e-mail]>]

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
<[e-mail]>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:* [e-mail] [mailto:[e-mail]] *Per conto
> di *[e-mail]
> *Inviato:* Wednesday, September 11, 2013 10:45 PM
> *A:* [e-mail]; [e-mail]
> *Cc:* [e-mail]
> *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:* [e-mail] [mailto:[e-mail]] *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 <
> [e-mail]> 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, <[e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Saturday, September 07, 2013 7:43 PM
> *To:* Xavi Vilajosana
> *Cc:* Pascal Thubert (pthubert); [e-mail]
> *Subject:* Re: [6tsch] report flow contents****
>
>  ****
>
> Xavi,****
>
> Great, thanks!****
>
> Thomas****
>
>  ****
>
> On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen <
> [e-mail]> 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 <
> [e-mail]> 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) <
> [e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Xavier Vilajosana Guillen
> *Sent:* vendredi 6 septembre 2013 01:17
> *To:* Thomas Watteyne
> *Cc:* [e-mail]
> *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 <
> [e-mail]> 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 <
> [e-mail]> 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 <
> [e-mail]> 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 <
> [e-mail]> 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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ****
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ****
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ****
>
>  ****
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>