Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-02.txt

From: [email-masked]
Date: Mon, 25 Jul 2016 23:30:35 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e of the IETF.

        Title           : 6top Protocol (6P)
        Authors         : Qin Wang
                          Xavier Vilajosana
	Filename        : draft-ietf-6tisch-6top-protocol-02.txt
	Pages           : 28
	Date            : 2016-07-25

Abstract:
   This document defines the 6top Protocol (6P), which enables
   distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
   in a 6TiSCH network to add/delete TSCH cells to one another.  6P is
   part of the 6TiSCH Operation Sublayer (6top), the next higher layer
   of the IEEE802.15.4 TSCH medium access control layer.  The 6top
   Scheduling Function (SF) decides when to add/delete cells, and
   triggers 6P Transactions.  Several SFs can be defined, each
   identified by a different 6top Scheduling Function Identifier (SFID).
   This document lists the requirements for an SF, but leaves the
   definition of the SF out of scope.  Different SFs are expected to be
   defined in future companion specifications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-protocol-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 26 Jul 2016 08:32:20 +0200

Dear all,

we have submitted a revision of the 6top draft. It includes most of the
changes proposed in the WG meeting in Berlin.

please send us your comments.

kind regards,
Xavi
---------- Forwarded message ----------
From: <[email-masked]>
Date: 2016-07-26 8:30 GMT+02:00
Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-02.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
of the IETF.

Abstract:

_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Jiliang Wang <[email-masked]>
Date: Tue, 26 Jul 2016 16:05:02 +0800

Thanks for the great work. This is Jiliang Wang from Tsinghua University. I
am very interested in this version and I just have several questions.

1.       In 4.3.10, it says “If node A requests more cells than can fit in
the response, node B MUST return code RC_ERR_NORES and an empty cell list.”

1.- Is there any fragmentation method to transmit all the cells if the
requested cells cannot be fit in a response?

2.       Will the clear command result in inconsistency in current design?
For example, a clear command is sent from A to B and the response from B to
A is lost.

3.       Currently, the add command supports best-effort cell adding, i.e.,
when the cells is not enough, partial of the cells can be added – if I
understand correctly.

 –what is the purpose of best-effort adding. Why not just return success
and fail?
best,

-------------
Jiliang Wang
Assistant Professor
http://tns.thss.tsinghua.edu.cn/~jiliang/

---

From: Xavi Vilajosana Guillén <[email-masked]>
Date: Tue, 26 Jul 2016 15:14:59 +0200

Dear Jiliang,

see inline please,

2016-07-26 10:05 GMT+02:00 Jiliang Wang <[email-masked]>:

> Thanks for the great work. This is Jiliang Wang from Tsinghua University.
> I am very interested in this version and I just have several questions.
>
> 1.       In 4.3.10, it says “If node A requests more cells than can fit
> in the response, node B MUST return code RC_ERR_NORES and an empty cell
> list.”
>
No, we keep it simple. The LIST command supports pagination. You can retry
with a smaller page size if it does not fit in a packet.

> 2.       Will the clear command result in inconsistency in current
> design? For example, a clear command is sent from A to B and the response
> from B to A is lost.
>
The CLEAR is not executed until the response is received. B side executes
the CLEAR after receiving the L2 ACK of the response message.

> 3.       Currently, the add command supports best-effort cell adding,
> i.e., when the cells is not enough, partial of the cells can be added – if
> I understand correctly.
>
Best effort minimizes the amount of data to be sent.

> best,
Kind regards,
Xavi

-- 
Dr. Xavier Vilajosana Guillén
Research Professor
Wireless Networks Research Group
Internet Interdisciplinary Institute (IN3)
Universitat Oberta de Catalunya

+34 646 633 681| [email-masked] | Skype: xvilajosana
http://xvilajosana.org
http://wine.rdi.uoc.edu/

Parc Mediterrani de la Tecnologia
Av. Carl Friedrich Gauss, 5. Edifici B3
08860 Castelldefels (Barcelona)

---

From: "Lijo Thomas" <[email-masked]>
Date: Fri, 29 Jul 2016 18:38:36 +0530

Hi Xavi,
 
I observed a small typo in section 4.2.10 instead of node it is written as note 
 
I am bit confused with  Consitency description in 4.1 
 
You mean to say that the nodes should keep the count for each ADD/DELETE with the neighbor, does it create problem when a node has multiple neighbors
 
Is this used for cross checking the schedules after the cell allocation/deletion process.
 
Thanks & Regards,
Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: 26 July 2016 12:02
To: [email-masked]
Subject: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-02.txt
 
Dear all,
 
we have submitted a revision of the 6top draft. It includes most of the changes proposed in the WG meeting in Berlin. 

kind regards,
Xavi
---------- Forwarded message ----------
From: < <mailto:[email-masked]> [email-masked]>
Date: 2016-07-26 8:30 GMT+02:00
Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-02.txt
To:  <mailto:[email-masked]> [email-masked]
Cc:  <mailto:[email-masked]> [email-masked]

Abstract:

The IETF datatracker status page for this draft is:
 <https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/> https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/

There's also a htmlized version available at:
 <https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02> https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02

A diff from the previous version is available at:
 <https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-protocol-02> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-protocol-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at  <http://tools.ietf.org> tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
 <ftp://ftp.ietf.org/internet-drafts/> ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
6tisch mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/6tisch> https://www.ietf.org/mailman/listinfo/6tisch

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Jiliang Wang <[email-masked]>
Date: Fri, 29 Jul 2016 21:33:06 +0800

Thanks very much for your response. My comments are as follows.

> with a smaller page size if it does not fit in a packet.
Is the pagination decision made by node A? This seems to be not simple
since the actual number is not know and thus it is difficult to determine
whether to use pagination.

> the CLEAR after receiving the L2 ACK of the response message.
It there any problem when the L2 ACK is lost in which A clears while B does
not?

> Best effort minimizes the amount of data to be sent.
Is it possible that a node needs to issue an all-or-no adding request? For
example, a node prefers to transmit all data at once.