Subject: [6tisch] 6TiSCH Protocol Stack in draft-ietf-6tisch-architecture-12

From: Yasuyuki Tanaka <[email-masked]>
Date: Wed, 29 Nov 2017 14:33:04 +0900

Hello Pascal,

I have one minor comment on Figure 1 of the draft;

   https://tools.ietf.org/html/draft-ietf-6tisch-architecture-12#section-3.1

My suggestion is to put "6LoWPAN HC / 6LoRH" directly on "IEEE Std 
802.15.4 TSCH" and to add one box labeled with "Scheduling Functions". 
It would look like...

(suggested version)

       +-----+-----+
       |    COMI   |
       +-----+-----+-----+------+-------+-----+
       | CoAP/EDHOC/COSE |  6LoWPAN ND  | RPL |
       +-----+-----+-----+------+-------+-----+
       |       UDP       |        ICMPv6      |
       +-----+-----+-----+-----+-------+------+------------------------+
       |                 IPv6                 |  Scheduling Functions  |
       +--------------------------------------+------------------------+
       |        6LoWPAN HC   /   6LoRH        |      6top protocol     |
       +--------------------------------------+------------------------+
       |                     IEEE Std 802.15.4 TSCH                    |
       +---------------------------------------------------------------+

(current version)

       +-----+-----+
       |    COMI   |
       +-----+-----+-----+------+-------+-----+
       | CoAP/EDHOC/COSE |  6LoWPAN ND  | RPL |
       +-----+-----+-----+------+-------+-----+
       |       UDP       |          ICMP      |
       +-----+-----+-----+-----+-------+------+----+
       |                 IPv6                      |
       +-------------------------------------------+
       |             6LoWPAN HC   /   6LoRH        |
       +-------------------------------------------+
       |                   6top                    |
       +-------------------------------------------+
       |             IEEE Std 802.15.4 TSCH        |
       +-------------------------------------------+

"ICMP" is replaced with "ICMPv6" as well.

Thanks!

Best,
Yatch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Nov 2017 08:31:27 +0000

Hello Yatch:

Great point. You’ll note that 6P runs at the top of the MAC and below 6LoWPAN and IP, so I’d rather not group it as you suggest.

What about the following:

   +-----+-----+

   |    COMI   |

   |       UDP       |      ICMPv6        |

   +-----+-----+-----+-----+-------+------+

   |                 IPv6                 |

   +--------------------------------------+----------------------+

   |     6LoWPAN HC   /   6LoRH HC        | Scheduling Functions |

   +--------------------------------------+----------------------+

   |     6top (to be IEEE Std 802.15.12) inc. 6top protocol (6P) |

   +-------------------------------------------------------------+

   +-------------------------------------------------------------+

?

Pascal

-----Original Message-----
From: Yasuyuki Tanaka [mailto:[email-masked]]
Sent: mercredi 29 novembre 2017 06:33
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]
Subject: 6TiSCH Protocol Stack in draft-ietf-6tisch-architecture-12

Hello Pascal,

It would look like...

(suggested version)

       +-----+-----+

       |    COMI   |

       |       UDP       |        ICMPv6      |

(current version)

       +-----+-----+

       |    COMI   |

       |       UDP       |          ICMP      |

       |                 IPv6                      |

      |             6LoWPAN HC   /   6LoRH        |

       |                   6top                    |

Thanks!

Best,

Yatch

---

From: Randy Turner <[email-masked]>
Date: Wed, 29 Nov 2017 08:28:00 -0500

Hi Guys,

I think this stack diagram looks ok — the “Scheduling Functions” block does not add a protocol encapsulation (on the wire) as the other blocks do, correct? It’s just an internal set of algorithms ?

If so, you could probably leave this off as “internal APIs” or non  on-the-wire functionality would not fit with the rest of the diagram - if non on-the-wire functionality is included then some type of visual cue would be
needed by RPL to indicate that RPL does not only utilize ICMPv6 for its’ functionality but also probably needs connectivity with the “IPv6” block for routing table access, or connectivity down to the TSCH block for neighbor table state changes, etc.

However, all that being said, it’s not a big deal, I’m interpreting this stack as an “on the wire” layering showing where protocol headers are encapsulated/deencapsulated, and I’m assuming there’s a scheduling function somewhere, but it’s really not a protocol layer.  Am I interpreting this correctly?

