Subject: Re: [6tsch] Dynamic Channel Allocation
From: Thomas Watteyne <[email-masked]>
To: IETF 6TSCH <[email-masked]>
Date: Thu, 31 Jan 2013 23:53:48 -0800
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>

Pascal,
A couple of thoughts inline.
Thomas

On Thu, Jan 31, 2013 at 11:15 PM, Pascal Thubert
<[email-masked]>wrote:

> 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.
>

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.

> 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?
>
>
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
>
>