[Tinyos-devel] AM ID guidelines for net2 protocols and other applications

[Matt Welsh]

I think we're on the same page here but there are some details to work  
out.

Anything in "tos" could be assigned an AM ID range by the net2 WG. The  
question is how do things move from "contrib", "apps", etc. to "tos"?  
An example might be a new timesync protocol that someone develops and  
wants to be part of the official release (by which I mean, in "tos").  
There needs to be a clear way for someone to (a) get their code in  
there and (b) get the AM IDs assigned for it. Being a member of the  
net2 WG is one way to do that, but I would hope there are other  
avenues that permit inclusion of third-party protocols as part of the  
standard tree.

The flip side is what happens if a lot of protocols end up being  
"blessed" in this way and we start to run out of AM IDs in the 128-255  
range. My suggestion was to consider an AM ID assignment as a  
revokable lease, rather than a permanent guarantee. That way the net2  
WG can reclaim unused/stale AM IDs if needed.





On Apr 30, 2008, at 12:11 PM, Philip Levis wrote:
>
> On Apr 30, 2008, at 6:02 AM, Matt Welsh wrote:
>> That makes a lot more sense to me than just "protocols developed by  
>> net2". As Om said you only need about 15-20 IDs, but you're  
>> proposing to claim 128. Seems like a mismatch.
>>
>> Here's a proposal. As TinyOS matures it's clear that we need some  
>> way to resolve AM ID space conflicts. One approach is for net2 (or  
>> some appropriate working group) to maintain the AM ID registry for  
>> all *standard* protocols included in the TinyOS core tree (apart  
>> from contrib).
>
> What is a standard protocol? I mean, if it's in the tree, it needs  
> to be able to work with the other protocols in the tree. Note that  
> protocols defined in apps/ would fall into the range 0-127.
>
>
>> When a protocol is pushed into the main tree, it is assigned AM  
>> ID(s) by the net2 WG and these are published somewhere (doc wiki  
>> seems like a good idea). Those IDs would be assigned in the range  
>> 128-255. The range 0-127 is marked as "unassigned" and applications  
>> are free to use anything in that range (at their own peril).
>>
>> The main challenge with this approach is determining what  
>> constitutes an "official" protocol that warrants an ID in the  
>> reserved space. Over time I would expect accretion of "dead"  
>> protocols that are claiming AM IDs. One policy would be for the AM  
>> ID to have a renewal period of, say, 2 years. This problem would  
>> largely go away if we could move to 16-bit AM IDs.
>
> I think the criterion is "in the tinyos-2.x tree." More precisely, a  
> protocol has an ID in the range 128-255 iff it is in tinyos-2.x/tos/.
>
> Phil