Active Networks are networks based on programmable network infrastructure. Such networks can be programmed at many levels, including per-user, per-connection, and even per-packet. A major architectural issue in such networks is the tension between flexibility, performance, and security. Many of the same issues that arise in extensible operating systems such as SPIN and the Exokernel also arise in Active Networks. An important additional difficulty is that the resources that must be safely shared are those of an inter-network's routers and bridges, and these resources must be shared among ``users'' that may be as transient as a single packet.
The SwitchWare project is an Active Networking effort that is taking a programming language centric approach to solving these traditionally operating systems problems. As part of our effort, we are designing PLAN (Programming Language for Active Networks) to serve as the basis for light-weight mobile code carried in packets. As with Java for browsers or Modula-3 for SPIN, part of our approach is to use type-safety and garbage collection to guarantee that PLAN programs are pointer-safe and thus can execute in unprotected address spaces without compromising the integrity of other parts of the system. However, PLAN goes beyond pointer safety by providing key aspects of its security mechanisms as part of the language. The central goal is to allow a pure PLAN program to be executed anywhere in the network fabric without the need for authentication. Avoiding both protection and authentication allows the execution of PLAN code to be extremely lightweight.
Several key aspects of PLAN's design allow it to avoid the need for authentication. First, PLAN is based on a formal semantics, thus allowing us to formally reason about what PLAN programs can and (more importantly) can not do, both in general and for specific programs. For example, a proof of the type-safety of PLAN allows us to avoid the need for heavy-weight address spaces as mentioned above. A novel aspect of PLAN's semantics is that it is based on the idea of remote execution. Second, because some functionality requires authentication, PLAN provides the ability to make service calls to routines in other languages. These routines can authenticate and thus provide the needed functionality. The interface between PLAN and these service routines is specified in much the same way as a RPC interface. This allows the service routines to be written in a number of different languages, but still provides a well-typed and formally tractable interface to PLAN. The final mechanism is much the same as that used in packet filter programming, which is to say that the expressibility of the language is restricted so that important insecure actions are simply not possible. In particular, by design, PLAN restricts the usage of certain key resources (cycles, memory, and bandwidth) to be bounded and easily controlled.
Although PLAN is in a central sense a "language" effort, it does attempt to provide novel solutions to a number of traditional systems problems. Furthermore, in both its design and implementation, PLAN brings notions and constructs that have been developed by the systems community into a language context. We believe that such category crossing approaches are essential to solve the problems that arise in building systems supporting mobile code in demanding environments like Active Networks.
More information can be found at http://www.cis.upenn.edu/~switchware/PLAN/.