Subject: Re: [6tsch] Message flows

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Thu, 15 Aug 2013 19:06:50 +0000

HI Qin,
The conflicts I am referring to are -

Consdiering multihop communication and hard-cells

  1.  Route 1 requires a particular set of slots to be setup. Say node A must listen on slot number 11, 34, 65 and Tx on 13, 35, 68
  2.  But another route 2 requires node A to listen on slot 35.

There may be other such conflicts that we may need to resolve.

-raghuram

Hi Raghuram,

I totally agree to your approach to define the flow information to L3.

Regarding to your question, can you explain more about:
(1) from nodeA to nodeB is one hop or multi-hop?
(2) installing the route with hard cells or soft cells?
(3) what "conflict during route installation" mean? what kind of conflict?

Thanks
Qin

On Thu, Aug 15, 2013 at 10:16 PM, Raghuram Sudhaakar (rsudhaak) <[email-masked]<mailto:[email-masked]>> wrote:
Qin,
I have pretty much the same line of thought. I agree with the point that 6top is independent from L3. What we are trying to do is define what L3 will need to implement to obtain information from 6top. Obviously, 6top will expose these interfaces in its standard implementation.

Do you think finding the common requirements from 6top to L3 flows between RPL and PCE is a good place to start? I am sure there are going to be some specific requirements for each but they can be added as PCE or RPL specific primitives. I am not suggesting that we implement specific primitives for every L3 protocol, but once we cover RPL and PCE I think we will satisfy the requirements of most L3s.

The different flows you have identified is perfect.
(1) The flows from 6top -> L2 have been addressed quite extensively in the draft already. There are a few flows from L2 -> 6top that have to be addressed. GET_TIMING_PARENT for e..g.
(2) I would consider the requirements of PCE, RPL, (probably v6ND) in terms of parameters required for route computation to define the general requirements for flows between L3 and 6top. In the draft, you have already addressed some RPL specific primitives like control message delivery. I think this should go in the RPL specific part. We define primitives to expose parameters required by L3 to perform route computation in the general flows. For e.g. L2 neighbor list, link quality to each neighbor. We need to specify the message format that needs to used by L3 to obtain this info.
(3) We will also need 6top->L3 flows to be defined. For e.g., in the RPL case,  GET_RPL_PARENT will be one such flow as 6top needs to provide the primitive GET_TIMING_PARENT in the L2->6top flow. A similar primitive needs to be there for PCE.

(Note: when I say L2 -> 6top flow, I mean L2 is the data requestor entity and 6top is the data provider. This is my own convention and hence the clarification)

Another critical part I want to get your opinions on is the following. We have decided that irrespective of L3 (PCE or RPL) a node A will initiate route installation request when it has data to send to node B. In this case -

  1.  How do resolve conflict during route installation? L3 computes a route and send it over to 6top. Which in turn converts it to slot reservations using the 6top -> L2 primitives in the slot frame. What if there is a conflict during this slot reservation? What are the messages that will inform L3 and the node that route installation failed? This must also cause L3 to recompute its route.
  2.  Then we have to ask, does 6top provide a mechanism to inform L3 about failure and obtain a recomputed route (i.e.) perform n number of retries. Or just fail after one try and leave it to the node to reinitiate a route request.

-raghuram

From: Qin Wang <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 15, 2013 6:00 AM
To: raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Message flows

Hi Raghuram,

Sorry for the late response. It is welcome for you to add flow information if necessary.

Just one thing I want to understand more clearly. I think 6top is a relatively independent sublayer from upper layer. RPL is used as upper layer in the first step, but, just one kind of upper layers in the future. Correct?

In this sense, we should separate the general flow information to upper layer and the specific flow information to RPL. Then, can we organize the flow information related to 6top in this way?

(1) flow information with L2, i.e. TSCH
(2) general flow information with upper layer, may be L3 or L2.5
(3) flow information with specific upper layer protocol like RPL.

What do you think?

Qin

On Thu, Aug 15, 2013 at 6:10 AM, Raghuram Sudhaakar (rsudhaak) <[email-masked]<mailto:[email-masked]>> wrote:
Ok.

Qin, if you are OK I can add the flow information specific to RPL.

-raghuram

From: Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>>
Reply-To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, August 14, 2013 2:32 PM
To: raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>
Cc: Qin Wang <[email-masked]<mailto:[email-masked]>>
Subject: Re: Message flows

Hi Raghuram,

I let Qin answer as she is the main author. My opinion is that by now we keep the document as a single file but we separate the two message flows. IMHO, if you have information to add it is more than welcome!

X

On Wed, Aug 14, 2013 at 1:42 PM, Raghuram Sudhaakar (rsudhaak) <[email-masked]<mailto:[email-masked]>> wrote:
Xavi, Qin,
I believe that there is some information that needs to be added to the message flows that will occur between L3 -> 6top and L2 -> 6top, in addition to what is already there in Qin's draft. I wanted to check with you guys if you want to add to the same document or split it into a separate RFC. When I say split into separate RFC,  what I mean is, L3 to 6top is one RFC and L2 to 6top is another. The current draft has a lot of information about L2 to 6top. I could add more about the RPL to 6top is its OK..

-raghuram

---

From: <[email-masked]>
Date: Thu, 15 Aug 2013 21:52:50 +0000

Hi Raghuram, Qin,
Let me enter to your discussion
I agree with Raghuram that when the higher layer call the 6top's commands (or .requests primitives) it should be informed about the status of its request by "command reply" or ".confirm" primitives. The status of the ".confirm" or "reply" can be success, failure or ...
Am I right?
I couldn't either find the 6top's behavior upon receiving the "MLME-SET-SLOTFRAME.confirm" or "MLME-SET-LINK.confirm" primitives that might be called by L2. Did I miss that?

