openNetVM NFV Platform

openNetVM is a system composed of three primary components:

1. Manager: Orchestrates traffic between Network Functions (NFs). It handles all Rx/Tx traffic entering and leaving the system, manages the dynamic starting and stopping of NFs, and provides system-wide statistics.
2. NF Library: Provides the interface for NFs to communicate with the Manager. It allows NFs to initialize and send/receive packets. The library requires the NF to provide a function pointer to its packet_handler to the Manager.
3. Packet Helper Library: A utility library used to extract TCP/IP, UDP, and other packet headers that are lost when using Intel DPDK. Since DPDK bypasses the Linux Kernel to bring packet data into userspace, it wraps data in rte_mbuf structures, losing the standard kernel-level encapsulation/decapsulation.

openNetVM is a high-performance Network Function Virtualization (NFV) platform built on top of DPDK and Docker containers. It provides a framework for deploying network functions (NFs) and interconnecting them to construct service chains.

Key architectural details:

• DPDK-based: Leverages Data Plane Development Kit for high performance.
• Containerized: Uses Docker to run NFs, which can be started automatically or manually.
• Branching Model: The master branch contains verified stable releases, while the develop branch tracks experimental builds and active development.

The ARP Response NF is a Network Function designed to respond to ARP Requests. It allows you to configure the IP address for each NIC port by providing a comma-separated list of IPs. Each IP in the list is mapped to the corresponding port index (e.g., the first IP maps to port 0, the second to port 1).

Example mapping: `-s 10.0.0.31,11.0.0.31` maps port 0 to 10.0.0.31 and port 1 to 11.0.0.31.

The l2switch is a Network Function (NF) based on the DPDK l2fwd example. It functions as a Layer 2 switch that forwards packets out of adjacent ports.

Forwarding Logic:

• The destination port is determined by the enabled portmask. For example, if the first four ports are enabled (portmask 0xf), ports 1 and 2 forward into each other, and ports 3 and 4 forward into each other.
• The destination MAC address of individual packets is replaced with 02:00:00:00:00:TX_PORT_ID.

NAPT (Network Address Port Translation) is a Network Function (NF) developed using the NFD framework. NAPT enables mappings from tuples (address, L4 port number) to tuples (registered address and assigned port number) to perform address translation.

The NFD framework consists of two parts:

1. NFD Language: A table-form language used to write NF model files (e.g., model.txt).
2. NFD Compiler: Translates the NFD model file into a standard runtime environment, such as C++.

In this specific example, NAPT is translated from model.txt into a C++ environment.

SYN Flood Detection is a Network Function (NF) developed using the NFD framework. It monitors incoming traffic to identify potential SYN flood attacks by counting the number of SYN packets received from a sender (IP) that do not have a corresponding matching ACK.

If a single sender exceeds a user-defined threshold $X$, the sender is blocked. In the provided example, the threshold is set to 100.

The web console functions by consuming JSON files generated by the openNetVM Manager's stats thread.

1. Data Generation: The manager's master thread runs a stats thread that periodically updates onvm_json_stats.json (port and NF statistics) and onvm_json_events.json (event lists).
2. Data Serving: The start_web_console.sh script runs cors_server.py (an extension of Python's SimpleHTTPServer with CORS enabled) to serve these files.
3. Frontend Consumption: The React-based frontend uses AppWrapper.react.js to make periodic web requests to fetch this data and update the global state.
4. State Management: Global state is managed via a custom publisher/subscriber library (pubsub.js). React components subscribe to NF or event data on mount and unsubscribe on unmount. To optimize performance, pubsub.js only retains the last 40 data points per NF and Port.

The DNS Amplification Mitigation Network Function (NF) is designed to protect users from DoS attacks where an attacker spoofs a server's IP to trigger large DNS responses.

Mechanism:

1. The NF tracks all legitimate DNS requests sent by the user's server.
2. It uses a map to store these real requests.
3. It allows real DNS responses to pass through while dropping responses that do not correspond to a previously recorded request from the spoofed IP.
4. It specifically targets DNS response packets where the TCP/UDP source port is 53.

NFs in openNetVM are executed using three distinct tiers of configuration flags, separated by --. When running an NF, you must provide arguments for each tier in the following order:

1. DPDK configuration flags: Configures DPDK initialization. Typically includes -l CPU_CORE_LIST -n 3 --proc-type=secondary.
2. openNetVM configuration flags: Configures how the manager handles the NF. Use these to set service IDs, instance IDs, core sharing, or TTL.
3. NF configuration flags: User-defined flags specific to your NF's logic (e.g., throttling or destination IDs).

Example command structure: ./nf_binary [DPDK_FLAGS] -- [ONVM_FLAGS] -- [NF_FLAGS]

The Load Balancer NF is a Layer 3, round-robin load balancer.

Behavior:

• Flow Management: When a packet arrives, the NF checks for an existing flow. If no flow exists, it creates a new entry and assigns it to a destination backend server.
• Port-based Logic: The NF determines packet handling based on the arrival port.
• Flow Table Maintenance: The NF automatically cleans the flow table when it reaches capacity.

Requirement: This NF must be run in conjunction with an ARP NF, as the onvm_mgr does not currently resolve ARP requests. The ARP NF is used to respond to client and server ARP requests with the Load Balancer NF set as the destination.