A Generalized Computing Model of Active Networks

A Generalized Computing Model of Active Networks D. Scott Alexander February 25, 1997

1 Introduction As network connectivity grows throughout the world, the uses of the network also grow. The current network infrastructure cannot and does not keep up with this increase in protocols. We believe that the \Active Networks" approach will help to deal with this problem. Active Networks are those networks in which a node of the network can undergo state changes and can provide information about its current state through execution of programs. Thus, it becomes possible to deploy a new protocol by loading it into a switch or for a packet to attempt to nd an optimal route by discovering the state of the switch through which it is currently traveling. In the SwitchWare architecture for active networks, each node is capable of executing programs written in Caml, a dialect of ML.

1.1 Problem Statement

We see several problems with existing networking technologies, speci cally the Internet technology. First, as the Internet has moved from an experimental network to a production network, switch providers have begun to implement only standard protocols and the standards committees have become more deliberate in their standardization processes. This leads to long lead times between the initial formulation of protocols and their general deployment. Second, the current model which limits protocol decision making to the edges of the network limits the latency with which decisions can be made which impedes ow control and congestion avoidance. Third, while the merger of computing and communications has been much talked-about, communications systems are only slowly re ecting the impact of computing technologies in the basic design assumptions. Active Networks is an extremely promising approach to these general problems. This approach oers a network infrastructure that is programmable on a per-user or even a per-packet basis. While this approach is promising at a high level, there are a number of core problems that must be addressed:  What is the relationship between network elements and the programming model for the infrastructure as a whole? 1



   

What restrictions to a general purpose computing model in the network elements will lead to a network infrastructure which is simultaneously secure and exible? How are these restrictions rei ed in the design of a programmable network element? How scalable is the general purpose computing model when implementing the Active Network model? What are the metrics with which a programmable network infrastructure can be evaluated? Under these metrics, what are the possible architectural tradeos, for example between security and packet processing rates?

1.2 Motivation and Approach

Given our belief that a general programming model will allow applications that we have never envisioned, we strive to allow the users as much exibility as is consistent with the proper, secure operation of a shared resource like a switch. Tennenhouse, et al., [TSS+ 97] propose dividing active networks into two models based on either programmable switches or capsules. A programmable switch network has a set of switches in its core each of which is capable of receiving programs that will extend the capabilities of the network. In a capsule approach, \every message is a program." [TSS+ 97] Each message is executed based on some standard execution model and results in zero, one, or many packets being produced by the switch. Additionally, legacy switches are mentioned in the paper as another resource in the network. We propose to build a hybrid system that will include legacy, programmable switch, and capsule features.1 When the switch rst starts, it starts as a limited programmable switch. It then loads in a core functionality that is likely to include all three modes. For example, a program for processing UDP packets might operate in \legacy" mode in that all packets with Ethernet type UDP would be handed to it to be processed in the traditional fashion. Similarly, the basic functions of the programmable switch are likely to be extended so that programs can be reliably loaded across unreliable, unordered networks. Finally, the core is likely to include programs that, upon receiving a capsule, will build the intended execution environment and invoke it. To build such a system, we propose to build a three smaller parts that roughly parallel the boot process of an operating system. These are a loader that parallels the boot ROM, a Core Switchlet that parallels a microkernel,

1 It would be possible to describe the system as a pure capsule system since that is the most general of the mechanisms. For example, over an Ethernet, one could declare that the Ethernet type eld was the \start address" of the program in the \capsule." An instruction with a value that corresponds to the IP type would call a routine that processes the data portion of the packet as an IP packet and then would exit. However, we feel that stretching the model to that extent reduces the usefulness of the model.

2

application lib core switchlet loader Figure 1: Software architecture and the application and library switchlets that parallel the applications. The loader will be capable of loading a switchlet either from the network or the local disk and may provide some core services needed to load the initial switchlets. The Core Switchlet will set up the basis of security (including hardware access policies and interswitchlet communication mechanisms) and provide a set of basic services including a service for loading switchlets. This program is special in that it is given access to entry points not available to later switchlets. (For example, it is the only switchlet allowed to call . See Subsection 3.3 for more details.) Finally, there will be library and application switchlets loaded to allow the end users to tailor the system to their individual needs. Figure 1 illustrates this an application running on this architecture. We believe that such a system is likely to accrue bene ts in two primary ways. First, the network will be able to react more quickly to changes in state. For example, currently if a source is sending at a rate which exceeds the ability of a switch to handles its packets, the switch has few remedies other than to randomly drop packets and hope for the best. With an active switch, the packets themselves may contain programs to indicate which packets to drop rst, when to drop them, and how best to control the ow rate of the hosts. In the absence of such information, the switch could take measures like installing a leaky bucket

