next up previous
Next: Flow handles. Up: Rationale on Dispatchers and Previous: Rationale on Dispatchers and

Flow dispatchers.

Our system uses a chain of dispatchers to identify incoming packets. A dispatcher is a Java interface that consists of a single routine that accepts incoming packets. Depending on its implementation, a dispatcher may buffer a packet or identify another dispatcher to which the packet must be presented, possibly after skipping a header. Since the dispatch routines are executed at non-accounted interrupt time, their execution time must be individually and globally bounded. They should not make copies of the buffer itself. In the general case, guaranteeing these properties requires worst-case execution time (WCET) analysis. We make the following simplifying assumptions: first, we assume that trusted dispatchers adhere to this restriction. Second, we assume that untrusted dispatchers--such as those used by untrusted active protocols extending the dispatch chain--are only implemented as subclasses of trusted dispatcher base classes, except for one single untrusted method that examines the actual buffer content and makes a yes/no decision as to whether to accept this packet, akin to traditional packet filters. We expect to be able to restrict the code of these filter routines in a way that will allow a simple verifier to assure their safety, i.e., their boundedness. If we had more general verifier available to us that would allow us to ensure the safety of the more general dispatch function, we could extend the trust perimeter even further.

Flow dispatchers that demultiplex packets to higher layers act as as partial classifiers. Defining these dispatchers in our framework allows them to be written in a modular fashion, which allows different combinations of protocols to be assembled.



Jay Lepreau
Tue Jun 2 05:48:49 MDT 1998