Raghuram, I just have one minor comment, in your example. I think that the RPL (L3) should use the "Create soft cell command" to ask a new cell without specifying the exact cell. Because the L3 does not have enough information to ask for reserving specific cell in L2. The "Create hard cell command" should be called by the one who has the global knowledge on network schedules, like PCE. However, I agree that the PCE by calling the "Create hard cell command" or RPL by calling "Create soft cell command" should be informed by 6top about the status of its request. For example, It might happen that PCE send a same request twice or RPL's request can't be serviced.
AM I right?

Pouria.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: Thursday, August 15, 2013 9:07 PM
To: Qin Wang
Cc: [email-masked]
Subject: Re: [6tsch] Message flows

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

---

From: Qin Wang <[email-masked]>
Date: Fri, 16 Aug 2013 06:31:33 +0800

Hi Raghuram and Pouria,

The following is my understanding.

(1) Taking the assumption in Raghuram's example, i.e. installing a route
with hard cells, then, some role like PCE should exist and take
responsibility to make conflict-free. In another word, the scenario
described in the Raghuram's example should not happen. (But, it doesn't
mean a confirmation message is not needed, see the following) .

(2)  “MLME-SET-SLOTFRAME.confirm” and “MLME-SET-LINK.confirm” are
primitives of 802.15.4e. The confirmation to upper layer should come from
the execution of 6top commands, which may related with the two 15.4e
primitives, but not exactly same.

(3) RPL is a routing protocol. It uses the TSCH schedule to forward
packets, no matter the schedule is installed by PCE (hard cell) , or by
some reservation protocol like RSVP (soft cell).

Make sense?

Thanks
Qin

On Fri, Aug 16, 2013 at 5:52 AM, <[email-masked]> wrote:

