Hi Malisa.
Thanks to your explanation, I get the point.
how could we ensure that the “acceptable” amount of unauthenticated traffic
that actually gets forwarded does not trigger cell allocation?
It'd be fine to trigger cell allocations by *acceptable* amount of
unauthenticated traffic if necessary. Otherwise, important packets,
authenticated traffic for applications, could be dropped because of no
room in the TX queue filled with unauthenticated packets.
Or, the intermediate route should drop more "unauthenticated" traffic if
you don't want to trigger. But, even doing this, we cannot ensure the
first relayed join request since the last hour or year does not trigger
a cell allocation.
The cells used to transport the join traffic will be marked as used by MSF, and
depending on the amount of regular traffic as well as the join rate limit, this
may cause the cell allocation threshold to be surpassed. Right?
Yes, it causes another cell allocation.
Any L2 component including MSF doesn't case about information in the MAC
frame payload field, although MSF (a 6TisCH scheduling function) is not
on the path of outgoing packets in the protocol stack:
https://tools.ietf.org/html/draft-ietf-6tisch-architecture-28#section-3.7
+--------+--------+
| Applis | CoJP |
+--------+--------+--------------+-----+
| CoAP / OSCORE | 6LoWPAN ND | RPL |
+-----------------+--------------+-----+
| UDP | ICMPv6 |
+-----------------+--------------------+
| IPv6 |
+--------------------------------------+----------------------+
| 6LoWPAN HC / 6LoRH HC | Scheduling Functions |
+--------------------------------------+----------------------+
| 6top inc. 6top protocol |
+-------------------------------------------------------------+
| IEEE Std. 802.15.4 TSCH |
+-------------------------------------------------------------+
Figure 4: 6TiSCH Protocol Stack
Thank you, again!
Yatch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