ow control switchlet in a switch between the oending source and the switch. Either of these mechanisms will control the ow in far less time than a round trip to the source and back. The second source of bene ts comes from the exibility that such a system entails. In the same way that the general host-host model of NCP allowed Dynlink.add available units

3

electronic mail to evolve over a system which originally only envisioned resource sharing, we hope that a general model will lead to valuable uses not currently envisioned. If such a model were currently present, a group of users wanting to experiment with multicast could add the support to their portion of the network directly instead of having to resort to the tunneling scheme that Mbone currently requires. The following are research goals for the dissertation:  Investigate active node architectures which unify the capsule and programmable switch models using a general purpose computing model.  Experimentally evaluate the advantages and disadvantages of this model over the present \passive" store-and-forward packet switching model. This will include a determination of appropriate quantitative metrics.  Analyze the architecture to ensure that it can act as a basis for building secure systems.

1.3 Novelty

The proposed work is novel in that it proposes a general model of computing as the basis of the switch.

2 Related Work Wetherall and Tennenhouse [WT96] have constructed an Active Network node architecture that uses a TCL interpreter operating on the LINUX operating system. The ACTIVE IP option is used to ag IP packets containing capsules, which are packets and data passed to the TCL interpreter. The scheme has been applied to some IP tasks, such as implementing traceroute with capsules. This work has been very focused on a proof-of-concept for an active node, and demonstrating viability of the idea. Our research is concentrated on the design and construction of the programming environment for a robust extensible node, and would be as useful for capsule support as it is for adding bridge functionality. Other work at MIT [WEK96] has demonstrated methods for loading network modules (Application-Speci c Safe Handlers, or ASHs) into O.S. kernels. Like our work, ASHs rely on pre-module loading static analyses; we believe that the Caml approach oers a better long-term opportunity for formal veri cation. Zegura, et al. [BCZ96] have designed a similar IP-based system, that demultiplexes an arriving packet with an IPOPT AP option ag to a pre-loaded function under SunOS. This approach has two aws from our perspective. First, it appears in exible with respect to applications loading new functions on-the- y. Second, to address this exibility limitation with modi cations to SunOS, there will be security risks unless languages and tools are used to validate loaded modules, as in our approach. 4

Liquid Software [HMPP96] extends the capabilities of the Java language bytecodes as mobile code fragments. Major foci are technologies for fast compilation of mobile code (to ensure high packet processing rates) and runtime support using the Scout operating system as a basis. The interaction between the Scout system and the Java API should provide some valuable lessons in the nature of a virtual machine that could support Active Nets. The choice of Java is a potential weakness, as a number of serious security problems have been discovered. Unlike ML [MTH90], Java lacks a mathematical de nition, making formal analysis of programs dicult. BBN's Smart Packets [PJ96] is focused on the ecient construction of the packet interpreting programming system for active networks. Smart Packets, like the capsules proposed in the MIT design, contain code in some form. The initial eort seems targeted at ecient byte code (e.g., a re ned Java or intermediate language) or even machine code in the packet. The intent is to ensure that loadable active technologies will be viable on even the highest-performance networks. Netscript [Yd96] provides a model for network programming, but is less focused on the construction of active network nodes than the MIT, Georgia Tech, Arizona and BBN eorts, and more on de ning examples of network programming. MMM [Rou96] is a browser that uses Caml as its applet language. They also use the strongly typed features of the language for security, but are able to assume a model in which all applets cooperate. Further, their applets extend a browser rather than extending the functionality of a network switch. Some of our infrastructure, in particular support for module thinning is derived from their eorts. Knabe's Mobile Agents [Kna95] is a system that provides for remote evaluation of parts of programs. Through his Facile language, a client can send a set of functions to be executed on a server for example to access information unavailable at the client or to access a faster CPU. We believe that the client-server model is unnecessarily limiting. SOFTNET [ZF83] was an amateur radio system built at the University of Linkoping, Sweden in the early 1980's. Each node in the network was a computer with a Motorola 6809 processing running a version of Forth. Each packet was considered a program to be executed on receipt. A goal of this network was to provide programmability of all layers of the infrastructure so that the network could adapt as the users learned about networking. Advances in networking and computing capacity allow us to go beyond this early active network.

3 Preliminary Results

3.1 The GWBridge

At the most general, the infrastructure for the sort of programmable switch proposed could be any system that is programmable and has a reasonable se5

