The Network Virtual Machine (NetVM) is a virtual network processor optimized for implementation and execution of packet handling applications. As a Java Virtual Machine virtualizes a CPU, the NetVM virtualizes a network processor. The NetVM is expected to provide a unified layer for networking tasks (e.g., packet filtering, packet counting, string matching) performed by various network applications (firewalls, network monitors, intrusion detectors) so that they can be executed on any network device, ranging from high-end routers to small appliances. Moreover, the NetVM will provide efficient mapping of the elementary functionalities used to realize the above mentioned networking tasks onto specific hardware functional units (e.g., ASICs, FPGAs, and network processing elements) included in special purpose hardware systems possibly deployed to implement network devices.
Our work on the NetVM includes the definition and implementation of a software architecture comprising two macro-components:
The NetVM follows the principles motivating the architecture of network processors; consequently, differently from the existing general purpose virtual machines, the NetVM is explicitly designed to process network packets. This is reflected in the set of supported functionalities that, on the one side is reduced with respect to the one of general purpose virtual processors, but on the other side is targeted to manipulations usually performed on network packets (classification, hash table handling, CRC calculation, encryption/decryption). This is reflected in the assembly instruction set of the virtual processor.
A NetVM program is location-independent because the NetVM code is translated at run-time (e.g., by a Just-In-Time Compiler) into native code for the specific hardware platform on which the NetVM is running in such a way that its execution is optimized. For example, if the underlying hardware architecture includes an integrated circuit performing a specific CRC calculation, the corresponding CRC calculation instruction will be translated in such a way that the CRC calculation will be performed by such integrated circuit. Consequently, program execution is optimized in terms of efficiency and the availability of custom hardware - even highly sophisticated one as in the case of off-load boards is leveraged of transparently for the programmer.
NetVM programming is further simplified by the definition of a high-level programming language that operates according to packet descriptions realized with NetPDL (Network Packet Description Language) and is compiled into native NetVM bytecode.
The second component of the software architecture, NetBee, aims at enabling a simple interaction between the user - i.e., the network application programmer, possibly the network manager himself - and the NetVM by providing the functionalities required to drive the NetVM. For example, NetBee will include a compiler able to translate programs written in a high level network programming language into assembly code for the NetVM. Hence, NetBee will enable the execution, possibly within programs written in a general purpose programming language, such as C, C# or Java, of NetVM programs that can efficiently perform any kind of processing on packets traveling through the network and return the outcome to the calling program.
Thanks to its flexibility, NetVM can be implemented for execution on network devices, thus enabling them to be programmed by means of third party software. Currently, having programs for network devices written by anyone else than the device's vendor is not practical also because of the specificity of the development tool that, when at all available, is required by each network device architecture.
|IP packets are today switched asynchronously with performance characteristics that are
unpredictable - thus adversely affecting especially streaming media
(audio/video) applications - unless network utilization is kept (very)
low. Moreover, asynchronous packet switching performs poorly at bandwidth
mismatch points, i.e., when switching traffic from a high capacity channel
- say a backbone optical link - to a low capacity channel - say an
access wireless link. Data bursts - that typically build up across
asynchronous packet switched networks - tend to overload and possibly
overflow buffers feeding low capacity channels. As a consequence, the
quality of the service as perceived by users decreases as a result of
packet drops and large delays.
The above problems of asynchronous packet switching result in - (1) unacceptable trade-off between predictable performance and network utilization and (2) poor handling of bandwidth mismatch.
The NetGroup has been conducting research on an enhancement to asynchronous IP - actually applicable to any packet switched technology - that leverages on a common time reference, possibly derived from UTC (Coordinated Universal Time a.k.a. GMT) as provided by GPS or Galileo, to realize pipeline forwarding of packets. There are two basic ways of implementing pipeline forwarding:
The NetGroup has tackled several issues related to pipeline forwarding implementation and performance evaluation. Current activities are listed below.
Recently the NetGroup designed and is developing a prototype router implementing time-driven priority packet scheduling. The prototype is based on a high-end general-purpose personal computer equipped with multiple Gigabit Ethernet cards. The FreeBSD operating system (version 4.8) is deployed to provide IP routing functionality, while TDP packet scheduling is added to the default FIFO queuing policy. A Symmetricom time processor PCI card equipped with a GPS receiver provides the common time reference derived from UTC. Specifically, the time processor card generates a programmable periodic interrupt over the PCI bus, which determines the beginning of a TDP scheduling interval - called time-frame (see references for more information).
The prototype is being deployed in various testbeds for the demonstration and experimentation of the pipeline forwarding of packets. The realization of the prototype enables gaining early experience in the implementation of TDP and its deployment in future packet backbones designed to efficiently offer high revenue services. Moreover, the demonstration testbed offers the opportunity to demonstrate the benefits brought by UTC-based pipeline forwarding to carrier(s) and network equipment vendor(s).
Preliminary measurements demonstrate that the maximum throughput and the average CPU load showed by the router when performing TDP scheduling and when FIFO queuing is deployed are comparable, while packet delay variation (jitter) is within the bound devised by analytical studies of TDP.
Pipeline forwarding without external time reference source
Protocols and algorithms are being developed for acquiring the common time reference from another network node, rather than an external source, such as UTC. These protocols and algorithms are implemented in the router prototype described above and their properties and constraints are being studied both analytically and experimentally.
|WinPcap, the well-known, widely deployed tool
for link-layer network access in Windows environments, was first developed
by the NetGroup. WinPcap allows applications to capture and transmit
network packets bypassing the protocol stack, and has additional useful
features, including kernel-level packet filtering, a network statistics
engine and support for remote packet capture.
WinPcap consists of a driver, that extends the operating system to provide low-level network access, and a library that is used to easily access the low-level network layers. This library also contains the Windows version of the well known libpcap Unix API.