Subject: [6tsch] Scope: 6LoWPAN + 1

From: Carsten Bormann <[email-masked]>
Date: Wed, 13 Mar 2013 12:31:49 -0400

So, my take of the discussion we just had:

-- This is focused on the 6LoWPAN and the TSCH configuration within that
-- Packets will also need to make one IP hop outside the 6LoWPAN, let's call that the backbone
-- The backbone could be 802.1TSN style (~ Ethernet)
-- Setting the DSCP to ~ EF, doing the admission control for that, and possibly some 802.1TSN setup, is mostly all that we need in the backbone

That would simplify things by taking RSVP out of the picture and taking more of a diffserv approach.

Grüße, Carsten

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 13 Mar 2013 18:01:06 -0400

Carsten,

Thank you for the summary. I believe your statements are accurate: the only
thing 6TSCH is interested about is how to make the 6LoWPAN LLN work when
using IEEE802.15.4e at the MAC layer, using nothing but IEEE and IETF
standards.

The architecture we are targetting is shown in [1], i.e.:
- one or more LLNs, each connected to a backbone router (BBR)
- BBRs are connected through a backbone
- optionally a PCE sits on the backbone and drives the LLNs' TSCH schedules.
- when a packet goes from one LLN to another over the backbone, ideally, we
want the deterministic nature of the transmission to remain on the
backbone. So if there is some easy mapping between deterministic TSCH flows
and deterministic "backbone" flows (e.g. IEEE802.1TSN), that would be great.
- I agree that the obvious choice is to map DSCPs into TSCH flow priorities.

As for the term "RSVP", it might be a big word for our little group :) What
we are talking about it to use some distributed multi-hop resource
reservation protocol within the TSCH LLN to reserve TSCH cells.

I hope this makes sense,
Thomas

[1] http://tools.ietf.org/html/draft-thubert-6tsch-architecture-00#page-5

On Wed, Mar 13, 2013 at 12:31 PM, Carsten Bormann <[email-masked]> wrote:

> -- Setting the DSCP to ~ EF, doing the admission control for that, and
> possibly some 802.1TSN setup, is mostly all that we need in the backbone
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 14 Mar 2013 20:31:42 +0900

Hi,

I am trying to understand the architecture accurately.  Let me ask one thing.

> - optionally a PCE sits on the backbone and drives the LLNs' TSCH schedules.

If a PCE is option, who coordinates the LLNs' TSCH ? Is it by BBRs ?
Do you assume that each BBR negotiates something TSCH parameters with other in order to make a logical PCE on the BBRs ?

I guess a PCE is option only when a single LLN that doesn't need to exchange packets with other LLNs and the BBR has a function of PCE.  Correct ?

Shoichi

On 3/14/13 7:01 AM, Thomas Watteyne wrote:
> Carsten,
>
> Thank you for the summary. I believe your statements are accurate: the only thing 6TSCH is interested about is how to make the 6LoWPAN LLN work when using IEEE802.15.4e at the MAC layer, using nothing but IEEE and IETF standards.
>
> - when a packet goes from one LLN to another over the backbone, ideally, we want the deterministic nature of the transmission to remain on the backbone. So if there is some easy mapping between deterministic TSCH flows and deterministic "backbone" flows (e.g. IEEE802.1TSN), that would be great.
> As for the term "RSVP", it might be a big word for our little group :) What we are talking about it to use some distributed multi-hop resource reservation protocol within the TSCH LLN to reserve TSCH cells.
>
> I hope this makes sense,
> Thomas
>
>
> On Wed, Mar 13, 2013 at 12:31 PM, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Paul Chilton <[email-masked]>
Date: Thu, 14 Mar 2013 12:02:08 +0000

Following on from this question: 
Just to clarify - is the sense of the sentence that "there may or may not be a PCE in the system" or that "the PCE must be present but can be placed on the backbone or elsewhere"?

Am I correct in thinking that if there isn't a PCE in the system then there will be no hard links allocated, and that all the links will be soft links, and the slot allocation will be performed by a decentralised scheme with the routing layer requesting bandwidth over a route between endpoints?

