Re: [6tsch] report flow contents

"Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl> Fri, 13 September 2013 14:23 UTC

Return-Path: <diego.dujovne@mail.udp.cl>
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 60B4321E8055 for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 07:23:13 -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 UAob9tK9+NKl for <6tsch@ietfa.amsl.com>; Fri, 13 Sep 2013 07:23:13 -0700 (PDT)
Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 5360421E809C for <6tsch@ietf.org>; Fri, 13 Sep 2013 07:23:06 -0700 (PDT)
Received: by mail-wi0-f182.google.com with SMTP id ez12so888589wid.3 for <6tsch@ietf.org>; Fri, 13 Sep 2013 07:23:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iztsCuqTm3uB6ETp8GeV99ynFYYwnf52vnjaVBu/5Z4=; b=bPiGjj/EOmHBCDKYduD9wLzqyPYCa8VtnW1sL+m7g2m4Bs6nt1ciVlK0ylTe/1hbMU pyI3sM1aUfQRTazY+GX+8t137O3yfmh7vfTBhYcbv4PmepLAjAlfocDxjA7W5hTH5MpM xxWy0KHzJOXR9wDlpMkL0Z4jWq4EbIs+l5alkdWUEYFLEf8oAZ4qU7IV8zduqt83Ekbe DRNcdxncIkFup53XxNQfWvpgKtyfJGSvIjUBj0/mytpsZt/n5wc6O2g5q+omiPjGe90K uLd7DTdxSuW2TIRe68tnFlx5iBVvJJrjPdiAeg90IASDRO3zS8z0Ed3cawaECknWI/ln 1oPQ==
X-Gm-Message-State: ALoCoQnTnS5UJPEkgpDfdyPiWOIU7gMRJPttbVOiGSOBywgcguYeUscfffa8fylcbHzny7mVOPLU
MIME-Version: 1.0
X-Received: by 10.180.36.231 with SMTP id t7mr2717614wij.53.1379082183480; Fri, 13 Sep 2013 07:23:03 -0700 (PDT)
Received: by 10.194.122.103 with HTTP; Fri, 13 Sep 2013 07:23:02 -0700 (PDT)
In-Reply-To: <CAAzoce4Up5ar80n-1zr-Opq10QOBVDcvNApBBgPKr+g6UjDENw@mail.gmail.com>
References: <CADJ9OA_XeC7Z5hFxyHhFGqD0aFMcBn=iHzDfRq34sL9qPi2P4A@mail.gmail.com> <CALEMV4YN3rA2OXeAV1akOZhdQrMOQvhN0A+t6vsL9RPVV=VMnQ@mail.gmail.com> <CADJ9OA8Cx3ingeiMdr60zUfMMENiay-Nftv0nMFOTD7=YcKgwg@mail.gmail.com> <CALEMV4ZdgWAFMyA=FtRik96evup-qJPQfTcDQEu99sfC0xFwuQ@mail.gmail.com> <E045AECD98228444A58C61C200AE1BD84145CB61@xmb-rcd-x01.cisco.com> <CALEMV4a=azY5MU00jNmcoek022gS=pUeXK1xVnucG+Zy6NTBOA@mail.gmail.com> <CALEMV4a=DCXV9ra832-5zEtiD7moUmj6GYu7tiosDYsD5v4ObA@mail.gmail.com> <CADJ9OA9OpGRvB1A4j-Byho_m8Zp3z1A5krCVi08U7xWP1Ohk+Q@mail.gmail.com> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7B88C@EXMBX23.ad.utwente.nl> <CADJ9OA9qb6aqyqonEmfZpqt3NHqm5EWPK-p2BAQf9C9sw8Cp3A@mail.gmail.com> <CALEMV4b4rfoLBWSOW8=wWR2xWy32V_uCXEzJ=5vaebL6g+LpbQ@mail.gmail.com> <76EA352C3C95BB42A2C4F2EE6493AD6E4DA7BC47@EXMBX23.ad.utwente.nl> <52316e72.c7380f0a.73cf.ffffc7a5@mx.google.com> <CADJ9OA9p2jihyn_o2XtLi7X7EBRQFMEADFjW8upKzgD70h3WOg@mail.gmail.com> <CAAzoce4Up5ar80n-1zr-Opq10QOBVDcvNApBBgPKr+g6UjDENw@mail.gmail.com>
Date: Fri, 13 Sep 2013 11:23:02 -0300
Message-ID: <CAH7SZV9-KaAiWOGxstDX3j5exL2EUC=4O_-pfm6tJMwe3kYOhA@mail.gmail.com>
From: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
To: Qin Wang <qinwang@berkeley.edu>
Content-Type: multipart/related; boundary=e89a8f6466f7a9a54304e64497b3
Cc: Thomas Watteyne <watteyne@eecs.berkeley.edu>, 6TSCH <6tsch@ietf.org>
Subject: Re: [6tsch] report flow contents
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2013 14:23:13 -0000

Hello Qin,
              I think that a per-frequency report will help the PCE
to decide which frequency to use, and maybe temporarily
black-list them. For example, a dynamic scheme may include
sampling the blacklisted frequencies every X minutes to re-enable
them once the interference has disappeared.
             This will require the node to refresh the RSSI
and LQI values in a opportunistic way (every time the a cell
uses that frequency) to save energy.

Any thoughts?

                            Diego





2013/9/13 Qin Wang <qinwang@berkeley.edu>

