Subject: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set/get protocol, must be direct to PCE

From: "Grossman, Ethan A." <[email-masked]>
Date: Wed, 4 May 2016 23:16:22 +0000

Statement:
6TiSCH use case: Path set/get protocol, must be direct to PCE
Discussion:
There has been discussion about whether path configuration is pushed to an endpoint directly from the PCE, or whether the path is configured from device to device starting with the talker endpoint device, as it is in an AVB network. Because devices that use 6TiSCH usually have constrained resources, the assumption here is that this configuration would always be direct from the PCE, thus removing the peer-to-peer protocol requirement from the device. Similar logic applies to getting device capability information from the device to the PCE - making this a direct query from the PCE to the device means that the device would not have to support being an intermediary for collecting or forwarding capabilities of neighbor devices to the PCE.  Here is an example of relevant text from the Use Cases draft, however part of this conversation was offline and was not directly covered in the draft.

       "a tiny IoT device may have just enough buffers to  store one or a few IPv6 packets, and will have limited bandwidth between  peers such that it can maintain only a small amount of peer information, and  will not be able to store many packets waiting to be forwarded. It is  advantageous then for it to only be required to carry out the specific behavior assigned to it by the PCE/NME"

As a counter example, I could imagine that for a larger DetNet network with many and powerful devices, perhaps device querying and configuration might better be done in a hierarchical or tree'd manner; that is, limiting configuration to direct communication from the PCE to every individual device may be inefficient or limiting.

So the question as I understand it is "will the DetNet architecture support direct PCE-to-device interrogation and configuration?" It would not have to be to the exclusion of e.g. a hierarchical model, but the point is not to assume a hierarchical model that would disenfranchise such small IoT devices.

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 9 May 2016 09:42:24 +0200

Ethan,

[I'm going through the set of e-mails you just sent to the ML, assuming you
created these to kickstart different threads of execution. Please correct
me if I'm wrong.]

My 2c on this issue:
- small IoT devices (class 1 devices per RFC7228) are powerful enough to
run a state machine of a simple protocol such as 6P
(draft-ietf-6tisch-6top-protocol-00)
- network bandwidth is severely constrained, and having two neighbor node
discuss locally (e.g. as part of the 6P protocol) is more feasible than
globally with the PCE for each transaction.
- given this, I wouldn't dismiss having some distributed intelligence, with
possibly the PCE/NME giving high-level commands

On Thu, May 5, 2016 at 1:16 AM, Grossman, Ethan A. <[email-masked]> wrote:

> There has been discussion about whether path configuration is pushed to an
> endpoint directly from the PCE, or whether the path is configured from
> device to device starting with the talker endpoint device, as it is in an
> AVB network. Because devices that use 6TiSCH usually have constrained
> resources, the assumption here is that this configuration would always be
> direct from the PCE, thus removing the peer-to-peer protocol requirement
> from the device. Similar logic applies to getting device capability
> information from the device to the PCE – making this a direct query from
> the PCE to the device means that the device would not have to support being
> an intermediary for collecting or forwarding capabilities of neighbor
> devices to the PCE.  Here is an example of relevant text from the Use Cases
> draft, however part of this conversation was offline and was not directly
> covered in the draft.
>
> ”a tiny IoT device may have just enough buffers to  store one or a few
> IPv6 packets, and will have limited bandwidth between  peers such that it
> can maintain only a small amount of peer information, and  will not be able
> to store many packets waiting to be forwarded. It is  advantageous then for
> it to only be required to carry out the specific behavior assigned to it by
> the PCE/NME”
>
> As a counter example, I could imagine that for a larger DetNet network
> with many and powerful devices, perhaps device querying and configuration
> might better be done in a hierarchical or tree’d manner; that is, limiting
> configuration to direct communication from the PCE to every individual
> device may be inefficient or limiting.
>
> So the question as I understand it is “will the DetNet architecture
> support direct PCE-to-device interrogation and configuration?” It would not
> have to be to the exclusion of e.g. a hierarchical model, but the point is
> not to assume a hierarchical model that would disenfranchise such small IoT
> devices.
>
>
> _______________________________________________
> detnet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet
>
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: "Grossman, Ethan A." <[email-masked]>
Date: Mon, 9 May 2016 16:31:29 +0000

Hi Thomas,

Yes you are correct about my intent, and thank you for contributing. I have not yet finished sending out all of this batch of emails (about 6 remain) but once I do I will start harassing the group about replying to them :- )

My intent is to collate the results of replies to these "question statements" into "answer statements", then have the group "approve" the updated statements, then update the Use Cases text accordingly.

Ethan.

