Subject: [6tsch] PCE<->6TSCH protocol: requirements

From: Thomas Watteyne <[email-masked]>
Date: Thu, 9 May 2013 01:29:01 -0700

All,

Let's continue the discussion on the requirements for the protocol used by
the PCE to communicate with a 6TSCH network. We have had several
discussions and have identified existing protocols which answer different
parts of the needs.

I'd like to start summarizing the requirements we have identified for this
protocol. The objective is to be able to assess the different solutions.
This can turn into a discussion on the next call, then maybe a section in
the architecture or a future requirements draft.

Thomas

---

*Requirement 1.*

*The protocol MUST carry metric information from the nodes to the PCE.*

Here, "metrics" is a general term which covers:
- link metrics, quantifying the connection between neighbor nodes
- node metrics, quantifying the general status and health of a node in the
network

The PCE uses this information to keep an up-to-date view of the network,
which it uses to determine the TSCH schedule.

*Discussion*:

RFC6551 is a great starting point. The DAG Metric Container Format [1] can
probably be used as-is as the payload of the protocol. IANA tracks the
different types of metrics and other attributes [2], and since these are
designed for RPL, I believe this is a perfect fit..

*Requirement 2.*

*The protocol MUST carry commands from the PCE to the motes in the network.*

This allows the PCE to "remote control" the TSCH schedule, based on the
view of the topology if has (requirements 1 and 4) and the scheduling
requirements it receives from the mote (requirement 3).

*Discussion*:

These commands could map almost directly to the commands identifies in the
6tus draft [3]. That is, the PCE can:
- add/remove slotframes
- add/remove hard cells
- control time source neighbors
- control the generation of EBs

On top of this, the PCE can map cells to labels, to allow for 6tus-based
label switching (this feature has been discussed, but is not currently in
the 6tus draft).

*Requirement 3.*

*The protocol MUST carry scheduling requirements from any node to the PCE.*

When an application starts reporting data on a node, this node must be able
to contact the PCE, indicating the traffic requirements it has. Similarly,
the PCE must be able to indicate whether it can satisfy those requirements
or not.

*Discussion*:

It looks like this requirement is fully satisfied by PCEP [5] which defines
the formats of the PCReq and PCResp. Moreover, the IANA is tracking the
different types of requirements [6].

*Requirement 4.*

*The protocol MUST carry alarms from any node to the PCE.*

If a node in the network detects a malfunction, possibly through a local
OAM mechanism [4], it must be able to indicate this to the PCE so it can
take the appropriate action. This information is complementary to the
metric information.

*Discussion*:

In the case of a fully deterministic network (i.e. all tracks consist of
dedicated cells, and the schedule is collision free), the OAM mechanism can
be greatly simplified since the PCE can do the OAM's Connectivity
Verification (CV) by looking at the schedule of the network.

What's then left is the Continuity Check. The periodic re-synchronization
mechanism between a nodes and its time source neighbor imposed by TSCH can
be used to help with that.

*Requirement 5.*

*The protocol MUST ensure mutual authentication between the PCE and the
nodes.*
*
*
Nodes in the 6TSCH network need to be able to ensure that a command is
coming from the PCE; and the PCE must make sure that the data is coming
from a node.

*Discussion*:

How this is done might be left to some secure transport layer (e.g. DTLS),
or build in the protocol directly.

*Requirement 6.*

*The protocol MAY ensure confidentiality of the traffic between the PCE and
the nodes.*

In case all traffic is unicast between the PCE and the 6TSCH nodes, one can
imagine an encryption mechanism whereby a mote can not spoof on the PCE
command it is relaying.

[1] http://tools.ietf.org/html/rfc6551#section-2
[2]
http://www.iana.org/assignments/rpl-routing-metric-constraint/rpl-routing-metric-constraint.xml
[3] http://tools.ietf.org/html/draft-wang-6tsch-6tus-00#section-2.4
[4] http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08
[5] http://tools.ietf.org/html/rfc5440#section-6.4
[6] http://www.iana.org/assignments/pcep/pcep.xml

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 9 May 2013 02:14:44 -0700

Hi Thomas,

The requirement list is very helpful to make our discussion move forward.

Can you explain more about "On top of this, the PCE can map cells to
labels, to allow for 6tus-based label switching" in Requirement-2?
Because, to me, "Label" is a new concept in the context of 6TSCH.