>  Hi Raghuram, Qin,****
>
> Let me enter to your discussion****
>
> I agree with Raghuram that when the higher layer call the 6top’s commands
> (or .requests primitives) it should be informed about the status of its
> request by “command reply” or “.confirm” primitives. The status of the
> “.confirm” or “reply” can be success, failure or …****
>
> Am I right?****
>
> I couldn’t either find the 6top’s behavior upon receiving the
> “MLME-SET-SLOTFRAME.confirm” or “MLME-SET-LINK.confirm” primitives that
> might be called by L2. Did I miss that?****
>
> ** **
>
> Raghuram, I just have one minor comment, in your example. I think that the
> RPL (L3) should use the “Create soft cell command” to ask a new cell
> without specifying the exact cell. Because the L3 does not have enough
> information to ask for reserving specific cell in L2. The “Create hard cell
> command” should be called by the one who has the global knowledge on
> network schedules, like PCE. However, I agree that the PCE by calling the
> “Create hard cell command” or RPL by calling “Create soft cell command”
> should be informed by 6top about the status of its request. For example, It
> might happen that PCE send a same request twice or RPL’s request can’t be
> serviced. ****
>
> AM I right?****
>
> ** **
>
> Pouria.      ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Raghuram Sudhaakar (rsudhaak)
> *Sent:* Thursday, August 15, 2013 9:07 PM
> *To:* Qin Wang
> *Cc:* [email-masked]
> *Subject:* Re: [6tsch] Message flows****
>
> ** **
>
> HI Qin,****
>
> The conflicts I am referring to are -****
>
> ** **
>
> Consdiering multihop communication and hard-cells****
>
>    1. Route 1 requires a particular set of slots to be setup. Say node A
>    must listen on slot number 11, 34, 65 and Tx on 13, 35, 68****
>    2. But another route 2 requires node A to listen on slot 35. ****
>
>  There may be other such conflicts that we may need to resolve.****
>
> ** **
>
> -raghuram****
>
> ** **
>
> ** **
>
> Hi Raghuram, ****
>
> ** **
>
> I totally agree to your approach to define the flow information to L3.****
>
> ** **
>
> Regarding to your question, can you explain more about:****
>
> (1) from nodeA to nodeB is one hop or multi-hop?****
>
> (2) installing the route with hard cells or soft cells?****
>
> ****
> ** **
> Thanks****
> Qin****
> ** **
> ** **
> ** **
> On Thu, Aug 15, 2013 at 10:16 PM, Raghuram Sudhaakar (rsudhaak) <
> [email-masked]> wrote:****
>
> Qin,****
>
> I have pretty much the same line of thought. I agree with the point that
> 6top is independent from L3. What we are trying to do is define what L3
> will need to implement to obtain information from 6top. Obviously, 6top
> will expose these interfaces in its standard implementation.****
>
> ** **
>
> Do you think finding the common requirements from 6top to L3 flows between
> RPL and PCE is a good place to start? I am sure there are going to be some
> specific requirements for each but they can be added as PCE or RPL specific
> primitives. I am not suggesting that we implement specific primitives for
> every L3 protocol, but once we cover RPL and PCE I think we will satisfy
> the requirements of most L3s.****
>
> ** **
>
> The different flows you have identified is perfect. ****
>
> (1) The flows from 6top -> L2 have been addressed quite extensively in the
> draft already. There are a few flows from L2 -> 6top that have to be
> addressed. GET_*TIMING_P*ARENT for e..g.****
>
> (2) I would consider the requirements of PCE, RPL, (probably v6ND) in
> terms of parameters required for route computation to define the general
> requirements for flows between L3 and 6top. In the draft, you have already
> addressed some RPL specific primitives like control message delivery. I
> think this should go in the RPL specific part. We define primitives to
> expose parameters required by L3 to perform route computation in the
> general flows. For e.g. L2 neighbor list, link quality to each neighbor. We
> need to specify the message format that needs to used by L3 to obtain this
> info.****
>
> (3) We will also need 6top->L3 flows to be defined. For e.g., in the RPL
> case,  GET_*RPL_*PARENT will be one such flow as 6top needs to provide
> the primitive GET_*TIMING_*PARENT in the L2->6top flow. A similar
> primitive needs to be there for PCE.****
>
> ** **
>
> (Note: when I say L2 -> 6top flow, I mean L2 is the data requestor entity
> and 6top is the data provider. This is my own convention and hence the
> clarification)****
>
> ** **
>
> Another critical part I want to get your opinions on is the following. We
> have decided that irrespective of L3 (PCE or RPL) a node A will initiate
> route installation request when it has data to send to node B. In this case
> -****
>
>    1. How do resolve conflict during route installation? L3 computes a
>    route and send it over to 6top. Which in turn converts it to slot
>    reservations using the 6top -> L2 primitives in the slot frame. What if
>    there is a conflict during this slot reservation? What are the messages
>    that will inform L3 and the node that route installation failed? This must
>    also cause L3 to recompute its route.****
>    2. Then we have to ask, does 6top provide a mechanism to inform L3
>    about failure and obtain a recomputed route (i.e.) perform n number of
>    retries. Or just fail after one try and leave it to the node to reinitiate
>    a route request. ****
>
>  -raghuram****
>
> ** **
>
> ** **
>
> *From: *Qin Wang <[email-masked]>
> *Date: *Thursday, August 15, 2013 6:00 AM
> *To: *raghuram sudhaakar <[email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *Subject: *Re: Message flows****
>
> ** **
>
> Hi Raghuram, ****
>
> ** **
>
> Sorry for the late response. It is welcome for you to add flow information
> if necessary.****
>
> ** **
>
> Just one thing I want to understand more clearly. I think 6top is a
> relatively independent sublayer from upper layer. RPL is used as upper
> layer in the first step, but, just one kind of upper layers in the future.
> Correct? ****
>
> ** **
>
> In this sense, we should separate the general flow information to upper
> layer and the specific flow information to RPL. Then, can we organize the
> flow information related to 6top in this way?****
>
> ** **
>
> (1) flow information with L2, i.e. TSCH****
>
> (2) general flow information with upper layer, may be L3 or L2.5****
>
> (3) flow information with specific upper layer protocol like RPL.****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Qin ****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Thu, Aug 15, 2013 at 6:10 AM, Raghuram Sudhaakar (rsudhaak) <
> [email-masked]> wrote:****
>
> Ok. ****
>
> ** **
>
> Qin, if you are OK I can add the flow information specific to RPL. ****
>
> ** **
>
> -raghuram****
>
> ** **
>
> *From: *Xavier Vilajosana Guillen <[email-masked]>
> *Reply-To: *"[email-masked]" <[email-masked]
> >
> *Date: *Wednesday, August 14, 2013 2:32 PM
> *To: *raghuram sudhaakar <[email-masked]>
> *Cc: *Qin Wang <[email-masked]>
> *Subject: *Re: Message flows****
>
> ** **
>
> Hi Raghuram,****
>
> I let Qin answer as she is the main author. My opinion is that by now we
> keep the document as a single file but we separate the two message flows.
> IMHO, if you have information to add it is more than welcome!
>
> X****
>
> ** **
>
> On Wed, Aug 14, 2013 at 1:42 PM, Raghuram Sudhaakar (rsudhaak) <
> [email-masked]> wrote:****
>
> Xavi, Qin,****
>
> I believe that there is some information that needs to be added to the
> message flows that will occur between L3 -> 6top and L2 -> 6top, in
> addition to what is already there in Qin's draft. I wanted to check with
> you guys if you want to add to the same document or split it into a
> separate RFC. When I say split into separate RFC,  what I mean is, L3 to
> 6top is one RFC and L2 to 6top is another. The current draft has a lot of
> information about L2 to 6top. I could add more about the RPL to 6top is its
> OK..****
>
> ** **
>
> -raghuram****
>
> ** **
>
> ** **
>
> ** **
>

---

From: <[email-masked]>
Date: Thu, 15 Aug 2013 23:44:59 +0000

Hi Qin,
Regarding to (2), this is my understanding from the procedure for creating a hard cell and slotframe. Am I missing something from 6top?

Best Wishes,
Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Friday, August 16, 2013 12:32 AM
To: Zand, P. (EWI)
Cc: Raghuram Sudhaakar (rsudhaak); [email-masked]
Subject: Re: Message flows

Hi Raghuram and Pouria,

(1) Taking the assumption in Raghuram's example, i.e. installing a route with hard cells, then, some role like PCE should exist and take responsibility to make conflict-free. In another word, the scenario described in the Raghuram's example should not happen. (But, it doesn't mean a confirmation message is not needed, see the following) .

(2)  "MLME-SET-SLOTFRAME.confirm" and "MLME-SET-LINK.confirm" are primitives of 802.15.4e. The confirmation to upper layer should come from the execution of 6top commands, which may related with the two 15.4e primitives, but not exactly same.

(3) RPL is a routing protocol. It uses the TSCH schedule to forward packets, no matter the schedule is installed by PCE (hard cell) , or by some reservation protocol like RSVP (soft cell).

Make sense?

Thanks
Qin

On Fri, Aug 16, 2013 at 5:52 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Raghuram, Qin,
Let me enter to your discussion
I agree with Raghuram that when the higher layer call the 6top's commands (or .requests primitives) it should be informed about the status of its request by "command reply" or ".confirm" primitives. The status of the ".confirm" or "reply" can be success, failure or ...
Am I right?
I couldn't either find the 6top's behavior upon receiving the "MLME-SET-SLOTFRAME.confirm" or "MLME-SET-LINK.confirm" primitives that might be called by L2. Did I miss that?

Pouria.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: Thursday, August 15, 2013 9:07 PM
To: Qin Wang
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] Message flows

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

---

From: Qin Wang <[email-masked]>
Date: Fri, 16 Aug 2013 20:04:36 +0800

Hi Pouria,

It is the process to create a hard cell and slotframe. You see,
“MLME-SET-SLOTFRAME.confirm”
and “MLME-SET-LINK.confirm” generates confirmation from L2, which usually
is one of factors to generate the confirmation message to higher layer. In
another word, when the status returned by  “MLME-SET-SLOTFRAME.confirm” or
“MLME-SET-LINK.confirm” is False, the status reported from 6top to higher
layer must be False. But, there may be some other factors also making the
status False.

Make sense?

Qin

On Fri, Aug 16, 2013 at 7:44 AM, <[email-masked]> wrote:

>  Hi Qin,****
>
> Regarding to (2), this is my understanding from the procedure for creating
> a hard cell and slotframe. Am I missing something from 6top?****
>
> ** **
>
> ****
>
> Best Wishes,****
>
> Pouria****
>
> ** **
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* Friday, August 16, 2013 12:32 AM
> *To:* Zand, P. (EWI)
> *Cc:* Raghuram Sudhaakar (rsudhaak); [email-masked]
> *Subject:* Re: Message flows****
>
> ** **
>
> Hi Raghuram and Pouria,****
>
> ** **
>
> The following is my understanding.****
>
> ** **
>
> mean a confirmation message is not needed, see the following) .****
>
> ** **
>
> primitives, but not exactly same.****
>
> ** **
>
> some reservation protocol like RSVP (soft cell).****
>
> ** **
>
> Make sense?****
>
> ** **
>
> Thanks****
>
> Qin****
>
> ** **
>
>  ****
>
> ** **
>
> On Fri, Aug 16, 2013 at 5:52 AM, <[email-masked]> wrote:****
>
> Hi Raghuram, Qin,****
>