________________________________
From: Thomas Watteyne <[email-masked]>
Sent: Monday, May 9, 2016 12:42 AM
To: Grossman, Ethan A.
Cc: [email-masked]; Pascal Thubert (pthubert) ([email-masked])
Subject: Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path set/get protocol, must be direct to PCE

Ethan,

[I'm going through the set of e-mails you just sent to the ML, assuming you created these to kickstart different threads of execution. Please correct me if I'm wrong.]

My 2c on this issue:
- small IoT devices (class 1 devices per RFC7228) are powerful enough to run a state machine of a simple protocol such as 6P (draft-ietf-6tisch-6top-protocol-00)
- network bandwidth is severely constrained, and having two neighbor node discuss locally (e.g. as part of the 6P protocol) is more feasible than globally with the PCE for each transaction.
- given this, I wouldn't dismiss having some distributed intelligence, with possibly the PCE/NME giving high-level commands

On Thu, May 5, 2016 at 1:16 AM, Grossman, Ethan A. <[email-masked]<mailto:[email-masked]>> wrote:
Statement:
6TiSCH use case: Path set/get protocol, must be direct to PCE
Discussion:
There has been discussion about whether path configuration is pushed to an endpoint directly from the PCE, or whether the path is configured from device to device starting with the talker endpoint device, as it is in an AVB network. Because devices that use 6TiSCH usually have constrained resources, the assumption here is that this configuration would always be direct from the PCE, thus removing the peer-to-peer protocol requirement from the device. Similar logic applies to getting device capability information from the device to the PCE - making this a direct query from the PCE to the device means that the device would not have to support being an intermediary for collecting or forwarding capabilities of neighbor devices to the PCE.  Here is an example of relevant text from the Use Cases draft, however part of this conversation was offline and was not directly covered in the draft.

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=CwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=P_tJiWfmMCRANf1PTpveLEVwR1a7Qimd7lbfpAaoUK8&s=-tW3nOJYOLqJrFfLWK584DQiRfQJhdc-ZRtCtMnQaeI&e=>

Thomas Watteyne, PhD

www.thomaswatteyne.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.thomaswatteyne.com&d=CwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=P_tJiWfmMCRANf1PTpveLEVwR1a7Qimd7lbfpAaoUK8&s=QX0NBbUhgCBAQvngsJWb-1gcAArhhyrQPSc_O6wkg3w&e=>
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 10 May 2016 07:14:38 +0200

Ethan,
Great, thanks!
Thomas

On Mon, May 9, 2016 at 6:31 PM, Grossman, Ethan A. <[email-masked]> wrote:

> Hi Thomas,
>
> Yes you are correct about my intent, and thank you for contributing. I
> have not yet finished sending out all of this batch of emails (about 6
> remain) but once I do I will start harassing the group about replying to
> them :- )
>
> My intent is to collate the results of replies to
> these "question statements" into "answer statements", then have the group
> "approve" the updated statements, then update the Use Cases text
> accordingly.
>
> Ethan.
> ------------------------------
> *From:* Thomas Watteyne <[email-masked]>
> *Sent:* Monday, May 9, 2016 12:42 AM
> *To:* Grossman, Ethan A.
> *Cc:* [email-masked]; Pascal Thubert (pthubert) ([email-masked])
> *Subject:* Re: [Detnet] DetNet Use Case Statements - 6TiSCH - Path
> set/get protocol, must be direct to PCE
>
> Ethan,
>
> [I'm going through the set of e-mails you just sent to the ML, assuming
> you created these to kickstart different threads of execution. Please
> correct me if I'm wrong.]
>
> My 2c on this issue:
> - given this, I wouldn't dismiss having some distributed intelligence,
> with possibly the PCE/NME giving high-level commands
>
>
>
>
>
>> There has been discussion about whether path configuration is pushed to
>> an endpoint directly from the PCE, or whether the path is configured from
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=CwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=P_tJiWfmMCRANf1PTpveLEVwR1a7Qimd7lbfpAaoUK8&s=-tW3nOJYOLqJrFfLWK584DQiRfQJhdc-ZRtCtMnQaeI&e=>
>>
>>
>
>
> --
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.thomaswatteyne.com&d=CwMFaQ&c=lI8Zb6TzM3d1tX4iEu7bpg&r=ZcHC6wX_gDwPDcfMaFNZiQ&m=P_tJiWfmMCRANf1PTpveLEVwR1a7Qimd7lbfpAaoUK8&s=QX0NBbUhgCBAQvngsJWb-1gcAArhhyrQPSc_O6wkg3w&e=>

Thomas Watteyne, PhD

www.thomaswatteyne.com