Subject: [6tisch] addressing ticket 3

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 13 Feb 2014 17:00:54 +0000

Dear all;

As a reminder ticket 3 http://tools.ietf.org/wg/6tisch/trac/ticket/3 is this:
Describe the basic operation between 6top and other parties for dynamic update of cells in a bundle.

*       Devices can live without on the fly at all (that's the chartered item)

*       This leads to a degree of suboptimality depending on how well the schedule is computed

*       6top can negotiate addition of removal of cells in a bundle based on management request. Eg PCE, NME, OTF layer
To complete the existing text and introduce OTF I suggest the following additions to the architecture draft:

8.1. Minimal Static Scheduling

In the simplest incarnation of a 6TiSCH network, a common fixed
schedule may be shared by all nodes in the network and nodes will
contend for slot access in a slotted aloha manner. A static TSCH
schedule can be used to bootstrap a network, as a initial phase
during implementation, or as a fall-back mechanism in case of network
malfunction. This scheduled can be preconfigured, or learnt by a
node when joining the network, but it remains unchanged after the
node has joined a network. The Routing Protocol for LLNs (RPL) is
used on the resulting network. This "minimal" scheduling mechanism
that implements this paradigm is detailed in [I-D.vilajosana-6tisch-
minimal].

8.2. neighbor-to-neighbor Scheduling

In the simplest incarnation of a 6TiSCH network described in Section
8.1, nodes may expect a packet at any cell in the schedule and will
waste energy listening just in case. In a more complex incarnation
of a 6TiSCH network, a matching portion of schedule is established
between peers to reflect the observed amount of transmissions between
those nodes. The aggregation of the cells between a node and a peer
form a bundle that the 6top layer uses to implement the abstraction
of a link for IPv6. The bandwidth on that link is proportional to the
number of cells in the bundle.

If the size of a bundle is configured to fit an average amount of
bandwidth, peak emissions will be destroyed. If the size is
configured to allow for peak emissions, then energy will be wasted in
idle listening.

In the most efficient incarnation of a 6TiSCH network, the size of
the bundles that implement the links may be changed dynamically in
order to adapt to the need of end-to-end flows routed by RPL.
An optional on-the-fly component may be used to monitor the
usage of bandwidth and perform requests for dynamic allocation by the
6top sublayer.

The 6top sublayer [I-D.wang-6tisch-6top] defines a protocol for
neighbor nodes to reserve soft cells to one another. Because this
reservation is done without global knowledge of the schedule of nodes
in the LLN, scheduling collisions are possible. 6top defines a
monitoring process which continuously tracks the packet delivery
ratio of soft cells. It uses these statistics to trigger the
relocation of a soft cell in the schedule, using a negotiation
protocol between the neighbors nodes communicating over that cell.
Monitoring and relocation is done in the 6top layer. For the upper
layer, the connection between two neighbor node appears as an number
of cells. Depending on the traffic requirements, the upper layer can
request 6top to add or delete a number of cells scheduled to a
particular neighbor, without being responsible for choosing the exact
slotOffset/channelOffset of those cells.

Pascal

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 13 Feb 2014 15:30:38 -0200

Pascal,
          What I can see from the text is that OTF coexists with
other schedule management modules, such as PCE or NME,
but there would be no OTF-only implementation (full distributed
approach). Am I right?
           Thanks,

                               Diego

2014-02-13 14:00 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> ·       Devices can live without on the fly at all (that's the chartered
> item)
>
> ·       This leads to a degree of suboptimality depending on how well the
> schedule is computed
>
> ·       6top can negotiate addition of removal of cells in a bundle based
> on management request. Eg PCE, NME, OTF layer
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 14 Feb 2014 07:58:31 +0000

Hi Pascal,
Thanks for putting together this additional text, introducing OTF.
Just few minor changes:

-        what about ".. simplest CONFIGURATION of a 6TiSCH network...", instead of " .. INCARNATION of a 6TiSCH network..."?

-        " The aggregation of the cells between a node and a peer, **ALONG a TRACK** form a bundle that the 6top layer uses to implement the abstraction of a link for IPv6."
That's all. Thanks
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, February 13, 2014 6:01 PM
To: [email-masked]
Subject: [6tisch] addressing ticket 3

Dear all;

Pascal

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 14 Feb 2014 08:12:45 +0000

Diego, in my understanding OTF will provide a support for improving the initial schedule (that can be the minimal one, or the one built by a PCE, etc.) for fulfilling the new bandwidth requests that single nodes may have.
By using the OTF distributed approach, the response to the new bandwidth need will be faster, than the one that can be achieved by using a centralized approach.
Do you agree?
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: Thursday, February 13, 2014 6:31 PM
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [6tisch] addressing ticket 3

Pascal,

2014-02-13 14:00 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Dear all;

Pascal

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

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Feb 2014 08:52:54 +0000

I agree with you, Maria Rita.

OTF is an optional abstract component that completes the base LLC operation (6top).
We can conceive that in the future there are other complements to 6top, or that there are different variations of OTF.
As Maria Rita points out, distributed OTF allows for a faster reaction but with probably less historical perspective for lack of resources.

Cheers,

Pascal

From: Maria Rita PALATTELLA [mailto:[email-masked]]
Sent: vendredi 14 février 2014 09:13
To: Prof. Diego Dujovne; Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: RE: [6tisch] addressing ticket 3

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

Pascal,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Feb 2014 08:55:09 +0000

Hello Diego:

I think this is orthogonal. The deployments I have in mind will certainly have an NME in any case.
But for a home / unmanaged deployment, we could still see a need for OTF.
Should I change text in Archie?

Cheers,

Pascal

From: Prof. Diego Dujovne [mailto:[email-masked]]
Sent: jeudi 13 février 2014 18:31
To: Pascal Thubert (pthubert)
Cc: [email-masked]
Subject: Re: [6tisch] addressing ticket 3

Pascal,

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Feb 2014 09:03:34 +0000

Hello Maria Rita

-        what about ".. simplest CONFIGURATION of a 6TiSCH network...", instead of " .. INCARNATION of a 6TiSCH network..."?
[PT] or " instantiation" ?

[PT] Hum, no. This text is about an IP link between 2 adjacent nodes with direct connectivity. Actually we have not really discussed if we could extend the term bundle to refer to multiple cells that are used in parallel over a same hop to increase the bandwidth of a track. What do you think?

Thanks a bunch for your review!

Pascal
From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, February 13, 2014 6:01 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [6tisch] addressing ticket 3

Dear all;

Pascal

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 14 Feb 2014 09:21:18 +0000

Pascal, please find inline my answers.
Maria Rita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Friday, February 14, 2014 10:04 AM
To: Maria Rita PALATTELLA; [email-masked]
Subject: RE: addressing ticket 3

Hello Maria Rita

-        what about ".. simplest CONFIGURATION of a 6TiSCH network...", instead of " .. INCARNATION of a 6TiSCH network..."?
[PT] or " instantiation" ?
MR Yes, I am fine with instantiation

[PT] Hum, no. This text is about an IP link between 2 adjacent nodes with direct connectivity. Actually we have not really discussed if we could extend the term bundle to refer to multiple cells that are used in parallel over a same hop to increase the bandwidth of a track. What do you think?
[MR] uhmmm... I am a bit confused ( sorry) because based on some discussion that I had with Qin in the last days   (you were in CC), a Track (and thus, a TrackID) is always assigned to a bundle. The group of cells between two adjacent nodes form a bundle, on a track. I mean, several group of cells may be reserved between two nodes, but on different tracks, and thus, there will be different bundles...
Is it correct?

My pleasure :)

