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.
Thanks Yatch! 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:
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 N
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 d
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 th
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 DS
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 ne
, and therefore gets
aggregated with (join) traffic from other JPs in the network. The
purpose of the traffic tagging mechanism in minimal-security is for such
nodes, closer to the DAG root, to avoid allocating cells in response to
the join traffic.
Mališa
On 5 Dec 2019, at 17:48, Yasuyuki
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 join
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 b
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 c
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> ...
rf
Hi all,
I reviewed draft-ietf-6tisch-msf-08. Here are my comments;
* [clarification] Section 1
draft> the 6 steps described in Section 4. The end state of the join
draft> process is that the node is synchronized to the network, has
draft> mutually authenticated to the network, has identified a
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 return
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,
mTxAck
draft> MUST be divided by 2.
I'd propose to remove the second sentence in the first paragraph,
which starts with "The "MUST" statements in this section...", and to
alter the section just to demonstrate how we can resolve "schedule
collisions" using 6P RELO
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 introdu
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 defini
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 Vers
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 sense?
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 M
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 slotframes
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 tim
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 neigh
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 la
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 thi
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 Kiv
scheduled :-)
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 n
tening for EBs 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:
>
&g
time (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 te
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 nod
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
https://www.ietf.or
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
thers 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
>>
>> Hel
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
> default,
Hi authors,
Congratulations on this great work!
https://tools.ietf.org/html/draft-ietf-6tisch-msf-00
I'm sharing my comments on the draft; major comments are followed by minor
comments.
* discussion: when to schedule autonomous TX cells to neighbors
According to Section 4, a join proxy (JP)
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 (3*ETX)-
Thank you, Tero!!
tero> I.e., the text this refers to ("A device upon encountering a
tero> transmission failure in a shared link shall initialize the BE to
tero> macMinBe.") is on page 66, not in page 65.
OK, we're on the same page now :-)
tero> Note, that CCA will NOT fail for other tsch transm
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 including
Hello Tero,
Thank you so much for the detailed comments! I'll take time to read your email
carefully.
>> I didn't look closer the left-most branch (retransmission with PCA),
>> by the way.
>
> Nobody looks closely on the PCA branch :-)
Oh (>_<)
Best,
Yatch
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> sl
Thomas,
> Would you be able to spend 2min during the 6TiSCH call this afternoon to
> summarize and ask for input? I can dedicate some time in the OAB.
Yes, I will. Thank you!
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/
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
Hi,
I'm sharing my comments on draft-chang-6tisch-msf-01.
https://tools.ietf.org/html/draft-chang-6tisch-msf-01
[1] how should a node handle a 6P transaction failure?
draft> 3. Node Behavior at Boot
draft> ...
draft> 3.6. Step 5 - 6P ADD to Preferred Parent
draft>
draft>After having
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 F
Hi Thomas, Xavi,
> I would recommend to use a MAY in this case. That is, a node MUST remove
> cells, and MAY send a CLEAR.
That sounds good to me!
Best,
Yatch
___
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch
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 se
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 unreachabl
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.
internal algorithms.
Cheers,
Pascal
*From:*Randy Turner [mailto:rtur...@amalfisystems.com]
*Sent:* mercredi 29 novembre 2017 14:28
*To:* Pascal Thubert (pthubert)
*Cc:* Yasuyuki Tanaka ; 6tisch@ietf.org
*Subject:* Re: [6tisch] 6TiSCH Protocol Stack in
draft-ietf-6tisch-architecture-12
Hi Guys,
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 <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
On 2017/07/19 19:22, Xavi Vilajo
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
co
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 bett
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
All,
Now the 6P dissector in a development version of Wireshark supports
draft-ietf-6tisch-6top-protocol-07 with the constant values defined for
ETSI Plugtest.
You can try it with the latest auto-build version of Wireshark that is
available at the following page:
https://www.wireshark.or
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 page.
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 event.
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 Yasuyuk
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 defin
Nice comments!
I also want to see the definition of "effectively used cell" and
how to calculate PDR.
In addition, I don't think that we would count the number of
cells used for 6P in terms of SF0. Is it correct? In any case,
some text on how SF0 should handle traffic or cell usage by 6P
would b
|TX=1,RX=0,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 u
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 "hard
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 Randy,
Rahul Jadhav and Rabi Narayan Sahoo, I guess.
https://www.ietf.org/proceedings/97/slides/slides-97-lwig-neighbor-management-policy-for-6lowpan-01.pdf
https://www.ietf.org/mail-archive/web/roll/current/msg10012.html
Best,
Yatch
On 2016/12/10 0:25, Randy Turner wrote:
Hi All,
Apologie
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 wit
Hi Xavi,
Let me respond to the following first:
What if A resets? how you now at B that A has reset? do this require
a STATUS call from A to B when it join the network again?
That is one of options. Basically, it's up to an SF employed between
them. Here are other options in my mind:
(1) A
r nodeB'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
wrote:
Thanks, Qin.
(1) Timeout in nodeA can be triggered
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 detec
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 add/remo
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 suc
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
le of more edits might be
needed :-\
On Tue, Nov 22, 2016 at 7:11 PM, Yasuyuki Tanaka 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 commit hash of 0f36cf6. This patch
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 wr
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 includ
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 r
Hi all,
I'd like to bring up Nicola's idea, 6P ACK, which came out on the
thread of "SF Timeout calculation (Ticket #53)":
https://www.ietf.org/mail-archive/web/6tisch/current/msg04866.html
A 6P ack would make the 6P negotiation reliable. B can 'half' open
the RX side after receiving the mac
of view of the
SF, there will be no more effectively used cells towards
that particular neighbour, thus reducing the number of
cells to the OVERPROVISION value.
Regards,
Diego
2016-11-21 9:08 GMT-03:00 Yasuyuki Tanaka mailto:yasuyuki9.tan...@toshiba.co.jp
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 gue
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 s
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 ADVE
Diego
2016-11-16 11:05 GMT-03:00 Thomas Watteyne mailto:thomas.watte...@inria.fr>>:
@Tengfei,
Does that suggestion work for you or should we create an issue
on SF0?
Thomas
On F
icated TX cells
to the specific neighbour.
I think the reason to use TX or Shared cells as a default, is covered by
Thomas' answer.
Thank you.
Regards,
Diego
2016-11-16 8:33 GMT-03:00 Yasuyuki Tanaka mailto:yasuyuki9.tan...@toshiba.co.jp>>:
H
Hi Diego,
diego> b) if we keep working with the initial assumption, and do not
diego> allow any shared cells to be scheduled by SF0.
Why is scheduling shared cells not allowed by the initial assumption?
I'm a relative newcomer to 6TiSCH and not sure about the initial
assumption...
To me, it see
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
.?
Best,
Yatch
On 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 mailto:kivi...@iki.fi>> wrote:
Yasuyuki Tanaka writes:
> To my understanding, the scheduled cell in 6tisc
Hi all,
To my understanding, the scheduled cell in 6tisch-minimal can be used
for both of unicast and broadcast. The destination address of a frame
to be sent with the cell may have the MAC address of a particular
neighbor or the broadcast address.
But I'm not sure how we can handle that use cas
cells.
Hope this helps.
Let me know your thoughts about it.
Regards,
Diego Dujovne
2016-11-11 14:20 GMT-03:00 Yasuyuki Tanaka mailto:yasuyuki9.tan...@toshiba.co.jp>>:
Hi all,
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 leas
Hi Tengfei,
I think an assumption there is that a node has no state with its
neighbors just after booting up or restarting. On the other hand, a
neighbor of them may have cells allocated for the node. To resolve
such a possible inconsistency, the node issues CLEAR to each of its
neighbors.
Best,
100 matches
Mail list logo