curity model. To dierentiate between possible systems, we look to engineering principles including performance, usability, and completeness. Simplicity will also be considered an important criterion because of the belief that a simpler system is generally easier to analyze and make correct. In order to develop an initial understanding and intuition about the correct model, we have built a prototype system that provides a simple learning bridge functionality. The system is written in Objective Caml [Ler96] and uses their byte-code language as the medium of transmission across the network. On top of their dynamic linking facilities, we built a simple loader capable of adding functions to a symbol table, executing functions from that symbol table, and removing functions from the symbol table. On top of this loader, we then built a learning bridge2. A bridge was chosen because of its inherent simplicity and because of the limited facilities necessary to run experiments. It is quite easy to test whether or not a bridge is functioning properly. Similarly, since a bridge is intended to be \transparent," the facilities to test it do not need the strict control that would be required for any more complex system. An undergraduate in our lab then implemented the 802.1D [IEE93] [Per92] spanning tree algorithm on top of the learning bridge. She then modi ed this switchlet to implement a spanning tree algorithm that uses DEC spanning tree format packets to maintain the spanning tree. Finally, we wrote a switchlet that would automatically transition the network from the DEC-like protocol to the 802.1D protocol in a controlled manner. Moreover, it was capable of switching back to the DEC-like protocol if a failure was noted in the 802.1D protocol implementation. This provided a clear demonstration of the active nature of the Active Bridge.

3.2 Objective Caml

Because ML [MTH90] is strongly typed, is well studied by programming language semanticists, and because we have some considerable local ML expertise, we have chosen to use Caml [Ler95], an ML dialect, for our work. Caml is a language developed at INRIA based on ML. It also provides a module system and an object system. There were two primary motivations for the choice of Caml: the portable byte-code that it generates and the ability to perform dynamic linking. The byte-code compiler and interpreter provided give us a portable, compact language for describing switchlets. The dynamic linking facilities give us the ability to add switchlets to an executing system quite easily. We do not use the object oriented extensions available. Since this is the only dialect of ML that supports these features, it would make it much more dicult to move to a dierent compiler later if desirable. However, this version of the compiler is the one on which work is being performed, so desired xes or changes are much more likely to be available in Objective Caml than in other versions of Caml.

2 All references to bridges refer to 802.1D transparent bridges unless stated otherwise. This model was chosen as being widely implemented and requiring few test facilities.

6

3.2.1 Module Isolation

A key transition made by our security model is from using address spaces to name spaces as the basis of security. Aspects of such a model have been examined in the context of the Nemesys operating system for multimedia applications [LMB+ 96], and in some sense by capability-based systems. If switchlets were written in a weakly typed language like C, a switchlet would be able to access any part of its address space. Unchecked this ability would allow a switchlet to call any function in the address space, or worse to over-write the code or data of another switchlet. Enforcing security in a shared address space would be impossible. Traditionally, if multiple programs written in weakly typed languages are to share resources, security mechanisms such as separate address spaces are used to ensure that a program can only aect its own physical memory. Page protections ensure that a program only directly reads, writes, or executes unshared resources. When sharing is needed, it is mediated by the operating system, and when dierent processes need to execute, they require a context switch. These mechanisms operate while the program is executing and thus have a runtime cost. Our prototype presumes a single-language environment and uses strong typing to guarantee that only certain operations are allowed. Furthermore, by using static typing, which enforces type safety during compilation and linking, we are able to substitute compile-time and link-time costs for runtime costs. For example, functions are immutable objects, so there is no operator that allows one to change a function. (One could change a function reference to refer to another function, but there is no way to modify the function itself.) Further, there is no equivalent of a C cast operator3, so there is no way to \trick" Caml into thinking a function is an object that can be changed. Thus, there is no need for page protection since Caml provides equivalent protection on an object by object basis at compile and link times when it ensures that the types are all correct. For type safety to be fully enforced statically, it is also necessary for the system to use automatic dynamic storage allocation (garbage collection) and to check that array bounds are not overrun. Both of these features improve the safety and thus security of the system in general. For example, many common Unix security holes are created because C does not check array bounds. This allows a malicious programmer to overwrite the stack and upon returning from a call to execute arbitrary code. Similar tricks can be played if the programmer is allowed to free memory that is in use by other parts of the program. Using garbage collection (GC) avoids these problems, since only the system frees storage. The lack of a cast operator or an address operator also makes it impossible to refer to any object without either its name or a string of legal pointer references from a known object. Name-space based security rests on this feature. Figure 2 (the module interface) and Figure 3 (the module itself) contain some 3 There are transformation operators for making some safe, well understood transformations. For example, there is a function to transform an integer to a oating point number.

7

val pub_hash: (string, (int -> int)) Safestd.Hashtbl.t val pub_func: unit -> unit

Figure 2: example.mli open Safestd let pub_hash = Hashtbl.create 15 let priv_func x = x - 7 let some_func x = (priv_func x) + 5 let pub_func () = Hashtbl.add pub_hash "func" some_func

