Apr 15, 1996 - workstations), are vertically integrated closed systems. ... software, are rigidly built-in by intermediate nodes vendors. Vendors must ... nodes. For example, virtually every PC incorporates powerful multimedia capabilities.
TOWARDS PROGRAMMABLE NETWORKS Yechiam Yemini & Sushil da Silva Department of Computer Science Columbia University {dasilva, yemini}@cs.columbia.edu
April 15, 1996
Abstract Intermediate nodes (e.g., routers, switches) of current networks, in contrast with end nodes (e.g., PCs workstations), are vertically integrated closed systems. Their functions, mostly implemented by embedded software, are rigidly built-in by intermediate nodes vendors. Vendors must follow designs dictated by slow and intractable standard committees rather than pursue rapid introduction of innovative costeffective technologies. There is thus a need for new technologies that would enable programming intermediate nodes with the same simplicity of programming end-nodes. This paper describes the NetScript project, pursuing agent-based middleware for programming functions of intermediate network nodes. Delegated agents are used to deploy functions in intermediate nodes. The NetScript programming language provides means to script processing of packet streams; it is particularly suitable to program routing, packet analyzers or signalling functions. This paper describes an architecture for programmable network nodes; middleware for agent-based programming of these nodes; the NetScript language to program node functions and applications of these technologies to create programmable SNMP agents, protocol analyzers, signalling and routing protocols and firewalls.
1. INTRODUCTION End nodes in a network--e.g., PC’s and workstations -- are organized as open systems whose functions can be programmed with ease. In contrast, intermediate nodes --e.g., routers and switches -- are closed vertically-integrated systems whose functions are determined through long and intractable standardization processes. These different paradigms have created an increasing gap between the functions and capabilities of end nodes in networks and those of intermediate nodes. For example, virtually every PC incorporates powerful multimedia capabilities. However, it may take a decade before the various standardization processes have been completed, implemented by vendors and deployed by end users to accomplish ubiquitous interactive multimedia networks. There is thus a need to reconsider the very paradigm of closed vertically-integrated intermediate nodes, underlying current networks. This paper provides a preliminary description of the NetScript project, for creating technologies to program intermediate network node functions. The idea underlying NetScript is simple. One should be able to deploy software in intermediate nodes dynamically with the same ease of launching an end-node application. This will enable software vendors to provide powerful software that programs intermediate nodes to support innovative applications. For example, a vendor of a multicast multimedia application could provide its users with applications software for endnodes as well as routing software for intermediate nodes. End users will deploy and use this software in both end nodes as well as intermediate nodes with the same ease. Such programmable networks will enable and stimulate faster introduction of innovative network technologies and functions than is possible today. They will also eliminate the need for intractable standardization, replacing committees with market forces in establishing standards. While this may seem, at first, a radical transition it is indeed a very natural evolutionary step. Already today intermediate nodes contain a large variety of software to support a growing range of protocols and functions. A typical router incorporates software to support over 20 different routing protocols. This growing featurization of elements has given rise to ever-complex configuration management. Configuration management has become, in effect, a form of programming intermediate node functions. Often this is sufficiently complex, with elements MIBs already incorporating thousands of configuration variables, that one develops specialized scripting languages to program configuration choices. Thus the problem is not whether networks should be programmable, but what is the right paradigm to program them efficiently. The situation described above is not dissimilar from the evolution of printing some 15 years ago. With rapid improvements in printing technologies vendors increased featurization of printers. To enable users to take advantage of these features they developed corresponding configuration capabilities. Applications vendors had to include scripts to manage these configurations options to create output to different printers. The introduction of Postscript enabled a simpler, universal and more efficient paradigm for programming printing engines. It enabled rapid development and introduction of more powerful, innovative and cost-efficient printing technologies. It enabled applications to be designed to take advantage of and program these features of printing engines. A central feature that distinguishes programmable engines from a configurable ones is the programming model used. A configurable engine focuses on establishing a maximal set of highlevel features that can be activated as single atomic actions. In contrast, a programmable engine
2
focuses on identifying a minimal set of primitives from which one can compose an indefinite spectrum of high-level features. The NetScript project seeks to create a model for programmable, rather than merely configurable, intermediate network node engine. We use the term agent to describe a program that can be dynamically dispatched to and executed at a remote system. NetScript uses agents to program management and control the functions of intermediate nodes. A NetScript agent glues primitive node functions to processing packet streams and allocate node resources. NetScript agents can be programmed to handle both standardized as well non-standardized protocols. Packet streams arriving at intermediate nodes are processed by the appropriate agents to accomplish the desired functionality of these protocols. For example, consider the provisioning of a private virtual network and processing of packet streams transported over this networks. NetScript agents can be dispatched to intermediate nodes to allocate resources to the virtual network and to configure its processing functions to handle routing and flow control of packet streams over this network. In what follows we overview the various technologies pursued by the NetScript project towards accomplishing such programmable networks. The NetScript project consists of three components: a architecture for programming networks in the large, an architecture of a dynamically programmable networked device, and a language called NetScript for building networked software on a programmable network. Section 2 describes the NetScript architecture; Section 3 presents a conceptual overview of the NetScript language; Section 4 outlines a few NetScript applications to network management and control; Section 5 describes related work. We conclude with an overview of challenges that must be overcome if networks are to become programmable.
2. AN ARCHITECTURE FOR PROGRAMMABLE NETWORKS How can one program a large scale multi-domain network to provide communication services used by a large number of end-nodes? How can this be accomplished in networks that contain a mix of programmable and non-programmable nodes? This section outlines the answers pursued by NetScript. NetScript views a network as a collection of Virtual Network Engines (VNE) interconnected by Virtual Links (VL). The VNEs can be programmed by NetScript agents to process packet streams and relay these streams over VLs to other VNEs. The collection of VNEs and VLs defines a NetScript Virtual Network (NVN). NetScript provides a language to program a NVN. NVN may correspond only loosely to the underlying physical network. A physical network node may be responsible to execute multiple VNEs, and a VL may correspond to a collection of physical links and nodes that interconnect VNEs. Furthermore, a VL can interconnect any number of VNEs; this is particularly useful to handle broadcast links. Consider now the architecture of a VNE, depicted in the figure below. The Agent Services layer provides a portable multi-threaded execution environment to support delegation, execution and control of agent programs. It supports, additionally, message communication services among agents. The Agent Services layer uses the SMARTS Operations Server (SOS) implementation [1] of the management by delegation agents [2]. It provides a library that enables NetScript programs to delegate, execute and control agents at VNEs.
3
Figure 1: Architecture of a Programmable Virtual Network Engine The NVN Connectivity Services module is responsible to interact with the underlying physical environment to allocate and maintain VLs to neighboring VNEs. It provides a library of primitives used by NetScript programs to control the allocation of VL resources, scheduling and transmission of packets over VLs. The NetScript interpreter provides a multi-threaded execution environment for NetScript agents. It maintains local libraries of agents and provides access to a distributed global directory of agents executing at different VNEs. A NetScript program can be viewed as a collection of threads, distributed at the VNEs and processing packet streams moving through the NVN. For example, a routing protocol programmed in NetScript consists of agents, executing at multiple VNEs, whose task is to relay packet streams belonging to this protocol. Routing agents are responsible to analyze packet headers and forward them accordingly to other routing agents. They are also responsible to maintain routing tables at these VNEs. Similarly, a virtual network programmed in NetScript consists of agents that configure and maintain the virtual network topology and resources; agents to provide routing and flow control functions along the virtual links of this network; and agents that support signalling protocols for this virtual network. A firewall programmed in NetScript consists of agents who filter NetScript packet streams and remove packets that fail to meet the filter criteria. How do NetScript programs communicate? Packets contain a minimal NetScript encapsulation header that basically identifies the stream to which they belong. When a packet arrives at a VNE this header is used by the run-time environment to pass it to the respective programs which process this stream. This communication model is essentially similar to Milner’s CCS semantic model. The communication model permits a single stream to be processed by multiple programs. These programs may perform global routing, collect stream statistics for management purposes, monitor a stream to detect intrusion attacks or filter packets. It is important to note that the NVN does not have built-in global routing functions. Communication services provided by the VNE are entirely local and permit interactions with neighboring VNEs only. Global routing is left to programmable protocols. The NetScript run-time environment provides a default global
4
routing protocol. This protocol is used by VNEs to access various global services such as topology and agent directory services. How does NetScript interoperate with other network protocols and technologies? Two possible models are used to accomplish interoperability. First, one can overlay the NetScript Virtual Network on top of other network architectures. For example, a VL of NetScript may be implemented on top of IP links or tunnels, or use an ATM virtual circuit. A second possibility is to overlay an existing protocol stack as a NetScript program. For example a NetScript program may implement IP routers in VNEs. IP packets will be encapsulated in NetScript header and routed by this program to neighboring VNEs, where they are processed again by the IP routers. How are NetScript programs deployed and executed in the NVN? This is accomplished through the use of the Agent Services layer. NetScript agents can be dispatched from any VNE to any other VNEs. The source VNE uses the local Agent Services layer to delegate and execute agents at remote VNEs. The default global routing program is used to support these agent services.
3. THE NETSCRIPT LANGUAGE This section presents a high-level overview of the NetScript language. Our goal here is to describe the computational model and guiding design principles behind NetScript, not to provide a detailed description of the language; the NetScript Language Manual [3] gives such a description. NetScript is a small and simple dataflow language designed specifically for communicationsbased tasks. In particular, NetScript programs operate on streams of packets. The language provides a set of standard primitives that simplify the construction of stream-based computations. These primitives include operations on messages -- parse, flatten, split, join -- and operations on streams of messages -- multiplex, demultiplex, etc. NetScript is based on simple object-oriented principles, so programmers can override the default operators with customized versions of their own. A NetScript program consists of a pool of communicating threads. These threads communicate through message streams that connect inputs to outputs of executing programs. Communicating NetScript programs need not reside on a single VNE; they can be geographically distributed on VNEs across a network. NetScript utilizes the services of a Virtual Link (VL) to provide stream communication between distributed NetScript programs. It is important to note that a program that runs on a VNE need not be written completely in NetScript. Resident programs, especially common-path, low-level protocols and drivers, can be written in any convenient programming language (e.g. C, C++). One can think of NetScript as the "glue" that ties together computations on a VNE. Figure 2 below shows a typical VNE configuration. Here a NetScript implementation of a hypothetical Multimedia Multicasting Protocol (MM) communicates with a UDP protocol through a pair of streams. The arrival of messages from the network successively activates the Ethernet, IP, UDP, and MM modules.
5
Figure 2: Typical VNE Configuration We now illustrate how one would use NetScript to deploy a new protocol across a network. We use the Multimedia Multicasting Protocol (MM) from Figure 2 as a guiding example. MM provides multicasting services, jitter control and video synchronization for multi-conferencing applications on an internetwork. MM must run on both the intermediate nodes (the routers) and the end nodes of the network. At the intermediate nodes, MM maintains multicast routing trees, and aids in jitter-control; at the end nodes, MM lets users enter and leave multi-conferencing sessions, and provides video data streams. A software vendor could code the intermediate and end node components of MM in NetScript and bundle both with a multi-conferencing application. When a user launches the application, the application first attempts to dispatch and execute MM on the intermediate nodes of the network if it has not been loaded already. To do this, NetScript utilizes the NVN Connectivity Services to identify intermediate routers in the network, and the SOS Agents Services Layer to dispatch intermediate node MM agents to the routers. To start the end-node version of MM, the application communicates with the VNE on local machine, loads the end-node version of MM at the VNE, builds stream connections with the VNE, and begins communicating. Both the local and intermediate versions of MM operate by making VL connections to local resources (e.g. UDP) and to remote resources (e.g. MM instances on other intermediate nodes). Three features distinguish NetScript. First, NetScript provides a universal abstraction of a programmable networking device; second, NetScript is a dynamic language; and third, NetScript is a dataflow language. NetScript provides a universal abstraction of a programmable networking device. Universality means that a NetScript program will execute on any VNE without regard for the current state or configuration (e.g. executing programs, connected devices) of that engine. NetScript constructs, along with services provided by the VNE, hide the heterogeneity of networking devices behind simple abstractions. In analogy, PostScript provides an abstraction of a universal, programmable printing device.
6
NetScript is a dynamic language. This means that programs or devices can be added to or removed from a VNE on-the-fly, at runtime, without disturbing the execution of existing protocols. The language utilizes SOS Agent Services to dynamically execute and control NetScript agents that arrive from the network. It is also worth noting that the programmer need not explicitly connect NetScript programs together on a target VNE. Instead the program is simply delegated to a remote engine. When NetScript program arrives at a VNE for execution, the environment automatically configures the program and connects the program to other executing programs based on the type signature of that program. This automatic configuration is important because internal state can differ radically from one VNE to another. If a program depends for its execution on other programs or protocols (e.g. IP) that do not currently reside on a given engine, the program simply remains dormant until the dependent programs arrive from the network. Autoconfiguration saves the programmer from writing complex, tedious and error-prone scaffolding code to ensure that a program will execute on all VNEs. NetScript’s computational model is based on dataflow. This model is sufficiently different from the conventional control-flow model of computing that it deserves elaboration. In a dataflow model, a computation is organized as a set of concurrent, communicating processes where the flow of data within the system drives the computation in each process. A dataflow computation is nicely described by a graph (see figure), where the nodes represent computational elements and the edges represent communication paths. Essentially, the arrival of data at the inputs of a program determines which part of the graph is computing, and which is not. This is in contrast with the traditional computer model which focuses on a single sequence of instructions (or statements) in a program. The control in a program determines the single execution path through the instruction sequence. A dataflow model is particularly appropriate for network-based applications because network traffic is essentially asynchronous. Message streams arrive asynchronously from both the network and user programs; the arrival of a message triggers a computation in a NetScript program; the type of a message (its header) determines its path through a graph of connected NetScript programs. Another advantage of dataflow is that it greatly simplifies the construction of concurrent programs. Coordinating and synchronizing multiple concurrent activities is often the most difficult part of building networked systems. Dataflow programs, however, do not require explicit and complex synchronization mechanisms (e.g. mutex locks, semaphores) because such programs communicate solely through well-defined formal interfaces. This is particularly important for NetScript programs, which will run on remote VNEs under a variety of hardware and software configurations, and therefore must make minimal assumptions about the host environment.
4. NETWORK MANAGEMENT APPLICATIONS This section outlines some Network Management applications and shows how one could use NetScript to easily program these applications on a network. We describe a Remote Network Monitor, an SNMP Agent, and an ATM Signalling Protocol. Although we focus on Network Management applications here, NetScript could be used for other kinds of protocols also. 4.1 REMOTE NETWORK MONITOR
7
A Remote Network Monitor allows an organization to watch the performance and health of a network and protocols from a remote location such as a workstation. Ideally, to get a reasonable view of the overall behavior of network, one would want to probe the network at strategic locations within the network. These include both the intermediate nodes (switches, routers) and the end nodes (workstations, PCs). Information from the probes could be gathered in real-time at a workstation application to provide a system administrator with a comprehensive, dynamic view of her network. As we have discussed, the current network architecture does not permit easy programming of internal nodes. One could RMON MIBs to monitor the network, but RMON supports only a rigid set of operations, and requires that filters be written with low-level bit manipulations. Additionally, the polling model in SNMP makes real-time monitoring of a large network impractical. Alternatively, one can dispatch NetScript monitoring agents throughout a programmable network. These monitoring agents are essentially high-level filters that watch and instrument packet streams in real-time at VNEs. Each filter performs header classification of one or more streams, maintains counters in internal state variables, and uses a VL to report results back to the administrator’s monitoring application and display. 4.2 SNMP AGENTS IN NETSCRIPT Although NetScript opens up new possibilities for private network management protocols, NetScript can interoperate with, even implement existing standards like SNMP. This is of special importance when a NetScript VNE resides on a network managed by existing non-programmable infrastructure. Here we show how NetScript enables the construction of SNMP agents. An SNMP agent typically consists of three components. One component is a back-end that maintains the consistency of MIB data structures. The second performs MIB instrumentation. This component consists of various routines to collect and maintain MIB variables such as traffic counters. The final component is a front-end to SNMP. This component parses incoming SNMP requests, interacts with the MIB back-end, and generates SNMP replies or traps. NetScript could be used to implement all three components. The NetScript implementation of the MIB back-end would consist of NetScript programs that provide atomic access to MIB variables. To perform instrumentation, NetScript stream analysis programs can report and manipulate MIB status variables. A NetScript front-end would consist of programs that parse SNMP request packets and call an appropriate back-end program to get or set a MIB variable.
4.3 ATM SIGNALLING PROTOCOL The term ATM Signalling refers to the connection setup phase in an ATM network. ATM networks use a signaling protocol to open and close virtual circuits on an ATM network. To do this, a the switching protocol must negotiate circuit setup with all intermediate switches in a path from source to destination in a virtual circuit. Typically, this involves sending signalling cells between switches. The emerging standard for ATM signalling (Q.2931) is a comprehensive, scaleable signalling protocol for large networks. Because current ATM switches are constructed as closed, vertically integrated black-boxes it is not currently possible for customers to deploy small subsets of the standard or even private signalling protocols. Nor is it possible for vendors to incrementally upgrade installed control software as the relevant standards emerge and evolve. One possi-
8
bility is to make an ATM network programmable by embedding a VNE in the vendor switches, adaptation cards, and host software. NetScript agents installed at the switches would maintain switching tables that map virtual circuits to input and output ports. These agents parse, interpret, and forward incoming private or standard signalling cells set up and tear down circuits in the network.
5. RELATED WORK NetScript shares similar goals with the Active Networks [4] initiative at MIT and the SwitchWare [5] effort at the University of Pennsylvania and Bellcore. Like NetScript, these projects seek to make the network programmable. The Active Network extends the concept of a packet from a passive data object to one that might contain a fully-functional active program. This approach is not incompatible with that of NetScript. Indeed, mobile NetScript programs are encapsulated in conventional protocol messages, for example IP. The SoftSwitch project is attempting to build a programmable switch. They intend to explore security operating system issues among others. The central difference between our work and Active Net or SoftSwitch is our focus on the programmability of networks. NetScript uses a single, universal language, specifically designed for protocol implementation in a programmable network; the Active Network project currently uses Safe-Tcl [6] while SoftSwitch uses Java [7]. We believe that a single language based on the right model can greatly simplify protocol construction, can be more effectively optimized for efficient performance, is easier to secure, and will allow us maximum flexibility in experimenting with appropriate programming features. Another difference is that NetScript treats the network as a single programmable abstraction (the NVN) rather than an heterogeneous collection of programmable routers, switches and end-nodes. We believe that this approach will enable programming of massive Internet-sized networks. Java and Telescript [8] are programming languages also intended for networked applications. Java is targeted as a language for programming user-interface functionality in Web browsers. TeleScript is an agent-based language for Internet commerce. Both languages provide abstractions to support their respective domains. NetScript’s abstractions are designed specifically for dynamic implementation of protocols in a programmable network.
6. CONCLUSIONS This paper provides a preliminary overview of the NetScript project. Several challenges exist if networks are to become programmable: 1. How to organize a network to support programmability of node functions while assuring interoperability with a variety of nodes and protocol stacks of current networks and enabling scalability for large networks. The NetScript project is pursuing a virtual network architecture that provide effective answers to this challenge.
9
2. How to facilitate effective dynamic distribution and execution of software to program network nodes. The NetScript project is building on the delegated agent technology introduced in [2],[1] to address this challenge. 3. How to create a simple and effective paradigm to program packet stream processing in network nodes. The NetScript language has developed a dataflow programming model that addresses this challenge. Several additional challenges, not addressed in this paper, are investigated by the project. 1. How to assure that node programs are efficient to handle fast real-time performance requirements. 2. How to ensure the security of programmable nodes against unauthorized access. Success of this research would mean that we have established effective mechanisms to program intermediate network nodes with the same ease and efficiency available for programming end nodes. Success would mean that intermediate node functions can be programmed and deployed through simple, open and rapid processes that do not require standard committees or vendors resources. Success would mean that NetScript programs can be generated and deployed in intermediate node engines to control and manage their functions with the same simplicity as Postscript programs are applied in printing engines.
10
7. REFERENCES [1] SMARTS, SMARTS Operational Server Manual, . 1994, System Management Arts. [2] Yemini, Y., G. Goldszmidt, and S. Yemini. Network Management by Delegation. in The Second International Symposium on International Network Management. 1991. Washington DC. [3] daSilva, S. and Y. Yemini, NetScript Language Tutorial and Reference, . 1996, Columbia University Computer Science Department: New York. [4] Tennenhouse, D.L. and D.J. Wetherall, Towards Active Networks, . 1996, MIT Laboratory for Computer Science. [5] Smith, J.M., et al., SwitchWare: Accellerating Network Evolution (White Paper), . 1996, University of Pennsylvania Computer Science Department. [6] Borenstein, N. Email with a Mind of its Own: The Safe-Tcl Language for Enabled Mail. in IFIP International Conference. 1994. Barcelona, Spain. [7] Gosling, J. and H. McGilton, The Java Language Environment: A White Paper, . 1995, Sun Microsystems. [8] White, J.E., Telescript Technology: The Foundation for the Electronic Marketplace, . 1994, General Magic.
11
