Granular Packet Monitoring

July 16, 2023 · 3 minute read

Introduction

Monitoring devices such as Netflow collect active IP network traffic as it flows in or out of an interface. While Netflow and other legacy provide visibility and help identifying network problems, they are not granular (resolution is typically in the order of seconds) and are subject to proprietary implementations.

Research Challenge

The goal of this project is to use the capability of P4 devices to monitor and track flows, and collect correspond statistics. Examples of statistics to be collected are:

Statistics:

Source and destination IP address
Source and destination transport-layer ports
Amount of unidirectional traffic (bytes)
Start Time
End Time
Rate (bits per second)

What is P4? P4 is an open source, domain-specific programming language for network devices, specifying how data plane devices such as switches and routers process packets. P4 allows developers to acheive results at a granular level, allowing for extremely precise results. By providing a programmable language for network devices, P4 facillitates innovation and experimentation in network architectures and protocol.

The research will take over the course of eight weeks from February 1, 2022 - April 22, 2022.

Research challenge PDF can be found here.

The website of UofSC ONR CI can be found here.

P4 Structure

The V1Model is seperated into several different stages:

headers - contains the packet headers and metadata definitions
parser - contains the implementation of the programmable parser
ingress - contains the ingress control block that contains match-action tables
egress - contains the egress control block
deparser - contains the code that verifies and computes checksums

Code Overview

Ethernet, IPv4, and TCP classes along with metadata structures will be defined in headers.

The parser block will be parse and ethernet, IPv4, and TCP headers.

The ingress block is where the majority of implementation will take place. In order to store data pertaining to the various different flows, registers will be used. Their size will correspond to the byte size of the statistic, for example since IP Addresses have a byte size of 32, the registers will also be a byte size of 32 in order to store the data. The size of the registers will be 65536, which will be explained later on.

In order to uniquely identify flows, or streams of data that contain the same source/destination IP address, and source/destination port, we must use a hashing algorithm. Luckily, P4 has innate function to hash these values for us, specifically the hashing algorithm, CRC16. In doing this the function returns a unique value specific to that flow, in other words a flowID. This will be used as the primary way to identify and index into registers.

The function will specifically spit out a max value of 65536 or 2^16 due to the nature of the hashing algorithm in use. A standard forwarding table will be used, and applied in the apply block. Otherwise, the program will compute the hash of the packet entering the network device. If the unique hash value, the flowID has already been generated and already exists, then it will amend the start and end time of that flow, as well as the total amount of unidirectional traffic.. Source, destination IP Address and Port stays constant. Otherwise, we can assume that this is a brand new flow. Simply add the data in to the registers and indicate that the flow now exists.

Workflow of a P4 Program

After compiling a P4 program, two files are generated. A data plane configuration file that implements forwarding logic that includes instructions and resource mappings for the target. Then it generates runtime APIs that are used by the control plane to interact with the data plane. For example adding and removing entries from match-action tables or reading/writing the state of objects. This allows users to manipulate tables and objects.