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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]<mailto:[e-mail]>> a écrit :

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:[e-mail]]
*Sent:* mercredi 29 novembre 2017 14:28
*To:* Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
*Cc:* Yasuyuki Tanaka <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
*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)
   <[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>> 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.
   What about the following:
       +-----+-----+
       |    COMI   |
       +-----+-----+-----+------+-------+-----+
       | CoAP/EDHOC/COSE |  6LoWPAN ND  | RPL |
       +-----+-----+-----+------+-------+-----+
       |       UDP       |      ICMPv6        |
       +-----+-----+-----+-----+-------+------+
       |                 IPv6                 |
       +--------------------------------------+----------------------+
       |     6LoWPAN HC   /   6LoRH HC        | Scheduling Functions |
       +--------------------------------------+----------------------+
       |     6top (to be IEEE Std 802.15.12) inc. 6top protocol (6P) |
       +-------------------------------------------------------------+
       |                 IEEE Std 802.15.4 TSCH                      |
       +-------------------------------------------------------------+
   ?
   Pascal
   -----Original Message-----
   From: Yasuyuki Tanaka [mailto:[e-mail]]
   Sent: mercredi 29 novembre 2017 06:33
   To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>
   <mailto:[e-mail]>>
   Cc:[e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
   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   |
           +-----+-----+-----+------+-------+-----+
           | 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
   _______________________________________________
   6tisch mailing list
   [e-mail]<mailto:[e-mail]> <mailto:[e-mail]>
   https://www.ietf.org/mailman/listinfo/6tisch