Re: [6tsch] (no subject)

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