Subject: Re: [6tisch] addressing ticket 3

From: Tom Phinney <[email-masked]>
Date: Thu, 13 Feb 2014 09:12:49 -0800

peak emissions
will be destroyed.

This should be "momentary traffic peaks will result in extra delay
or discard."

On 2014.02.13 09:00, Pascal Thubert
(pthubert) wrote:

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

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