Tuesday, October 31, 2006

Paper: "A Modular Network Layer for Sensornets"

A Modular Network Layer for Sensornets
Cheng Tien Ee, Rodrigo Fonseca, Sukun Kim, Daekyeong Moon, and Arsalan Tavakoli, University of California, Berkeley; David Culler, University of California, Berkeley, and Arch Rock Corporation; Scott Shenker, University of California, Berkeley, and International Computer Science Institute (ICSI); Ion Stoica, University of California, Berkeley

Abstract

An overall sensornet architecture would help tame the increasingly complex structure of wireless sensornet software and help foster greater interoperability between different codebases. A previous step in this direction is the Sensornet Protocol (SP), a unifying link-abstraction layer. This paper takes the natural next step by proposing a modular network-layer for sensornets that sits atop SP. This modularity eases implementation of new protocols by increasing code reuse, and enables co-existing protocols to share and reduce code and resources consumed at run-time. We demonstrate how current protocols can be decomposed into this modular structure and show that the costs, in performance and code footprint, are minimal relative to their monolithic counterparts.

2 Comments:

Blogger Anthony Nicholson said...

This comment has been removed by a blog administrator.

6:43 PM  
Blogger Anthony Nicholson said...

Official scribe comments:

Cheng Tien Ee described work at Berkeley on a modular network layer for sensor networks. The authors recognize that sensor nets software from different organizations does not interoperate easily. The specific problem they address in this work is monolithic, vertically-integrated network stacks. Intuitively, one would expect that if such network layers were modularized there would be a good deal of overlay between different implementations. Since the authors argue that we are probably stuck with multiple network protocols, they focus on making it as efficient as possible to run multiple network protocols at once on one system.

Their solution decomposes the network layer into modules. First, they break the network layers into the data plane and control plane. Each of these is further subdivided into many components, such an output queue and forwarding engine in the data layer, and a routing engine and routing topology in the control plane. They show how diverse protocols can actually share components, like output queues, resulting in runtime benefits and code reuse. Their evaluation of several common protocols showed that protocol-specific code made up a small fraction of the total code base for their implemented examples.

Matt Welsh from Harvard was concerned about the interplay between different network protocols with regard to such things as packet scheduling, memory usage, et cetera. Cheng responded that memory management indeed is a cross-layer issue, and that they are currently looking at dealing with such effects. Matt also asked if the code was available, and Cheng said they are currently attempting to integrate their work into TinyOS. Eddie Kohler from UCLA asked what types of protocols would fit this model less well than the examples the authors chose. Cheng answered that there isn't any class of protocols they can't decompose, but the main difficulty they have with more complex protocols is the decomposition of REs and FEs into smaller ones that can be better reused. An example of such a protocol is one with multiple phases during the forwarding of a packet along its path. For such protocols, it is not immediately clear how the futher decomposition can be done. An indication of an improperly decomposed network protocol is multiple similar functions, such as packet fowarding methods, being implemented within a type of component. The last question noted that there are protocols they can't support, but said this is due to SP---for example, anything with rate limiting can't be represented to SP. The question was if there is anything the authors would have wanted from the lower-level abstractions that they don't currently supply. Cheng answered that he didn't need anything else from SP, and on the contrary found it often provided more info than necessary.

7:10 PM  

Post a Comment

<< Home