---

From: <[email-masked]>
Date: Fri, 16 Aug 2013 13:24:17 +0000

Qin,

I completely agree with you that the status of the report/confirm form 6top to higher layer might be changed by other factors as well. My point is that, one of those factors, is the status of ".confirm" primitives received form L2. I think in 6top, we have to add them to the list of the factors that effect on the reply/confirm to higher layer. Am I right?

Regarding to (1), I think, when the 6top commands/primitives are called by higher layer (either by PCE, potential signaling protocol, or temporary by RPL in the lack of signaling protocol) we have to send a ".confirm" to inform them about the status of their requests. Am I right? I would say that in some cases we might need to send the confirmation to PCE with the FAIL status.

Regarding to (3), I agree that the signaling protocol and PCE should call the cell creation commands/primitives. Do you agree that 6top should be independent form the higher layer that has called its primitives/command? Is there any limitation that in the lack of signaling protocol, the RPL can't call some of the 6top' management commands/primitives (e.g. Soft cell creation)? In this case, we might need to reply to RPL, by SUCCESS or FAIL status? Did I miss anything?

Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Friday, August 16, 2013 2:05 PM
To: Zand, P. (EWI)
Cc: Raghuram Sudhaakar (rsudhaak); [email-masked]
Subject: Re: Message flows

Hi Pouria,

It is the process to create a hard cell and slotframe. You see,  "MLME-SET-SLOTFRAME.confirm" and "MLME-SET-LINK.confirm" generates confirmation from L2, which usually is one of factors to generate the confirmation message to higher layer. In another word, when the status returned by  "MLME-SET-SLOTFRAME.confirm" or "MLME-SET-LINK.confirm" is False, the status reported from 6top to higher layer must be False. But, there may be some other factors also making the status False.

Make sense?

Qin

On Fri, Aug 16, 2013 at 7:44 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,
Regarding to (2), this is my understanding from the procedure for creating a hard cell and slotframe. Am I missing something from 6top?

Best Wishes,
Pouria

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, August 16, 2013 12:32 AM
To: Zand, P. (EWI)
Cc: Raghuram Sudhaakar (rsudhaak); [email-masked]<mailto:[email-masked]>
Subject: Re: Message flows

Hi Raghuram and Pouria,

Make sense?

Thanks
Qin

Pouria.

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Fri, 16 Aug 2013 14:53:27 +0000

Qin, Pouria,
The message flow diagram idescribes the scenario perfectly. I think it should go in the document or at least in an appendix to the document. I would make one change though, instead of have two command from L3 to 6top (create hard cell, create soft cell) we can have only one command (install route) and depending on the type of L3 6top decides whether to create  a hard or soft cell. This will help 6top ensure that there are minimal conflicts (as pointed out already in this discussion) and in future we may be able to work with PCE and RPL simultaneously. This scenario of working with multiple L3's may occur when there are multiple overlay/logical networks are being created over the same physical network.

The only caveat to this though is that we need to define a command from L3 to 6top that will help 6top identify the L3 protocol. Or we could also include a L3 protocol type field in every message from L3 -> 6top.

Qin mentioned that the status returned by L2 for the the slot installation process can be forwarded to L3 by 6top but in some cases we may there may be other factors also. I thought about this but I can't identify what other factors might affect the reply the 6top will send to L3. Can you please identify what factors you had in mind. I think it is important we nail down this flow very clearly and take care of all edge cases.

-raghuram

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 16, 2013 6:24 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Message flows

Qin,

I completely agree with you that the status of the report/confirm form 6top to higher layer might be changed by other factors as well. My point is that, one of those factors, is the status of “.confirm” primitives received form L2. I think in 6top, we have to add them to the list of the factors that effect on the reply/confirm to higher layer. Am I right?

Regarding to (1), I think, when the 6top commands/primitives are called by higher layer (either by PCE, potential signaling protocol, or temporary by RPL in the lack of signaling protocol) we have to send a “.confirm” to inform them about the status of their requests. Am I right? I would say that in some cases we might need to send the confirmation to PCE with the FAIL status.