Figure 3: example.ml contrived code to illustrate this point. If another module wishes to reference objects from the module example, initially, it can only refer to those objects in its interface (signature). Attempts to access other objects result in compile time errors. If the other module were compiled against a signature built by an attacker that included some private objects, a link time error would result because the signatures would not match. The values accessible from the interface are the function example.pub func and the hash table example.pub hash; they can be referred to directly by name. Initially, example.pub hash is empty and does not lead to any functions. When example.pub func is evaluated, example.some func becomes accessible because there is a reference path to it through pub hash, and evaluating Hashtbl.find example.pub hash "func" would return example.some func.

3.2.2 Caml Threads

We intend to use the threads packages provided by Caml to produce two important eects. First, the scheduler inherent in the threads packages gives a basis for ensuring equitable allocation of the CPU to competing switchlets. This helps to combat certain types of denial of service attacks. The second important characteristic that we expect will be provided by using threads is scalability. If a network is heavily loaded at some switch, the cost of redeploying the network to reduce the load is usually prohibitive. Therefore, it is important to be able to increase the switching capacity at that node. For this to be possible, the node must be scalable. Thus, we expect that with our architecture, it will be possible to increase performance by increasing the number of threads running on independent CPUs. We note that two dierent thread packages are currently provided with Objective Caml. The rst, more stable version, is a user mode threads package. This package relies on SIGALRM signals to perform scheduling within a single Unix process. Since a single process can only run on one CPU, no speed-up is 8

let _ = try let lexbuf = Lexing.from_channel stdin in Dynlink.init(); Dynlink.add_available_units Crcs.crc_unit_list; while true do Func.do_op (Cmds.main Lexcmd.token lexbuf); done with Lexcmd.Eof -> exit 0

Figure 4: The code for the loader gained although a simpler programming paradigm is provided for certain problems. The second package is built on top of the POSIX threads interface. This package makes use of kernel threads meaning that the kernel individually schedules each thread on a par with the other processes on the system. In particular, this means that multiple threads can be running on separate CPUs simultaneously. Currently, we are using the user mode threads package because it is reliable. We anticipate that the kernel threads package will become reliable soon; when it is, we will transition to it. The interfaces provided by each of the packages is nearly identical, so this will be a very easy transition.

3.3 The Structure of the Loader

The loader is a fairly simple program as shown in Figure 4. It performs some initialization of a parser and of the dynamic linking routines and then loops evaluating its input until the user signals end of le. The commands currently understood by the loader are , , and . The command takes the name of a Caml byte-code le as its argument. It then dynamically links this le into the running image. All top level expressions are evaluated. Generally, these will be function de nitions, although this is not required to be the case. Usually, there will be a call to which registers a function so that the command can refer to it. The command allows such a named function to be executed. The two arguments to this command are the name associated with the function and a string that will be the argument when the function is called. The function is required to return a string that will be printed at function termination. Finally, removes the association between a name and a function. Henceforth, calls to for this function will return an unknown function error. Note that if the function exists in the global symbols table, it will continue to exist there. This means that other functions that refer to it will continue to work and future les that are loaded can link against this symbol. To maintain security, it is necessary to restrict the environment in which the loaded switchlets run. To produce the restricted environment we use a feature of Caml called module thinning [Rou96]. In Caml, groups of related functions, load

exec

unload

load

Func.register

exec

exec

unload

exec

9

along with their supporting data structures and types, can be aggregated into a module. Each module has a signature that describes which values, types, and functions are known to external functions. We have thinned the signature of the modules to be accessed by switchlets to exclude those functions that might allow security violations. This leaves the switchlet with no way of naming the excluded function and thus, no way of accessing it. Caml supports this process by including signatures in the byte code that is used to transmit switchlets. When Caml compiles a set of sources into byte codes, it includes an MD5 [Riv92] digest of the interfaces required by this module as well as the MD5 digest of the interface exported by this module. If the byte codes are unaltered module thinning works as described. We have not addressed the authentication issues, but these are an important avenue for further work. There are two problems with the current loader. First, it only loads switchlets from disk. This is quite easily xed by having the loader start by reading packets of a determined Ethernet type eld from the network. A fairly simple protocol will then be sucient for downloading switchlets. The second problem is that there is only one symbol table for all switchlets loaded. Thus, if a user downloads a switchlet that exports a function that returns information about the current state of the switchlet, any switchlet subsequently loaded can call that function and access that information. A simple solution is to extend the dynamic linker to allow multiple symbol tables. Others are looking into more general solutions.

3.4 The Core Switchlet

