Embedded Rule-based Management for Content-based DTNs - Advances in Network-Embedded Management and Applications - page 95

physical devices, allowing to simulate a large network while monitoring the resource
consumption on a real device.
For the embedded platforms in our tests (consumer grade wireless routers such
as Linksys WRT54GL and Asus 520gu), we have used OpenWRT [5], a distribution
of Linux for embedded devices. This setup provides a profusion of standard tools
for managing and conguring the behavior of the node. At the same time, in recent
versions of OpenWRT Lua is used as a platform for the administration web-page,
and thus most of the runtime needed for our programs is already in place by default.
As a result, we could develop a networking platform, a general purpose decision
engine, and a monitoring software in a high level scripting language, which can run
unmodied on a PC, a wireless router, or a network simulator.
5.2 PDP
PDP's task is to take autonomous decisions, based on the stream of Notications
it receives through the Notication Bus. To this purpose, a special policy le is
pushed from a central server. This policy le is generated in the central server
from the rules specied by an administrator, and delivered to the PDP agent in a
command notication through the network. The policy le is a Lua program that
implements a state machine, accessible through function calls. When a policy le
is received, the PDP executes it in a special sandboxed environment, and starts
triggering it with notications. The state is kept internally in the policy script, and
the PDP must not know how it is implemented, only that call hooks are respected.
The PDP maintains a list of recent notications, which is shared into the scripts
environment. This list contains a sliding window of the last arrived notications. To
simplify the state machine, the notications are ordered in the window by a xed
ordering rule. In this way, the state machine does not have to handle every possible
permutation of the notications of interest.
The size of the sliding windows can be set at conguration time. For this purpose
there are two parameters: a length of time in seconds, and a maximum number
of notications in the window. Also, there is a special category of notications:
\happening notications". Those are notications that signal permanent change in
some attribute, and thus must be kept in the window for it to be correctly processed.
For example, a decision could depend on whether a given service is active or not,
thus the hypothetical \going up" and \going down" notications from that service
could be marked as happening to keep them in the window. This way, the state
machine could count on the presence of said notication no mater how old they are.
Marking and unmarking notications as \happening" is policy's responsibility, and
the PDP will comply while maintaining the sliding window.
Beside accessing the window, the policy script must provide the following calls:
{ initialize () This is called once after the script is loaded.
{ process window add () This function is called whenever a new notication ar-
rives. It gives the opportunity to advance the state machine.
{ process window move () This function is called whenever the sliding window
moves, thus a notication is removed from the leading edge. This implies that