NetServ is a programmable node architecture designed for deploying in-network services (see also http://www.cs.columbia.edu/irt/project/netserv/). It is suited for any types of nodes, such as routers, servers, set-top boxes, and user equipment. NetServ includes an in-network virtualized service container and a common execution environment for both network services and traditional addressable services (e.g. a Web server).

NetServ is thus able to fill the gap between these two types of services that have traditionally been kept separated in the Internet architecture. In this way administrators can be provided with a suitable flexibility to optimize resource exploitation.

The NetServ prototype architecture is currently based on the Linux operating system. It includes an NSIS-based signaling protocol, used for dynamic NetServ node discovery and service modules deployment therein. The NetServ controller coordinates NSIS signaling daemons, service containers, and the node transport layer. It receives control commands from the NSIS signaling daemons, which may trigger installation or removal of both application modules within service containers and filtering rules in the data plane. Each deployed module has a lifetime associated with it. It needs to be refreshed by a specific signaling exchange by its lifetime expiration, otherwise it is automatically removed.

The NetServ controller is also in charge of setting up and tearing down service containers, authenticating users, fetching and isolating modules, and managing service policies. Service containers are user space processes. Each container includes a Java Virtual Machine (JVM), executing the OSGi framework for hosting service modules. Each container may handle different service modules, which are OSGi-compliant Java archive files, referred to as bundles. The OSGi framework allows for bundles hot-deployment. Hence, the NetServ controller may install modules in service containers, or remove them, at runtime, without requiring JVM reboot. Each container holds a number of preinstalled modules, which implement essential services. They include system modules, library modules, and wrappers of native system functions.

The current NetServ prototype uses Eclipse Equinox OSGi framework. Service modules are OSGi bundles deployed in a service container:

• Server modules, circles located within the upper-right service container. They act as standard network servers, communicating with the external through a TCP or UDP port.
• Packet processing modules, circles located within the lower-left container. They are deployed in routers along packet path and can both inspect and modify packets in transit.

The module classification as server module or packet processing module is only logical, since each NetServ module may act in both ways. This is actually an important NetServ feature since it overcomes the traditional distinction between router and server by sharing each other’s capabilities. Currently, the Linux kernel is used to implement the NetServ transport layer. Packet filters, used to intercept packets in the NetServ node, and rules, used to route them to the proper service container, are installed in the node forwarding plane by using the netfilter library through the iptables tool. NetServ is able to perform dynamic node discovery and dynamic module deployment through an NSIS-based signaling protocol. NSIS (Next Steps In Signaling), is an IETF standardized signaling protocol framework for managing general-purpose states in network nodes. It consists of two layers:

• NSIS transport layer protocol (NTLP), a generic lower layer used for node discovery and message sending, which is regarded as independent of any signaling application;
• NSIS signaling layer protocol (NSLP), the upper layer which defines message format and sequences; it contains the specific signaling application logic.

These NSIS signaling layers are part of the NetServ architecture and based on GIST (General Internet Signaling Transport protocol), a widely used implementation of NTLP. GIST uses existing transport and security protocols to transfer signaling (i.e. NSLP) messages on behalf of the served upper layer signaling applications. It provides a set of easy-to-use basic capabilities, including node discovery and message transport and routing. NetServ NSLP is the NetServ-specific implementation of NSLP.

These two layers run as separate daemon processes in each NetServ node and exchange messages and events through UNIX sockets. The current implementation of the NetServ signaling daemons is based on an extended version of NSIS-ka, an open source NSIS implementation by the Karlsruhe Institute of Technology, modified so as to provide the dynamic capabilities needed by NetServ. NetServ signaling messages convey commands to install and remove modules, and to retrieve information about NetServ nodes. Any authorized NetServ instance can query any other NetServ node to discover, for example, the supported types of services, the list of the currently installed modules, a particular service output, and general information about the node and its supported service policies and containers.

The current GIST specification defines the on-path discovery method only. Nevertheless, since the standard allows introducing different message routing methods and provides generic objects for making GIST easily extendable, we implemented in NetServ an epidemic routing method would allow discovering and signaling peers in all directions efficiently, in order to optimally locate NetServ nodes able to run the requested services.

Specifically, the extension will enable the following modes of signal dissemination in addition to the on-path propagation:

1. signalling dissemination within an area around the sender (bubble),
2. signalling dissemination within an area around the receiver (balloon), and
3. signalling dissemination within an area around the path between the sender and the receiver (hose).

The bubble or balloon modes will be useful for NetServ deployemnt within an enterprise environment. The hose mode will be useful for scenarios where NetServ nodes are not immediately on-path, but a couple of hops away.

A video illustrating how NetServ can be used to protect an application server by a DoS attack can be downloaded from here [link].

The relevant live demo has been performed during the Demo session of IEEE LCN 2011, Bonn, Germany.