Regarding to (3), I agree that the signaling protocol and PCE should call the cell creation commands/primitives. Do you agree that 6top should be independent form the higher layer that has called its primitives/command? Is there any limitation that in the lack of signaling protocol, the RPL can’t call some of the 6top’ management commands/primitives (e.g. Soft cell creation)? In this case, we might need to reply to RPL, by SUCCESS or FAIL status? Did I miss anything?

Pouria

Hi Pouria,

It is the process to create a hard cell and slotframe. You see,  “MLME-SET-SLOTFRAME.confirm” and “MLME-SET-LINK.confirm” generates confirmation from L2, which usually is one of factors to generate the confirmation message to higher layer. In another word, when the status returned by  “MLME-SET-SLOTFRAME.confirm” or “MLME-SET-LINK.confirm” is False, the status reported from 6top to higher layer must be False. But, there may be some other factors also making the status False.

Make sense?

Qin

Best Wishes,
Pouria

Hi Raghuram and Pouria,

(2)  “MLME-SET-SLOTFRAME.confirm” and “MLME-SET-LINK.confirm” are primitives of 802.15.4e. The confirmation to upper layer should come from the execution of 6top commands, which may related with the two 15.4e primitives, but not exactly same.

Make sense?

Thanks
Qin

On Fri, Aug 16, 2013 at 5:52 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Raghuram, Qin,
Let me enter to your discussion
I agree with Raghuram that when the higher layer call the 6top’s commands (or .requests primitives) it should be informed about the status of its request by “command reply” or “.confirm” primitives. The status of the “.confirm” or “reply” can be success, failure or …
Am I right?
I couldn’t either find the 6top’s behavior upon receiving the “MLME-SET-SLOTFRAME.confirm” or “MLME-SET-LINK.confirm” primitives that might be called by L2. Did I miss that?

Raghuram, I just have one minor comment, in your example. I think that the RPL (L3) should use the “Create soft cell command” to ask a new cell without specifying the exact cell. Because the L3 does not have enough information to ask for reserving specific cell in L2. The “Create hard cell command” should be called by the one who has the global knowledge on network schedules, like PCE. However, I agree that the PCE by calling the “Create hard cell command” or RPL by calling “Create soft cell command” should be informed by 6top about the status of its request. For example, It might happen that PCE send a same request twice or RPL’s request can’t be serviced.
AM I right?

Pouria.

From:[email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Raghuram Sudhaakar (rsudhaak)
Sent: Thursday, August 15, 2013 9:07 PM
To: Qin Wang
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] Message flows

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

---

From: <[email-masked]>
Date: Fri, 16 Aug 2013 15:50:21 +0000

Hi Raghuram,
Just one minor comment on the diagram. I intend to show a simple flow diagram from L2 -> 6top -> higher layer. That's why I choose the simplest commands from 6top (e.g. "CREATE hardcell" and "Create Slotframe") to show the ".confirm" flow from L2 -> 6top -> higher layer. I didn't show the other potential detailed flows for these two commands.
If we intend to show the complete flow diagram of "Create Link Commands" (i.e. "CREATE hardcell" and "CREATE softcell"), there will be more details. Especially, for "Create softcell" command that also need the negotiation with the other neighbor. But, It would be helpful if we can draw these diagrams with ASCII text.
Pouria

From: Raghuram Sudhaakar (rsudhaak) [mailto:[email-masked]]
Sent: Friday, August 16, 2013 4:53 PM
To: Zand, P. (EWI); [email-masked]
Cc: [email-masked]
Subject: Re: Message flows

Qin, Pouria,

-raghuram

Qin,

Pouria

Hi Pouria,

Make sense?

Qin

Best Wishes,
Pouria

Hi Raghuram and Pouria,

Make sense?

Thanks
Qin

Pouria.

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Fri, 16 Aug 2013 15:53:25 +0000

Pouria, Agreed.

From: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday, August 16, 2013 8:50 AM
To: raghuram sudhaakar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: Message flows

Hi Raghuram,
Just one minor comment on the diagram. I intend to show a simple flow diagram from L2 -> 6top -> higher layer. That’s why I choose the simplest commands from 6top (e.g. “CREATE hardcell” and “Create Slotframe”) to show the “.confirm” flow from L2 -> 6top -> higher layer. I didn’t show the other potential detailed flows for these two commands.
If we intend to show the complete flow diagram of “Create Link Commands” (i.e. “CREATE hardcell” and “CREATE softcell”), there will be more details. Especially, for “Create softcell” command that also need the negotiation with the other neighbor. But, It would be helpful if we can draw these diagrams with ASCII text.
Pouria

To: Zand, P. (EWI); [email-masked]<mailto:[email-masked]>

Qin, Pouria,

-raghuram

Qin,

Pouria

Hi Pouria,

Make sense?

Qin

Best Wishes,
Pouria

Hi Raghuram and Pouria,

Make sense?

Thanks
Qin

Pouria.

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

---

From: Qin Wang <[email-masked]>
Date: Sat, 17 Aug 2013 21:17:39 +0800

Pouira,

I see your point. In the task item-1 "Timeslot Management methods and
formats", control flows will be defined (See the record for teleconference
on 8/9). We can address the issue you mentioned above in that document.
Maybe we should start a thread to discuss what the control flows should be,
what the message contents should be.

Regarding to the interface between 6top and RPL, my understanding is RPL
just use the TSCH schedule, instead of building the schedule by using
something like Soft cell creation. But, maybe, the status of TSCH schedule
can be taken as a factor of RPL's OF. What do you think?

Qin

On Fri, Aug 16, 2013 at 9:24 PM, <[email-masked]> wrote:

>  Qin,****
>
> ** **
>
> I completely agree with you that the status of the report/confirm form
> 6top to higher layer might be changed by other factors as well. My point is
> that, one of those factors, is the status of “.confirm” primitives received
> form L2. I think in 6top, we have to add them to the list of the factors
> that effect on the reply/confirm to higher layer. Am I right?   ****
>
> ** **
>
> Regarding to (1), I think, when the 6top commands/primitives are called by
> higher layer (either by PCE, potential signaling protocol, or temporary by
> RPL in the lack of signaling protocol) we have to send a “.confirm” to
> inform them about the status of their requests. Am I right? I would say
> that in some cases we might need to send the confirmation to PCE with the
> FAIL status.****
>
> ** **
>
> Regarding to (3), I agree that the signaling protocol and PCE should call
> the cell creation commands/primitives. Do you agree that 6top should be
> independent form the higher layer that has called its primitives/command?
> Is there any limitation that in the lack of signaling protocol, the RPL
> can’t call some of the 6top’ management commands/primitives (e.g. *Soft
> cell creation*)? In this case, we might need to reply to RPL, by SUCCESS
> or FAIL status? Did I miss anything?****
>
> ** **
>
> Pouria****
>
> ** **
>
> *Sent:* Friday, August 16, 2013 2:05 PM
>
> *To:* Zand, P. (EWI)
> Hi Pouria,****
> It is the process to create a hard cell and slotframe. You see,  “MLME-SET-SLOTFRAME.confirm”
> status False.****
> On Fri, Aug 16, 2013 at 7:44 AM, <[email-masked]> wrote:****
>
> Hi Qin,****
>

---

From: Qin Wang <[email-masked]>
Date: Sat, 17 Aug 2013 21:33:06 +0800

Hi Raghuram,

In the Table 44g—MLME-SET-LINK.confirm parameters of IEEE802.15.4e, the
status value is defined as follows.

SUCCESS,
INVALID_PARAMETER,
UNKNOWN_LINK,
MAX_LINKS_EXCEEDED

It does not include the factors like Cell Conflict, which are introduced in
6top.

Make sense?

Qin

On Fri, Aug 16, 2013 at 10:53 PM, Raghuram Sudhaakar (rsudhaak) <
[email-masked]> wrote:

>  Qin, Pouria,
> The message flow diagram idescribes the scenario perfectly. I think it
> should go in the document or at least in an appendix to the document. I
> would make one change though, instead of have two command from L3 to 6top
> (create hard cell, create soft cell) we can have only one command (install
> route) and depending on the type of L3 6top decides whether to create  a
> hard or soft cell. This will help 6top ensure that there are minimal
> conflicts (as pointed out already in this discussion) and in future we may
> be able to work with PCE and RPL simultaneously. This scenario of working
> with multiple L3's may occur when there are multiple overlay/logical
> networks are being created over the same physical network.
>
>  The only caveat to this though is that we need to define a command from
> L3 to 6top that will help 6top identify the L3 protocol. Or we could also
> include a L3 protocol type field in every message from L3 -> 6top.
>
>  Qin mentioned that the status returned by L2 for the the slot
> installation process can be forwarded to L3 by 6top but in some cases we
> may there may be other factors also. I thought about this but I can't
> identify what other factors might affect the reply the 6top will send to
> L3. Can you please identify what factors you had in mind. I think it is
> important we nail down this flow very clearly and take care of all edge
> cases.
>
>  -raghuram
>
>   From: "[email-masked]" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Cc: raghuram sudhaakar <[email-masked]>, "[email-masked]" <
> [email-masked]>
> *From:* Qin Wang [mailto:[email-masked] <[email-masked]>]
> *From:[email-masked] [mailto:[email-masked]] *On Behalf

---

From: <[email-masked]>
Date: Sat, 17 Aug 2013 15:56:12 +0000

Hi Qin,

I agree with starting a new threat and discuss about the details of the control flows.

Regarding to the interface between 6top and higher layer (e.g. RPL), Let me explain my point with an example: Let's consider a new joined device, node A, that needs some cells to start sending its RPL control packets to its parent node B. How does node A, upon choosing a new parent (node B), can reserve cells (e.g. for exchanging RPL control packets like DAO or DIO)? How does node B (or node B' parent), who has just received node A' DAO packet as its children, can reserve extra cells toward their parent. In the lack of signaling protocol and without installing a track, is there any primitive that the RPL or 6top can use, to reserve some cells locally based on it DAO and DIO packet rates with their parents?
In order to handle this situation in 6top, don't we need to import some information from the parent table and route table (in storing mode) from L3 to 6top? I mean how does a RPL parent inform 6top about its children and descendants numbers and the potential control messages rate (e.g. DAO) that it should forward toward the DODAG root? In addition how does the new device inform the 6top about its new parent?
You might say that DAO and DIO transmission rate might changes overtime and reserving resources doesn't make sense. But let's consider RPL control packets just as an example.
Am I missing anything?

Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Saturday, August 17, 2013 3:18 PM
To: Zand, P. (EWI)
Cc: Raghuram Sudhaakar (rsudhaak); [email-masked]
Subject: Re: Message flows

Pouira,

I see your point. In the task item-1 "Timeslot Management methods and formats", control flows will be defined (See the record for teleconference on 8/9). We can address the issue you mentioned above in that document. Maybe we should start a thread to discuss what the control flows should be, what the message contents should be.

Regarding to the interface between 6top and RPL, my understanding is RPL just use the TSCH schedule, instead of building the schedule by using something like Soft cell creation. But, maybe, the status of TSCH schedule can be taken as a factor of RPL's OF. What do you think?

Qin

On Fri, Aug 16, 2013 at 9:24 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Qin,

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Make sense?

Qin

Best Wishes,
Pouria

Hi Raghuram and Pouria,

Make sense?

Thanks
Qin

Pouria.

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

---

