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 protected]]
*Sent:* mercredi 29 novembre 2017 14:28
*To:* Pascal Thubert (pthubert) <[email protected]>
*Cc:* Yasuyuki Tanaka <[email protected]>; [email protected]
*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 protected] <mailto:[email protected]>> 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:[email protected]]
Sent: mercredi 29 novembre 2017 06:33
To: Pascal Thubert (pthubert) <[email protected]
<mailto:[email protected]>>
Cc:[email protected] <mailto:[email protected]>
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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
