Subject: Re: [6tsch] PCEP for centralized scheduling in 6TSCH architecture

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 May 2013 14:09:09 +0000

I'm with you Thomas;

I think that your first requirement applies in particular to the methods for peer evaluation that should homogeneous between RPL and PCE.

Which leads us to:
- consistent metrics (and metrics formats?) => reuse RFC 6551 when advertising metrics to the PCE
- shared methods for link maintenance
- shared methods for link measurements

We'll note that RPL does not define the aforementioned methods, which are left to the particular use case / link.
But since we are focusing on a particular MAC, maybe at 6TSCH we should be more specific?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: mercredi 1 mai 2013 05:39
To: IETF 6TSCH
Subject: Re: [6tsch] PCEP for centralized scheduling in 6TSCH architecture

Maria Rita,

Awesome! Thanks for putting this on the ML.

One important step I think is to decide what we want the scope of this protocol to be.

Here are a couple of thoughts on what the goals are (I'm at the airport, so please forgive the not-so-organized nature of this e-mail):
- this is the protocol used for signalling messages to flow between the PCE and the nodes in the network
- the nodes use this protocol (if possible) to tell the PCE how they are doing. This includes topological information, traffic requirements, etc.
- what happens in the PCE is independent from this protocol,
- the PCE uses this protocol to drive the network schedule, installing and moving tracks in the network, probably using mostly hard cells.

On top of this, I can think on the following requirements:
- reuse existing protocols and techniques as much as possible
- security: nodes and PCE should be able to authenticate each other. It might also be useful to ensure confidentiality, so that a node can not overhear the traffic between the PCE and another node.
- simplicity and applicability to out simple LLNs (i.e. small state, small overhead,...)

Thoughts?

Thomas

On Tue, Apr 30, 2013 at 1:53 AM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Dear all,
I have started investigating the RFC5440 "Path Computation Element Communication Protocol (PCEP)" in order to check " if" and "how" it could fit in our 6TSCH architecture.
In detail, I wanted to see if we could use PCEP + TASA (Traffic Aware Scheduling Algorithm) for computing and distributing the schedule from the PCE to the nodes in a 6TSCH architecture that uses a centralized scheduling algorithm.
I had some preliminary discussion already with Thomas on this topic, but let's discuss all together on the ML. We would like to have your feedback in order to see if we can really use PCEP, and how we can fix some open issues in the 6TSCH context.
I will use some extracts from the RFC5440, that summarize the behavior of the protocol, and show features that we could exploit.
This will result in a *very long* email. Sorry for that. And thanks for going through it, and come back to me with your comments, questions, suggestions.
Maria Rita

>>PCEP is such a protocol designed specifically for communications between a PCC and a PCE [...] a PCC may use PCEP to send a path computation request for one or more TE LSPs to a PCE, and the PCE may reply with a set of computed paths if one or more paths can be found that satisfies the set of constraints.
>> PCC:  Path Computation Client; any client application requesting a path computation to be performed by a Path Computation Element.
>> PCE:  Path Computation Element; an entity (component, application, or network node) that is capable of computing a network path or route based on a network graph and applying computational constraints.
>> Explicit path:  Full explicit path from start to destination; made of a list of strict hops where a hop may be an abstract node such as an AS.
 [MR] The explicit path could be seen as a 6TSCH track, composed by hard cells.

>> [...] it is assumed that the PCE has the required information (usually including network topology and resource information) so as to perform the computation of a path for a TE LSP.  Such information can be gathered by routing protocols or by some other means.  The way in which the information is gathered is out of the scope of this document (i.e, RFC5440).
 [Thomas] Is that not a bit limiting? This means that we need one protocol (PCEP) to send data from the PCE to the motes, and another for stats and topological and requirement data to go from the motes to the PCE.
 [MR] Yes, it is. Like 15.4e TSCH that uses a schedule but it doesn't specify how to build and distribute it, PCEP does not define how to collect the required information (network topology, requirements) used for computing paths. But the motes can specify the requirements of the requested path within the PCReq messages.

>>  Transport Protocol. PCEP operates over TCP using a registered TCP port (4189). This allows the requirements of reliable messaging and flow control to be met without further protocol work. All PCEP messages MUST be sent using the registered TCP port for the source and destination TCP port.
 [Thomas] can PCEP run on something else than TCP? It looks like no. There is always the possibility for proposing a UDP version of PCEP, but it's unclear to me how much rework is required.
[MR] According to the RFC5440, a PCEP session can be established ONLY  over a  TCP connection. In other words, first a TCP connection (3-way handshake) between the PCC and the PCE has to be established, and after a PCEP session can be started. About proposing an UDP version of PCEP, it is something to be investigated.

>> Once the PCC has selected a PCE, it sends a Path Computation Request to the PCE (PCReq message) that contains a variety of objects that
specify the set of constraints and attributes for the path to be computed.  For example, "Compute a TE LSP path with source IP address=x.y.z.t,
 destination IP address=x'.y'.z'.t', bandwidth=B Mbit/s, Setup/Holding priority=P, ...".  Additionally, the PCC may desire to specify the urgency
 of such request by assigning a request priority.

[Thomas]If the PCE received a PCReq to go from A to B, is there a way for the PCE to contact all the motes along the multi-hop path between A and B and
install cells/links? it looks like the PCE is only used to calculate a multi-hop path on an already existing topology.
[MR]I agree with you. PCEP can set up a multi-hop path on an already existing topology. There is correspondence 1-to-1 between PCReq and PCRep. Thus, it seems that PCE cannot contact the motes along the multi-hop path between A and B. BUT... PCEP include some RP in the messages (see below)
 >>A Path Computation Reply(PCRep) Message can contain either a set of computed paths if the request can be satisfied, or a negative reply if not.  The negative reply may indicate the reason why no path could be found.
>>The RP (Request Parameters) object MUST be carried within each PCReq and PCRep messages. The RP object is used to specify various characteristics of the path computation request.
 >> The END-POINTS object is used in a PCReq message to specify the source IP address and the destination IP address of the path for which a path computation is requested. Note that the source and destination addresses specified in the END-POINTS object may correspond to the source and destination IP address of the TE LSP or to those of a path segment.
 [MR] Setting the END-POINT object, maybe it could be possible to allocate cells/links for each path segment. This is something to be investigated.
 >>The BANDWIDTH object is used to specify the requested bandwidth for a TE LSP. The notion of bandwidth is similar to the one used for RSVP >>signaling in [RFC2205], [RFC3209], and [RFC3473].
 >>The METRIC object is optional and can be used for several purposes. In a PCReq message, a PCC MAY insert one or more METRIC objects:
 o To indicate the metric that MUST be optimized by the path computation algorithm (IGP metric, TE metric, hop counts).
Currently, three metrics are defined: the IGP cost, the TE metric (see [RFC3785]), and the number of hops traversed by a TE LSP.
 o To indicate a bound on the path cost that MUST NOT be exceeded for the path to be considered as acceptable by the PCC.
 >>The path computation algorithmic aspects used by the PCE to optimize a path with respect to a specific metric are outside the scope of this >>document.
[MR] TASA could be a possible algorithm for computing the path. It seems to fits well with the RFC5440 Specification.

TASA provides a method to the PCE for computing a network path, based on the network graph and applying computational constraints (i.e., selecting duplex- and
interference-free conflict links, according to local and global queue level).
Each node in the TSCH TASA-based network could act as PCC (Path Computation Client), requesting a path computation to be performed by the PCE. In detail, with the PCReq message,
the PCC asks the PCE to compute a path toward it (thus, source IP address = PCC IP address, destination IP address = PCE destination address), having a  given bandwidth, equal to the number of packets it wants to transmit (i.e., TASA local queue level, or  in other word, traffic load offered by the single node to the network).
After having collected all the PCReq messages from all the nodes in the network, the PCE can build a schedule, setting one or more paths for each PCC.
Once, the schedule has been built according to TASA matching and coloring procedures, it is transmitted to each node in the network, using PCRep messages.
Then, the 6TSCH 6TUS adaptation protocol can provide the functionality for delivering the traffic in the queues, according to the schedule built with TASA+PCEP.

Some Open ISSUES:

Q1: How the PCE collect the information related to the network graph?
R1: Note that this is out of the scope of both RCF5440 and TASA. However, we may suppose that such information are provided by the routing protocol, RPL, as suggested in RFC5440.
"How" still has to be defined!
[Thomas] Agreed, that's a really important point.

Q2: How the network is set up before implementing TASA+PCEP for building the schedule?
R2: TASA does not specify how the network is built. In fact, TASA runs over a network that has been already built, and that needs a schedule in order
to allow traffic-flow exchanges (i.e., transmissions between each node and the PCE). Maybe, 6TUS could fill this gap and provide the functionality for the 15.4e TSCH network formation.

[Thomas] I believe the "minimal" use case identified in the charter covers this.

Q3: Is there any need to change the PCReq and PCRep messages format, for allowing the integration of PCEP with TASA?
[MR] there could be such need.

Q4:How the info in the PCRep messages can be used by 6TUS?

[Thomas] The entity in the motes which received PCRep message simply send commands over the 6tus interface.

Q5: How would a TASA+PCEP solution work for P2P traffic? That is, data flowing from a switch to a light without going through the DAGroot?
[MR]TASA supports multi-point-to-point traffic (from each mote in the network to the DODAGroot). PCEP support P2P traffic. TASA+PCEP maybe could support P2P traffic. This is something to be investigated.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 1 May 2013 14:21:31 +0000

[PT] agreed
 [Thomas] Is that not a bit limiting? This means that we need one protocol (PCEP) to send data from the PCE to the motes, and another for stats and topological and requirement data to go from the motes to the PCE.
 [MR] Yes, it is. Like 15.4e TSCH that uses a schedule but it doesn't specify how to build and distribute it, PCEP does not define how to collect the required information (network topology, requirements) used for computing paths. But the motes can specify the requirements of the requested path within the PCReq messages.
[PT] This is actually cool, because we probably want to reuse RPL's metrics containers, and we can do that with no change to PCEP. But since RPL is not a link state protocol, we will have to add stuff to describe the slot-frames, cells and the associated metrics to the PCE. In short, we'll have a brand new protocol for what's really specific, and we'll reuse PCEP for what's common.

[PT] I talked to JP about that at the last IETF. He mentioned that PCEP over UDP had been evaluated and was possible. Now that we have a use case, I can imagine that we could convince the PCE WG to take that work to completion.

[Thomas]If the PCE received a PCReq to go from A to B, is there a way for the PCE to contact all the motes along the multi-hop path between A and B and
install cells/links? it looks like the PCE is only used to calculate a multi-hop path on an already existing topology.
[MR]I agree with you. PCEP can set up a multi-hop path on an already existing topology. There is correspondence 1-to-1 between PCReq and PCRep. Thus, it seems that PCE cannot contact the motes along the multi-hop path between A and B. BUT... PCEP include some RP in the messages (see below)
[PT] Defining the topological information, selecting the peerings that are advertised to the PCE, etc... All that takes will end up with a considerable piece of work. We can probably export the PCEP over UDPO work to PCE, but the rest is a good piece of work altogether.
>>The RP (Request Parameters) object MUST be carried within each PCReq and PCRep messages. The RP object is used to specify various characteristics of the path computation request.
[PT] We will have to validate whether we can work out our use cases with RPs as specified.

[PT] We could imagine that the root acts as a relay (like in DHCP) for TASA, PCEP, etc... In that case, the discovery and security model is greatly simplified.
Some Open ISSUES:

[PT] Yes. It is fundamental that the basic operation maintains connectivity to all nodes at all times possible, so that anything else we do (PCE, management) can rely on that connectivity.
Q3: Is there any need to change the PCReq and PCRep messages format, for allowing the integration of PCEP with TASA?
[MR] there could be such need.

[PT] Thanks Maria for this great start!

Pascal

---

From: Xavier Vilajosana <[email-masked]>
Date: Wed, 01 May 2013 12:00:44 -0700

Hi,

I like to look in the inverse direction, PCEP seems to me very close to 
RSVP-TE. But with the difference that RSVP provides path maintenance 
functionalities in addition to reservation functionalities. Maintenance 
functionalities (TIME object in RSVP) are used to trigger a refresh 
operation to a track. In a refresh operation the requirements of the 
path are checked and if not met this can trigger a new reservation. This 
mechanism can be used by the nodes to inform the PCE about network status.

Maybe I am biased by my recent readings on NSIS/RSVP but I don't see a 
benefit on PCEP over a minimal version of NSIS or RSVP.
As far as I understand NSIS/RSVP can provide:

+supported on UDP
+reservation (Point to Point)
+maintenance - status collection and monitoring
+Ad-hoc QoS content definition following a TLV and being appended to a 
generic header
+upstream and downstream reservation
+In case of NSIS neighbour discovery in case no routing state is installed.
+hop by hop state installation, does not require end to end messaging 
per hop

as negative points:
  -if fully implemented on motes will require lots of memory
  -long headers (although this messages are not very frequent so maybe 
this is not important)
  -not sure if there is support for  P2MP and MP2P reservation
  -RSVP - end to end state reservation.

Finally, I am not saying that I am against PCEP, but maybe we need to 
get an in deep knowledge of why PCEP should be better suited for our 
scenario.

On 01/05/13 07:21, Pascal Thubert (pthubert) wrote:
>
> Hello Maria Rita:
>
> >> Explicit path:  Full explicit path from start to destination; made of 
> a list of _strict hops_ where a hop may be an abstract node such as an AS.
>
> */[PT] agreed/*
> >> [...] it is assumed that the PCE has the required information 
> (usually including network topology and resource information) so as to 
> perform the computation of a path for a TE LSP.  Such information can 
> be gathered by routing protocols or by some other means.  The way in 
> which the information is gathered is out of the scope of this document 
> (i.e, RFC5440).
>
> [Thomas] Is that not a bit limiting? This means that we need one 
> protocol (PCEP) to send data from the PCE to the motes, and another 
> for stats and topological and requirement data to go from the motes to 
> the PCE.
>
>  [MR] Yes, it is. Like 15.4e TSCH that uses a schedule but it doesn't 
> specify how to build and distribute it, PCEP does not define how to 
> collect the required information (network topology, requirements) used 
> for computing paths. But the motes can specify the requirements of the 
> requested path within the PCReq messages.
>
> */[PT] This is actually cool, because we probably want to reuse RPL's 
> metrics containers, and we can do that with no change to PCEP. But 
> since RPL is not a link state protocol, we will have to add stuff to 
> describe the slot-frames, cells and the associated metrics to the PCE. 
> In short, we'll have a brand new protocol for what's really specific, 
> and we'll reuse PCEP for what's common./*
>
> *//*
>
> >>Transport Protocol. PCEP operates over TCP using a registered TCP port 
> (4189). This allows the requirements of reliable messaging and flow 
> control to be met without further protocol work. All PCEP messages 
> MUST be sent using the registered TCP port for the source and 
> destination TCP port.
>
> [Thomas] can PCEP run on something else than TCP? It looks like no. 
> There is always the possibility for proposing a UDP version of PCEP, 
> but it's unclear to me how much rework is required.
>
> [MR] According to the RFC5440, a PCEP session can be established ONLY  
> over a  TCP connection. In other words, first a TCP connection (3-way 
> handshake) between the PCC and the PCE has to be established, and 
> after a PCEP session can be started. About proposing an UDP version of 
> PCEP, it is something to be investigated.
>
> */[PT] I talked to JP about that at the last IETF. He mentioned that 
> PCEP over UDP had been evaluated and was possible. Now that we have a 
> use case, I can imagine that we could convince the PCE WG to take that 
> work to completion./*
>
> specify the set of constraints and attributes for the path to be 
> computed.  For example, "Compute a TE LSP path with source IP 
> address=x.y.z.t,
>  destination IP address=x'.y'.z'.t', bandwidth=B Mbit/s, Setup/Holding 
> priority=P, ...".  Additionally, the PCC may desire to specify the urgency
> [Thomas]If the PCE received a PCReq to go from A to B, is there a way 
> for the PCE to contact all the motes along the multi-hop path between 
> A and B and
>
> install cells/links? it looks like the PCE is only used to calculate a 
> multi-hop path on an already existing topology.
>
> [MR]I agree with you. PCEP can set up a multi-hop path on an already 
> existing topology. There is correspondence 1-to-1 between PCReq and 
> PCRep. Thus, it seems that PCE cannot contact the motes along the 
> multi-hop path between A and B. BUT... PCEP include some RP in the 
> messages (see below)
>
> */[PT] Defining the topological information, selecting the peerings 
> that are advertised to the PCE, etc... All that takes will end up with 
> a considerable piece of work. We can probably export the PCEP over 
> UDPO work to PCE, but the rest is a good piece of work altogether. /*
>
> >>A Path Computation Reply(PCRep) Message can contain either a set of computed paths if the request can be 
> satisfied, or a negative reply if not.  The negative reply may 
> indicate the reason why no path could be found.
>
> >>The RP (Request Parameters) object MUST be carried within each PCReq and 
> PCRep messages. The RP object is used to specify various 
> characteristics of the path computation request.
>
> */[PT] We will have to validate whether we can work out our use cases 
> with RPs as specified. /*
>
>  >> The END-POINTS object is used in a PCReq message to specify the 
> source IP address and the destination IP address of the path for which 
> a path computation is requested. Note that the source and destination 
> addresses specified in the END-POINTS object may correspond to the 
> source and destination IP address of the TE LSP or to those of a path 
> segment.
>
> [MR] Setting the END-POINT object, maybe it could be possible to 
> allocate cells/links for each path segment. This is something to be 
> investigated.
>
>  >>The BANDWIDTH object is used to specify the requested bandwidth for 
> a TE LSP. The notion of bandwidth is similar to the one used for RSVP 
> >>signaling in [RFC2205], [RFC3209], and [RFC3473].
>
>  >>The METRIC object is optional and can be used for several purposes. 
> In a PCReq message, a PCC MAY insert one or more METRIC objects:
>
>  o To indicate the metric that MUST be optimized by the path 
> computation algorithm (IGP metric, TE metric, hop counts).
>
> Currently, three metrics are defined: the IGP cost, the TE metric (see 
> [RFC3785]), and the number of hops traversed by a TE LSP.
>
>  o To indicate a bound on the path cost that MUST NOT be exceeded for 
> the path to be considered as acceptable by the PCC.
>
> _>>The path computation algorithmic aspects used by the PCE to 
> optimize a path with respect to a specific metric are outside the 
> scope of this >>document._
>
> [MR] TASA could be a possible algorithm for computing the path. It 
> seems to fits well with the RFC5440 Specification.
>
> TASA provides a method to the PCE for computing a network path, based 
> on the network graph and applying computational constraints (i.e., 
> selecting duplex- and
> Each node in the TSCH TASA-based network could act as PCC (Path 
> Computation Client), requesting a path computation to be performed by 
> the PCE. In detail, with the PCReq message,
> the PCC asks the PCE to compute a path toward it (thus, source IP 
> address = PCC IP address, destination IP address = PCE destination 
> address), having a  given bandwidth, equal to the number of packets it 
> wants to transmit (i.e., TASA local queue level, or  in other word, 
> traffic load offered by the single node to the network).
>
> After having collected all the PCReq messages from all the nodes in 
> the network, the PCE can build a schedule, setting one or more paths 
> for each PCC.
>
> Once, the schedule has been built according to TASA matching and 
> coloring procedures, it is transmitted to each node in the network, 
> using PCRep messages.
>
> Then, the 6TSCH 6TUS adaptation protocol can provide the functionality 
> for delivering the traffic in the queues, according to the schedule 
> built with TASA+PCEP.
>
> */[PT] We could imagine that the root acts as a relay (like in DHCP) 
> for TASA, PCEP, etc... In that case, the discovery and security model 
> is greatly simplified. /*
>
> *Some Open ISSUES:*
>
> *Q1:*How the PCE collect the information related to the network graph?
>
> *R1:*Note that this is out of the scope of both RCF5440 and TASA. 
> However, we may suppose that such information are provided by the 
> routing protocol, RPL, as suggested in RFC5440.
>
> *Q2:*How the network is set up before implementing TASA+PCEP for 
> building the schedule?
>
> *R2:*TASA does not specify how the network is built. In fact, TASA 
> runs over a network that has been already built, and that needs a 
> schedule in order
> to allow traffic-flow exchanges (i.e., transmissions between each node 
> and the PCE). Maybe, 6TUS could fill this gap and provide the 
> functionality for the 15.4e TSCH network formation.
>
> */[PT] Yes. It is fundamental that the basic operation maintains 
> connectivity to all nodes at all times possible, so that anything else 
> we do (PCE, management) can rely on that connectivity./*
>
> *//*
>
> *Q3: *Is there any need to change the PCReq and PCRep messages format, 
> for allowing the integration of PCEP with TASA?
>
> *Q4:*How the info in the PCRep messages can be used by 6TUS?
>
> *Q5:*How would a TASA+PCEP solution work for P2P traffic? That is, 
> data flowing from a switch to a light without going through the DAGroot?
>
> [MR]TASA supports multi-point-to-point traffic (from each mote in the 
> network to the DODAGroot). PCEP support P2P traffic. TASA+PCEP maybe 
> could support P2P traffic. This is something to be investigated.
>
> */[PT] Thanks Maria for this great start!/*
>
> *//*
>
> */Pascal/*
>
>
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: "Qin Wang" <[email-masked]>
Date: Wed, 1 May 2013 23:42:53 -0700

Hi,

A quick question: PCE computes "PATH" or "TRACK"?

Qin

>> >> Once the PCC has selected a PCE, it sends a Path Computation Request
>> to the PCE (PCReq message) that
>> contains a variety of objects that

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 2 May 2013 06:49:06 +0000

Hi Qin,

PCEP computes path (i.e., TRACK according to the 6TSCH terminology).

Maria Rita

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Thursday, May 02, 2013 8:43 AM
To: Xavier Vilajosana
Cc: [email-masked]
Subject: Re: [6tsch] PCEP for centralized scheduling in 6TSCH architecture

Hi,

Qin

> Hi,
>
> I like to look in the inverse direction, PCEP seems to me very close 
> to RSVP-TE. But with the difference that RSVP provides path 
> maintenance functionalities in addition to reservation 
> functionalities. Maintenance functionalities (TIME object in RSVP) are 
> used to trigger a refresh operation to a track. In a refresh operation 
> the requirements of the path are checked and if not met this can 
> trigger a new reservation. This mechanism can be used by the nodes to inform the PCE about network status.
>
> +maintenance - status collection and monitoring Ad-hoc QoS content 
> +definition following a TLV and being appended to a
> generic header
>> (usually including network topology and resource information) so as 
>> to perform the computation of a path for a TE LSP.  Such information 
>> can be gathered by routing protocols or by some other means.  The way 
>> in which the information is gathered is out of the scope of this 
>> document (i.e, RFC5440).
>>
>> for stats and topological and requirement data to go from the motes 
>> to the PCE.
>>
>> collect the required information (network topology, requirements) 
>> used for computing paths. But the motes can specify the requirements 
>> of the requested path within the PCReq messages.
>>
>> after a PCEP session can be started. About proposing an UDP version 
>> of PCEP, it is something to be investigated.
>>
>> use case, I can imagine that we could convince the PCE WG to take 
>> that work to completion./*
>>
>> address=x.y.z.t,  destination IP address=x'.y'.z'.t', bandwidth=B 
>> Mbit/s, Setup/Holding priority=P, ...".  Additionally, the PCC may 
>> desire to specify the urgency  of such request by assigning a request 
>> priority.
>>
>> install cells/links? it looks like the PCE is only used to calculate 
>> a multi-hop path on an already existing topology.
>>
>> that are advertised to the PCE, etc... All that takes will end up 
>> with a considerable piece of work. We can probably export the PCEP 
>> over UDPO work to PCE, but the rest is a good piece of work 
>> altogether. /*
>>
>> >>The RP (Request Parameters) object MUST be carried within each 
>> >>PCReq
>> and
>> source IP address and the destination IP address of the path for 
>> which a path computation is requested. Note that the source and 
>> destination addresses specified in the END-POINTS object may 
>> correspond to the source and destination IP address of the TE LSP or 
>> to those of a path segment.
>>
>>  >>The BANDWIDTH object is used to specify the requested bandwidth 
>> for a TE LSP. The notion of bandwidth is similar to the one used for 
>> RSVP
>> Currently, three metrics are defined: the IGP cost, the TE metric 
>> (see [RFC3785]), and the number of hops traversed by a TE LSP.
>>
>> selecting duplex- and interference-free conflict links, according to 
>> local and global queue level).
>>
>> the PCE. In detail, with the PCReq message, the PCC asks the PCE to 
>> compute a path toward it (thus, source IP address = PCC IP address, 
>> destination IP address = PCE destination address), having a  given 
>> bandwidth, equal to the number of packets it wants to transmit (i.e., 
>> TASA local queue level, or  in other word, traffic load offered by 
>> the single node to the network).
>>
>> Then, the 6TSCH 6TUS adaptation protocol can provide the 
>> functionality for delivering the traffic in the queues, according to 
>> the schedule built with TASA+PCEP.
>>
>> schedule in order to allow traffic-flow exchanges (i.e., 
>> transmissions between each node and the PCE). Maybe, 6TUS could fill 
>> this gap and provide the functionality for the 15.4e TSCH network 
>> formation.
>>
>> connectivity to all nodes at all times possible, so that anything 
>> else we do (PCE, management) can rely on that connectivity./*
>>
>> *//*
>>
>> *Q3: *Is there any need to change the PCReq and PCRep messages 
>> format, for allowing the integration of PCEP with TASA?
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 May 2013 16:08:27 +0000

Hello Xavi;

One good point is that we should dive into the functionalities that we need in our building blocks.
For the centralized routing, we have:
- dependencies on the peering protocol to establish the links that IP sees between nodes
- a PCEP-like protocol to obtain a track (and destroy or update it?),
- an OAM (Operations Administration and Maintenance) protocol to validate a track is still good enough,
- a new link-state-like protocol to inform the PCE of links and (RPL's?) metrics;

For this building block and actually all the others, it would be good to dive a next level into the functional set so as to refine the work items.
What do you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mercredi 1 mai 2013 21:01
To: [email-masked]
Subject: Re: [6tsch] PCEP for centralized scheduling in 6TSCH architecture

Hi,

I like to look in the inverse direction, PCEP seems to me very close to RSVP-TE. But with the difference that RSVP provides path maintenance functionalities in addition to reservation functionalities. Maintenance functionalities (TIME object in RSVP) are used to trigger a refresh operation to a track. In a refresh operation the requirements of the path are checked and if not met this can trigger a new reservation. This mechanism can be used by the nodes to inform the PCE about network status.

Maybe I am biased by my recent readings on NSIS/RSVP but I don't see a benefit on PCEP over a minimal version of NSIS or RSVP.
As far as I understand NSIS/RSVP can provide:

+supported on UDP
+reservation (Point to Point)
+maintenance - status collection and monitoring
+Ad-hoc QoS content definition following a TLV and being appended to a generic header
+upstream and downstream reservation
+In case of NSIS neighbour discovery in case no routing state is installed.
+hop by hop state installation, does not require end to end messaging per hop

as negative points:
 -if fully implemented on motes will require lots of memory
 -long headers (although this messages are not very frequent so maybe this is not important)
 -not sure if there is support for  P2MP and MP2P reservation
 -RSVP - end to end state reservation.

Finally, I am not saying that I am against PCEP, but maybe we need to get an in deep knowledge of why PCEP should be better suited for our scenario.

Pascal

6tsch mailing list

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 2 May 2013 17:40:25 +0000

Both : )

Note that RSVP uses a path that is already determined by a routing protocol whereas PCE both computes the path and then the sequence of cells.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: jeudi 2 mai 2013 08:43
To: Xavier Vilajosana
Cc: [email-masked]
Subject: Re: [6tsch] PCEP for centralized scheduling in 6TSCH architecture

Hi,

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 2 May 2013 20:24:46 -0700

+1

On Thu, May 2, 2013 at 10:40 AM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> Both : )
>
> Note that RSVP uses a path that is already determined by a routing
> protocol whereas PCE both computes the path and then the sequence of cells.
>
> Cheers,
>
> Pascal
>
>  <https://www.ietf.org/mailman/listinfo/6tsch>
>

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 3 May 2013 00:57:06 -0700

Hi Maria Rita,

>From your description about PCEP +TASA in the following, my understanding
is that each node, no matter sensor nodes or router, will work as PCC and
send PCReq message to PCE. The PCReq will include Bandwidth required
besides source and destination address. In another word, a node, including
router, has to figure out the bandwidth it needs independently. But, how?
I think the bandwidth needed from a router to another router is the result
computed by PCE, instead of the input from each router to the computation
in PCE.

Maybe I miss something.

Regards
Qin

> Dear all,
> I have started investigating the RFC5440 "Path Computation Element
> Communication Protocol (PCEP)" in order to check " if" and "how" it could
> fit in our 6TSCH architecture.
> In detail, I wanted to see if we could use PCEP + TASA (Traffic Aware
> Scheduling Algorithm) for computing and distributing the schedule from the
> PCE to the nodes in a 6TSCH architecture that uses a centralized
> scheduling algorithm.
> I had some preliminary discussion already with Thomas on this topic, but
> let's discuss all together on the ML. We would like to have your feedback
> in order to see if we can really use PCEP, and how we can fix some open
> issues in the 6TSCH context.
> I will use some extracts from the RFC5440, that summarize the behavior of
> the protocol, and show features that we could exploit.
> This will result in a *very long* email. Sorry for that. And thanks for
> going through it, and come back to me with your comments, questions,
> suggestions.
> Maria Rita
>
>>>PCEP is such a protocol designed specifically for communications between
>>> a PCC and a PCE [...] a PCC may use PCEP to send a path computation
>>> request for one or more TE LSPs to a PCE, and the PCE may reply with a
>>> set of computed paths if one or more paths can be found that satisfies
>>> the set of constraints.
>>> PCC:  Path Computation Client; any client application requesting a path
>>> computation to be performed by a Path Computation Element.
>>> PCE:  Path Computation Element; an entity (component, application, or
>>> network node) that is capable of computing a network path or route
>>> based on a network graph and applying computational constraints.
>>> Explicit path:  Full explicit path from start to destination; made of a
>>> list of strict hops where a hop may be an abstract node such as an AS.
>>> [...] it is assumed that the PCE has the required information (usually
>>> including network topology and resource information) so as to perform
>>> the computation of a path for a TE LSP.  Such information can be
>>> gathered by routing protocols or by some other means.  The way in which
>>> the information is gathered is out of the scope of this document (i.e,
>>> RFC5440).
>  [Thomas] Is that not a bit limiting? This means that we need one protocol
> (PCEP) to send data from the PCE to the motes, and another for stats and
> topological and requirement data to go from the motes to the PCE.
>  [Thomas] can PCEP run on something else than TCP? It looks like no. There
> is always the possibility for proposing a UDP version of PCEP, but it's
> unclear to me how much rework is required.
> handshake) between the PCC and the PCE has to be established, and after a
> PCEP session can be started. About proposing an UDP version of PCEP, it is
> something to be investigated.
>
>>> Once the PCC has selected a PCE, it sends a Path Computation Request to
>>> the PCE (PCReq message) that contains a variety of objects that
> specify the set of constraints and attributes for the path to be computed.
>  For example, "Compute a TE LSP path with source IP address=x.y.z.t,
> [Thomas]If the PCE received a PCReq to go from A to B, is there a way for
> the PCE to contact all the motes along the multi-hop path between A and B
> and
> existing topology. There is correspondence 1-to-1 between PCReq and PCRep.
> Thus, it seems that PCE cannot contact the motes along the multi-hop path
> between A and B. BUT... PCEP include some RP in the messages (see below)
>  >>A Path Computation Reply(PCRep) Message can contain either a set of
> computed paths if the request can be satisfied, or a negative reply if
> not.  The negative reply may indicate the reason why no path could be
> found.
>>> PCRep messages. The RP object is used to specify various characteristics
>>> of the path computation request.
>  >> The END-POINTS object is used in a PCReq message to specify the source
> IP address and the destination IP address of the path for which a path
> computation is requested. Note that the source and destination
>  [MR] Setting the END-POINT object, maybe it could be possible to allocate
> cells/links for each path segment. This is something to be investigated.
>  >>The BANDWIDTH object is used to specify the requested bandwidth for a
> TE LSP. The notion of bandwidth is similar to the one used for RSVP
>  >>The METRIC object is optional and can be used for several purposes. In
> a PCReq message, a PCC MAY insert one or more METRIC objects:
>  o To indicate the metric that MUST be optimized by the path computation
> algorithm (IGP metric, TE metric, hop counts).
>  o To indicate a bound on the path cost that MUST NOT be exceeded for the
> path to be considered as acceptable by the PCC.
>  >>The path computation algorithmic aspects used by the PCE to optimize a
> path with respect to a specific metric are outside the scope of this
> >>document.
> [MR] TASA could be a possible algorithm for computing the path. It seems
> to fits well with the RFC5440 Specification.
>
> TASA provides a method to the PCE for computing a network path, based on
> the network graph and applying computational constraints (i.e., selecting
> duplex- and
> Computation Client), requesting a path computation to be performed by the
> PCE. In detail, with the PCReq message,
> the PCC asks the PCE to compute a path toward it (thus, source IP address
> = PCC IP address, destination IP address = PCE destination address),
> having a  given bandwidth, equal to the number of packets it wants to
> transmit (i.e., TASA local queue level, or  in other word, traffic load
> offered by the single node to the network).
> After having collected all the PCReq messages from all the nodes in the
> network, the PCE can build a schedule, setting one or more paths for each
> PCC.
> Once, the schedule has been built according to TASA matching and coloring
> procedures, it is transmitted to each node in the network, using PCRep
> messages.
> Then, the 6TSCH 6TUS adaptation protocol can provide the functionality for
> delivering the traffic in the queues, according to the schedule built with
> TASA+PCEP.
>
> Some Open ISSUES:
>
> R1: Note that this is out of the scope of both RCF5440 and TASA. However,
> we may suppose that such information are provided by the routing protocol,
> RPL, as suggested in RFC5440.
> R2: TASA does not specify how the network is built. In fact, TASA runs
> over a network that has been already built, and that needs a schedule in
> order
> to allow traffic-flow exchanges (i.e., transmissions between each node and
> the PCE). Maybe, 6TUS could fill this gap and provide the functionality
> for the 15.4e TSCH network formation.
>
> Q3: Is there any need to change the PCReq and PCRep messages format, for
> allowing the integration of PCEP with TASA?
> Q5: How would a TASA+PCEP solution work for P2P traffic? That is, data
> flowing from a switch to a light without going through the DAGroot?
> network to the DODAGroot). PCEP support P2P traffic. TASA+PCEP maybe could
> support P2P traffic. This is something to be investigated.
>
>

---

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

Hello Qin,

Based on my preliminary analysis, each node generating traffic  should work as PCC and ask the PCE to build a path, using a PCReq. In the PCReq, it can ask for a given bandwidth (i.e., number of cells), based on the traffic load  that it is going to offer to the network.  According to TSCH, 1 cell per single pkt will be allocated, given that one pkt can be transmitted within a single time slot.

Now, there are still some questions to be addressed. Among these, we have the following  -- we have been discussing about this with Thomas and Pascal--

Q1) If the PCE has received a PCReq for setting a path  from A to B, is there a way for the PCE to contact all the motes (routers) along the multi-hop path between A and B and install cells/links? 

It seems that PCE cannot contact the motes along the multi-hop path between A and B. Thus, in this case, one first possible solution could be to have  the router acting also as PCC and asks some bandwidth based on the traffic that it has to forward.
For sure this isn't the best solution, and it implies waste of energy.  We will need to figure out better how to deal with this.

I don't know if I answer your questions. Please, do not hesitate to come back to me, if I didn't get well your point.

Thank you
Maria Rita

-----Original Message-----
From: Qin Wang [mailto:[email-masked]] 
Sent: Friday, May 03, 2013 9:57 AM
To: Maria Rita PALATTELLA
Cc: [email-masked]; Thomas Watteyne ([email-masked]); Pascal Thubert (pthubert) ([email-masked])
Subject: Re: [6tsch] PCEP for centralized scheduling in 6TSCH architecture

Hi Maria Rita,

From your description about PCEP +TASA in the following, my understanding is that each node, no matter sensor nodes or router, will work as PCC and send PCReq message to PCE. The PCReq will include Bandwidth required besides source and destination address. In another word, a node, including router, has to figure out the bandwidth it needs independently. But, how?
I think the bandwidth needed from a router to another router is the result computed by PCE, instead of the input from each router to the computation in PCE.

Maybe I miss something.

Regards
Qin

> Communication Protocol (PCEP)" in order to check " if" and "how" it 
> could fit in our 6TSCH architecture.
> Scheduling Algorithm) for computing and distributing the schedule from 
> the PCE to the nodes in a 6TSCH architecture that uses a centralized 
> scheduling algorithm.
> I had some preliminary discussion already with Thomas on this topic, 
> but let's discuss all together on the ML. We would like to have your 
> feedback in order to see if we can really use PCEP, and how we can fix 
> some open issues in the 6TSCH context.
> I will use some extracts from the RFC5440, that summarize the behavior 
> of the protocol, and show features that we could exploit.
> This will result in a *very long* email. Sorry for that. And thanks 
> for going through it, and come back to me with your comments, 
> questions, suggestions.
> Maria Rita
>
>>>PCEP is such a protocol designed specifically for communications 
>>>between  a PCC and a PCE [...] a PCC may use PCEP to send a path 
>>>computation  request for one or more TE LSPs to a PCE, and the PCE 
>>>may reply with a  set of computed paths if one or more paths can be 
>>>found that satisfies  the set of constraints.
>>> PCC:  Path Computation Client; any client application requesting a 
>>>path  computation to be performed by a Path Computation Element.
>>> PCE:  Path Computation Element; an entity (component, application, 
>>>or  network node) that is capable of computing a network path or 
>>>route  based on a network graph and applying computational constraints.
>>> Explicit path:  Full explicit path from start to destination; made 
>>>of a  list of strict hops where a hop may be an abstract node such as an AS.
>>> can be gathered by routing protocols or by some other means.  The 
>>> way in which the information is gathered is out of the scope of this 
>>> document (i.e, RFC5440).
> protocol
> (PCEP) to send data from the PCE to the motes, and another for stats 
> and topological and requirement data to go from the motes to the PCE.
>>>  Transport Protocol. PCEP operates over TCP using a registered TCP 
>>> port (4189). This allows the requirements of reliable messaging and 
>>> flow control to be met without further protocol work. All PCEP 
>>> messages MUST be sent using the registered TCP port for the source 
>>> and destination TCP port.
>>> to the PCE (PCReq message) that contains a variety of objects that
> priority=P, ...".  Additionally, the PCC may desire to specify the 
> urgency  of such request by assigning a request priority.
>
> A and B and install cells/links? it looks like the PCE is only used to 
> calculate a multi-hop path on an already existing topology.
> Thus, it seems that PCE cannot contact the motes along the multi-hop 
> path between A and B. BUT... PCEP include some RP in the messages (see 
> below)  >>A Path Computation Reply(PCRep) Message can contain either a 
> set of computed paths if the request can be satisfied, or a negative 
> reply if not.  The negative reply may indicate the reason why no path 
> could be found.
>>>The RP (Request Parameters) object MUST be carried within each PCReq 
>>>and  PCRep messages. The RP object is used to specify various 
> allocate cells/links for each path segment. This is something to be investigated.
>  >>The path computation algorithmic aspects used by the PCE to 
> scope of this
> selecting
> TASA local queue level, or  in other word, traffic load offered by the 
> single node to the network).
> built with
> R1: Note that this is out of the scope of both RCF5440 and TASA. 
> over a network that has been already built, and that needs a schedule 
> in order to allow traffic-flow exchanges (i.e., transmissions between 
> each node and the PCE). Maybe, 6TUS could fill this gap and provide 
> the functionality for the 15.4e TSCH network formation.
>
> Q3: Is there any need to change the PCReq and PCRep messages format,

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 3 May 2013 02:27:34 -0700

Maria Rita,

Thank you for your explanation. I understand that PCEP is a communication
protocol between PCE and PCC. That is why PCE cannot tell the routers
along the path to PCC based on PCEP. Correct? For solving the problem, I
noticed that Thomas has a solution, i.e. the entity of PCEP in each node
along the path will extract the path information from PCRpl and use 6tus
commands to set the reserved cells into TSCH schedule. I think it works.

The remained problem is how PCE knows the bandwidth requirements in each
node. It is reasonable to assume that each node can send packet to PCE via
some sort of initial formation of network. Then,
(1)If a nodeA needs some bandwidth to nodeB, nodeA will work as PCC, send
PCReq to PCE.
(2) PCE select the routers between nodeA and nodeB, e.g. nodeC and nodeD, 
and compute all of the reserved cells for nodeA, nodeB, nodeC and nodeD.
(3) PCE sends PCRpl to nodeA, nodeB, nodeC and nodeD, separately. (a
little bit modification on PCEP).

Thought?
Qin

> Hello Qin,
>
> Based on my preliminary analysis, each node generating traffic  should
> work as PCC and ask the PCE to build a path, using a PCReq. In the PCReq,
> it can ask for a given bandwidth (i.e., number of cells), based on the
> traffic load  that it is going to offer to the network.  According to
> TSCH, 1 cell per single pkt will be allocated, given that one pkt can be
> transmitted within a single time slot.
>
> Now, there are still some questions to be addressed. Among these, we have
> the following  -- we have been discussing about this with Thomas and
> Pascal--
>
> Q1) If the PCE has received a PCReq for setting a path  from A to B, is
> there a way for the PCE to contact all the motes (routers) along the
> multi-hop path between A and B and install cells/links?
>
> It seems that PCE cannot contact the motes along the multi-hop path
> between A and B. Thus, in this case, one first possible solution could be
> to have  the router acting also as PCC and asks some bandwidth based on
> the traffic that it has to forward.
> For sure this isn't the best solution, and it implies waste of energy.  We
> will need to figure out better how to deal with this.
>
> I don't know if I answer your questions. Please, do not hesitate to come
> back to me, if I didn't get well your point.
>
> Thank you
> Maria Rita
>
>
>> computed.
>> PCRep.

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 3 May 2013 10:11:18 +0000

Qin,

Right, I also do agree that Thomas' suggestion can be a possible solution. We may need an interaction between PCEP and 6TUS, in order to reserve the cells to  the nodes (routers) along the multi-hop path between A and B.

Actually, we will need to define some sort of mechanisms for collecting at the PCE all the needed information related to network topology, requested bandwidth, etc. In fact, they are not specified in RF5440.

(1) Each source node  that has some traffic to delivery, will have to send a PCReq to PCE.
(2) PCE will build the schedule, following an algorithm (e.g., TASA, DeTAS, etc.) So, it will reserve some cells for each node.
(3) PCE can send the PCRep only to node A (according to RFC5440). We may need to modify it, as you are suggesting, in order to be able to send it also to node C, and D. Anyway we will  need to find a way for sending this info (maybe, exchanging hop by hop: from node A to node C,  from C to D.)

Maria Rita

-----Original Message-----
From: Qin Wang [mailto:[email-masked]] 
Sent: Friday, May 03, 2013 11:28 AM
To: Maria Rita PALATTELLA
Cc: Qin Wang; [email-masked]; Thomas Watteyne ([email-masked]); Pascal Thubert (pthubert) ([email-masked])
Subject: RE: [6tsch] PCEP for centralized scheduling in 6TSCH architecture

Maria Rita,

Thank you for your explanation. I understand that PCEP is a communication protocol between PCE and PCC. That is why PCE cannot tell the routers along the path to PCC based on PCEP. Correct? For solving the problem, I noticed that Thomas has a solution, i.e. the entity of PCEP in each node along the path will extract the path information from PCRpl and use 6tus commands to set the reserved cells into TSCH schedule. I think it works.

The remained problem is how PCE knows the bandwidth requirements in each node. It is reasonable to assume that each node can send packet to PCE via some sort of initial formation of network. Then, (1)If a nodeA needs some bandwidth to nodeB, nodeA will work as PCC, send PCReq to PCE.
(2) PCE select the routers between nodeA and nodeB, e.g. nodeC and nodeD, and compute all of the reserved cells for nodeA, nodeB, nodeC and nodeD.
(3) PCE sends PCRpl to nodeA, nodeB, nodeC and nodeD, separately. (a little bit modification on PCEP).

Thought?
Qin

> work as PCC and ask the PCE to build a path, using a PCReq. In the 
> PCReq, it can ask for a given bandwidth (i.e., number of cells), based 
> on the traffic load  that it is going to offer to the network.  
> According to TSCH, 1 cell per single pkt will be allocated, given that 
> one pkt can be transmitted within a single time slot.
>
> Now, there are still some questions to be addressed. Among these, we 
> have the following  -- we have been discussing about this with Thomas 
> and
> Pascal--
>
> Q1) If the PCE has received a PCReq for setting a path  from A to B, 
> is there a way for the PCE to contact all the motes (routers) along 
> the multi-hop path between A and B and install cells/links?
>
> between A and B. Thus, in this case, one first possible solution could 
> be to have  the router acting also as PCC and asks some bandwidth 
> based on the traffic that it has to forward.
> For sure this isn't the best solution, and it implies waste of energy.  
> We will need to figure out better how to deal with this.
>
> I don't know if I answer your questions. Please, do not hesitate to 
> come back to me, if I didn't get well your point.
>
> Thank you
> Maria Rita
>
>
> Cc: [email-masked]; Thomas Watteyne ([email-masked]); 
> Pascal Thubert (pthubert) ([email-masked])
> From your description about PCEP +TASA in the following, my 
> understanding is that each node, no matter sensor nodes or router, 
> will work as PCC and send PCReq message to PCE. The PCReq will include 
> Bandwidth required besides source and destination address. In another 
> word, a node, including router, has to figure out the bandwidth it needs independently. But, how?
> I think the bandwidth needed from a router to another router is the 
> result computed by PCE, instead of the input from each router to the 
> computation in PCE.
>
> Maybe I miss something.
>
> Regards
> Qin
>
>> Dear all,
>> Scheduling Algorithm) for computing and distributing the schedule 
>> from the PCE to the nodes in a 6TSCH architecture that uses a 
>> centralized scheduling algorithm.
>> feedback in order to see if we can really use PCEP, and how we can 
>> fix some open issues in the 6TSCH context.
>> I will use some extracts from the RFC5440, that summarize the 
>> behavior of the protocol, and show features that we could exploit.
>>>> to perform the computation of a path for a TE LSP.  Such 
>>>> information can be gathered by routing protocols or by some other 
>>>> means.  The way in which the information is gathered is out of the 
>>>> scope of this document (i.e, RFC5440).
>>>> Once the PCC has selected a PCE, it sends a Path Computation 
>>>> Request to the PCE (PCReq message) that contains a variety of 
>>>> objects that
>> A and B and install cells/links? it looks like the PCE is only used 
>> to calculate a multi-hop path on an already existing topology.
>> below)  >>A Path Computation Reply(PCRep) Message can contain either 
>> a set of computed paths if the request can be satisfied, or a 
>> negative reply if not.  The negative reply may indicate the reason 
>> why no path could be found.
>> R2: TASA does not specify how the network is built. In fact, TASA 
>> this gap and provide the functionality for the 15.4e TSCH network formation.
>>
>> Q5: How would a TASA+PCEP solution work for P2P traffic? That is,

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 3 May 2013 06:31:10 -0700

Maria Rita,

For installing schedule computed by PCE to every nodes along the path from
nodeA to nodeB, one solution may be something like "source routing",
another way may be multicast mentioned in "summary NSIS" branch.

Qin

> Qin,
>
> Right, I also do agree that Thomas' suggestion can be a possible solution.
> We may need an interaction between PCEP and 6TUS, in order to reserve the
> cells to  the nodes (routers) along the multi-hop path between A and B.
>
> Actually, we will need to define some sort of mechanisms for collecting at
> the PCE all the needed information related to network topology, requested
> bandwidth, etc. In fact, they are not specified in RF5440.
>
> (2) PCE will build the schedule, following an algorithm (e.g., TASA,
> DeTAS, etc.) So, it will reserve some cells for each node.
> (3) PCE can send the PCRep only to node A (according to RFC5440). We may
> need to modify it, as you are suggesting, in order to be able to send it
> also to node C, and D. Anyway we will  need to find a way for sending this
> info (maybe, exchanging hop by hop: from node A to node C,  from C to D.)
>
> Maria Rita
>
>
>
>
> Cc: Qin Wang; [email-masked]; Thomas Watteyne
> ([email-masked]); Pascal Thubert (pthubert)
> ([email-masked])
> some sort of initial formation of network. Then, (1)If a nodeA needs some
> bandwidth to nodeB, nodeA will work as PCC, send PCReq to PCE.

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 3 May 2013 07:46:57 -0700

Interesting discussion. If I understand the discussion above, we have two
options for distributing the schedule updated along the track between
source and destination motes:
- send a separate (unsolicited) PCResp to each node. I believe that this
breaks PCEP's current packet flow, so would have to see whether such a use
case is possible.
- send the PCResp only to the PCC requesting the route, and have that node
initiate the multi-hop reservation. This node could then use a PCNtf to
indicate to the PCE that the reservation has been completed.

There are other options, as discussed in the parallel e-mail thread about
RSVP/NSIS. I'm sure we will discuss those over the phone in a couple of
minutes.

Thomas

On Fri, May 3, 2013 at 6:31 AM, Qin Wang <[email-masked]> wrote:

> > (1) Each source node  that has some traffic to delivery, will have to
> send
> > a PCReq to PCE.

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 03 May 2013 07:58:41 -0700

just a short question,

what is the difference between having a node issuing a PCReq to the PCE 
and having a node requesting some amount of bandwidth using a 
Reservation request message from NSIS/RSVP?

In both cases we need a route to the PCE and the answer of the 
reservation request will come back to the issuer which will install the 
links/bw. If NSIS also the nodes in the path might install the bw.

X

Al 03/05/13 07:46, En/na Thomas Watteyne ha escrit:
> Interesting discussion. If I understand the discussion above, we have 
> two options for distributing the schedule updated along the track 
> between source and destination motes:
> - send a separate (unsolicited) PCResp to each node. I believe that 
> this breaks PCEP's current packet flow, so would have to see whether 
> such a use case is possible.
> - send the PCResp only to the PCC requesting the route, and have that 
> node initiate the multi-hop reservation. This node could then use a 
> PCNtf to indicate to the PCE that the reservation has been completed.
>
> There are other options, as discussed in the parallel e-mail thread 
> about RSVP/NSIS. I'm sure we will discuss those over the phone in a 
> couple of minutes.
>
> Thomas
>
>
> On Fri, May 3, 2013 at 6:31 AM, Qin Wang <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Maria Rita,
>
>     > (1) Each source node  that has some traffic to delivery, will
>     have to send
>     > a PCReq to PCE.
>     > From: Qin Wang [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     > Cc: Qin Wang; [email-masked] <mailto:[email-masked]>; Thomas
>     Watteyne
>     > ([email-masked]
>     <mailto:[email-masked]>); Pascal Thubert (pthubert)
>     > ([email-masked] <mailto:[email-masked]>)
>     >> From: Qin Wang [mailto:[email-masked]
>     <mailto:[email-masked]>]
>     >> Cc: [email-masked] <mailto:[email-masked]>; Thomas Watteyne
>     ([email-masked] <mailto:[email-masked]>);
>     >> Pascal Thubert (pthubert) ([email-masked]
>     <mailto:[email-masked]>)
>     >> word, a node, including router, has to figure out the bandwidth
>     it needs
>     >> independently. But, how?
>     >>>>>of a  list of strict hops where a hop may be an abstract node
>     such
>     >>>>>as  an AS.
>     >>>  [MR] The explicit path could be seen as a 6TSCH track,
>     composed by
>     >>> hard cells.
>     >>>
>     >>> interference-free conflict links, according to local and
>     global queue
>     >>> level).
>     >>> [Thomas] I believe the "minimal" use case identified in the
>     charter
>     >>> covers this.
>     >>>
>     >>> [Thomas] The entity in the motes which received PCRep message
>     simply
>     >>> send commands over the 6tus interface.
>     >>>
>     >>> [email-masked] <mailto:[email-masked]>

---

From: "Qin Wang" <[email-masked]>
Date: Sat, 4 May 2013 19:01:54 -0700

Xavi,

I have just read some document on NSIS, only have very basic understanding
as foolws.

Considering our requirement on installing tracks into nodes, I think that
GIST (General Internet Signaling Transport) of NSIS may be a candidate.
But, there is still a problem, i.e. the signaling nodes along a path are
discovered by peer of nodes distributed in GIST, while in the PCE-based
case, the nodes along a path are computed by PCE. In another word, likely,
it is necessary to couple the path implied by a Track with a signaling
path. But, how?

Qin

>>     >>> path between A and B. BUT... PCEP include some RP in the
>> messages
>>     >>> (see

---

From: Xavier Vilajosana <[email-masked]>
Date: Sat, 04 May 2013 19:16:42 -0700

Hi Qin,

GIST is the lower layer of NSIS and it provides the transport 
functionalities as you say. As regards to the track discovery can be 
done in two ways (as far as I understand):

  1-A routing protocol exists, then NSIS/GIST can make use the route 
between the to edges of the track
  2-If a routing protocol does not exist or there is no defined route 
from the two edge nodes of the track, NSIS can discover the path by hop 
by hop neighbour discovery.

Note that, NSIS messages carry a MRI (Message Route Information Object) 
that according to RFC5971 section 5.1
http://tools.ietf.org/html/rfc5971#section-5.1

Message-Routing-Information (MRI):  Information sufficient to define how 
the signalling message should be routed through the network.

IMHO, this MRI object can be used by the PCE to indicate the list of 
nodes (or whatever information that can be used to determine the next 
hop) in the Track as routing state is not installed yet in the network.

Note that this is my opinion and guess, this is maybe an aspect that 
needs further investigation and discussion.

cheers!
Xavi