In GWBridge, the Core Switchlet is made up of a series of modules linked into the loader when the loader is built. None of these functions is called by the loader, but linking these modules improves the security in view of the nearly nonexistent security model. When we have a model for distinguishing between the privilege levels of switchlets, it will be possible to tailor the execution environment to the switchlet. With such a tailored environment, it will be possible to dynamically load the modules that make up the Core Switchlet. Currently, the Core Switchlet consists of an initial set of eight modules. These modules de ne the basic environment in which a switchlet will execute. We expect this set to continue to evolve as we gain more experience programming switchlets. The most basic of the modules provided is Safestd. This is a slightly modi ed version of the Safestd module from the MMM browser[Rou96]. It provides a set of standard Caml functions ranging from integer operations to an implementation of hash tables. As the name implies, it has been thinned to only allow \safe" operations. Similarly, Safeunix is a very heavily thinned version of the Unix module from Caml. Our version of Safeunix provides access to some time related functions and to some types that are needed for networking. Since we provide no functions for generating output as part of Safeunix, we provide a module called Log that allows logging messages to be generated. It 10

also allows us to change the method of logging, to a terminal, to disk, or not at all. We also provide a set of thread related modules. Currently, these are built on top of the basic Caml threads package that works entirely in user mode. We hope to be able to take advantage of the POSIX threads in the near future. The threads modules are Safethread, Condition, and Mutex. Safethread is only very lightly modi ed from Thread; because there are no ways to create an object of type Thread.t except by calling Thread.create, we can even leave Thread.kill in the module. So far, we have had to create two new modules to provide support. The rst of these, Func, contains glue routines to allow the loaded functions to properly register themselves. The register routine simply takes a string as a key and a function and enters them into a hash table. There is also a function that allows one to evaluate one of these functions. Finally, we provided a module to allow access to the network. Unixnet provides a set of functions that allow access to the network interfaces on the machine as shown in Figure 5. Our model separates those functions used for input from those from output. In each case, a function is provided to connect to a given port, to connect to the next available port, to disconnect from a port, to check the status of the port, and to send or receive a packet on the port. Whenever an input port is bound, it is put into promiscuous mode.

3.5 Automatic Protocol Transition

A major goal of GWBridge is to illustrate how active networks allow us to replace basic functionality. To demonstrate this facility, we built a switchlet that allows our bridge to transition between dierent, incompatible spanning tree protocols in a coordinated, automatic manner with automatic fall back if the new protocol should fail. A diculty encountered in managing a network is making changes to the infrastructure. Generally, this requires bringing down the node to be upgraded. If the change is incompatible, the problem becomes much worse. In the case that none of the nodes is capable of acting as a gateway between the two versions of the protocol, the network must either be partitioned into a portion supporting the old protocol and another supporting the new protocol or the entire network must be brought down, upgraded, and returned to service as a unit. Generally, neither of these choices is very acceptable to the users of the network. Moreover, if it turns out that the new protocol does not work for some reason, the same process must be used in reverse to back out the changes. In this experiment, we show how an active bridge can perform such a transition in an automated, coordinated fashion. The network partition still occurs, but at the pace the infrastructure sends and processes packets rather than at the pace of the network administrators can move from machine to machine. Thus, the transition can be expected to take time similar to what would occur if there were a power failure at each of the bridges. Moreover, active monitoring can occur while the network is stabilizing, detecting any failures in the new im11

type packet = { len : int; addr : Safeunix.sockaddr; pkt : string } type iport type oport exception Already_bound exception No_interface (* Input ports *) val pkts_waiting_p_in: iport -> bool val bind_in: string -> iport val bind_addr: string -> iport val get_next_pkt_in: iport -> packet val unbind_in: iport -> unit val unbind_addr: iport -> unit val get_iport: unit -> iport (* Output ports *) val bind_out: string -> oport val send_pkt_out: oport -> string -> int -> int -> Safeunix.sockaddr -> int val unbind_out: oport -> unit val get_oport: unit -> oport val ready_to_send_p_out: oport -> bool (* Generic functions *) val iport_to_oport: iport -> oport (* Debugging aids *) val debug_iport_to_string: iport -> string val debug_oport_to_string: oport -> string val debug_demux_num_devs: unit -> int

Figure 5: unixnet.mli

12

