Subject: [6tsch] summary NSIS

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 08 Apr 2013 10:03:54 -0700

Hi all,

as said last Friday I want to share with you a brief summary on how NSIS 
can be used to transport and maintain QoS along a track. An open issue 
is how PCE can make use of NSIS to install scheduling configuration.

Note that maybe it is not possible to use NSIS for PCE centralized 
scheduling but as said we are exploring some alternatives.

Any suggestion, idea or proposal is welcome.

kind regards,
Xavi

---

From: "Bless, Roland (TM)" <[email-masked]>
Date: Wed, 10 Apr 2013 17:14:55 +0200

Hi,

> scheduling but as said we are exploring some alternatives.

Please note that it is possible to use NSIS also for path-decoupled
signaling, e.g., if you have a PCE signaling to some device.

> GIST also provides peer discovery mechanism in case no routing state
>  is known in the network. As we assume RPL we don't consider the use
>  of QUERY messages from GIST to discover neighbor peers. However, 
> QUERY messages can also be used to discover if a certain QoS is 
> supported by other neighbors (i.e exploring for resources).

IMHO this is not fully correct or confuses different aspects:
"in case no routing state is known in the network" is only correct
if you are referring to GIST's signaling routing state. In that case
the first message is a (GIST) QUERY message that is usually sent
towards the data flow's destination and intercepted by the next
relevant GIST peer that wants to process the signaling message.
If the latter is willing to establish a signaling session it
continues a three-way handshake.
So this probing QUERY is a means to find/discover the next signaling
peer along a (given) network route.
I don't know RPL very well, but you cannot omit the GIST QUERY
message, just because you assume RPL for route establishment.
Sending the QUERY will simply follow a route that is established by
RPL.

The other type of mentioned QUERY message is at QoS NSLP layer
(no to be confused with the GIST/NTLP layer) and it is optional,
whereas the GIST QUERY message is always required for establishing
the NTLP/GIST signaling session.

> Note that the baseline message routing functionality in GIST is that 
> signaling messages follow a route defined by an existing flow in the 
> network (i.e RPL),  visiting a subset of the nodes through which it 
> passes.  This is the  appropriate behavior for application scenarios 
> where the purpose of the signaling is to manipulate resources for 
> that flow as is our case.

To be more precise: GIST finds/discovers all relevant nodes along a
flow's data path in order to allocate/manipulate resources for
that data flow. However, path-coupled signaling is only one possible
(signaling) message routing method. As I said, it's possible to
implement others (we implemented a so called explicit signaling target
MRM). We also added multicast support to GIST and QoS NSLP.

> With that in mind, I will welcome any idea or suggestion on whether
> it is possible or not to extend QSPEC messages [RFC5975] so a PCE
> oriented message can be transported using the NSIS QoS
> specification.

It should be no problem to define additional QoS parameters
within the QSPEC template if needed (cf. sec 4.4 of RFC5975).
It is also easy to add additional QoS NSLP objects if the QSPEC
template isn't a good match...,e.g., we augmented a QoS NSLP
message with addressing information in order to set up
virtual links.

Regards,
 Roland

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 10 Apr 2013 15:48:23 +0000

Hello Roland:

Thanks a bunch for this.

Please note that the first comment we got when we introduced NSIS in the discussion is that it is a rather large piece of code to be included in memory and CPU constrained devices.
Would you have any comment on that ?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bless, Roland (TM)
Sent: mercredi 10 avril 2013 17:15
To: Xavier Vilajosana
Cc: [email-masked]
Subject: Re: [6tsch] summary NSIS

Hi,

> scheduling but as said we are exploring some alternatives.

Please note that it is possible to use NSIS also for path-decoupled signaling, e.g., if you have a PCE signaling to some device.

> of QUERY messages from GIST to discover neighbor peers. However, QUERY 
> messages can also be used to discover if a certain QoS is supported by 
> other neighbors (i.e exploring for resources).

IMHO this is not fully correct or confuses different aspects:
"in case no routing state is known in the network" is only correct if you are referring to GIST's signaling routing state. In that case the first message is a (GIST) QUERY message that is usually sent towards the data flow's destination and intercepted by the next relevant GIST peer that wants to process the signaling message.
If the latter is willing to establish a signaling session it continues a three-way handshake.
So this probing QUERY is a means to find/discover the next signaling peer along a (given) network route.
I don't know RPL very well, but you cannot omit the GIST QUERY message, just because you assume RPL for route establishment.
Sending the QUERY will simply follow a route that is established by RPL.

The other type of mentioned QUERY message is at QoS NSLP layer (no to be confused with the GIST/NTLP layer) and it is optional, whereas the GIST QUERY message is always required for establishing the NTLP/GIST signaling session.

> where the purpose of the signaling is to manipulate resources for that 
> flow as is our case.

To be more precise: GIST finds/discovers all relevant nodes along a flow's data path in order to allocate/manipulate resources for that data flow. However, path-coupled signaling is only one possible
(signaling) message routing method. As I said, it's possible to implement others (we implemented a so called explicit signaling target MRM). We also added multicast support to GIST and QoS NSLP.

> With that in mind, I will welcome any idea or suggestion on whether it 
> is possible or not to extend QSPEC messages [RFC5975] so a PCE 
> oriented message can be transported using the NSIS QoS specification.

It should be no problem to define additional QoS parameters within the QSPEC template if needed (cf. sec 4.4 of RFC5975).
It is also easy to add additional QoS NSLP objects if the QSPEC template isn't a good match...,e.g., we augmented a QoS NSLP message with addressing information in order to set up virtual links.

Regards,
 Roland

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

---

From: Roland Bless <[email-masked]>
Date: Wed, 10 Apr 2013 22:15:27 +0200

Hi,

> Would you have any comment on that ?

Sure, as an implementer we have some rough idea about the complexity.
In our C++ Linux-based implementation (http://nsis-ka.org/) we
have roughly 32,000 sloc for GIST and 18,000+4,000 sloc for QoS NSLP
+QSPEC resulting in several MBytes of executable. So NSIS has maybe some
functionality (e.g., mobility support) and extensibility that is not
strictly required in your particular scenario. However, we never
had a focus on a lightweight implementation rather than a nearly
complete and easy to test prototype.

Regards,
 Roland

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 12 Apr 2013 08:11:50 -0700

Hi Roland,
you said that NSIS will be suitable to support PCE management networks. 
Can you explain how NSIS will work in the following scenario:

" A PCE computes the schedule for a set of devices in a TSCH network, 
which includes information such as a collection of tuples 
<time_slot,ch_offset,destination_address,link_type> for each node in the 
set. The PCE needs to install that information in the schedule of each 
node meaning that each node has to receive that information."

 From your emails I have the intuition that:
1) QSPEC messages can be extended to carry that information.
2) NSIS QoS on GIST can be used to send the message along the route so 
each of the nodes in the set receive the configuration

However I don't see very clear how GIST will build the "path" to each of 
this nodes. Will it use a reverse-reservation (initiated from the receiver?)

Can you illustrate that scenario please?

X