[6tsch] report flow contents

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