Thanks
Qin

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

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 9 May 2013 02:35:22 -0700

Qin,

This is something that was discussed over the last couple of phone calls,
mainly by Xavi and Pascal. Sorry if it did not appear clearly in the
minutes.

The idea is to do MPLS-like label switching on a TSCH network: the packet
comes in on one cell, and rather than being sent up to the routing layer,
it is switched out onto a different cell directly in L2, i.e. directly in
6tus.

What makes this very powerful is to use GMPLS: instead of having to attach
a label to each packet (a field), the cell you receive it on is an implicit
label. The switching table then says something like "if you receive on
slotoffset 5, channel offset 6, switch the packet to slotoffset 8, channel
offset 9".

The role of the PCE in this case is to communicate this switching table to
the node. The PCE can build the switching table to match the multi-hop
tracks.

Changes to 6tus are relatiely small to support this:
- the ability to attach one or more labels to a cell
- a flag in each cell indicating whether to use switching or traditional
routing to forward the packet.
- the associated commands for an upper layer to set the labels and the
switching flag.

I hope this makes sense.

Thomas

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 09 May 2013 07:08:27 -0700

Hi Thomas,all,

this is very useful list of requirements, out of what we have been 
looking (PCEP,NSIS/RSVP) which seem to be only small pieces of what we 
need and would require us to build a Frankenstein protocol, CoAP comes 
to my mind, i.e, CoAP is a transport protocol that we can use to 
transport the requirements of PCE/Nodes in the network.
For example:

- status information flowing from the nodes to the PCE could consist of 
a CoAP transport with the DAG Metric Container Format from RFC6551 in 
the payload. This would avoid having to reinvent all the different metrics.
- similarly, the message to ask the PCE to install a track, and for the 
PCE to confirm that it was installed could simply be a PCEP payload.
- finally, it we run CoAP on top of DTLS, we get 
authentication/encryption for free.

As for the distributed approach, CoAP can be used to communicate to 
arbitrary nodes that live in a track, the only restriction I see is that 
a possible track reservation will require unicast messages from the 
originator to each of the nodes in the track, which is not bad in terms 
of energy consumption compared to the 3 hand-shake per hop by NSIS. In 
that case CoAP can transport QoS Spec objects defined by RFC 5975 so we 
don't need to re-invent them. Of course for the distributed approach 
NSIS is still suitable so we can still decide what would be the best.

regards,
Xavi

