Moab - the Utah NodeOS
		  http://www.cs.utah.edu/flux/janos/
		    janos-discuss@flux.cs.utah.edu

			     Mar 17, 2002

Source snapshot VI: Try Some New Stuff.  This release reflect the results
of several experiments demonstrating the flexibility of the Moab implementation
as well as improving its performance.

New for this release:

 * More work with Click-based channels.  We have implemented a library that
   sits above the NodeOS interface allowing a user (i.e., an EE) to insert
   an arbitrary Click graph into the packet processing path.  Using this
   technique, it is possible to bind one or both sides of a NodeOS channel
   to one or more Click graphs.  We have implemented a simple "ping" click
   graph and a complicated NAT (Network Address Translation) graph to
   demonstrate the usefulness of this library.  We have also used this
   library to provide a user-level implementation of the full NodeOS
   channel protocol and addressing specifications, including nested
   protocol configurations (e.g., IP in IP).
   [ LAST MINUTE NOTE: we have not yet packaged up the necessary Click
   changes, so you cannot use this feature right now. ]

 * Added alternate API style.  Moab has been modified to support either
   a "direct" or "descriptor" based API.  Direct means the current API,
   where the object reference returned by calls refers directly to the
   internal object state; i.e., the internal implementation is exposed.
   Descriptor adds a layer of indirection.  The returned reference is to
   a struct which contains a small integer descriptor used to look up the
   actual object; i.e., the internal implementation is not exposed.
   See item #21 in the NOTES file for more details.

 * Optional use of polling device drivers in the OSKit version.  Enables
   the use of packet polling (supported in select OSKit ethernet drivers)
   rather than interrupt-driven packet receipt.  Under heavy traffic load
   this dramatically improves the packet throughput.  Currently, the
   implementation is not very robust.

 * More synchronization with NodeOS spec.  Added a simple console logging
   interface, brought demuxkey implementation in synch, improved the
   event implementation.

 * Added assorted new test EEs.  Several testing the new Click channel
   capabilities, and a prototype for testing the ``Active Doom'' protocol
   (see envs/adoom/README).

 * Integrate with emulab.net.  When running in Utah's network testbed
   (emulab.net) Moab will use infrastructure-supplied information to
   determine available interfaces and their associated IPv4 information.

 * The inevitable, continuing cleanup of source code.  The source directories
   were heavily reorganized to support the direct and descriptor based APIs.
   Also many files changed as a result of (finally!) renaming "flows" to be
   "domains" as per the current NodeOS spec.

 * Fix old bugs, introduce new ones.

==============

What this NodeOS has:

 + Domains, including the domain termination hierarchy.
 + Threads, starting, exiting, interrupting, and priorities.
 + Thread synchronization, mutexes and condition variables.
 + Channels, socket-based UDP (ETH/IP/UDP) and "raw" ethernet packets (ETH),
   simple cut-through channels.
 + Click channels, accepting Click router graphs as specs.
 + Prototype of Click-based in/out channels (needs work).
 + Packet demux, using lists of <len,key,mask> triples,
   support for some specialized header demuxing (IP, UDP, TCP, ANEP)
 + Packet buffers, simple contiguous data buffers.
 + Mempools, in name only with simple malloc/free interface.
 + Resource controls: domain thread limits, channel thread/memory limits,
   proportional-share outgoing network bandwidth and CPU limits.
 + Simple event mechanism.
 + Rough implementation of the filesystem interface.
 + Simple statistics interfaces for domains, mempools, and channels.

What this NodeOS doesn't have:

 - No memory resource controls.
 - Shared memory interface (haven't needed it).
 - Credentials, or any sort of access control ("security") framework.
 - A truly useful, efficient packet filtering mechanism (ala DPF).
 - Full spec-compliance: no NodeOS packet interface, events not complete,
   no routing table interface, API syntax somewhat out of sync.
 - No extension mechanism.

If you are looking for instructions for building the NodeOS, see the
INSTALL file.  For details on the implementation and code layout see
HACKING.  For things that need to be done, see TODO.  For random
soul-searching and assorted, occasionally out-of-date notes, see
NOTES.

Please direct any questions, comments, or other feedback to the Janos
mailing list: 
	janos-discuss@flux.cs.utah.edu.

Thanks,

The Janos Team