How will multicast traffic work without a PCE?  I am assuming that the system needs to allocate slots for the use of multicast groups within the lln - is that correct?  If that is the case, then is it intended that the routing layer can allocate multicast slots as well as dedicated soft links for DAG and p2p routes

Apologies if the terminology doesn't match whats in the terminology draft - still thinking in 4e-land

Paul

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shoichi Sakane
Sent: 14 March 2013 07:32
To: IETF 6TSCH
Subject: Re: [6tsch] Scope: 6LoWPAN + 1

Hi,

Shoichi

---

From: Shoichi Sakane <[email-masked]>
Date: Thu, 14 Mar 2013 21:39:17 +0900

>>- optionally a PCE sits on the backbone and drives the LLNs' TSCH schedules.

Ah, maybe understood.  It doesn't say that existence of PCE is optional.  It says that it's optional to put PCE in the backbone.  It doesn't preclude to put it on BBR.  Correct ?

Shoichi

---

From: "Qin Wang" <[email-masked]>
Date: Thu, 14 Mar 2013 09:27:42 -0700

Hi Shoichi and all,

My understanding is as follows.

(1) The networks which we are talking about could include one LLN or
multiple LLNs connected by backbone. PCE is a optional device in the
networks.

(2) If there is PCE, there may be different setting. For example, PCE is
in charge for reserving both multiple hop path (i.e. every next hop
neighbor) and cells; or PCE is just in charge for reserving the multiple
hop path and leaving cell reservation to local, and the distributed cell
reservation will meet the bandwidth requirement from multiple hop path
reservation. In the first case, hard cell reservation will be used.

(3)If there is no PCE, both multihop path and cells are reserved in local.
For example, RPL + soft cell reservation in 6tus.

Does it make sense?

Qin

> Ah, maybe understood.  It doesn't say that existence of PCE is optional.
> It says that it's optional to put PCE in the backbone.  It doesn't
> preclude to put it on BBR.  Correct ?
>
> Shoichi

---

From: Shoichi Sakane <[email-masked]>
Date: Fri, 15 Mar 2013 05:46:53 +0900

Hi Qin,

Very clear.  Thanks!

Shoichi

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 14 Mar 2013 22:55:34 -0700

Shoichi, Paul,

I agree with Qin's description. I believe we should not close any doors,
and allow for different setups:
- one "standalone" LLN, or multiple LLNs connected over a backbone
- TSCH schedule built by a PCE, or in a distributed way, or a hybrid
approach.

Paul, in my mind a PCE reserves hard cells, and a distributed protocol soft
cells. The distinction is simply related to collisions: if you are certain
that the network schedule is collision-free (which we might assume from a
PCE), then schedule hard cells. If collisions are possible (e.g. between
two independent pairs of nodes), then schedule soft cells, since you need
6tus to monitor them and move one if needed. Of course, one could imagine a
hybrid approach, in which both hard and soft cells are present in the
network.

John has started to investigate protocols such as RSVP or NSIS to reserve
cells along a multi-hop path (a track) inside the LLN. In a setup where
only this protocol is used for scheduling, the PCE would not be present.

I hope this answers your question.

Thomas

On Thu, Mar 14, 2013 at 1:46 PM, Shoichi Sakane <[email-masked]> wrote:

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

---

From: "Qin Wang" <[email-masked]>
Date: Fri, 15 Mar 2013 10:42:37 -0700

Thomas,

I'm not very clear about the relationship between RSVP/NSIS and PCE. My
understanding is RSVP/NSIS is used to reserve resource along a multihop
path, basically by translating the feature of data flow and Qos
requirement into communication resource reservation. They could be
centralized or distributed, i.e. with or without PCE. Correct?

Qin

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 15 Mar 2013 11:58:23 -0700

Hi Qin,
let me add something meanwhile :-)

