Hi Xavi,

Thanks for explanation! It makes sense for me.

Xavi, Diego, All,

Does the token indicates the ID of one transaction? How this 8-bits value
changes during a transaction/multiple transaction? It would be helpful if
there is some martial showing how the token works with 6p. Let me know if
there is also a discussion somewhere which I can trace. Thanks!

Tengfei

On Thu, Mar 3, 2016 at 8:23 PM, Xavier Vilajosana <
[email protected]> wrote:

> Hi Tengfei,
>
> if we want (now or in the future) to support asynchronous responses (such
> as the piggybacking case or if we want to aggregate confirmations) then the
> token is handy. If we think that this mechanism will always be synchronous
> and that concurrency will not be allowed then the state machine works.
>
> my 2 cents :)
> X
>
>
> 2016-03-03 18:47 GMT+01:00 Tengfei Chang <[email protected]>:
>
>> Hello Diego,
>>
>> For the Token to identify the transaction, personally, if *the idea is
>> to identify a request and a response with a token*,  it can be replaced
>> by implementing a status machine, in which the status is able to identify
>> the status of 6P transaction.
>>
>> Here is a rough example which is able to explain how Status Machine works:
>>
>> *Initially* the status of 6P can be set as 6P_IDLE.
>>
>> *For a mote sending 6p request:*
>>
>>
>>    1.  after the 6p request is ready to be sent which contains the
>>    candidate cell, the status turns to 6P_REQUEST_INIT
>>    2. after the request is sent, the status turns to
>>    6P_REQUEST_WAITING_RESPONSE
>>    3. after received the response from parent, mote sends ACK back and
>>    add/delete cell in schedule. The status turns to 6P_IDLE
>>
>> *For a mote received 6p request:*
>>
>>    1. after receiving the 6p request, the mote turns status to
>>    6P_RECEIVED_REQUEST
>>    2. when cells are selected or no cell is available, set status to
>>    6P_RESPONSE_TOBESENT
>>    3. after sending the response and get the ACK, mote will add/delete
>>    cells in schedule and set status back to 6P_IDLE
>>
>> If the mote will not process the next 6P request if the status is
>> correct. Even if there are some issue that the mote stuck at one status,
>> the timeout will reset the status to 6P_IDLE.
>>
>> With this, one byte can be save, though it's not that much.
>> What do you think?
>>
>> Tengfei
>>
>> On Thu, Mar 3, 2016 at 4:30 PM, Prof. Diego Dujovne <
>> [email protected]> wrote:
>>
>>> Dear all,
>>>             In order to continue the discussion we left
>>> unfinished at the Interim meeting in March 26th, I
>>> will open a number of threads to take action on several
>>> pending issues for the drafts:
>>>
>>> draft-wang-6tisch-6top-sublayer-04 (which will be renamed to
>>> 6top-protocol)
>>> draft-dujovne-6tisch-6top-sf0-00
>>>
>>> - Regarding the use of a Token to identify transactions on
>>> the 6top protocol, there was a proposal on the call to add
>>> an 8-bit field to the packet header.
>>>
>>> Do you agree with this solution?
>>>
>>> Regards,
>>>
>>>                               Diego Dujovne
>>>
>>> --
>>> 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
>>>
>>> _______________________________________________
>>> 6tisch mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/6tisch
>>>
>>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to