plementation and transitioning the infrastructure to a stable state such as the previous protocol. In order to have a simple pair of protocols to transition between, an undergraduate modi ed the spanning tree switchlet to send DEC spanning tree packets to the DEC management multicast address instead of 802.1D packets to the All Bridges multicast address4. This DEC-like protocol was used as the old protocol. The 802.1D protocol was used as the new protocol. We also wrote a control switchlet that was capable of controlling the transition between the two protocols. In order to load the control switchlet, both the 802.1D switchlet and the DEC switchlet must already be loaded. It checks that the DEC switchlet is operating and that the 802.1D switchlet is not. It then arranges to receive any packets addressed to the All Bridges multicast address. When an 802.1D packet arrives, the control switchlet assumes that the network is transitioning to the new protocol. It halts the DEC protocol and starts the 802.1D protocol giving it the received 802.1D packet. It also arranges to let the 802.1D protocol listen to the All Bridges address and it starts to listen to the DEC address. Any DEC protocol packets received during an initial transition period are suppressed. The 802.1D switchlet sends out con guration packets on all of its ports thus causing any bridge that is on a connected network and that has not transitioned to do so. The control switchlet now moves into its monitoring phase. For this particular transition, the critical change is the protocol for computing the spanning tree. As such, the control switchlet monitors the information about the spanning tree accumulated at the current node. This is compared with information captured from the DEC algorithm at the time of its termination. (If the changes were such that the information to be checked were not available at the node, it could be hand calculated for the expected case.) If the spanning tree does not converge to the expected values within a predetermined time, the control switchlet will determine that there must be a bug in the new protocol implementation. Similarly, the old host location table could be compared with the new host location tables if the network administrators were not planning to move any hardware during the transition period. If a failure is detected, the functions implementing the new protocol are stopped and the old protocol is restarted. The control switchlet again changes so that it receives new protocol packets (which it suppresses) and allows the old protocol to process its own packets. As a nal measure to allow fall back to occur gracefully, if the control switchlet nds any old protocol packets after the initial transition period, it falls back to the old protocol assuming that a failure has occurred elsewhere in the network. To completely implement the DEC protocol would require changing some timings and states as well. We did not do this. We simply required an incompatible packet format so that we could make a transition. 4

13

4 Characterization of a Solution

4.1 Requirements

Based on the knowledge acquired and being acquired from the loadable bridge, a loadable switch must be built. This switch needs to have a clearly de ned set of services and a basis on which a security policy could be built. There must be support for legacy protocols and for new protocols. Additionally, while performance is not the primary goal of this work, the switch must be capable of processing packets at a rate that will allow realistic experimentation.

4.2 Security Policy

The security policy of the Active Switch is a dicult issue. Clearly de ning such a security policy is likely to provide the basis for at least one other thesis. As such, it is not within the scope of this work. However, this work will be substantially less meaningful if it ignores the issues necessary to such a policy. As such, it is a goal of this work to allow a reasonable security policy. Two examples of how this might be demonstrated are by sketching the form that such a policy would take or by demonstrating adherence to a security policy drafted by another researcher.

4.3 Measurements and Characterization

At the completion of this research, there should be a number of measurements and characterizations possible. In particular, it should be possible to characterize any departure from the model of a general computational node and a minimal model for security required by such a switch. Additionally, it should be possible to demonstrate functionality not available in current switches.

4.4 Performance

The goal of the performance measurements which are to make are part of this work are to better understand the costs inherent in the design. Thus, we will take measurements of characteristics including throughput, ltering rates, and frame rates as well as pro ling the switchlets to discover the cost of speci c operations. By contrasting these costs with existing systems, we can develop an understanding of the situations in which these techniques may or may not be appropriate. We also hope to avoid the sorts of misinterpretations that can occur when the cost of a single expensive operation is averaged with the costs of many inexpensive operations.

5 Plan of Action To act as a road map towards answering the question posed, we have come up with the following schedule. The date by each item is intended as a rough 14

estimate only. We believe that each of these steps will aid in answering the question that we pose.      

  

 

Continue to measure and analyze GWBridge to more fully understand its performance and limitations (4/1/97) Complete WPE II requirements (Spring 1997) Modify loader to accept (digitally signed) commands from the network (6/1/97) Create draft services model (6/30/97) Modify the loader to load the Core Switchlet modules (instead of linking with them) (7/15/97) Implement IP router switchlet to demonstrate brouter functionality and to take advantage of the preponderance of trac on the local network as test data (10/1/97) Update services model and Core Switchlet based on results of the brouter (11/1/97) Implement a capsule oriented protocol (1/1/98) Based on these results, determine whether additional revisions are needed to any of the above and determine what additional protocols should be implemented (1/15/98) Capture data from the system and from existing hardware implementations of bridges and/or routers (early 1998) Analyze data to determine the characterizations and measurements outlined in Section 4. Present dissertation to committee (3/13/98).

5.1 Discussion of Milestones

5.1.1 Continue to measure and analyze GWBridge

We have begun to analyze the behavior of the GWBridge, but questions remain. For example, we have characterized its throughput in a simple experiment as being limited to approximately 15Mbps. This can be compared with a measurement of 70Mbps throughput if we replace the bridge with a piece of cable directly connecting the two end systems. We have also crudely determined that, on average, it takes 0.465ms for a packet to be processed by the Caml portion of the bridge. We have not determined the cause of the limitation on performance. The rough timing measurement gives a rough estimate that of the 8.75 seconds that it took to send the 16MB of ttcp data, somewhere between 5.749s and 6.112s were used within Caml. By more carefully instrumenting the Caml code, it should be possible to determine the source of these costs. We have speculated 15