Al 09/05/13 01:29, En/na Thomas Watteyne ha escrit:
> All,
>
> Let's continue the discussion on the requirements for the protocol 
> used by the PCE to communicate with a 6TSCH network. We have had 
> several discussions and have identified existing protocols which 
> answer different parts of the needs.
>
> I'd like to start summarizing the requirements we have identified for 
> this protocol. The objective is to be able to assess the different 
> solutions. This can turn into a discussion on the next call, then 
> maybe a section in the architecture or a future requirements draft.
>
> Thomas
>
> ---
>
> *_Requirement 1_.*
>
> /The protocol MUST carry metric information from the nodes to the PCE./
>
> - node metrics, quantifying the general status and health of a node in 
> the network
>
> The PCE uses this information to keep an up-to-date view of the 
> network, which it uses to determine the TSCH schedule.
>
> _Discussion_:
>
> RFC6551 is a great starting point. The DAG Metric Container Format [1] 
> can probably be used as-is as the payload of the protocol. IANA tracks 
> the different types of metrics and other attributes [2], and since 
> these are designed for RPL, I believe this is a perfect fit..
>
> *_Requirement 2_.*
>
> /The protocol MUST carry commands from the PCE to the motes in the 
> network./
>
> This allows the PCE to "remote control" the TSCH schedule, based on 
> the view of the topology if has (requirements 1 and 4) and the 
> scheduling requirements it receives from the mote (requirement 3).
>
> _Discussion_:
>
> These commands could map almost directly to the commands identifies in 
> the 6tus draft [3]. That is, the PCE can:
> - add/remove slotframes
> - add/remove hard cells
> On top of this, the PCE can map cells to labels, to allow for 
> 6tus-based label switching (this feature has been discussed, but is 
> not currently in the 6tus draft).
>
> *_Requirement 3_.*
>
> /The protocol MUST carry scheduling requirements from any node to the 
> PCE./
>
> When an application starts reporting data on a node, this node must be 
> able to contact the PCE, indicating the traffic requirements it has. 
> Similarly, the PCE must be able to indicate whether it can satisfy 
> those requirements or not.
>
> _Discussion_:
>
> It looks like this requirement is fully satisfied by PCEP [5] which 
> defines the formats of the PCReq and PCResp. Moreover, the IANA is 
> tracking the different types of requirements [6].
>
> *_Requirement 4_.*
>
> /The protocol MUST carry alarms from any node to the PCE./
>
> If a node in the network detects a malfunction, possibly through a 
> local OAM mechanism [4], it must be able to indicate this to the PCE 
> so it can take the appropriate action. This information is 
> complementary to the metric information.
>
> _Discussion_:
>
> In the case of a fully deterministic network (i.e. all tracks consist 
> of dedicated cells, and the schedule is collision free), the OAM 
> mechanism can be greatly simplified since the PCE can do the OAM's 
> Connectivity Verification (CV) by looking at the schedule of the network.
>
> What's then left is the Continuity Check. The periodic 
> re-synchronization mechanism between a nodes and its time source 
> neighbor imposed by TSCH can be used to help with that.
>
> *_Requirement 5_.*
>
> /The protocol MUST ensure mutual authentication between the PCE and 
> the nodes./
> /
> /
> coming from the PCE; and the PCE must make sure that the data is 
> coming from a node.
>
> _Discussion_:
>
> How this is done might be left to some secure transport layer (e.g. 
> DTLS), or build in the protocol directly.
>
> *_Requirement 6_.*
>
> /The protocol MAY ensure confidentiality of the traffic between the 
> PCE and the nodes./
>
> In case all traffic is unicast between the PCE and the 6TSCH nodes, 
> one can imagine an encryption mechanism whereby a mote can not spoof 
> on the PCE command it is relaying.
>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 9 May 2013 14:10:05 -0700

I like your concept of a Frankenstein protocol. Beware that if we keep
using it, Maria Rita will add it to the terminology draft :)

If I understand your proposal correctly, CoAP is the foundation of all
communication between the PCE and the nodes. DTLS could take care of
authentication and encryption, and the payload carried by CoAP would
consist of headers borrowed from the different protocols we've been talking
about:
- RFC6551's DAG Metric Container
- PCEP's PReq and PResp. Maybe even the setup handshaking and keep-alive
procedures?

It would require at a handful of fields at the beginning of the CoAP
payload to indicate at the very least the type of packet (alarm from a
mote, command from the PCE, metrics, etc), right?

If you have already some thoughts about this, maybe you could throw
together a handful of slides to show how the piece would fit together? You
could present them at the call tomorrow and we could gather a first
impression from the attendees.

What do others think?

Thomas

On Thu, May 9, 2013 at 7:08 AM, Xavier Vilajosana <
[email-masked]> wrote:

>  Hi Thomas,all,
>
> this is very useful list of requirements, out of what we have been looking
> (PCEP,NSIS/RSVP) which seem to be only small pieces of what we need and
> would require us to build a Frankenstein protocol, CoAP comes to my mind,
> i.e, CoAP is a transport protocol that we can use to transport the
> requirements of PCE/Nodes in the network.
> For example:
>
> - status information flowing from the nodes to the PCE could consist of a
> CoAP transport with the DAG Metric Container Format from RFC6551 in the
> payload. This would avoid having to reinvent all the different metrics.
> - finally, it we run CoAP on top of DTLS, we get authentication/encryption
> for free.
>
> arbitrary nodes that live in a track, the only restriction I see is that a
> possible track reservation will require unicast messages from the
> originator to each of the nodes in the track, which is not bad in terms of
> energy consumption compared to the 3 hand-shake per hop by NSIS. In that
> case CoAP can transport QoS Spec objects defined by RFC 5975 so we don't
> need to re-invent them. Of course for the distributed approach NSIS is
> still suitable so we can still decide what would be the best.
>
> regards,
> Xavi
>
>
>
>  Let's continue the discussion on the requirements for the protocol used
> by the PCE to communicate with a 6TSCH network. We have had several
> solutions. This can turn into a discussion on the next call, then maybe a
> section in the architecture or a future requirements draft.
>
>  Thomas
>
>  ---
>
>  *Requirement 1.*
>
> can probably be used as-is as the payload of the protocol. IANA tracks the
> Similarly, the PCE must be able to indicate whether it can satisfy those
> requirements or not.
>
>  *Discussion*:
>
> defines the formats of the PCReq and PCResp. Moreover, the IANA is tracking
> the different types of requirements [6].
>
>  *Requirement 4.*
>
> re-synchronization mechanism between a nodes and its time source neighbor
> imposed by TSCH can be used to help with that.
>
>  *Requirement 5.*
>
>  *The protocol MAY ensure confidentiality of the traffic between the PCE
> and the nodes.*
>
>  In case all traffic is unicast between the PCE and the 6TSCH nodes, one
> can imagine an encryption mechanism whereby a mote can not spoof on the PCE
> command it is relaying.
>
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 10 May 2013 06:27:21 +0000

