[Tinyos-devel] Runtime grouping proposal for TinyOS 1.2 - please comment

Cory Sharp cory.sharp at gmail.com
Tue Feb 8 11:34:08 PST 2005

I've been wanting a routing layer that encodes forwarding information
that describes the protocol and destination that the receiving node
should use to forward a packet.  That's the solution I came to when
trying to juggle the practical use of half a dozen routing protocols
in the NEST Challenge API.  It allows a base station node (or any
node) to essentially perform this (re)grouping behavior on a
per-packet basis -- which is exactly the problem Gil is trying to
solve here.

For instance, in special circumstance, maybe I *do* want Deluge or
Mate to use the "broadcast group", and with forwarding information
built into the routing middleware layer.  The apps layer doesn't have
to tie to specific grouping/routing protocols.  It extends nicely to
regionalized geographic routing and constrained broadcasts.

It's perhaps too complicated for right now, and maybe  that's what you
guys are discussing in the sensor network architecture group, but
that's the pie in the sky of what I suspect would be powerful.


On Tue, 08 Feb 2005 11:31:08 -0800, Philip Levis <pal at eecs.berkeley.edu> wrote:
> On Feb 8, 2005, at 10:23 AM, Gilman Tolle wrote:
> >
> > To support re-assigning groups, we need to enhance the basic group ID
> > system. Once a node has been associated with group X, it currently
> > ignores all messages sent by nodes not in group X. So that we can
> > regroup a node whose group ID is unknown, we introduce the "broadcast"
> > group ID. Nodes will receive messages sent with the node's own group,
> > or with the broadcast group. The host sending the association command
> > will tag that command with the broadcast group ID, ensuring that it
> > will able to reach the node. The identifier for this group will be
> > 0xFF, but given our legacy, 0x7D will also be treated as a broadcast
> > group identifier. Implementing this will require making a small change
> > to AMStandard.
> >
> > A broadcast group represents a hole in the administrative boundary --
> > and Deluge will flow through any hole. Thus, Deluge itself should
> > explicitly ignore all messages sent with the broadcast group ID.
> >
> This is a cool idea for a problem which has been tossed back and forth
> for a while. It's good to know that a management layer is the place
> where it will be dealt with. That seems like the right place.
> But, any traffic can flow through the hole. Deluge is just one simple
> example. Maté scripts, broadcasts, etc. I would argue, in fact, that
> few kinds of traffic want to be on the AM broadcast address, and that
> it should be something you have to specifically enable. Doing so is not
> very difficult:
> module AMJobby {
>    provides ReceiveMsg as MyReceive[uint8_t id];
>    provides ReceiveMsg as BCastReceive[uint8_t id];
> }
> Unfortunately, this will require a little bit of wrapping to be
> completely backwards compatible with 1.1. Specifically, you might want
> to have AMInternal that is the actual AM implementation, then
> components such as AMStandard are configurations that do not pass the
> broadcast receive handler through (so implicit wiring will work).
> > Next, group assignment should not only be a single-hop operation. Drip
> > should be able to disseminate the association command, so that it can
> > reach a node anywhere in the network. To ensure that the command will
> > reach every node, it must be rebroadcast with the broadcast group
> > ID. But, TinyOS automatically tags every outgoing message with the
> > local group ID. We need to include the ability to select the group ID
> > of an outgoing message before sending it.
> >
> > This could be done by changing the group field of the TOS_Msg before
> > passing it to send(). Logic in AMStandard will check this group id
> > before sending. If it is the broadcast group id, AMStandard leaves it
> > alone, and for all other group IDs, it changes the group id to the
> > node's own group id. Because this is stateful, reusing the buffer
> > without clearing the field could result in unintended messages being
> > sent to the broadcast group. Thus, AMStandard should explicitly clear
> > the group ID field of every message after the message has been sent.
> > This solution is a bit hacky, but it minimizes changes to the current
> > interface.
> >
> > With this ability to send messages either to the local group or the
> > broadcast group, the component implementing the association command
> > can retransmit its messages to the broadcast group, allowing
> > dissemination to complete. The group assignment command can then be
> > used throughout the network.
> I think it's useful to examine what the purpose of AM groups are: a
> logical network partition. There are other ways to do this. As Naveen
> and Chris have pointed out, crypto keys can do the same thing; in this
> circumstance, the broadcast group is an unencrypted message. AM groups
> are just one way to do this. I would argue that if you have a network
> with something like AES, you neither need nor want AM groups, as they
> are a waste of packet.
> Phil
> -------
> "We shall not cease from exploration
> And the end of all our exploring
> Will be to arrive where we started
> And know the place for the first time."
> - T. S. Eliot,  'Little Gidding'
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at Millennium.Berkeley.EDU
> http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-devel

More information about the Tinyos-devel mailing list