that they could be caused by inherent ineciencies in the byte-code interpreter, poorly written code, an inecient library, or bad interactions with the garbage collector. Without further analysis, it could be any of these or something else. Further analysis should allow us to understand the system and to make the appropriate corrections or allowances in the router.

5.1.2 Complete WPE II requirements

This does not directly apply to this work, but is listed to aid in understanding the timeline.

5.1.3 Modify loader to accept (digitally signed) commands from the network

There are two reasons for completing this milestone. The rst is that we have found that the terminal interface currently available is quite awkward for running tests. A network interface such as the one described, allows one to more easily automate test procedures. Moreover, it becomes possible to control several switches from one central point. It also simpli es the internal design of the loader: after initially loading enough information o the disk to start the network, the loaders only task is to read switchlets o the network and execute them. The switchlets themselves are responsible for executing previously loaded functions or modifying the execution environment. The second reason for adding these features is to make it possible for switches to send switchlets to adjacent switches. Thus, the automatic switchover experiment could be modi ed so that one loads a copy of the 802.1D spanning tree algorithm and control switchlets into one switch and then that switch loads these switchlets into the surrounding switches. The controlled, rippling switchover occurs, but the task of the network administrator is even further reduced.

5.1.4 Create draft services model

One of the crucial aspects of building a exible system is to ensure that the programmer will be able to write any program that does not violate the policies of the system. Providing a well designed set of services is a basis of meeting this goal. By making the model for providing these services explicit, we hope to attract useful comments. The rst step in devising this model will be to examine the model used in GWBridge and to try to imagine where that model will need to be expanded for other anticipated applications. Functions will also need to be divided into those that must be provided in the loader, those that must be provided as privileged functions, and those that may be provided in unprivileged libraries. For example some of the functions used to access the network will be used by the loader in order to load the rst switchlets. While it would be possible to duplicate these functions, it will probably make most sense to keep only one copy which is linked into the loader. This decision will also force some other 16

modules (for example, ) to be in the loader. As we discuss in the next item, care must be taken not to move too many services into the loader. In contrast, there will be modules which contain code which needs to be privileged, but does not need to be in the loader. The thread-related modules will fall into this category. They need to be trusted in order to be able to allocate a critical resource (more threads which implies more access to the CPU), but they are not used in the loader. In the nal category, there are likely to be functions which will be useful to providing a usable programming environment, but which do not need to be privileged. In this category, there is likely to be functions like marshalling and unmarshalling functions. Safestd

5.1.5 Modify the loader to load the Core Switchlet modules

One of the features of the software architecture illustrated in Figure 1 is that it is possible to burn the loader into the ROM of a dedicated system. If this were done, then it would be quite dicult to make changes to the loader. By moving most of the functionality of the Core Switchlet out of the loader, it becomes possible to make changes to the Core Switchlet more easily. Thus, this step helps to keep the experimental framework closer to the sort of system described by the model.

5.1.6 Implement IP router switchlet

This switchlet will form the core of the experimental framework to answer the question that we have posed. Since most of the trac traveling across our network is IP trac, it will allow us to quickly gain experience with the operation of the architecture. Moreover, IP switches are common and have been the subject of other research, which presents a basis for comparison of this work.

5.1.7 Update services model and Core Switchlet based on results of the IP router

We expect that as we attempt to use the services model that we developed, we will discover de ciencies. Since this model is critical to the proper design of the system, we believe that it will be worthwhile to make revisions to the model in a deliberate manner. It is hoped that the revisions to this model will again draw comments.

5.1.8 Implement a capsule oriented protocol

The work described to this point has all been possible with the programmable switch model. Given our model that capsules are transient programs, this is necessary to build the infrastructure. However, while it would be possible to emulate a capsule model by sending switchlets to every possible switch which captured and processed packets of the type to be sent, clearly the capsule model 17

is more elegant and simpler. As such, implementing a capsule protocol (probably a routing protocol) will increase our understanding of how such a system operates.

5.1.9 Determine whether additional revisions and what additional protocols are needed

In building a system of this sort, there are bound to be surprises. We believe that it is important to take the time to review the surprises and react to them. This will occur informally during the course of the work, but we feel it is often helpful to stop and do it formally at some point in the process. After the major implementations and initial experiments are complete seems a good time to schedule this milestone.

5.1.10 Capture data from the system and from existing hardware implementations of bridges and/or routers

Having built the experimental apparatus, we now set about measuring it. During the course of building the apparatus, debugging the apparatus and performing primary experiments will often coincide. To determine whether the IP router is functioning will involve performing the experiment in which we run a switchlet which implements an IP router. However, there are likely to be some primary experiments which have not been run because of the complexity of the apparatus required and there are likely to be secondary experiments relating to the performance of the system which have not been run. Additionally, comparisons with other systems can best be performed at this time.

