Hi Xavi,

Let me respond to the following first:

What if A resets? how you now at B that A has reset? do this require
a STATUS call from A to B when it join the network again?

That is one of options. Basically, it's up to an SF employed between
them. Here are other options in my mind:

  (1) A sends a Clear Request to B before the first transaction for
      Add or Delete operation since its reboot.
      # This is what SF0 of draft-02 does.

  (2) B notices that nothing has been received over scheduled cells
      with A or transmission to A over them is always fails.

    - Then, B sends a Clear Request to A. Or,

    - B tries to relocate such cells. Relocation fails because A
      doesn't have the cells to relocate (a proper return code is yet
      to be defined); then B sends a Clear Request to A.

Since these are independent of the generation counter, they could
happen even if the schedule generation management is used.

Could you please summarize how the timeout will work in the 2 and 3
step transactions: (snip) If the confirmation is lost B timeouts and
A should cancel or timeout because it does not receive ACK at the
MAC layer.

Sure, but I'd rather ignore ACK at the MAC layer here since it's a
message at a different protocol layer from 6P.

I drew some pictures so that we can see easily when and how timeout
occurs. Timeout event is supposed to be communicated to a
correspondent SF which decides how to deal with it.

[2-step transaction]

 (2-step.1) Request is lost: A gets Timeout

                A            B
  Send Add Req. |            |
  + Start Timer |->x Add Req.|
                |            |
                |            |
        Timeout |            |

 (2-step.2) Response is lost: A gets Timeout

                A            B
  Send Add Req. |            |
  + Start Timer |----------->| Recv Add Req.
                |            |
                |            |
                |    Res. x<-| Send Res.
        Timeout |            |

 (2-step.3) Everything is fine: no timeout

                A            B
  Send Add Req. |            |
  + Start Timer |----------->| Recv Add Req.
                |            |
                |            |
  Recv Res.     |<-----------| Send Res.
  + Stop Timer  |            |
        
        
[3-step transaction]
        
 (3-step.1) Request is lost: A gets Timeout
        
               Same as (2-step.1)
        
 (3-step.2) Response is lost: A and B gets Timeout
        
                A            B
  Send Add Req. |            |
  + Start Timer |----------->| Recv Add Req.
                |            |
                |            | Send Res.
                |    Res. x<-| + Start Timer
        Timeout |            |
                |            |
                |            |
                |            | Timeout
        
 (3-step.3) Confirmation is lost: B gets Timeout
        
                A            B
  Send Add Req. |            |
  + Start Timer |----------->| Recv Add Req.
                |            |
                |            | Send Res.
  Recv Res.     |<-----------| + Start Timer
  + Stop Timer  |            |
                |            |
  Send Conf.    |->x Conf.   |
                |            | Timeout
                        
 (3-step.4) Everything is fine: no timeout
                        
                A            B
  Send Add Req. |            |
  + Start Timer |----------->| Recv Add Req.
                |            |
                |            | Send Res.
  Recv Res.     |<-----------| + Start Timer
  + Stop Timer  |            |
                |            |
  Send Conf.    |----------->| Recv Conf.
                |            | + Stop Timer
                        
Hope these pictures are displayed correctly.
                        
Best,
Yatch

_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to