Thomas, Xavi
What a great job! Thanks a lot for having worked on the requirements and paved the way to the 6TSCH Frankenstein protocol :)
It seems that all the little pieces (i.e., the different protocols we have analyzed) can fit together, and thanks to CoAP we can build what we need in the 6TSCH architecture.
For sure, we still have some work left, but this is a good starting point!
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Thursday, May 09, 2013 11:10 PM
To: 6TSCH
Subject: Re: [6tsch] PCE<->6TSCH protocol: requirements

I like your concept of a Frankenstein protocol. Beware that if we keep using it, Maria Rita will add it to the terminology draft :)

If I understand your proposal correctly, CoAP is the foundation of all communication between the PCE and the nodes. DTLS could take care of authentication and encryption, and the payload carried by CoAP would consist of headers borrowed from the different protocols we've been talking about:
- RFC6551's DAG Metric Container
- PCEP's PReq and PResp. Maybe even the setup handshaking and keep-alive procedures?

It would require at a handful of fields at the beginning of the CoAP payload to indicate at the very least the type of packet (alarm from a mote, command from the PCE, metrics, etc), right?

If you have already some thoughts about this, maybe you could throw together a handful of slides to show how the piece would fit together? You could present them at the call tomorrow and we could gather a first impression from the attendees.

What do others think?

Thomas

On Thu, May 9, 2013 at 7:08 AM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas,all,

this is very useful list of requirements, out of what we have been looking (PCEP,NSIS/RSVP) which seem to be only small pieces of what we need and would require us to build a Frankenstein protocol, CoAP comes to my mind, i.e, CoAP is a transport protocol that we can use to transport the requirements of PCE/Nodes in the network.
For example:

- status information flowing from the nodes to the PCE could consist of a CoAP transport with the DAG Metric Container Format from RFC6551 in the payload. This would avoid having to reinvent all the different metrics.
- similarly, the message to ask the PCE to install a track, and for the PCE to confirm that it was installed could simply be a PCEP payload.
- finally, it we run CoAP on top of DTLS, we get authentication/encryption for free.

As for the distributed approach, CoAP can be used to communicate to arbitrary nodes that live in a track, the only restriction I see is that a possible track reservation will require unicast messages from the originator to each of the nodes in the track, which is not bad in terms of energy consumption compared to the 3 hand-shake per hop by NSIS. In that case CoAP can transport QoS Spec objects defined by RFC 5975 so we don't need to re-invent them. Of course for the distributed approach NSIS is still suitable so we can still decide what would be the best.

regards,
Xavi

Let's continue the discussion on the requirements for the protocol used by the PCE to communicate with a 6TSCH network. We have had several discussions and have identified existing protocols which answer different parts of the needs.

I'd like to start summarizing the requirements we have identified for this protocol. The objective is to be able to assess the different solutions. This can turn into a discussion on the next call, then maybe a section in the architecture or a future requirements draft.

Thomas

---

Requirement 1.

The protocol MUST carry metric information from the nodes to the PCE.

Here, "metrics" is a general term which covers:
- link metrics, quantifying the connection between neighbor nodes
- node metrics, quantifying the general status and health of a node in the network

The PCE uses this information to keep an up-to-date view of the network, which it uses to determine the TSCH schedule.

Discussion:

RFC6551 is a great starting point. The DAG Metric Container Format [1] can probably be used as-is as the payload of the protocol. IANA tracks the different types of metrics and other attributes [2], and since these are designed for RPL, I believe this is a perfect fit..

