Subject: [6tsch] Dynamic Channel Allocation

From: Pascal Thubert <[email-masked]>
Date: Fri, 1 Feb 2013 08:15:04 +0100

Hi:

When talking of radio links, there is sort of chicken and an egg problem
between routing and peering selection / link bandwidth allocation.

If we do not set up a adjacency with a neighbor, then routing cannot use
that neighbor in the route computation and we will never know how much
traffic would pass between hte 2 in an optimal world.OTOH, we cannot
physically allocate stuff at the link level for all possible peers either.

One way of running around that problem is to  virtualize the links so that
the router thinks there is bandwidth, even though potentially no slot is
physically allocated. And then, we need to be able to allocate more and
more slots to a particular neighbor as the routing drives more and more
traffic through that peering.

RPL makes life a lot easier, because it enables a selection of
parent/children that limits the number of initial peering, and thus of
slots to be allocated. Still, I can see the need of a virtualization of the
available bandwidth for consumption by the routing piece, and a Dynamic
Channel Allocation mechanism triggered the forwarding piece - or some
reservation mechanism should we put something like that in place for a few
particular flows.

As the size of the network grows, and the number of usages grow beyond
critical command and control, link utilization becomes statistical, and an
exagerated use of (centrally controlled) reservation depletes the available
resources much faster than they are actually used. Link utilization is
better observed and managed by the local device in a reactive fashion. This
is another argument along the lines that Mischa, Robert and Thomas
discussed earlier that we want a distributed mechanism for the bulk of the
operations.

The shim layer that was already discussed has a lot of value to enable that
virtualization and dynamic allocation. On principle I'm all for it. I'm
just unclear how much of it is above IP (like we placed ND above IP as
opposed to ARP) and how mush is under IP, the the 15.4 IEs. Could there be
an IP abstraction that we could reuse in other similar link layers?

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 31 Jan 2013 23:53:48 -0800

Pascal,
A couple of thoughts inline.
Thomas

> traffic through that peering.

The chicken and egg problem is indeed a real complexity: how to manage the
feedback loop between changing the schedule and changing the routes. To
borrow some ideas from Kris, 15.4e includes the notion of shared (i.e.
slotted Aloha) slots: the network could bootstrap with only a couple of
shared slots, offering the possibility for a mote to communicate with any
of its neighbors. This base enables some control traffic to be exchanged to
set up dedicated slots.

The simplest possible case could be to run on shared slots only. This is
what we did about a year of so ago during an IPSO interop event.

> The shim layer that was already discussed has a lot of value to enable
> that virtualization and dynamic allocation. On principle I'm all for it.
> I'm just unclear how much of it is above IP (like we placed ND above IP as
Could we borrow some ideas from traditional Internet resource management
systems? In the end, 15.4e does give us a very straightforward unit of
bandwidth (slots) and a stable topology (thanks to channel hopping).

The shim layer could sit right on top of 15.4e, and receive request to
add/remove links. The "brains" that give the orders could be many things:
some traffic observation unit inside the mote, a centralized scheduling
engine (à la TASA), or some distributed resource reservation mechanism such
as RSVP.

The interface to the shim layer could be keps extremely simple:
- "add/remove this particular slot". This could be used by some omniscient
central scheduler which builds a highly optimized schedule, or
- "always maintain 3 slots per second to this neighbor". This could be used
by some more distributed scheduling entity (e.g. RSVP?). It's then the shim
layer's responsibility to put in the slots needed to meet that requirement.

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