5.1.11 Analyze the data

This step will, of course, continue throughout the process. However, we expect that as we start to write the dissertation, it will become clear that time is needed to examine the data in new ways. With the perspective of writing the document is likely to come new insights into the bene ts to be derived from building a programmable switch.

6 Expected Results If the research proposed here is successful, we will have a new model for distributed computing. We will have generalized the behavior of the network from a simple transport to service to cooperatively developed services integrating hosts and the network infrastructure. The new model will have been exempli ed by the prototype system discussed, proving that such a system can be constructed, and further that it can be applied to open problems in network management and extensibility. If the thesis is successful, the model should demonstrate:  A programming environment for network elements adapted from general purpose computing environments 18

Uses of this programming environment to solve problems identi ed in the networking technical literature  Restrictions to a general purpose computing environment necessary for security considerations in network elements  A characterization of the performance costs of per-packet computing in a network element  Performance, security, and architectural tradeos between the capsule and programmable switch models for programming active networks  An architecture that can unify the programmable switch and capsule models in a single framework, and its implementation  Metrics with which active network elements can be quantitatively evaluated In addition, the model will demonstrate features which we believe will accelerate the creation of network software, such as the ability to operate \personal protocols" and to load new software \on-the- y." Since the proof of these aspects will require large-scale deployment and this is a proof of concept system, we cannot report on the success or failure of this work with respect to these goals, but will articulate reasons why we think they will take place based on this and similar work. 

References [BCZ96]

Samrat Bhattacharjee, Ken Calvert, and Ellen W. Zegura. Implementation of an active network architecture. Technical report, Georgia Institute of Technology, July 1996. White paper presented at Gigabit Switch Technology Workshop, Washington University. [HMPP96] J. Hartman, U. Manber, L. Peterson, and T. Proebsting. Liquid software: A new paradigm for networked systems. Technical Report Technical Report 96-11, University of Arizona, June 1996. http://www.cs.arizona.edu/liquid/. [IEE93] IEEE. Media access control (mac) bridges. Technical Report ISO/IEC 10038, ISO/IEC, 1993. [Kna95] Frederick Colville Knabe. Language Support for Mobile Agents. PhD thesis, Carnegie Mellon University, Pittsburgh, PA, December 1995. [Ler95] Xavier Leroy. The Caml Special Light System (Release 1.10). INRIA, France, November 1995. [Ler96] Xavier Leroy. The Objective Caml system release 1.03. Institut National de Recherche en Informatique et Automatique, October 1996. 19

[LMB+ 96] I. M. Leslie, D. McAuley, R. Black, T. Roscoe, P. Barham, D. Evers, R. Fairbairns, and E. Hyden. The design and implementation of an operating system to support distributed multimedia applications. IEEE Journal on Selected Areas in Communications, 14(7):1280{ 1297, September 1996. [MTH90] R. Milner, M. Tofte, and R. Harper. The De nition of Standard ML. MIT Press, 1990. [Per92] Radia Perlman. Interconnections: Bridges and Routers. AddisonWesley, 1992. [PJ96] Craig Partridge and Alden Jackson. Smart packets. Technical report, BBN, 1996. http://www.net-tech.bbn.com-/smtpkts/smtpktsindex.html. [Riv92] R. Rivest. The MD5 message-digest algorithm. Technical Report RFC1321, MIT Laboratory for Computer Science and RSA Data Security, Inc., April 1992. [Rou96] Francois Rouaix. A web navigator with applets in Caml. Fifth WWW Conference, May 1996. http://pauillac.inria.fr/mmm/papers/mmm.ps.gz. [TSS+ 97] D. L. Tennenhouse, J. M. Smith, W. D. Sincoskie, D. J. Wetherall, and G. J. Minden. A survey of active network research. IEEE Communications Magazine, pages 80{86, January 1997. [WEK96] D. A. Wallach, D. Engler, and M. F. Kaashoek. Ashs: Applicationspeci c handlers for high-performance messaging. In Proc. 1996 ACM SIGCOMM Conference, 1996. [WT96] David J. Wetherall and David L. Tennenhouse. The active ip option. In 7th ACM SIGOPS European Workshop, September 1996. http://www.tns.lcs.mit.edu-/publications/sigops96ws.html. [Yd96] Y. Yemini and S. daSilva. Towards programmable networks. In IFIP/IEEE International Workshop on Distributed Systems: Operations and Management, October 1996. http://www.cs.columbia.edu/ dasilva/netscript.html. [ZF83] Jens Zander and Robert Forchheimer. SOFTNET | An approach to high level packet communication. Technical report, Department of Electrical Engineering, Linkoping University, 1983.

20