Thx,
Randy

> On Nov 29, 2017, at 3:31 AM, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Yatch:
>  
> From: Yasuyuki Tanaka [mailto:[email-masked] <mailto:[email-masked]>] 
> To: Pascal Thubert (pthubert) <[email-masked] <mailto:[email-masked]>>
> Cc: [email-masked] <mailto:[email-masked]>
>    https://tools.ietf.org/html/draft-ietf-6tisch-architecture-12#section-3.1 <https://tools.ietf.org/html/draft-ietf-6tisch-architecture-12#section-3.1>
>  
> _______________________________________________
> 6tisch mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6tisch <https://www.ietf.org/mailman/listinfo/6tisch>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 29 Nov 2017 16:07:41 +0000

Hello Randy

The SF actually triggers 6top messages for bandwidth allocation and the messages can carry opaque (to 6P) SF chat. So no it is not entirely internal algorithms.

Cheers,

Pascal

From: Randy Turner [mailto:[email-masked]]
Sent: mercredi 29 novembre 2017 14:28
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: Yasuyuki Tanaka <[email-masked]>; [email-masked]
Subject: Re: [6tisch] 6TiSCH Protocol Stack in draft-ietf-6tisch-architecture-12

Hi Guys,

Thx,
Randy

On Nov 29, 2017, at 3:31 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:

Hello Yatch:

   +-----+-----+
   |    COMI   |

?

Pascal
-----Original Message-----
From: Yasuyuki Tanaka [mailto:[email-masked]]
Sent: mercredi 29 novembre 2017 06:33
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: 6TiSCH Protocol Stack in draft-ietf-6tisch-architecture-12

Hello Pascal,

(suggested version)

       +-----+-----+
       |    COMI   |

(current version)

       +-----+-----+
       |    COMI   |

Thanks!

Best,
Yatch

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

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 30 Nov 2017 10:47:21 +0900

Thank you, Randy, Pascal!

As Pascal said, some 6P fields may be redefined by a certain SF. Here is 
an example from draft-ietf-6tisch-6top-protocol-09:

>    The CellOptions is an opaque set of bits, sent unmodified to the SF.
>    The SF MAY redefine the format of the CellOptions bitmap.  The SF MAY
>    redefine the meaning of the CellOptions bitmap.
 
https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-09#section-3.2.3

In this sense, having "Scheduling Functions" in the figure could make 
some sense.

Regarding 6top, I may have a misunderstanding on what 6top is... I need 
to read the following paragraph carefully...

> 4.2.1.  6top
> 
>    6top is a logical link control sitting between the IP layer and the
>    TSCH MAC layer, which provides the link abstraction that is required
>    for IP operations.  The 6top operations are specified in
>    [I-D.ietf-6tisch-6top-protocol].  In particular, 6top provides a
>    management interface that enables an external management entity to
>    schedule cells and slotFrames, and allows the addition of
>    complementary functionality, for instance to support a dynamic
>    schedule management based on observed resource usage as discussed in
>    Section 4.4.2.
 
https://tools.ietf.org/html/draft-ietf-6tisch-architecture-13#section-4.2.1

Anyway, from my view point, putting IPv6 over 6top *protocol* seems 
something wrong. 6top protocol doesn't encapsulate an IPv6 packet; In 
other words, a MAC frame having an IPv6 packet doesn't necessarily have 
a 6top protocol message at the same time.

Best,
Yatch

On 2017/11/30 1:07, Pascal Thubert (pthubert) wrote:
> Hello Randy
> 
> The SF actually triggers 6top messages for bandwidth allocation and the 
> messages can carry opaque (to 6P) SF chat. So no it is not entirely 
> internal algorithms.
> 
> Cheers,
> 
> Pascal
> 
> *From:*Randy Turner [mailto:[email-masked]]
> *Sent:* mercredi 29 novembre 2017 14:28
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* Yasuyuki Tanaka <[email-masked]>; [email-masked]
> *Subject:* Re: [6tisch] 6TiSCH Protocol Stack in 
> draft-ietf-6tisch-architecture-12
> 
> Hi Guys,
> 
> I think this stack diagram looks ok — the “Scheduling Functions” block 
> does not add a protocol encapsulation (on the wire) as the other blocks 
> do, correct? It’s just an internal set of algorithms ?
> 
> If so, you could probably leave this off as “internal APIs” or non 
>   on-the-wire functionality would not fit with the rest of the diagram - 
> if non on-the-wire functionality is included then some type of visual 
> cue would be
> 
> needed by RPL to indicate that RPL does not only utilize ICMPv6 for its’ 
> functionality but also probably needs connectivity with the “IPv6” block 
> for routing table access, or connectivity down to the TSCH block for 
> neighbor table state changes, etc.
> 
> However, all that being said, it’s not a big deal, I’m interpreting this 
> stack as an “on the wire” layering showing where protocol headers are 
> encapsulated/deencapsulated, and I’m assuming there’s a scheduling 
> function somewhere, but it’s really not a protocol layer.  Am I 
> interpreting this correctly?
> 
> Thx,
> 
> Randy
> 
>     On Nov 29, 2017, at 3:31 AM, Pascal Thubert (pthubert)
>     <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hello Yatch:
> 
>     Great point. You’ll note that 6P runs at the top of the MAC and
>     below 6LoWPAN and IP, so I’d rather not group it as you suggest.
> 
>     Cc:[email-masked] <mailto:[email-masked]>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 30 Nov 2017 05:04:08 +0000

Hello Yatch:

I published -13 with the corrected picture and some other refreshes.

IPv6 runs over 6top which is the sublayer that decides which time slot is used for which packet (scheduler). 6P is considered as part of that layer.

 It is unclear whether some future SF also impacts the scheduler but I expect it may, e.g. to hint on which time slot gets which flow.

 The picture is better now thanks to your suggestions. I do not see how to improve it further on that matter but I’m open to suggestions!

Take care,

Pascal

Le 30 nov. 2017 à 02:47, Yasuyuki Tanaka <[email-masked]<mailto:[email-masked]>> a écrit :

As Pascal said, some 6P fields may be redefined by a certain SF. Here is an example from draft-ietf-6tisch-6top-protocol-09:

In this sense, having "Scheduling Functions" in the figure could make some sense.

Regarding 6top, I may have a misunderstanding on what 6top is... I need to read the following paragraph carefully...

4.2.1.  6top

Anyway, from my view point, putting IPv6 over 6top *protocol* seems something wrong. 6top protocol doesn't encapsulate an IPv6 packet; In other words, a MAC frame having an IPv6 packet doesn't necessarily have a 6top protocol message at the same time.

Best,
Yatch

*To:* Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
*Cc:* Yasuyuki Tanaka <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
*Subject:* Re: [6tisch] 6TiSCH Protocol Stack in draft-ietf-6tisch-architecture-12
   <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:
   -----Original Message-----
   From: Yasuyuki Tanaka [mailto:[email-masked]]
   Sent: mercredi 29 novembre 2017 06:33
   To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>
   <mailto:[email-masked]>>
   Cc:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
   Subject: 6TiSCH Protocol Stack in draft-ietf-6tisch-architecture-12
   Hello Pascal,
   I have one minor comment on Figure 1 of the draft;
   https://tools.ietf.org/html/draft-ietf-6tisch-architecture-12#section-3.1
   My suggestion is to put "6LoWPAN HC / 6LoRH" directly on "IEEE Std
   802.15.4 TSCH" and to add one box labeled with "Scheduling Functions".
   It would look like...
   (suggested version)
           +-----+-----+
           |    COMI   |
           |                 IPv6                 |  Scheduling
   Functions  |
           |        6LoWPAN HC   /   6LoRH        |      6top
   protocol     |
   [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 30 Nov 2017 14:30:27 +0900

Hello Pascal,

 > I published -13 with the corrected picture and some other refreshes.

Thank you; I like this picture better than one in -12! :-)

Best,
Yatch

On 2017/11/30 14:04, Pascal Thubert (pthubert) wrote:
> IPv6 runs over 6top which is the sublayer that decides which time slot 
> is used for which packet (scheduler). 6P is considered as part of that 
> layer.
> 
>   It is unclear whether some future SF also impacts the scheduler but I 
> expect it may, e.g. to hint on which time slot gets which flow.
> 
>   The picture is better now thanks to your suggestions. I do not see how 
> to improve it further on that matter but I’m open to suggestions!
> 
> Take care,
> 
> Pascal