Pascal

Dear all;

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 14 Feb 2014 10:42:58 +0000

I see, Maria-Rita;

My memory is that we initially defined bundles to support the concept link, as opposed to track. Extending to track is fine with me, meaning that we'll switch from any cell in bundle A into any cell in bundle B along a track; still, the subject matter of the particular section in the archie is the IP link as opposed to the G-MLPS track.

Cheers,

Pascal

From: Maria Rita PALATTELLA [mailto:[email-masked]]
Sent: vendredi 14 février 2014 10:21
To: Pascal Thubert (pthubert); [email-masked]
Subject: RE: addressing ticket 3

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Friday, February 14, 2014 10:04 AM
To: Maria Rita PALATTELLA; [email-masked]<mailto:[email-masked]>
Subject: RE: addressing ticket 3

Hello Maria Rita

Pascal

Dear all;

·       Devices can live without on the fly at all (that's the chartered item)

·       This leads to a degree of suboptimality depending on how well the schedule is computed

·       6top can negotiate addition of removal of cells in a bundle based on management request. Eg PCE, NME, OTF layer
To complete the existing text and introduce OTF I suggest the following additions to the architecture draft:

Pascal

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 14 Feb 2014 13:16:55 -0200

Pascal,
          From that point of view, I do agree. Nevertheless, I was thinking
in (far) future deployments were relocation (as we discussed some months
ago) or even mobility can be taken into account.
          You can keep the same text on the archie.
          Thank you,

                                    Diego

2014-02-14 5:55 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> *From:* Prof. Diego Dujovne [mailto:[email-masked]]
> *Sent:* jeudi 13 février 2014 18:31
>
> *To:* Pascal Thubert (pthubert)
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] addressing ticket 3
>
>
>
> Pascal,
>