Hi Marco,
Although I'm still not sure how effective the selective jamming attack
is in reality, the proposed operation is considered as part of the
6TiSCH scheduling function.
> At IETF 105, this work was put on hold, without proceeding to check
> for WG adoption as requested by the authors.
atch! I will have those comments integrated into next version.
---- Original message
From: Yasuyuki Tanaka mailto:yasuyuki.tan...@inria.fr>>
Date: Fri, Dec 13, 2019, 12:01 AM
To: Tengfei Chang mailto:tengfei.ch...@gmail.com>>
Cc: 6tisch@ietf.or
Hi Tengfei,
Thank you for the updates. The new version addresses my comments. Here
are a couple of trivial comments:
(Section 5.1)
The node MUST maintain the following counters for the selected parent
on both negotiated Tx and Rx cells:
To my understanding, we have separate pairs of
Thank you, Tengfei.
> On Dec 6, 2019, at 22:49, Tengfei Chang wrote:
>
> Handling DSCP value will be a per-packet process. Can we pass DCSP value
> to the TSCH layer using the interface for transmission defined by
> IEEE802.15.4? I don't think so.
>
> TC: Not sure this is a standard way to
Hi Tengfei,
How do we distinguish multiple MSF sessions?
What if two MSF sessions have a same "selected parent", and then one of
them selects another selected parent? How many negotiated cells should
be taken over to the new selected parent?
These are not covered by the current text, and I
Hi Pascal, Tengfei,
On 12/6/2019 6:48 PM, Tengfei Chang wrote:
Yes, MSF indeed aware of the routing information such as RPL parent, I
consider this is like an information stored at IPv6 layer that MSF can
read it from without touching the frame L2 payload.
In such sense, I could consider the
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
Hi,
On 12/5/2019 5:17 PM, Tengfei Chang wrote:
Does anyone know other way to make the SF not adapt to unsecured traffic
without knowing upper layer field?
I have no idea...
Why can't the "join rate" avoid such undesired cell allocations? If the
join rate is properly configured, incoming
Hi Tengfei,
Related to MAX_NUMCELLS, LIM_NUMCELLSUSED_HIGH and LIM_NUMCELLSUSED_LOW
need to be revisited.
In Section 5.1., these values are used in the following way:
The counters are used as follows:
1. Both NumCellsElapsed and NumCellsUsed are initialized to 0 when
the node
Thank you, Pascal for your comment.
On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
RPL underneath is designed to operate with multiple parents, and for a good
reason.
I understand that point.
My point is, rephrasing the word alone couldn't be enough.
Bandwidth allocation doesn’t
Hi Pascal,
pascal> My problem is that there’s only one preferred parent, but a
pascal> node may use several parents for data traffic. This is why we
pascal> build dodags in the first place.
pascal>
pascal> I believe that the node may allocate cells with all of those
pascal> “selected parents” if
Thank you, Tengfei.
TC: we only mentioned 6P SIGNAL, because that's 6P leaves it to scheduling
function, which must mention how it is used.
I understand that Section 6 corresponds to the following point mentioned
Section 4.2 of RFC 8480:
rfc8480> The specification for an SF
rfc8480> ...
Hi,
This is an open issue, what return code to return when there is no available
cell.
Christian raised it before:
https://mailarchive.ietf.org/arch/msg/6tisch/Awiip2xOfwZTPyg1jQIeIOyqSgk
As per RFC8480:
- RC_SUCCESS with an empty list will be returned
- RC_ERR_BUSY is defined to be
Hi Esteban,
> * Maybe out of the scope but, should not be defined here a housekeeping
> function that removes unused negotiated cells (TX or RX)? For example
> for cells that can't be removed with a 6P transaction (e.g. nodes are
> not in range any more).
It'd be nice to mention something there,
Thank you, Tengfei and the other authors, for the update!
Here are my comments:
[Major] Negotiated RX cell (Section 4.6)
https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-4.6
If MSF is designed for regular upstream traffic, I don't think we need
the negotiated RX cell that is
Thanks, Diego!
I think, if SeqNum=0 has the special meaning, 6P would need to pass a received
SeqNum to a corresponding SF... But, my understandings is that, SeqNum is
maintained only by 6P and not revealed to SFs... An alternative way to tell
a power-cycle event to the peer would have been
Hi Xavi,
> What is the issue you see with this?
At least, there is an inconsistency in RFC8480. Here is another example:
https://tools.ietf.org/html/rfc8480#section-3.2.2
rfc8480> 6P Request, 6P Response, and 6P Confirmation messages for a given
rfc8480> transaction MUST share the same
Hi Xavi,
Thank you for your reply.
On 4/22/2019 5:34 PM, Xavi Vilajosana Guillen wrote:
When node B power cycles loses the last seen seqNum. Its stored value is then 0
and hence when it receives the request responds with the error and with the
stored last seen seqnum (0).
does it make
Hi,
I came across a question in RFC8480 (6P), which looks like an error to
me... Can anybody help? This is about the SeqNum field of the 6P header.
Section 3.2.2 defines SeqNum like this:
[https://tools.ietf.org/html/rfc8480#section-3.2.2]
> SeqNum: The sequence number associated with the 6P
Thank you, the authors!
I confirmed most of my comments to the previous version have been
addressed. It reads better :-)
Here are my comments: two comments are major, the rest are minor.
[major: usage of the autonomous cell and the managed cell]
The draft specifies rules what type of frames
Hi Marco,
I'd like to ask you to help me understand the attack (>_<)
https://tools.ietf.org/html/draft-tiloca-6tisch-robust-scheduling-01#section-3.2
> 3.2. Attack Example
>
> (snip)
>
>2. The adversary picks a channel 'f*' at random, and monitors it for
>N_C consecutive
Thank you, Tengfei.
Additional and following-up comments:
[Section 5.1, what to do after timeout of a 6P transaction]
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02#section-5
The draft does not say anything about how to handle timeout of a 6P
transaction. I know, the initiator of the
Hi,
Thank you, Tengfei and the other authors, for updating the draft!
I'm sharing my comments on the latest version.
https://tools.ietf.org/html/draft-ietf-6tisch-msf-02
[Security Consideration on autonomous SHARED cell allocation]
4.5. Step 4 - Installing Autonomous Cells for each
Hi Tero,
Thank you for the clear explanation!
Yatch
> On Dec 11, 2018, at 11:13, Tero Kivinen wrote:
>
> Yasuyuki Tanaka writes:
>> Is there any update on CID 93? I checked LB150 Consolidated Comments
>> (rev.12)[1], but the item for CID 93 is filtered out for some
&
Thank you, Pascal.
> Please let me know if you intend to provide a review soon.
Yes. Here are my additional but minor comments:
---
[Definition of 6P / Section 2.2 and Figure 1]
In the terminology section, 6top is explained as follows:
6top (6TiSCH Operation Sublayer): The next highest
Hi Pascal,
I'm reviewing the architecture draft, although the deadline has already
passed... I have one comment.
I see some ideas which don't have concrete protocol specifications discussed as
WG drafts, for instance, centralized reservation and tracks. They look like
kind of "concepts" at
Hi Tero,
Is there any update on CID 93? I checked LB150 Consolidated Comments
(rev.12)[1], but the item for CID 93 is filtered out for some reason...
[1]
https://mentor.ieee.org/802.15/dcn/18/15-18-0433-12-04md-lb150-consolidated-comments.xlsx
Best,
Yatch
> On Oct 6, 2018, at 3:28, Tero
:-)
Best,
Yatch
> On Oct 6, 2018, at 3:28, Tero Kivinen wrote:
>
> Yasuyuki Tanaka writes:
>> I came across another question on the retransmission algorithm.
>> Could you help...?
>>
>> What should we do when a frame sent in an un-scheduled slot is not
>>
on that
draft>frequency.
draft>
draft> 4.3. Step 2 - Receiving EBs
draft>
draft>Upon receiving the first EB, the pledge SHOULD continue listening for
draft>additional EBs to learn:
Best,
Yatch
On Aug 31, 2018, at 15:33, Yasuyuki Tanaka wrote:
>
> Thank you, S
(Section 7.2.1.3 of IEEE 802.15.4-2015).
While I don't think the back-off wait is necessary in this case, this topic is
not covered by IEEE 802.15.4-2015...
Thank you!
Yatch
> On Jun 22, 2018, at 17:52, Yasuyuki Tanaka wrote:
>
> Thank you, Tero!!
>
> tero> I.e., the text this re
Hi Christian,
Indeed, there is no return code found in draft-ietf-6tisch-6top-protocol-12 for
such a case.
> Node C indicates a 6P ADD to node A which is answered with 6P_SUCCESS but
> with an empty cellist (2-step transaction). I guess next time node C can try
> 3-step transaction giving
Hello Atis,
> So, I suggest adding a requirement/recommendation for the implementer to
> prioritize 6top packets over data packets.
I agree with you. I prefer recommendation here.
Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
Thank you, Simon and Xavi!
A couple of things:
>>> 'MUST' here sounds too strong... Some may want to use MSF with a base
>>> schedule
>>> other than one defined RFC 8180 with full understands on implications by not
>>> following RFC 8180. Then, I'd propose 'SHOULD'.
>>>
>>> By the way, I'm not
Hi all,
We've released v1.1.5 of the 6TiSCH Simulator, a high-level 6TiSCH simulator
written in Python:
https://bitbucket.org/6tisch/simulator/src/v1.1.5/
There are a lot of changes/improvements made since v1.0.0 that Malisa announced
last March. Here are a couple of key updates, which may be
think?
>
> Pascal
>
>> -----Original Message-
>> From: Pascal Thubert (pthubert)
>> Sent: lundi 27 août 2018 17:29
>> To: 'Yasuyuki Tanaka' ; 6tisch@ietf.org
>> Subject: RE: [6tisch] Questions on RPL Settings in RFC 8180
>>
>> Hello Yatch
>&g
Thank you, Pascal!
> [PT>] True, so we never reach 9 and stay compatible with OF0. I guess the max
> ETX of 3 is arbitrary, we could have gone up to 11/3...
OK! That is what I understood. It's very clear now.
> The initial value of I (see RFC 6206) is between Imin and Imax. With the
>
Hi all,
I have a few questions on the RPL settings described in RFC
8180. Could anyone help me find answers...?
https://tools.ietf.org/html/rfc8180#section-5
---
(1) Rank Computation
RFC 8180 says:
rfc8180> 5.1.1. Rank Computation
rfc8180> (...)
rfc8180> Sp SHOULD be calculated as
Hello Tero,
I think I'm very close to the full understanding. Bear with me...
tero> As commented already the text in page 65 consider the case where
tero> we are doing initial transmission, not retransmission.
I see; this would clear my confusion. (note: "page 65" here is a page
number
Hi,
This proposal looks useful. I like the idea of Network ID!
I'm sharing my comments on the draft:
https://tools.ietf.org/html/draft-richardson-6tisch-enrollment-enhanced-beacon-01
[1] (trivial comment)
draft> There are a limited number of timeslots designated as a broadcast
draft>
Thank you for your comment, Thomas!
> On Jun 14, 2018, at 18:30, Thomas Watteyne wrote:
>
> I agree with Fabrice's comments, that's how I read the document.
>> the backoff window is selected randomly between 0 and 2^BE-1.
I may miss something, but I don't think so
My understanding right
Thank you, Fabrice!
> the backoff window is selected randomly between 0 and 2^BE-1.
According to you, the term of "the backoff window" seems to be used as the
retransmission backoff or the retransmission backoff wait. If so, I was
confused by a sentence in the third paragraph of the section,
Hello all,
Could anyone help me understand correctly the TSCH CSMA-CA
retransmission algorithm described in Section 6.2.5.3 of IEEE
802.15.4-2015, starting from page-64?
I have some questions...:
---
[1] What does it mean exactly by "the backoff window"?
There is no "backoff window" found in
Hi all,
I'd like to share my comments on draft-watteyne-6lo-minimal-fragment-00.txt.
LLN Minimal Fragment Forwarding
https://www.ietf.org/id/draft-watteyne-6lo-minimal-fragment-00.txt
I have four comments:
[1]
> 1. Overview of 6LoWPAN Fragmentation
> (snip)
> In Figure 1, node A has
Hi all,
I'd like to share my comments on draft-chang-6tisch-msf-00:
https://tools.ietf.org/html/draft-chang-6tisch-msf-00
The first one is about 6P CLEAR after detecting unreachability to a neighbor.
> 3.8. Step 7 - Neighbor Polling
>
> (snip)
>
>When a neighbor is declared
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:
Hello Yatch:
I published -13 with the corrected picture and some other refreshes.
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
22:30 GMT+02:00 Yasuyuki Tanaka <yatch1.tan...@toshiba.co.jp
<mailto:yatch1.tan...@toshiba.co.jp>>:
Xavi,
That sounds interesting.
Could you share any example what kind of configuration will be
conveyed in a Signal Request and/or Response?
Best,
Yatch
Xavi,
That sounds interesting.
Could you share any example what kind of configuration will be conveyed
in a Signal Request and/or Response?
Best,
Yatch
On 2017/07/19 19:22, Xavi Vilajosana Guillen wrote:
Dear all,
I would like to propose a new command to be used to the 6P Protocol. The
Hi,
Here is my understanding...
- 1. If you're sending a LOWPAN_IPHC frame without 6LoRH, it'd be better
to use page-0 LOWPAN_IPHC, without paging dispatch, in case a receiver
is a legacy, non-6TiSCH, node.
- 2. Since a node may receive a page-1 LOWPAN_IPHC frame without 6LoRH,
it'd be
Hi Thomas,
Jonathan's 6LoRH patch has not been merged yet; it's under review.
Yatch
On 2017/07/04 13:23, Thomas Watteyne wrote:
Great, thanks for the update. I understand Remy and Jonatyan have also
been pushing the 6LoRH code to Wireshark. Is the build you point to now
complete (i.e. parses
Hi,
I found a conflict between the ranges defined in Figure 29 of
draft-ietf-6tisch-6top-protocol-06:
+---+--+
| Range | Registration Procedures |
+---+--+
Thank you, Xavi!
Important things have not changed.I see; I won't make an excuse with the draft-06
release... (>_<)
Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
Hello Thomas,
As far as I know, the latest official Wireshark stable release, v2.2.7,
doesn't contain the 6P dissector.
- the latest official Wireshark build contains reasonably-up-to-date dissectors
of 6P, no 6LoRH
Development versions would have; they are available at the following
Hello Maria Rita,
Thank you! I'm opening the page right now :-)
Best,
Yatch
On 2017/06/02 23:55, Maria Rita Palattella wrote:
Dear all,
I am glad to announce that together with the support of ETSI, in the
framework of the F-Interop Project, we are organising a 6TiSCH
Interoperability
Thank you, Xavi!
> I think this will be announced soon, maybe this Friday.
I'm looking forward to it ;-)
Best,
Yatch
On 2017/05/31 23:18, Xavier Vilajosana wrote:
Hi Yatch,
I think this will be announced soon, maybe this Friday.
regards,
Xavi
2017-05-31 14:36 GMT+02:00 Yasuyuki Tan
Hi all,
Is there any web page such as a registration site which provides details
on the plugtest in July...?
Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
eplaced with "required cells" or should
"the number of effectively used cells" be replaced with "the current number of
required cells" according to section 4...?
Thank you!
Yatch
On 2017/03/05 22:13, Yasuyuki Tanaka wrote:
Nice comments!
I also want to see the definition
,S=0| select the cells scheduled with A |
draft>| | and marked as RX |
draft>+-+-------+
Best,
Yatch
On 2017/02/02 16:38, Yasuyuki Tanaka wrote:
Hi Rémy,
From my understandin
Hi Rémy,
From my understanding, CMD_CLEAR won't have any impact on hard cells since hard
cells are read-only for 6top.
https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.1
draft> 3.1. Hard/Soft Cells
draft>
draft>6top qualifies each cell in the schedule as either
Thank you, Thomas.
Let me add comments on a couple of the ppt slides in advance, which
could save time of the coming meeting, I hope...:
The ppt sides Thomas provided:
https://bitbucket.org/6tisch/meetings/raw/c9bd4d78fa452a0588abefc104d08520d32e0c26/161209_webex/slides_161209_webex.ppt
Hi Tengfei,
My first impression of your ideas is that it's a bit complicated,
especially the idea of generalizing Add, Delete, and Relocate
commands. I'd suggest discussing the Relocation command format alone
first.
I have another comment, which is more technical.
it will ends up something
's MAC to process the Request message. As you
mentioned, failure of the first part can be identified by mac-ack from nodeB, but
not the second part. Right?
Thanks
Qin
On Wednesday, November 30, 2016 1:49 PM, Yasuyuki Tanaka
<yasuyuki9.tan...@toshiba.co.jp> wrote:
Thanks, Qin.
(1) Timeout
Thanks, Qin.
(1) Timeout in nodeA can be triggered either by failure in
nodeA=>nodeB request process and by failure in nodeB=>nodeA response
process (i.e the process in above example). nodeA cannot tell exact
reason for a event of Timeout by itself. In another word, nodeA
cannot tell there is a
Hi Qin,
Hmm, in your example, node A can resolve the inconsistency without
using the generation counter by sending CLEAR to node B after the
timeout occurs. Node A could use STATUS or STATUS+LIST before sending
CLEAR in order to confirm inconsistency if the schedule generation
inconsistency
Hi all,
I'd suggest updating the explanation of SF in order to reflect what
SF really does. Here is the current test for SF:
SF: The "6top Scheduling Function" (SF) is the policy inside
the "6TiSCH Operation Sublayer" (6top) which decides when
to
Hi Qin,
Thank you for replying to my long email!!
I put the two cases you provided below, in which schedule generation
inconsistency could occur:
(1) failure in communication because of PHY problems like bed channel
condition, collision
(2) failure in processing because of MAC problems
Hi all,
I also have comments on draft-ietf-6tisch-6top-protocol-03; some of
them are covered by Simon. :-)
# I put a tag for each item: [C] for comment/suggestion, [Q] for
# question.
* Section 4.2.2:
- [Q] Why must the value of SeqNum increment *by exactly one* at each
new 6P request to
edits might be
needed :-\
On Tue, Nov 22, 2016 at 7:11 PM, Yasuyuki Tanaka <yasuyuki9.tan...@toshiba.co.jp
<mailto:yasuyuki9.tan...@toshiba.co.jp>> wrote:
Hi all,
A patch to support 6P of draft-03 has been merged into the master
branch of Wireshark with the short
Hi all,
Here is my opinion:
step 1: one suggestion to keep the original sentence explaining what
to do in SF0 after the system booting-up or restart. That is,
no change on draft-ietf-6tisch-6top-sf0-02#section-10.
step 2: +1
Thanks!
Yatch
On 2016/11/22 8:16, Thomas Watteyne
Hi all,
A patch to support 6P of draft-03 has been merged into the master
branch of Wireshark with the short commit hash of 0f36cf6. This patch
updates the code based on draft-02 that was already there.
The latest packages available at the following site, "automated build
section", should
Xavi, Thomas, thank you for the responses!
I'm replying both of you in a single email to save bandwidth ;-)
Sorry for making this email so long... I put a shorter response first.
thomas> From an implementation point of view, cells that are in the
thomas> process of being reserved (i.e. 6P add
Hi Thomas,
Could we say something to the effect that, if SF0 realizes
connection to a particular neighbor is no longer needed (for example
a change in parent by the routing protocol) SF0 MAY send CLEAR
requests to neighbor to speed up the cleanup process of the cells
with that neighbors?
I
Hi Thomas,
Sending an explicit CLEAR will speed things up, and avoid for the
previous preferred parent to waste energy listening to those. A
CLEAR wouldn't hurt, right?
This is right. But, I don't think it's a SF0 job. The thing is that
SF0 knows nothing about RPL.
If SF0 provided an API to
Thank you for your comment, Pat!
I noticed your message wasn't on the ML; I paste it here.
On 2016/11/17 16:40, pat.kin...@kinneyconsultingllc.com wrote:
Yasuyuki brings up a very good point. A major effort in creating
802.15.4-2015 was to eliminate (at least try to) ambiguities. As
per the
Hi all,
I'm wondering if the cell scheduled for the minimal configuration
should be ADVERTISING in terms of macLinkType rather than NORMAL.
The definition of LinkType can be found in Table 8-46 of IEEE
802.15.4-2015. This is a table about MLME-SET-LINK.request
parameters. It says:
Set to
Does that suggestion work for you or should we create an issue
on SF0?
Thomas
On Fri, Nov 11, 2016 at 8:50 PM, Yasuyuki Tanaka
<yasuyuki9.tan...@toshiba.co.jp <mailto:yasuyuki9.tan...@toshiba.co.jp>> wrote:
Hi Tengfei,
Hi Tero,
Thank you for the clear explanation!!
I check Figure 6-5 and Figure 6-6 that you referred. Indeed, there is
no distinction on a sending frame between unicast or broadcast.
Now I've got synchronized. :-)
Best,
Yatch
On 2016/11/16 4:05, Tero Kivinen wrote:
Yasuyuki Tanaka writes
2016/11/15 5:06, Thomas Watteyne wrote:
Yatch,
Can you confirm Tero has answered your question?
Thomas
On Tue, Nov 15, 2016 at 12:02 PM, Tero Kivinen <kivi...@iki.fi
<mailto:kivi...@iki.fi>> wrote:
Yasuyuki Tanaka writes:
> To my understanding, the scheduled cell in 6
e this helps.
Let me know your thoughts about it.
Regards,
Diego Dujovne
2016-11-11 14:20 GMT-03:00 Yasuyuki Tanaka <yasuyuki9.tan...@toshiba.co.jp
<mailto:yasuyuki9.tan...@toshiba.co.jp>>:
Hi all,
I'd appreciate it if someone could help me understand SF0 Cell
Estimation Algorithm mentioned in draft-ietf-6tisch-6top-sf0-02...
https://tools.ietf.org/html/draft-ietf-6tisch-6top-sf0-02#section-5
What I've read from the draft is that the Cell Estimation Algorithm
tries to have at
80 matches
Mail list logo
