Subject: [6tisch] 3 issues related to 6top interface

From: Qin Wang <[email-masked]>
Date: Mon, 19 May 2014 18:31:15 -0700 (PDT)

Hi all,

We have had great discussion related to 6top interface and consensus on using CoAP to implement not only PCE-6top communication but also 6top-to-6top communication. We have three reminding issues.

(1) For 6top-to-6top communication, is CoAP Block option more efficient comparing fragmenting in application layer? 
CoAP block option costs Block-option field in each fragment, but, has full functions like retry to convey data. Fragmentation in application layer has to implement those functions, and, in addition, may cost Uri-path option field for every small data. See the analysis in the thread "How to use Uri-path option while Block option is used". http://www.ietf.org/mail-archive/web/6tisch/current/msg02193.html

(2) If Block option is used for 6top-to-6top communication, what is about reusing IEEE802.15.4 Ack or some sort of Enhanced MAC Ack to replace CoAP Ack? 
Related discussion is in thread "reuse MAC ack vs 6top ack when using block option" . http://www.ietf.org/mail-archive/web/6tisch/current/msg02197.html

(3) Besides the passive mechanism for a node to get more bandwidth, i.e. being assigned cells by PCE while PCE thinks necessary, is it useful for a node to ask PCE more bandwidth directly? If yes, is there anything needed in YANG model?
Related discussion is in thread "Asking for more bandwidth". http://www.ietf.org/mail-archive/web/6tisch/current/msg02133.html

Please input your options.

Thanks
Qin

---

From: <[email-masked]>
Date: Tue, 20 May 2014 11:43:02 +0000

Dear Qin,

Regarding to issue (3), the requester of bandwidth can be either an end-device (Sensor or actuator) or a router. The device might ask for more bandwidth either (a) for forwarding it data to its parent or (b) for forwarding its data toward the gateway along the RPL.  I think one of the questions is, if in 6top layer (of end-devices), we have access to the traffic characteristics of the sensor data. For example, its communication type (periodic or non-periodic), and its requested publishing period.

Am I right?

Regards,
Pouria

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Tuesday, May 20, 2014 3:31 AM
To: [email-masked]
Subject: [6tisch] 3 issues related to 6top interface

Hi all,

Thanks
Qin

---

From: <[email-masked]>
Date: Tue, 20 May 2014 14:01:54 +0000

Dear Qin,

Regarding to issue (2), we intend to use block option for transferring large amount of 6top resources (between adjacent neighbors) and to use normal CoAP message format (CoAP parser) for smaller resources that fit in one 802.15.4 packet.
For those confirmable interactions that we don’t use block option (and we use normal CoAP message), still we have the question to use separate 6top Ack (CoAP Ack) or not? Am I right?

Regards,
Pouria

From: 6tisch [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, May 20, 2014 1:43 PM
To: [email-masked]; [email-masked]
Subject: Re: [6tisch] 3 issues related to 6top interface

Dear Qin,

Am I right?

Regards,
Pouria

From: 6tisch [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Tuesday, May 20, 2014 3:31 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] 3 issues related to 6top interface

Hi all,

Thanks
Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 22 May 2014 17:17:50 -0700

Qin,
Thanks for the very clear summary of open issues.
For clarifty, please see my 2c directly in
- http://www.ietf.org/mail-archive/web/6tisch/current/msg02237.html
- http://www.ietf.org/mail-archive/web/6tisch/current/msg02238.html
Thomas

On Mon, May 19, 2014 at 6:31 PM, Qin Wang <[email-masked]> wrote:

>  Hi all,
>
> We have had great discussion related to 6top interface and consensus on
> using CoAP to implement not only PCE-6top communication but also
> 6top-to-6top communication. We have three reminding issues.
>
> (1) For 6top-to-6top communication, is CoAP Block option more efficient
> comparing fragmenting in application layer?
> CoAP block option costs Block-option field in each fragment, but, has full
> functions like retry to convey data. Fragmentation in application layer has
> to implement those functions, and, in addition, may cost Uri-path option
> field for every small data. See the analysis in the thread "How to use
> Uri-path option while Block option is used".
> http://www.ietf.org/mail-archive/web/6tisch/current/msg02193.html
>
>
> (2) If Block option is used for 6top-to-6top communication, what is about
> reusing IEEE802.15.4 Ack or some sort of Enhanced MAC Ack to replace CoAP
> Ack?
> Related discussion is in thread "reuse MAC ack vs 6top ack when using
> block option" .
> http://www.ietf.org/mail-archive/web/6tisch/current/msg02197.html
>
> (3) Besides the passive mechanism for a node to get more bandwidth, i.e.
> being assigned cells by PCE while PCE thinks necessary, is it useful for a
> node to ask PCE more bandwidth directly? If yes, is there anything needed
> in YANG model?
> Related discussion is in thread "Asking for more bandwidth".
> http://www.ietf.org/mail-archive/web/6tisch/current/msg02133.html
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>