Requirement 2.

The protocol MUST carry commands from the PCE to the motes in the network.

This allows the PCE to "remote control" the TSCH schedule, based on the view of the topology if has (requirements 1 and 4) and the scheduling requirements it receives from the mote (requirement 3).

Discussion:

These commands could map almost directly to the commands identifies in the 6tus draft [3]. That is, the PCE can:
- add/remove slotframes
- add/remove hard cells
- control time source neighbors
- control the generation of EBs

On top of this, the PCE can map cells to labels, to allow for 6tus-based label switching (this feature has been discussed, but is not currently in the 6tus draft).

Requirement 3.

The protocol MUST carry scheduling requirements from any node to the PCE.

When an application starts reporting data on a node, this node must be able to contact the PCE, indicating the traffic requirements it has. Similarly, the PCE must be able to indicate whether it can satisfy those requirements or not.

Discussion:

It looks like this requirement is fully satisfied by PCEP [5] which defines the formats of the PCReq and PCResp. Moreover, the IANA is tracking the different types of requirements [6].

Requirement 4.

The protocol MUST carry alarms from any node to the PCE.

If a node in the network detects a malfunction, possibly through a local OAM mechanism [4], it must be able to indicate this to the PCE so it can take the appropriate action. This information is complementary to the metric information.

Discussion:

In the case of a fully deterministic network (i.e. all tracks consist of dedicated cells, and the schedule is collision free), the OAM mechanism can be greatly simplified since the PCE can do the OAM's Connectivity Verification (CV) by looking at the schedule of the network.

What's then left is the Continuity Check. The periodic re-synchronization mechanism between a nodes and its time source neighbor imposed by TSCH can be used to help with that.

Requirement 5.

The protocol MUST ensure mutual authentication between the PCE and the nodes.

Nodes in the 6TSCH network need to be able to ensure that a command is coming from the PCE; and the PCE must make sure that the data is coming from a node.

Discussion:

How this is done might be left to some secure transport layer (e.g. DTLS), or build in the protocol directly.

Requirement 6.

The protocol MAY ensure confidentiality of the traffic between the PCE and the nodes.

In case all traffic is unicast between the PCE and the 6TSCH nodes, one can imagine an encryption mechanism whereby a mote can not spoof on the PCE command it is relaying.

[2] http://www.iana.org/assignments/rpl-routing-metric-constraint/rpl-routing-metric-constraint.xml

6tsch mailing list

[email-masked]<mailto:[email-masked]>

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

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 9 May 2013 23:36:06 -0700

Maria Rita,

We want to make sure that, whatever we end up using, it is generic enough
to be usable by several PCE implementations. Given your experience with
these kinds of things, your input is very much appreciated. In particular,
please shout if a requirement is missing!

Thomas

On Thu, May 9, 2013 at 11:27 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Thomas, Xavi****
>
> What a great job! Thanks a lot for having worked on the requirements and
> paved the way to the 6TSCH Frankenstein protocol J****
>
> It seems that all the little pieces (i.e., the different protocols we have
> analyzed) can fit together, and thanks to CoAP we can build what we need in
> the 6TSCH architecture.****
>
> ****
> Maria Rita****
> ** **
> ** **
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Thursday, May 09, 2013 11:10 PM
> *To:* 6TSCH
> *Subject:* Re: [6tsch] PCE<->6TSCH protocol: requirements****
>
> ** **
>
> using it, Maria Rita will add it to the terminology draft :)****
>
> ** **
>
> about:****
> - RFC6551's DAG Metric Container****
>
> procedures?****
> ** **
> mote, command from the PCE, metrics, etc), right?****
>
> ** **
>
> impression from the attendees.****
>
> ** **
>
> What do others think?****
>
> ** **
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hi Thomas,all,
>
> Al 09/05/13 01:29, En/na Thomas Watteyne ha escrit:****
>
>   All,****
>
> ** **
>
> parts of the needs.****
> ** **
> the architecture or a future requirements draft.****
>
> ** **
>
> Thomas****
>
> ** **
>
> ---****
>
> ** **
>
> *Requirement 1.*****
>
> ** **
>
> *The protocol MUST carry metric information from the nodes to the PCE.****
> *
>
> ** **
>
> Here, "metrics" is a general term which covers:****
>
> - link metrics, quantifying the connection between neighbor nodes****
>
> network****
> ** **
> which it uses to determine the TSCH schedule.****
>
> ** **
>
> *Discussion*:****
>
> ** **
>
> designed for RPL, I believe this is a perfect fit..****
>
> ** **
>
> *Requirement 2.*****
>
> ** **
>
> *The protocol MUST carry commands from the PCE to the motes in the
> network.*****
>
> ** **
>
> requirements it receives from the mote (requirement 3).****
>
> ** **
>
> *Discussion*:****
>
> ** **
>
> 6tus draft [3]. That is, the PCE can:****
>
> - add/remove slotframes****
>
> - add/remove hard cells****
>
> - control time source neighbors****
>
> - control the generation of EBs****
>
> ** **
>
> the 6tus draft).****
> ** **
> *Requirement 3.*****
> ** **
> *The protocol MUST carry scheduling requirements from any node to the PCE.
> *****
>
> ** **
>
> requirements or not.****
> ** **
> *Discussion*:****
> ** **
> the different types of requirements [6].****
>
> ** **
>
> *Requirement 4.*****
>
> ** **
>
> *The protocol MUST carry alarms from any node to the PCE.*****
>
> ** **
>
> metric information.****
> ** **
> *Discussion*:****
> ** **
> Verification (CV) by looking at the schedule of the network.****
>
> ** **
>
> be used to help with that.****
>
> ** **
>
> *Requirement 5.*****
>
> ** **
>
> nodes.*****
> ** **
> from a node.****
> ** **
> *Discussion*:****
> ** **
> or build in the protocol directly.****
>
> ** **
>
> *Requirement 6.*****
>
> ** **
>
> and the nodes.*****
> ** **
> command it is relaying.****
>
> ** **
>
> [1] http://tools.ietf.org/html/rfc6551#section-2****
>
> [2]
> ****
> [3] http://tools.ietf.org/html/draft-wang-6tsch-6tus-00#section-2.4****
>
> [4] http://tools.ietf.org/html/draft-ietf-opsawg-oam-overview-08****
>
> [5] http://tools.ietf.org/html/rfc5440#section-6.4****
>
> [6] http://www.iana.org/assignments/pcep/pcep.xml****
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> 6tsch mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 10 May 2013 07:08:36 +0000

Thomas,
I totally agree about developing a GENERIC solution that works well in several scenario.
For the time being, your list of requirements is pretty good, and complete. If something else comes in my mind, I will let you know. Sure!
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Friday, May 10, 2013 8:36 AM
To: 6TSCH
Subject: Re: [6tsch] PCE<->6TSCH protocol: requirements

Maria Rita,

We want to make sure that, whatever we end up using, it is generic enough to be usable by several PCE implementations. Given your experience with these kinds of things, your input is very much appreciated. In particular, please shout if a requirement is missing!

Thomas

On Thu, May 9, 2013 at 11:27 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Thomas, Xavi
What a great job! Thanks a lot for having worked on the requirements and paved the way to the 6TSCH Frankenstein protocol :)
It seems that all the little pieces (i.e., the different protocols we have analyzed) can fit together, and thanks to CoAP we can build what we need in the 6TSCH architecture.
For sure, we still have some work left, but this is a good starting point!
Maria Rita

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Thomas Watteyne
Sent: Thursday, May 09, 2013 11:10 PM
To: 6TSCH
Subject: Re: [6tsch] PCE<->6TSCH protocol: requirements

What do others think?

Thomas

regards,
Xavi

Thomas

---

Requirement 1.

Discussion:

Requirement 2.

Discussion:

Requirement 3.

Discussion:

Requirement 4.

Discussion:

Requirement 5.

Discussion:

Requirement 6.

6tsch mailing list

---

From: Guillaume Gaillard <[email-masked]>
Date: Wed, 15 May 2013 09:39:26 +0200

Hello Thomas,
Your list of requirements seems to match the needs of communication between
nodes and PCE. I believe it permits precise observation of network
performance (req1, req4) and behavior (req3), and accurate enforcement of
PCE's control (req2).

Regards,
Guillaume

Guillaume Gaillard
PhD student "SLAs for multi-services WSN"
Orange Labs Meylan, France

2013/5/10 Maria Rita PALATTELLA <[email-masked]>

>  Thomas,****
>
> I totally agree about developing a GENERIC solution that works well in
> several scenario. ****
>
> For the time being, your list of requirements is pretty good, and
> complete. If something else comes in my mind, I will let you know. Sure!**
> **
>
> Maria Rita****
>
> ** **
>
> ** **
>
> ** **
>
> *Sent:* Friday, May 10, 2013 8:36 AM
>
> *To:* 6TSCH
> Maria Rita,****
> please shout if a requirement is missing!****
>
> ** **
>
> Thomas****
>
> ** **
>
> ** **
>
> ** **
>
> [email-masked]> wrote:****
>
> Thomas, Xavi****
>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 16 May 2013 18:51:30 -0700

Guillaume,

Awesome, glad you agree with the list.

One thing that might be missing is the bootstrapping of a network. In the
context of the PCE<->node protocol (looking forward to having a name for
it), the question is whether there are some particular packets and headers
a node uses when joining the network. Thoughts on this?

Thomas

On Wed, May 15, 2013 at 12:39 AM, Guillaume Gaillard <
[email-masked]> wrote:

> Hello Thomas,
> Your list of requirements seems to match the needs of communication
> between nodes and PCE. I believe it permits precise observation of network
>> complete. If something else comes in my mind, I will let you know. Sure!*
>> ***
>>
>> Maria Rita****
>>
>> ** **
>>
>> ** **
>>
>> ** **
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Thomas Watteyne
>> It seems that all the little pieces (i.e., the different protocols we
>> have analyzed) can fit together, and thanks to CoAP we can build what we
>> need in the 6TSCH architecture.****
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Thomas Watteyne
>> looking (PCEP,NSIS/RSVP) which seem to be only small pieces of what we need
>> and would require us to build a Frankenstein protocol, CoAP comes to my
>> mind, i.e, CoAP is a transport protocol that we can use to transport the
>> section in the architecture or a future requirements draft.****
>>
>>  ****
>>
>> Thomas****
>>
>>  ****
>>
>> ---****
>>
>>  ****
>>
>> *Requirement 1.*****
>>
>>  ****
>>
>> *The protocol MUST carry metric information from the nodes to the PCE.***
>> **
>>
>>  ****
>>
>> the network****
>> the 6tus draft [3]. That is, the PCE can:****
>>
>> *The protocol MUST carry scheduling requirements from any node to the
>> PCE.*****
>>
>>  ****
>>
>> DTLS), or build in the protocol directly.****
>>
>>  ****
>>
>> *Requirement 6.*****
>>
>>  ****
>>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 17 May 2013 06:40:28 +0000

Thomas,
In fact, we need to define better the set-up phase of the network. As already discussed, 6TUS may help for the 6TSCH network formation, but then, we have to clarify how each node can start interacting with the PCE, how communications happen before the schedule is build and distributed, etc.

Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Friday, May 17, 2013 3:52 AM
To: 6TSCH
Subject: Re: [6tsch] PCE<->6TSCH protocol: requirements

Guillaume,

One thing that might be missing is the bootstrapping of a network. In the context of the PCE<->node protocol (looking forward to having a name for it), the question is whether there are some particular packets and headers a node uses when joining the network. Thoughts on this?

Thomas

On Wed, May 15, 2013 at 12:39 AM, Guillaume Gaillard <[email-masked]<mailto:[email-masked]>> wrote:
Hello Thomas,
Your list of requirements seems to match the needs of communication between nodes and PCE. I believe it permits precise observation of network performance (req1, req4) and behavior (req3), and accurate enforcement of PCE's control (req2).

Regards,
Guillaume
[https://mail.google.com/mail/u/0/images/cleardot.gif]

Guillaume Gaillard

2013/5/10 Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>>
Thomas,
I totally agree about developing a GENERIC solution that works well in several scenario.
For the time being, your list of requirements is pretty good, and complete. If something else comes in my mind, I will let you know. Sure!
Maria Rita

To: 6TSCH

Maria Rita,

Thomas

What do others think?

Thomas

regards,
Xavi

Thomas

---

Requirement 1.

Discussion:

Requirement 2.

Discussion:

Requirement 3.

Discussion:

Requirement 4.

Discussion:

Requirement 5.

Discussion:

Requirement 6.

6tsch mailing list