> Hi Thomas and All,
>
> I think the per-frequency report (or called per-channel report in
> ISA100.11a) is important, because PCE can use it to build black frequency
> list and update channel hopping sequence. But, I'm not sure if it makes
> implementation too complex or not.
>
> Thought?
>
> Qin
>
>
> On Fri, Sep 13, 2013 at 8:48 AM, Thomas Watteyne <
> watteyne@eecs.berkeley.edu> wrote:
>
>> Pouria,
>> Thanks again for the overview, which complements your first document
>> nicely.
>>
>> Alfredo,
>> Could you please elaborate what you mean by in-network processing? Are
>> you referring to a distributed way for the nodes to "consume" this data,
>> some fusion as the data trickles up the DAG, or something else?
>>
>> Thomas
>>
>>
>> On Thu, Sep 12, 2013 at 12:34 AM, Alfredo Grieco <
>> alfredo.grieco@gmail.com> wrote:
>>
>>> Hi All,****
>>>
>>> ** **
>>>
>>> Do you think is it feasible to add a bit/flag that allows some form of
>>> in-network processing ? ****
>>>
>>> ** **
>>>
>>> This would be very useful to distributed/decentralized scheduling
>>> techniques and should not cost that much.****
>>>
>>> ** **
>>>
>>> Any thoughts is welcome.****
>>>
>>> ** **
>>>
>>> Cheers****
>>>
>>> ** **
>>>
>>> Alfredo****
>>>
>>> ** **
>>>
>>> *Da:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *Per conto
>>> di *P.Zand@utwente.nl
>>> *Inviato:* Wednesday, September 11, 2013 10:45 PM
>>> *A:* xvilajosana@eecs.berkeley.edu; watteyne@eecs.berkeley.edu
>>> *Cc:* 6tsch@ietf.org
>>> *Oggetto:* Re: [6tsch] report flow contents****
>>>
>>> ** **
>>>
>>> Thomas,****
>>>
>>> I agree with you that "source route failed" and "graph route failed" are
>>> out of scope of 6TiSCH.****
>>>
>>> Regarding to you question about the per-channel report, I think they are
>>> based on each radio channel supported by the specification (channel 11-26
>>> in 2.4GHz in IEEE 802.15.4), not channel offset. And a channel report
>>> generated for all neighbor.****
>>>
>>> Regarding to your first question, let me now explain more. I think both
>>> of these standard provide a mechanisms to make it possible for
>>> System/Network Manager to also read (pull) desired attributes (But not all
>>> the feature in 6TiSCH). For example in WirelessHART [1], by “Report
>>> Neighbor Health List” request, the network manager might mention the number
>>> of neighbors to be read in “Number of Neighbor entries read” field.. ***
>>> *
>>>
>>> I think, ISA100.11a provides more mechanisms for System manager to get
>>> the desired attributes from the field devices. And the first two features
>>> that you mentioned might also be supported by ISA100.11a.****
>>>
>>> In ISA100.11a, three mechanisms are provided for reporting diagnostic
>>> information contained in dlmo.NeighborDiag (described in section 1 later)
>>> and dlmo.ChannelDiag (described in Section 2 later):****
>>>
>>>    1. The health reports concentrator object (HRCO), can be configured
>>>    to report any attribute in the DL *on a* *periodic basis*.
>>>    dlmo.NeighborDiag entries (shown in Table 2) and dlmo.ChannelDiag (shown in
>>>    Table 5) can be reported through that mechanism. Through the HRCO, the
>>>    system manager can configure the device to report NeighborDiag
>>>    periodically, such as every 30 minutes. Following each such report, on a
>>>    per-entry basis, NeighborDiag counts shall be reset to zero. Levels shall
>>>    use the current value as a starting point for the next period [2].***
>>>    *
>>>    2. Diagnostic information can be retrieved at any time by the system
>>>    manager, by reading the applicable attributes. The system manager can read
>>>    (poll) NeighborDiag as a read-only attribute *on a per-entry basis*.
>>>    As in an HRCO report, counts shall be reset to zero when read [2].***
>>>    *
>>>    3. Diagnostic information can be reported by the DL on *an exception
>>>    basis*, through the DL_Connectivity alert (Described in section
>>>    3(a)). The DL can additionally be configured, through the dlmo.AlertPolicy
>>>    attribute (shown in Table 6), to report NeighborDiag information when
>>>    diagnostic values exceed a threshold. Only the row triggering the alert is
>>>    reported. No values are reset [2]. ****
>>>
>>> ** **
>>>
>>> In ISA100.11a, the system manager establishes a DL communication
>>> relationship between a device and its neighbor by adding an entry to the
>>> device’s dlmo.Neighbor attribute (see Table 1). Each such entry specifies a
>>> level of diagnostics to be collected, through the field
>>> dlmo.Neighbor[].DiagLevel. For each neighbor, diagnostics may be collected
>>> at a baseline level, or a detailed level including clock diagnostics [2].
>>> This levels are described in Section 1.****
>>>
>>> *Table **1. dlmo.Neighbor fields [2]*
>>>
>>> *Field name*
>>>
>>> *Field encoding*
>>>
>>> * Index (16-bit address of neighbor)****
>>>
>>> ExtDlUint (used as an index)****
>>>
>>> EUI64 (EUI-64 identifier of the neighbor)****
>>>
>>> Type: Unsigned64****
>>>
>>> …****
>>>
>>> …****
>>>
>>> *DiagLevel* (selection of neighbor diagnostics to collect)****
>>>
>>> Type: Unsigned2****
>>>
>>> Bit0 = 1 Collect link diagnostics****
>>>
>>> Bit1 = 1 Collect clock diagnostics****
>>>
>>> …****
>>>
>>> …****
>>>
>>> ** **
>>>
>>> When the dlmo.Neighbor[].DiagLevel field is set for a particular
>>> neighbor, the DL shall create corresponding entries in the read-only
>>> attribute dlmo.NeighborDiag. NeighborDiag values are accumulated from the
>>> time that the dlmo.NeighborDiag entry is created [2].****
>>>
>>> ***1.      ****dlmo.NeighborDiag:*
>>>
>>> dlmo.NeighborDiag is an indexed OctetString collection that contains
>>> diagnostics for a set of neighbors. The attribute is read-only, with rows
>>> created as needed by the DL [2].****
>>>
>>> NeighborDiag entries are instantiated by the system manager, by setting
>>> dlmo.Neighbor[].DiagLevel bits to non-zero values. Iff (if and only if)
>>> Bit0=1, then summary diagnostics shall be collected for the neighbor,
>>> consolidated across all channels. Iff Bit1=1, then detailed clock
>>> diagnostics shall be collected for the neighbor, consolidated across all
>>> radio channels [2].****
>>>
>>> *Table **2. dlmo.NeighborDiag fields [2]*
>>>
>>> Field name****
>>>
>>> Field encoding****
>>>
>>> * Index****
>>>
>>> Type: ExtDlUint (neighbor address, used as an index)****
>>>
>>> *Summary*
>>>
>>> Type: OctetString (see Table 3)****
>>>
>>> *ClockDetail*
>>>
>>> Type: OctetString (see Table 4)****
>>>
>>> ** **
>>>
>>> *Table **3. Diagnostic Summary OctetString fields [2]*
>>>
>>> Field name****
>>>
>>> Field encoding****
>>>
>>> RSSI (level)****
>>>
>>> Type: Integer8****
>>>
>>> RSQI (level)****
>>>
>>> Type: Unsigned8****
>>>
>>> RxDPDU (count)****
>>>
>>> Type: ExtDlUint****
>>>
>>> TxSuccessful (count)****
>>>
>>> Type: ExtDlUint****
>>>
>>> TxFailed (count)****
>>>
>>> Type: ExtDlUint****
>>>
>>> TxCCA_Backoff (count)****
>>>
>>> Type: ExtDlUint****
>>>
>>> TxNACK (count)****
>>>
>>> Type: ExtDlUint****
>>>
>>> ClockSigma (level)****
>>>
>>> Type: Integer16****
>>>
>>> ** **
>>>
>>> *Table **4. Diagnostic ClockDetail OctetString fields [2]*
>>>
>>> Field name****
>>>
>>> Field encoding****
>>>
>>> ClockBias (level, signed)****
>>>
>>> Type: Integer16****
>>>
>>> ClockCount (count)****
>>>
>>> Type: ExtDlUint****
>>>
>>> ClockTimeout (count)****
>>>
>>> Type: ExtDlUint****
>>>
>>> ClockOutliers (count)****
>>>
>>> Type: ExtDlUint****
>>>
>>> ** **
>>>
>>> **2.      ***dlmo.ChannelDiag*:****
>>>
>>> dlmo.ChannelDiag is a read-only dynamic attribute that reports DPDU
>>> transmit failure rates on each radio channel supported by the
>>> specification. This enables the system manager to be aware of consistent
>>> connectivity problems on a per-channel basis, as a diagnostic for spectrum
>>> management in a subnet [2].****
>>>
>>> Two diagnostics are reported for each channel, each indicating a
>>> different type of failure. **** indicates the percentage of time that
>>> unicast DPDU transmissions on channel N did not receive an ACK or a NACK.
>>> **** indicates the percentage of time that unicast DPDU transmissions
>>> on channel N were aborted due to CCA. [2]****
>>>
>>> *Table **5. dlmo.ChannelDiag fields*
>>>
>>> Field name****
>>>
>>> Field encoding****
>>>
>>> Count (Number of attempted unicast transmissions for all channels)****
>>>
>>> Type:Unsigned16****
>>>
>>> **** (Percentage of time transmissions on channel 0 did not receive an
>>> ACK)****
>>>
>>> Type: Integer8****
>>>
>>> **** (Percentage of time transmissions on channel 0 aborted due to CCA)*
>>> ***
>>>
>>> Type: Integer8****
>>>
>>> …****
>>>
>>> ** **
>>>
>>> **** (Percentage of time transmissions on channel 15 did not receive an
>>> ACK)****
>>>
>>> Type: Integer8****
>>>
>>> **** (Percentage of time transmissions on channel 15 aborted due to CCA)
>>> ****
>>>
>>> Type: Integer8****
>>>
>>> ** **
>>>
>>> ***3.      ****Data link layer alerts*
>>>
>>>    1. *DL_Connectivity alert*
>>>
>>> DL performance diagnostics are accumulated in the attributes
>>> dlmo.NeighborDiag for *per-neighbor* diagnostics, and dlmo.ChannelDiag
>>> for *per-channel* diagnostics. Normally the system manager configures
>>> the HRCO to report these diagnostics periodically, and the DL automatically
>>> resets the diagnostic counters whenever these attributes are so reported.
>>> Between such reports, diagnostics may indicate a problem that needs to be
>>> reported to the system manager immediately. The DL_Connectivity alert
>>> provides the mechanism for the DL to report such issues, and the
>>> dlmo.AlertPolicy attribute enables the system manager to set thresholds for
>>> such reporting [2].****
>>>
>>> The attribute dlmo.AlertPolicy enables/disables the DL_Connectivity
>>> alert and provides thresholds to control whether alerts are reported.
>>> dlmo.AlertPolicy is an OctetString containing fields as shown in Table 6
>>> [2].****
>>>
>>> *Table **6. dlmo.AlertPolicy fields*
>>>
>>> Field name****
>>>
>>> Field scalar type****
>>>
>>> Descriptor (Enables or disabled the DL_Connectivity alert.)****
>>>
>>> Type Alert report descriptor****
>>>
>>> NeiMinUnicast (Minimum number of unicast transactions needed for a
>>> neighbor report.)****
>>>
>>> Type: ExtDlUint****
>>>
>>> NeiErrThresh (Report neighbor diagnostic if the percentage error rate
>>> reaches this threshold )****
>>>
>>> Type: Unsigned8****
>>>
>>> ChanMinUnicast (Minimum number of unicast transactions on a channel
>>> needed as a pre-condition for triggering an alert.)****
>>>
>>> Type: ExtDlUint****
>>>
>>> NoAckThresh (Report ChannelDiag if a NoAck value is greater than this
>>> threshold)****
>>>
>>> Type: Unsigned8****
>>>
>>> CCABackoffThresh (Report ChannelDiag if a CCABackoff value is greater
>>> than this threshold)****
>>>
>>> Type: Unsigned8****
>>>
>>> ** **
>>>
>>>    1. *NeighborDiscovery alert***
>>>
>>> The NeighborDiscovery alert provides a mechanism for the DL to report
>>> the contents of the OctetString in dlmo.Candidates attribute (see Table 7).
>>> ****
>>>
>>> The neighbors in the dlmo.Neighbor attribute are set by the system
>>> manager, not by the device itself. The DL autonomously builds a list of
>>> candidate neighbors in the dlmo.Candidates attribute. This list is then
>>> forwarded to the system manager. The system manager considers the radio
>>> connectivity that is reported in dlmo.Candidates, but may also consider
>>> other criteria such as resource constraints, historical performance, or
>>> subnet topology [2].****
>>>
>>> *Table **7. dlmo.Candidates OctetString fields*
>>>
>>> Field name****
>>>
>>> Field encoding****
>>>
>>> N (count of discovered neighbors)****
>>>
>>> Type: Unsigned8****
>>>
>>> Neighbor1 (16-bit address of first candidate)****
>>>
>>> Type: ExtDlUint****
>>>
>>> RSSI1 (radio signal quality of first candidate)****
>>>
>>> Type: Integer8****
>>>
>>> RSQI1 (radio signal quality of first candidate)****
>>>
>>> Type: Unsigned8****
>>>
>>> etc…****
>>>
>>> ** **
>>>
>>> NeighborN (16-bit address of Nth candidate)****
>>>
>>> Type: ExtDlUint****
>>>
>>> RSSIN (radio signal quality of Nth candidate)****
>>>
>>> Type: Integer8****
>>>
>>> RSQIN (radio signal quality of Nth candidate)****
>>>
>>> Type: Unsigned8****
>>>
>>> ** **
>>>
>>> *References*
>>>
>>> 1.            IEC 62591: Industrial Communication Networks - Wireless
>>> Communication Network and Communication Profiles - WirelessHART.****
>>>
>>> ** **
>>>
>>> 2.            IEC 62734: Industrial communication networks - Fieldbus
>>> specifications - Wireless systems for industrial automation: process
>>> control and related applications - ISA100.11a.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On
>>> Behalf Of *Xavier Vilajosana Guillen
>>> *Sent:* Wednesday, September 11, 2013 8:54 PM
>>> *To:* Thomas Watteyne
>>> *Cc:* 6TSCH
>>> *Subject:* Re: [6tsch] report flow contents****
>>>
>>> ** **
>>>
>>> Hi Thomas, ****
>>>
>>> my 5 cents.****
>>>
>>> I agree on adding NACK information and timing differences with other
>>> than time source parent neighbors. I will add to the wiki :-)****
>>>
>>> As regards to the differences of what we do at 6TiSCH and WHart or
>>> ISA100.11a, our proposal is more flexible and has less cohesion with a cost
>>> of increased complexity (e.g configurable data and reporting period). We
>>> have to analyse carefully what are the implications in terms of protocol
>>> complexity and implementation of that mechanism versus how often they would
>>> be used. Could we maybe define some "templates" or default configurations
>>> so using the 6TiSCH can be done without configuration overhead? Then
>>> configuration can be used for those that are really interested on tuning
>>> their system. ****
>>>
>>> just thoughts..
>>> X****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> On Wed, Sep 11, 2013 at 9:58 AM, Thomas Watteyne <
>>> watteyne@eecs.berkeley.edu> wrote:****
>>>
>>> Pouria,****
>>>
>>> ** **
>>>
>>> Wonderful list.****
>>>
>>> ** **
>>>
>>> Your document clearly highlights that (1) the "report" flows both in
>>> WirelessHART and ISA100.11a are strictly periodic and (1) they have a fixed
>>> format. From what we have discussed so far, the solutions we are developing
>>> is different in the following ways:****
>>>
>>>    - 6TiSCH offers a mechanism allowing the PCE to configure what data
>>>    it want to receive, and configure the trigger for a node to generate from
>>>    data.****
>>>    - 6TiSCH offers a mechanism allowing the PCE to query the data, on
>>>    top of having the nodes push the information****
>>>    - In 6TiSCH, the format of the payload is not fixed. In particular,
>>>    it is possible to add application-specific fields, allowing for extensions.
>>>    ****
>>>    - In 6TiSCH, the transport (CoAP?) and formatting (CBOR?) are
>>>    IETF-friendly and integrate well in the IPv6 stack and associated mechanisms
>>>    ****
>>>
>>> Did I get that right?****
>>>
>>> ** **
>>>
>>> A couple of questions:****
>>>
>>>    - the WirelessHART "alarms" correspond to a 6TiSCH "events". Yet, I
>>>    suppose that a "source route failed" and "graph route failed" are out of
>>>    scope of 6TiSCH, but rather part of RPL. I would expect those to the ICMPv6
>>>    messages. Thoughts?****
>>>    - About the per-channel report, I assume this is "per frequency",
>>>    right? Is a channel report generated for each neighbor?****
>>>    - When comparing your list to *Xavi*'s
>>>    https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents:****
>>>
>>>
>>>    - we might want to add a "numNACK" counter to the neighbor
>>>       information****
>>>       - we might want to keep timing statistics for all neighbors, not
>>>       just time source parents. That is, when I receive a packet from a neighbor
>>>       which is not my time source neighbor, I do not change my clock, but I still
>>>       know the timing error.****
>>>
>>> Thomas****
>>>
>>> ** **
>>>
>>> On Wed, Sep 11, 2013 at 7:18 AM, <P.Zand@utwente.nl> wrote:****
>>>
>>> Dear All,****
>>>
>>> In the following, I listed the performance metrics reported to the
>>> Network/System Manager in WirelessHART and ISA100.11a.****
>>>
>>> Some reports still need be added, for example the path failure alerts in
>>> ISA100.11a.****
>>>
>>> Pouria****
>>>
>>>  ****
>>>
>>> *WirelessHART performance metrics*****
>>>
>>> In WirelessHART[1] network the statistics and events are reported to the
>>> Network Manager (act like PCE in 6TiSCH) through the following commands:
>>> ****
>>>
>>>    1. Report “Device Health” ****
>>>
>>> This report is sent periodically toward the Network Manager. The report
>>> summaries the communication statistics of a device.****
>>>
>>> Byte****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 0-1****
>>>
>>> Unsigned-16****
>>>
>>> Number of packets generated by this device since last report****
>>>
>>> 2-3****
>>>
>>> Unsigned-16****
>>>
>>> Number of packets terminated by this device since last report****
>>>
>>> 4****
>>>
>>> Unsigned-8****
>>>
>>> Number of Data-Link Layer MAC MIC failures detected****
>>>
>>> 5****
>>>
>>> Unsigned-8****
>>>
>>> Number of Network Layer (Session) MIC failures detected****
>>>
>>> 6****
>>>
>>> Enum-8****
>>>
>>> Power Status****
>>>
>>> 7****
>>>
>>> Unsigned-8****
>>>
>>> Number of CRC Errors detected****
>>>
>>>  ****
>>>
>>>    1. Report “Neighbor Health List” ****
>>>
>>> This report is sent periodically toward the Network Manager. The report
>>> includes the statistics of linked neighbors.****
>>>
>>> Byte****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 0****
>>>
>>> Unsigned-8****
>>>
>>> Neighbor table index****
>>>
>>> 1****
>>>
>>> Unsigned-8****
>>>
>>> Number of Neighbor entries read****
>>>
>>> 2****
>>>
>>> Unsigned-8****
>>>
>>> Total number of neighbors****
>>>
>>> 3-4****
>>>
>>> Unsigned-16****
>>>
>>> Nickname of neighbor****
>>>
>>> 5****
>>>
>>> Bit-8****
>>>
>>> Neighbor Flags****
>>>
>>> 6****
>>>
>>> Signed-8****
>>>
>>> Mean RSL (Receive Signal Level in dBm) since last report****
>>>
>>> 7-8****
>>>
>>> Unsigned-16****
>>>
>>> Number of Packets transmitted to this neighbor****
>>>
>>> 9-10****
>>>
>>> Unsigned-16****
>>>
>>> Number of Packets received from this neighbor****
>>>
>>> 11-12****
>>>
>>> Unsigned-16****
>>>
>>> Packets received from this neighbor****
>>>
>>> 13-…****
>>>
>>>  ****
>>>
>>> Number of entries based on response byte 1****
>>>
>>>  ****
>>>
>>>    1. Report “Neighbor Signal Levels”****
>>>
>>> This report is sent periodically toward the Network Manager. The report
>>> includes the statistics of discovered (but not linked) neighbors. These
>>> neighbors might be discovered when a device has heard the neighbor
>>> communication in the discovery links. A device that wish to join a network,
>>> send a join request to the Network manager, including this report.****
>>>
>>> Byte****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 0****
>>>
>>> Unsigned-8****
>>>
>>> Neighbor table index****
>>>
>>> 1****
>>>
>>> Unsigned-8****
>>>
>>> Number of Neighbor entries read****
>>>
>>> 2****
>>>
>>> Unsigned-8****
>>>
>>> Total number of neighbors****
>>>
>>> 3-4****
>>>
>>> Unsigned-16****
>>>
>>> Nickname of neighbor****
>>>
>>> 5****
>>>
>>> Signed-8****
>>>
>>> RSL of neighbor in dB****
>>>
>>> 6-8****
>>>
>>>  ****
>>>
>>> Repeats (as needed) based on response byte 1****
>>>
>>>  ****
>>>
>>>    1. Alarm “Path Down” ****
>>>
>>> The alarm is sent upon detecting a path failure. ****
>>>
>>> Byte****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 0-1****
>>>
>>> Unsigned-16****
>>>
>>> Nickname of neighbor to which path failure was detected****
>>>
>>>  ****
>>>
>>>    1. Alarm "Source Route Failed"****
>>>
>>> This alarm is sent upon detecting a source route failure.****
>>>
>>> Byte****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 0-1****
>>>
>>> Unsigned-16****
>>>
>>> Nickname of unreachable neighbor in the source route****
>>>
>>> 2-5****
>>>
>>> Unsigned-32****
>>>
>>> Network-Layer MIC (i.e., the MIC generated using the session key) from
>>> the NPDU that failed routing****
>>>
>>>  ****
>>>
>>>    1. Alarm "Graph Route Failed"****
>>>
>>> This alarm is sent upon detecting a graph route failure.****
>>>
>>> Byte****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 0-1****
>>>
>>> Unsigned-16****
>>>
>>> Graph Id of the failed route****
>>>
>>>  ****
>>>
>>>
>>> ****
>>>
>>>  ****
>>>
>>> *ISA100.11a performance metric*****
>>>
>>> In ISA100.11a[2], the L2 performance metrics are reported to the System
>>> Manager (act like PCE in 6TiSCH) and can be classified into (1)
>>> DL_Connectivity alert and (2) NeighborDiscovery alert.****
>>>
>>>    1. DL_Connectivity alert****
>>>
>>> The DL_connectivity alert can be classified into (a) Per-neighbor
>>> reports and (b) Per-channel reports. ****
>>>
>>>    - *Per-neighbor report*****
>>>
>>> Per-neighbor reports are the  performance metrics about the neighbors
>>> connection and are reported to the System Manager. These statistics are
>>> accumulated in the “dlmo.NeighborDiag” attribute, for each neighbor. This
>>> report is similar to “Neighbor Health List” report in WirelessHART. ****
>>>
>>> Each node in ISA100.11a might be asked to report the following
>>> statistics about its neighbor:****
>>>
>>>  ****
>>>
>>> Octets****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 1****
>>>
>>> Signed-8****
>>>
>>> RSSI (level)****
>>>
>>> 1****
>>>
>>> Unsigned-8****
>>>
>>> RSQI (level)****
>>>
>>> 1-2****
>>>
>>> ExtDLUint****
>>>
>>> RxDPDU(count): Number of valid Packets received from this neighbor ****
>>>
>>> 1-2****
>>>
>>> ExtDLUint****
>>>
>>> TxSuccessful (count):Count of successful unicast transmissions to the
>>> neighbor ****
>>>
>>> 1-2****
>>>
>>> ExtDLUint****
>>>
>>> TxFailed (count): Number of unicast transmission, without  getting any
>>> ACK or NACK****
>>>
>>> 1-2****
>>>
>>> ExtDLUint****
>>>
>>> TxCCA_Backoff (count): Number of unicast transmission aborted due to CCA
>>> ****
>>>
>>> 1-2****
>>>
>>> ExtDLUint****
>>>
>>> TxNACK (count): Number of NACKs received****
>>>
>>> 2****
>>>
>>> Signed-16****
>>>
>>> ClockSigma (level): A rough estimate of standard deviation of clock
>>> corrections****
>>>
>>>  ****
>>>
>>>    - *Per-channel report*****
>>>
>>> In addition, in ISA100.11a, several performance metrics are reported
>>> based on channel for all neighbors to the System Manager. These statistics
>>> are accumulated in the “dlmo.ChannelDiag” attribute. This report is similar
>>> to “Device Health” report in WirelessHART.****
>>>
>>> Byte****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 0-2****
>>>
>>> Unsigned-16****
>>>
>>> Count (Number of attempted unicast transmissions for all channels)****
>>>
>>> 3****
>>>
>>> Integer-8****
>>>
>>> (Percentage of time transmissions on channel 0 did not receive an ACK)**
>>> **
>>>
>>> 4****
>>>
>>> Integer-8****
>>>
>>> (Percentage of time transmissions on channel 0 aborted due to CCA)****
>>>
>>> …****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> 33****
>>>
>>> Integer-8****
>>>
>>> (Percentage of time transmissions on channel 15 did not receive an ACK)*
>>> ***
>>>
>>> 34****
>>>
>>> Integer-8****
>>>
>>> (Percentage of time transmissions on channel 15 aborted due to CCA)****
>>>
>>>  ****
>>>
>>>    1. NeighborDiscovery alert****
>>>
>>> In ISA100.11a, each node sends a report, including a list of candidate
>>> (overheard) neighbors, to the System Manager to make a potential new
>>> routing decisions. The “dlmo.Candidates” attributed is used to store those
>>> information in each node in the L2. This report is similar to the “Neighbor
>>> Signal Levels” report in WirelessHART.****
>>>
>>> Octets****
>>>
>>> Format****
>>>
>>> Description****
>>>
>>> 1****
>>>
>>> Unsigned-8****
>>>
>>> N (count of discovered neighbors)****
>>>
>>> 0-2****
>>>
>>> ExtDlUint****
>>>
>>> address****
>>>
>>> 0-1****
>>>
>>> Signed-8****
>>>
>>> ****
>>>
>>> 0-1****
>>>
>>> Unsigned-8****
>>>
>>> ****
>>>
>>> …****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> 0-2****
>>>
>>> ExtDlUint****
>>>
>>> address****
>>>
>>> 0-1****
>>>
>>> Signed-8****
>>>
>>> ****
>>>
>>> 0-1****
>>>
>>> Unsigned-8****
>>>
>>> ****
>>>
>>>  ****
>>>
>>> * *****
>>>
>>> *References*****
>>>
>>> 1.       IEC 62591: Industrial Communication Networks - Wireless
>>> Communication Network and Communication Profiles - WirelessHART.****
>>>
>>>  ****
>>>
>>> 2.       IEC 62734: Industrial communication networks - Fieldbus
>>> specifications - Wireless systems for industrial automation: process
>>> control and related applications - ISA100.11a.****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On
>>> Behalf Of *Thomas Watteyne
>>> *Sent:* Saturday, September 07, 2013 7:43 PM
>>> *To:* Xavi Vilajosana
>>> *Cc:* Pascal Thubert (pthubert); 6tsch@ietf.org
>>> *Subject:* Re: [6tsch] report flow contents****
>>>
>>>  ****
>>>
>>> Xavi,****
>>>
>>> Great, thanks!****
>>>
>>> Thomas****
>>>
>>>  ****
>>>
>>> On Fri, Sep 6, 2013 at 5:01 PM, Xavier Vilajosana Guillen <
>>> xvilajosana@eecs.berkeley.edu> wrote:****
>>>
>>> Hi,
>>> I created the scratchpad section in the wiki to keep ideas
>>> https://bitbucket.org/6tsch/meetings/wiki/Home
>>>
>>>
>>> and added the flow content information here.
>>>
>>> https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents****
>>>
>>> have a nice weekend!****
>>>
>>> X****
>>>
>>>  ****
>>>
>>> On Fri, Sep 6, 2013 at 10:43 AM, Xavier Vilajosana Guillen <
>>> xvilajosana@eecs.berkeley.edu> wrote:****
>>>
>>> Hi Pascal, it is a good idea!****
>>>
>>> I will collect that information and as Thomas put it at the wiki so we
>>> do not lose it.
>>>
>>> :-)****
>>>
>>> X****
>>>
>>>  ****
>>>
>>> On Fri, Sep 6, 2013 at 8:51 AM, Pascal Thubert (pthubert) <
>>> pthubert@cisco.com> wrote:****
>>>
>>> Hello Xavi:****
>>>
>>>  ****
>>>
>>> At the call I mentioned we could use info on tracks and cells as well,
>>> probably on demand from the PCE.****
>>>
>>> For instance, the PCE could observe energy levels over some cells for  a
>>> while to make sure they are clean.****
>>>
>>>  ****
>>>
>>> What do you think?****
>>>
>>> Pascal****
>>>
>>>  ****
>>>
>>> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On
>>> Behalf Of *Xavier Vilajosana Guillen
>>> *Sent:* vendredi 6 septembre 2013 01:17
>>> *To:* Thomas Watteyne
>>> *Cc:* 6tsch@ietf.org
>>> *Subject:* Re: [6tsch] report flow contents****
>>>
>>>  ****
>>>
>>> agreed!****
>>>
>>> So the fields become:****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> For each known neighbor:****
>>>
>>>  -ID****
>>>
>>>  -AVG RSSI in a running window****
>>>
>>>  -Latest RSSI****
>>>
>>>  -AVG LQI in a running window [optional]****
>>>
>>>  -Latest LQI [optional]****
>>>
>>>  -Num TX packets (option in case there is communication with that
>>> neighbor)****
>>>
>>>  -Num ACK packets (option in case there is communication with that
>>> neighbor)****
>>>
>>>  -Num RX packets (option in case there is communication with that
>>> neighbor)****
>>>
>>>  -Last ASN when it heart about that neighbor ****
>>>
>>>  -Bundle: Num links in the Schedule to that neighbor****
>>>
>>>       -PDR per link [Optional -- or maybe best and worst PDR only]****
>>>
>>>  ****
>>>
>>>  -Option Flag (weather there are optional TLV fields on that category)**
>>> **
>>>
>>>    +(TLV objects)* ****
>>>
>>>  ****
>>>
>>>  -For each Queue:****
>>>
>>>     - Avg Queue length in a running window****
>>>
>>>     - Max Queue length in a running window (peak)****
>>>
>>>     - Current Queue length (?)****
>>>
>>>     - ASN of the oldest packet in the QUEUE?****
>>>
>>>     -Option Flag (weather there are optional TLV fields on that category)
>>> ****
>>>
>>>         +(TLV objects)* ****
>>>
>>>  ****
>>>
>>> -Time source parent****
>>>
>>>     -ID****
>>>
>>>     -Avg clock drift (correction done) in a running window****
>>>
>>>     -Latest clock correction****
>>>
>>>     -Parent changes (counter of how many times I changed my time source
>>> parent)****
>>>
>>>     -Option Flag (weather there are optional TLV fields on that category)
>>> ****
>>>
>>>     +(TLV objects)* ****
>>>
>>>  ****
>>>
>>> -Option Flag (weather there are optional TLV fields in other categories)
>>> ****
>>>
>>>    +(TLV objects)* ****
>>>
>>>  ****
>>>
>>> as regards to this:****
>>>
>>>  ****
>>>
>>> "Finally, do you envision a generic mechanism whereby the PCE can turn
>>> fields on/off, or triggered independently?"****
>>>
>>>  ****
>>>
>>> I see it as CoAP Options, where a set of bytes can be used as "clever
>>> bitmap" to tell what options are there, the parsing will decode option by
>>> option and will read the fields. In that way any combination of fields is
>>> supported.****
>>>
>>>  ****
>>>
>>> would that work?****
>>>
>>> X****
>>>
>>>  ****
>>>
>>> On Thu, Sep 5, 2013 at 4:03 PM, Thomas Watteyne <
>>> watteyne@eecs.berkeley.edu> wrote:****
>>>
>>> Xavi,****
>>>
>>>  ****
>>>
>>> Fantastic!****
>>>
>>>  ****
>>>
>>> I believe PDR for each link might be too long to fit in a packet. While
>>> the mote will most likely keep that information, we could move that to the
>>> query flow, i.e. it is available to the PCE on-demand.****
>>>
>>>  ****
>>>
>>> Would you agree that the number of links in a bundle belongs to the
>>> neighbor? Of maybe we want a "bundle" category?****
>>>
>>>  ****
>>>
>>> In queuing, it might be interesting to see the age of the different
>>> packets, to be able to monitor latency.****
>>>
>>>  ****
>>>
>>> About LQI, there is no general consensus among vendors on what the
>>> definition is, or how exactly it is calculated. I would make it optional.
>>> ****
>>>
>>>  ****
>>>
>>> Also, it might be good to be able to add arbitrary fields to each
>>> category: neighbor, queue, time source neighbor.****
>>>
>>>  ****
>>>
>>> Finally, do you envision a generic mechanism whereby the PCE can turn
>>> fields on/off, or triggered independently?****
>>>
>>>  ****
>>>
>>> Thomas****
>>>
>>>  ****
>>>
>>> On Thu, Sep 5, 2013 at 12:47 PM, Xavier Vilajosana Guillen <
>>> xvilajosana@eecs.berkeley.edu> wrote:****
>>>
>>> Hi Thomas, Diego,****
>>>
>>>  ****
>>>
>>> I agree that LQI should be there as well. I update here the list with
>>> Thomas suggestions. ****
>>>
>>>  ****
>>>
>>> For each known neighbor:****
>>>
>>>  -ID****
>>>
>>>  -AVG RSSI in a running window****
>>>
>>>  -Latest RSSI****
>>>
>>>  -AVG LQI in a running window****
>>>
>>>  -Latest LQI****
>>>
>>>  -Num TX packets (option in case there is communication with that
>>> neighbor)****
>>>
>>>  -Num ACK packets (option in case there is communication with that
>>> neighbor)****
>>>
>>>  -Num RX packets (option in case there is communication with that
>>> neighbor)****
>>>
>>>  -Last ASN when it heart about that neighbor ****
>>>
>>>  ****
>>>
>>> Other fields****
>>>
>>>  -Num links in the Schedule to that neighbor****
>>>
>>>     -For each link PDR****
>>>
>>>  -For each Queue:****
>>>
>>>     - Avg Queue length in a running window****
>>>
>>>     - Max Queue length in a running window (peak)****
>>>
>>>     - Current Queue length (?)****
>>>
>>> -Time source parent****
>>>
>>>     -ID****
>>>
>>>     -Avg clock drift (correction done) in a running window****
>>>
>>>     -Latest clock correction****
>>>
>>>     -Parent changes (counter of how many times I changed my time source
>>> parent)****
>>>
>>>  ****
>>>
>>> -Option Flag (weather there are optional TLV fields)****
>>>
>>>    +(TLV objects)* ****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> Hope this makes sense.****
>>>
>>> cheers!
>>> Xavi****
>>>
>>>  ****
>>>
>>> On Thu, Sep 5, 2013 at 11:41 AM, Thomas Watteyne <
>>> watteyne@eecs.berkeley.edu> wrote:****
>>>
>>> *[renamed thread]*****
>>>
>>>  ****
>>>
>>> Xavi,****
>>>
>>>  ****
>>>
>>> A few thoughts:****
>>>
>>> - the counters (numTx, etc) will only be present for neighbors the node
>>> has communicate with, so they should be optional in the packet.****
>>>
>>> - you have focused on the topological information (which I think is the
>>> right one). It might be useful to gather other data related to
>>> synchronization or queuing.****
>>>
>>> - I couldn't agree more with your suggestion to make it extensible. This
>>> does mean that we will need to state somewhere that a device need to ignore
>>> silently fields it does not understand.****
>>>
>>>  ****
>>>
>>> Thomas****
>>>
>>>  ****
>>>
>>> On Thu, Sep 5, 2013 at 11:15 AM, Xavier Vilajosana Guillen <
>>> xvilajosana@eecs.berkeley.edu> wrote:****
>>>
>>> Hello, I guess that flows are getting defined and I started to think on
>>> the contents of the messages on that flows. Not sure if this is the right
>>> time or I am going way far..****
>>>
>>>  ****
>>>
>>> According to the previous discussion I assume that the five flows are:**
>>> **
>>>
>>>  ****
>>>
>>> ME-6TOP - Query Flow****
>>>
>>> ME-6TOP - Action Flow****
>>>
>>>  ****
>>>
>>> 6TOP - ME - Report Flow****
>>>
>>> 6TOP - ME - Event Flow****
>>>
>>> 6TOP - ME - Request BW Flow****
>>>
>>>  ****
>>>
>>> I'd like to start defining the content of the messages in the Report
>>> Flow:****
>>>
>>>  ****
>>>
>>> The Report Flow: has to deal with the information that a node knows and
>>> has to be sent to the ME so the ME can compute the schedule among others.
>>> Here I list  the information that we can know in a mote and can be used at
>>> the ME to compute the schedule (complete please if I miss something)****
>>>
>>>  ****
>>>
>>> For each known neighbor:****
>>>
>>>  -ID****
>>>
>>>  -AVG RSSI in a running window****
>>>
>>>  -Latest RSSI****
>>>
>>>  -Num TX packets****
>>>
>>>  -Num ACK packets****
>>>
>>>  -Num RX packets****
>>>
>>>  -Last ASN when it heart about that neighbor ****
>>>
>>>  ****
>>>
>>> Other fields****
>>>
>>>  -Num links in the Schedule to that neighbor****
>>>
>>>     -For each link PDR****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> Then we need to have some TLV like objects that can be used for
>>> ad-hoc/naive/other extensions of the reporting process. In that way we
>>> don't constraint the implementation of the scheduling alg. to that
>>> information.****
>>>
>>>  ****
>>>
>>> what do you think?****
>>>
>>> X****
>>>
>>>  ****
>>>
>>> On Fri, Aug 30, 2013 at 10:45 AM, Qin Wang <qinwang@berkeley.edu> wrote:
>>> ****
>>>
>>> Hi all,****
>>>
>>>  ****
>>>
>>> In this thread, we will continue the discussion about Confirmation
>>> message. Here is some background information.****
>>>
>>>  ****
>>>
>>> Context: e.g.****
>>>
>>>     - node sends a report and want to know if the report is accepted., *
>>> ***
>>>
>>>     - ME sends a action request and want to know if/when the action
>>> taken.****
>>>
>>> Options:****
>>>
>>>    (1) Nothing****
>>>
>>>    (2) Rely on transport mechanism (e.g. confirmable CoAP message)****
>>>
>>>    (3) App-level ACK type****
>>>
>>>    (4) Use different flow (i.e. action flow)****
>>>
>>>  ****
>>>
>>> IMHO, different control flow may have different requirement for
>>> confirmation message.****
>>>
>>>     (1) Action Flow, needs a App-level confirmation, like Succ/Fail****
>>>
>>>     (2) Query Flow, automatically has the confirmation, i.e. the message
>>> packet corresponding to a specific query.****
>>>
>>>     (3) Report Flow and Event Flow, option (1)-(3) are OK, but I prefer
>>> option (1) and (3), i.e. the confirmation message is an option, but if a
>>> confirmation message is needed, it should be App-level Ack, instead of
>>> transport layer confirmation, which will give 6top more flexibility.****
>>>
>>>  ****
>>>
>>> What do you think?****
>>>
>>>  ****
>>>
>>> Thanks****
>>>
>>> Qin****
>>>
>>>     ****
>>>
>>>  ****
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>>  ****
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>>  ****
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>>  ****
>>>
>>> ** **
>>>
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>> ** **
>>>
>>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>


-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125