your point is correct. RSVP/NSIS are used to setup and maintain 
multi-hop paths (tracks in our terminology) according to certain QoS 
requirements. If we think on MPLS/GMPLS, they use a Label Distribution 
Protocol to setup the label that define a path (or mapping between input 
cells an output cells in a particular node in the case of GMPLS), a 
Label Distribution protocol within the MPLS architecture is a generic 
concept that has different implementations, one of them is CR-LDP 
another is RSVP-TE that provides the semantics to carry QoS requirements 
and install labels along the path. For sure that NSIS has been thought 
on that direction although I am not so familiar with it.

What RSVP-TE/NSIS carry in the payload can be used to schedule the links 
along the track so they meet the required bandwidth, this information 
can be defined by a PCE and installed downstream by the RSVP-TE/NSIS 
protocol using the 6tus hardlink interface and some RSVP-TE object that 
can transport the information.

However, if the network does not use a PCE but a distributed approach 
(6tus soft-link approach), nothing prevents to RSVP to carry the actual 
bandwidth requirement and let 6tus install it at each hop along the 
track. So it seems very adequate to use any of these protocols to 
configure 6tus along a multi-hop path.

does this make sense to you?
X

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 16 Mar 2013 11:22:16 +0000

Hi Carsten:

As you figure, this looks like a yes for all your bullets but a no for RSVP. We need a reservation protocol inside the DODAG, that's for sure.
We might even end up reserving between one DODAG and another across the backbone, let's see what the charter discussion says about that.

In that case, the deterministic backbone would have to interpret the RSVP/PCEP extensions into an IEEE flow reservation across the switch fabric.
This is where we're interested in following what IEEE TSN does and how it is done it from a reasonably safe distance.
The assumption is that they are operating on a time scale that is 2+ orders of magnitude more precise than ours. 
This assumptions makes the backbone step negligible in terms of jitter and latency as a first approximation.

Cheers,

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: mercredi 13 mars 2013 12:32
To: IETF 6TSCH
Subject: [6tsch] Scope: 6LoWPAN + 1

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 17 Mar 2013 02:25:30 +0100

> This assumptions makes the backbone step negligible in terms of jitter and latency as a first approximation.

Indeed.  As long as there is some minimum amount of admission control, setting an 802.1Q priority is likely to be sufficient on the Ethernet side of things (which is likely 400..4000 times as fast as the 6LoWPANs and never has MAC delays).  Practically speaking, that can be done from a DSCP.

Grüße, Carsten

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 18 Mar 2013 09:06:43 +0000

Hi Qin, and all,
Sorry for coming back to this discussion after some time, but I wanted to raise and clarify a point.

Qin>>>(2) If there is PCE, there may be different setting. For example, PCE is in charge for reserving both multiple hop path (i.e. every next hop
Qin>>>neighbor) and cells; or PCE is just in charge for reserving the multiple hop path and leaving cell reservation to local, and the distributed cell reservation will meet the bandwidth requirement from multiple hop path reservation. In the first case, hard Qin>>> cell  reservation will be used.

Qin >>>(3)If there is no PCE, both multi-hop path and cells are reserved in local.
Qin>>For example, RPL + soft cell reservation in 6tus.

>From my point of view (and thinking about TASA implementation), the PCE shouldn't be in charge for reserving the multiple hop path. But the routing protocol (i.e., RPL in our case) should take care of the next hop neighbor selection.
When a centralized approach is adopted, the PCE will schedule the cells  (i.e., hard cells according to 6tus terminology). 
While, when a distributed solution is used, 6tus will allocate the soft cells.

In the centralized scenario with the PCE, to avoid the exchange of many signaling messages, for setting up the schedule, we may think (as Pascal was suggesting during one of the last call) to use some hybrid solutions.
In other words, if PCE allocates (timeoffset1, channeloffset3, slotframe1, TX) to node A for transmitting to node B, then, node B could know locally from node A, (and not from the PCE), that the cell (timeoffset1, channeloffset3, slotframe1, RX) has been reserved to it, for receiving from node A.
We may try to include some functionality in 6tus layer in order to manage such situation.
What do you think?

Maria Rita

----------------------------------------------------------------------------------------------------------------