From: Qin Wang <[email-masked]>
Date: Sun, 18 Aug 2013 05:33:19 +0800

Hi Pouria,

According to the new version of Charter, in the current step, we only
consider the static case of building TSCH schedule. That means the new node
(node B) will use shared cells to send RPL control messages like DAO to the
existing node (node A). The set of shared cells will be advertised in EB by
node A. And, in the shared cells, node A should be awake for listening (at
lease at the beginning of timeslots) . So, even in the lack of signaling
protocol and without installing a track, RPL should be able to work. Right?

Then, if RPL or other upper layer wants more bandwidth, some
centralized/distributed reservation mechanism will be needed. That will be
addressed in the next step. What do you think?

Qin

On Sat, Aug 17, 2013 at 11:56 PM, <[email-masked]> wrote:

>  Hi Qin,****
>
> ** **
>
> I agree with starting a new threat and discuss about the details of the
> control flows.****
>
> ** **
>
> ** **
>
> Regarding to the interface between 6top and higher layer (e.g. RPL), Let
> me explain my point with an example: Let’s consider a new joined device,
> node A, that needs some cells to start sending its RPL control packets to
> its parent node B. How does node A, upon choosing a new parent (node B),
> can reserve cells (e.g. for exchanging RPL control packets like DAO or
> DIO)? How does node B (or node B’ parent), who has just received node A’
> DAO packet as its children, can reserve extra cells toward their parent. In
> the lack of signaling protocol and without installing a track, is there any
> primitive that the RPL or 6top can use, to reserve some cells locally based
> on it DAO and DIO packet rates with their parents? ****
>
> In order to handle this situation in 6top, don’t we need to import some
> information from the parent table and route table (in storing mode) from L3
> to 6top? I mean how does a RPL parent inform 6top about its children and
> descendants numbers and the potential control messages rate (e.g. DAO) that
> it should forward toward the DODAG root? In addition how does the new
> device inform the 6top about its new parent?  ****
>
> You might say that DAO and DIO transmission rate might changes overtime
> and reserving resources doesn’t make sense. But let’s consider RPL control
> packets just as an example.****
>
> Am I missing anything?  ****
>
> ** **
>
> Pouria****
>
> ** **
>
> *Sent:* Saturday, August 17, 2013 3:18 PM
>
> *To:* Zand, P. (EWI)
> Pouira,****
> what the message contents should be.****
>
> ** **
>
> can be taken as a factor of RPL's OF. What do you think?****
>
> ** **
>
> Qin****
>
> ** **
>
> ** **
>
> ** **
>
> ** **
>
> On Fri, Aug 16, 2013 at 9:24 PM, <[email-masked]> wrote:****
>
> Qin,****
>
>  ****
>
> *Sent:* Friday, August 16, 2013 2:05 PM****
>
>
> *To:* Zand, P. (EWI)

---

From: <[email-masked]>
Date: Sat, 17 Aug 2013 22:13:38 +0000

Hi Qin,

Many thanks for your clarification.
Agreed,

Pouria

From: Qin Wang [mailto:[email-masked]]
Sent: Saturday, August 17, 2013 11:33 PM
To: Zand, P. (EWI)
Cc: Raghuram Sudhaakar (rsudhaak); [email-masked]
Subject: Re: Message flows

Hi Pouria,

According to the new version of Charter, in the current step, we only consider the static case of building TSCH schedule. That means the new node (node B) will use shared cells to send RPL control messages like DAO to the existing node (node A). The set of shared cells will be advertised in EB by node A. And, in the shared cells, node A should be awake for listening (at lease at the beginning of timeslots) . So, even in the lack of signaling protocol and without installing a track, RPL should be able to work. Right?

Then, if RPL or other upper layer wants more bandwidth, some centralized/distributed reservation mechanism will be needed. That will be addressed in the next step. What do you think?

Qin

On Sat, Aug 17, 2013 at 11:56 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

Pouria

To: Zand, P. (EWI)

Pouira,

Qin

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Make sense?

Qin

Best Wishes,
Pouria

Hi Raghuram and Pouria,

Make sense?

Thanks
Qin

Pouria.

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 19 Aug 2013 08:32:36 -0700

Qin, all,

I agree with you analysis; I believe it is important that we first start
with the simplest case, i..e a static schedule of shared slots. At the end
this charter, we will have clearly identified how a full network operates
in that case, and we then can start thinking about using a
centralized/distributed scheduling mechanism.

By then, we will have defined how to represent slots and cells in a
non-verbose way (we started thinking about using BSON) as well as
statistics and commands. Ideally, we want that format to be usable in the
centralized and distributed scheduling case, so although we are not talking
about this in the scope of this charter, we need to be aware how these
formats will be used, and we therefore need to identify the flows.

Coming back to Raghuram's case, I would argue that the cleanest approach
for reserving cells is to have the upper layer explicitly reserve either
soft or hard cells. This does not prevent a hybrid case, where one could
imagine reserving a piece of the schedule for hard, another for soft cells.
I believe it is, however, cleaner than having 6top ask about L3 and somehow
know what to do depending on the L3 being used.

I believe there are two immediate next steps:
- in light of this discussion, identifying what's missing from the basic
draft. Do you see anything obvious?
- continue the work on BSON. Before delving into the representation of the
information, I would first identify what the contents of the different
signaling packets are, which can easily be done in e.g. JSON.

Does this make sense? If we have a rough agreement, I propose we work on
this and come up with a couple of slides for both items, to be discussed on
Friday.

Thomas

On Sat, Aug 17, 2013 at 3:13 PM, <[email-masked]> wrote:

>  Hi Qin,****
>
> ** **
>
> Many thanks for your clarification.****
>
> Agreed,****
>
> ** **
>
> Pouria****
>
> ** **
>
> *Sent:* Saturday, August 17, 2013 11:33 PM
>
> *To:* Zand, P. (EWI)
> addressed in the next step. What do you think?****
>
> ** **
>
> Qin****
>
> ** **
>
> ** **
>
> ** **
>
> On Sat, Aug 17, 2013 at 11:56 PM, <[email-masked]> wrote:****
>
> Hi Qin,****
>
>  ****
>
> *Sent:* Saturday, August 17, 2013 3:18 PM****
>
>
> *To:* Zand, P. (EWI)
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Qin Wang <[email-masked]>
Date: Tue, 20 Aug 2013 01:04:58 +0800

Hi Thomas,

I totally agree with you. Can you set two threads corresponding the two
items in your email? I think it would be more organized.

Thanks
Qin

On Mon, Aug 19, 2013 at 11:32 PM, Thomas Watteyne <
[email-masked]> wrote:

>> Regarding to (1), I think, when the 6top commands/primitives are called
>> by higher layer (either by PCE, potential signaling protocol, or temporary
>> by RPL in the lack of signaling protocol) we have to send a “.confirm” to
>> Regarding to (2), this is my understanding from the procedure for
>> creating a hard cell and slotframe. Am I missing something from 6top?****
>>
>>  ****
>>
>> ****
>>
>> Best Wishes,****
>>
>> Pouria****
>>
>>  ****
>>
>> Raghuram, I just have one minor comment, in your example. I think that
>> the RPL (L3) should use the “Create soft cell command” to ask a new cell
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Raghuram Sudhaakar (rsudhaak)
>> Do you think finding the common requirements from 6top to L3 flows
>> between RPL and PCE is a good place to start? I am sure there are going to
>> be some specific requirements for each but they can be added as PCE or RPL
>> specific primitives. I am not suggesting that we implement specific
>> primitives for every L3 protocol, but once we cover RPL and PCE I think we
>> will satisfy the requirements of most L3s.****
>>
>>  ****
>>
>> (1) The flows from 6top -> L2 have been addressed quite extensively in
>> the draft already. There are a few flows from L2 -> 6top that have to be
>> Sorry for the late response. It is welcome for you to add flow
>> information if necessary.****
>>
>>  ****
>>
>> *Reply-To: *"[email-masked]" <
>> [email-masked]>

---

From: "Raghuram Sudhaakar (rsudhaak)" <[email-masked]>
Date: Mon, 19 Aug 2013 17:08:17 +0000

Thomas,
Agreed. Slides for Friday are a good idea.

-raghuram

From: Qin Wang <[email-masked]<mailto:[email-masked]>>
Date: Monday, August 19, 2013 10:04 AM
To: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Cc: 6TSCH <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tsch] Message flows

Hi Thomas,

I totally agree with you. Can you set two threads corresponding the two items in your email? I think it would be more organized.

Thanks
Qin

On Mon, Aug 19, 2013 at 11:32 PM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Qin, all,

I agree with you analysis; I believe it is important that we first start with the simplest case, i..e a static schedule of shared slots. At the end this charter, we will have clearly identified how a full network operates in that case, and we then can start thinking about using a centralized/distributed scheduling mechanism.

By then, we will have defined how to represent slots and cells in a non-verbose way (we started thinking about using BSON) as well as statistics and commands. Ideally, we want that format to be usable in the centralized and distributed scheduling case, so although we are not talking about this in the scope of this charter, we need to be aware how these formats will be used, and we therefore need to identify the flows.

Coming back to Raghuram's case, I would argue that the cleanest approach for reserving cells is to have the upper layer explicitly reserve either soft or hard cells. This does not prevent a hybrid case, where one could imagine reserving a piece of the schedule for hard, another for soft cells. I believe it is, however, cleaner than having 6top ask about L3 and somehow know what to do depending on the L3 being used.

I believe there are two immediate next steps:
- in light of this discussion, identifying what's missing from the basic draft. Do you see anything obvious?
- continue the work on BSON. Before delving into the representation of the information, I would first identify what the contents of the different signaling packets are, which can easily be done in e.g. JSON.

Does this make sense? If we have a rough agreement, I propose we work on this and come up with a couple of slides for both items, to be discussed on Friday.

Thomas

On Sat, Aug 17, 2013 at 3:13 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin,

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Qin

Regarding to the interface between 6top and higher layer (e.g. RPL), Let me explain my point with an example: Let’s consider a new joined device, node A, that needs some cells to start sending its RPL control packets to its parent node B. How does node A, upon choosing a new parent (node B), can reserve cells (e.g. for exchanging RPL control packets like DAO or DIO)? How does node B (or node B’ parent), who has just received node A’ DAO packet as its children, can reserve extra cells toward their parent. In the lack of signaling protocol and without installing a track, is there any primitive that the RPL or 6top can use, to reserve some cells locally based on it DAO and DIO packet rates with their parents?
In order to handle this situation in 6top, don’t we need to import some information from the parent table and route table (in storing mode) from L3 to 6top? I mean how does a RPL parent inform 6top about its children and descendants numbers and the potential control messages rate (e.g. DAO) that it should forward toward the DODAG root? In addition how does the new device inform the 6top about its new parent?
You might say that DAO and DIO transmission rate might changes overtime and reserving resources doesn’t make sense. But let’s consider RPL control packets just as an example.
Am I missing anything?

Pouria

To: Zand, P. (EWI)

Pouira,

Qin

Pouria

To: Zand, P. (EWI)

Hi Pouria,

Make sense?

Qin

Best Wishes,
Pouria

Hi Raghuram and Pouria,

Make sense?

Thanks
Qin

Pouria.

HI Qin,

-raghuram

Hi Raghuram,

Thanks
Qin

Hi Raghuram,

What do you think?

Qin

-raghuram

Hi Raghuram,

X

-raghuram

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch