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