NS4: A P4-driven Network SimulatorChengze Fan, Jun Bi, Yu Zhou, Cheng Zhang, Haisu Yu∗

Tsinghua University

ABSTRACTWe present NS4, a P4-driven network simulator, which is, to thebest of our knowledge, the �rst research e�ort in applying P4 tonetwork simulation. Key features of NS4 include (1) eliminationof laborious and redundant work for developing internal modelsof the simulator; (2) direct migration from simulation code to real-world P4 devices; (3) simulation of P4-enabled devices and networksystems; (4) seamless compatibility with ns-3; (5) better scalabilityover other P4 behavioral model validation tools.

We proposed and prototyped NS4 by integrating a P4 behavioralmodel in ns-3, and evaluated its e�ectiveness by a user case study.Source codes and examples of NS4 are publicly available at https://ns-4.github.io/

CCS CONCEPTS•Networks→Network simulations;Programmable networks;

KEYWORDSP4, simulationACM Reference format:Chengze Fan, Jun Bi, Yu Zhou, Cheng Zhang, Haisu Yu. 2017. NS4: A P4-driven Network Simulator. In Proceedings of SIGCOMM Posters and Demos’17, Los Angeles, CA, USA, August 22–24, 2017, 3 pages.DOI:

1 INTRODUCTIONNetwork simulation in a computer-based environment is widelyused in nearly every aspect of network research, education andindustry. Network simulators are typically used for two purposes:validating experimental protocols and testing device design cor-rectness before further production. For the latter, engineers arerequired to �rst develop a behavioral model of the device as an in-ternal module inside the simulator and then plug it in a large-scalenetwork to test if the behavioral model is well-behaved and robust.During this process, however, traditional network simulators havesome signi�cant drawbacks :∗Chengze Fan, Jun Bi, Yu Zhou, Cheng Zhang, and Haisu Yu are with Institute forNetwork Sciences and Cyberspace, Tsinghua University. Chengze Fan and Haisu Yu arealso with Department of Electronic Engineering, Tsinghua University. Jun Bi, Yu Zhou,and Cheng Zhang are with Department of Computer Science, Tsinghua University,and Tsinghua National Laboratory for Information Science and Technology (TNList).This research is supported by National Key R&D Program of China (2017YFB0801701),the National Science Foundation of China (No.61472213) and Tsinghua UniversityInitiative Scienti�c Research Program. Jun Bi is the corresponding author.

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor pro�t or commercial advantage and that copies bear this notice and the full citationon the �rst page. Copyrights for components of this work owned by others than ACMmust be honored. Abstracting with credit is permitted. To copy otherwise, or republish,to post on servers or to redistribute to lists, requires prior speci�c permission and/or afee. Request permissions from permissions@acm.org.SIGCOMM Posters and Demos ’17, Los Angeles, CA, USA© 2017 ACM. 978-1-4503-5057-0/17/08. . . $15.00DOI:

D1: Time-consuming and laborious work is unavoidable to de-velop the behavioral model in the simulator. Development of thebehavioral model requires intimate knowledge of the simulatorimplementation. However, it is frustrating that the learning curveof the simulator implementation is rather steep.

D2: Internal modules of network simulators can hardly be portedto real-world networks. Most of them are developed in generalpurpose languages (like C++) based on libraries provided by thisparticular simulator. Therefore simulation codes are distinct fromprototype or production version running on real devices (for ex-ample ASICs or FPGAs). As a result, simulation codes cannot bedirectly migrated to products, leading to both wastes of e�orts andhazards of incomplete or incorrect simulation.

D3: With an optimistic outlook of P4 [1], we believe there is anurgent need for tools to validate P4 design correctness and evaluateP4 program e�ciency. As far as we know, there is no networksimulator supporting simulation of P4-enabled networks.

In this paper, we step forward to incorporate P4 in the state-of-the-art network simulation platform ns-3 [2]. In order to solvethese problems and satisfy practical requirements of simulatingprogrammable networks, we present NS4, a P4-driven networksimulator, which is, to the best of our knowledge, the �rst researche�ort on applying P4 to network simulation.

For one thing, we notice the root of D1, D2 is that the behavior ofa device is tightly coupled with the implementation in ns-3. There-fore laborious work of redundant development and code migrationis unavoidable. P4 as a target independent language decouples be-havior of devices and ns-3 implementation. Developers can alwayswrite P4 programs to rapidly de�ne a particular behavior regardlessof simulator implementation, simulate on NS4 and deploy them onP4 targets (CPU, GPU, FPGA, etc.) with almost no overhead andmigration e�ort. (solution of D1, D2). For another, Integrating P4in ns-3 makes ns-3 able to simulate a P4 target where P4 programsrun. This integration facilitates P4 program behavioral validationand performance evaluation. (solution of D3)

NS4 also stands out from current P4 behavioral validation tools,such as bmv2 [3] and Mininet [4] with advantages as follows: (1)Seamless integration with ns-3, which provides a complete simu-lation toolset and community support. (2) Support for ultrahighspeed connection: The state-of-art P4 target ’Barefoot Ti�no’ claimsto have a 6.5Tb/s transfer speed [5], however, Mininet running ona 3GHz CPU can only switch about 10 Gbps of simulated tra�c[6]. Experiments with real tra�c is di�cult to bridge this huge gap.(3) Better scalability: a commercial PC can simulate a network ofextremely large size and long virtual simulation time, as long asgiven enough memory and simulation execution time.

2 DESIGN OF NS4Design Overview. As shown in Figure 1, NS4 is divided into con-trol plane half and data plane half, which collectively simulate acomplete network system with the programmable data plane (PDP)

105

10.1145/3123878.3132002

10.1145/3123878.3132002

SIGCOMM Posters and Demos ’17, August 22–24, 2017, Los Angeles, CA, USA C. Fan, J. Bi, Y. Zhou, C. Zhang, H. Yu

Parser

P4 Pipeline

P4 Programs

Match Action Tables

De-parser

Agent Model P4 PipelineConfigurator

Programmable Data Plane Model

802.11 a

CSMA

LTE

Bluetooth Channel M

anager

Populate Tables Defines Functions

Packet Path Controller Path P4 Binary PathModel Component

Controller Framework

802.11 a

CSMA

LTE

Bluetooth

Controller Model

Workflow

Bridge NIC

Controller Application

Bridge Interface

… …2

3

Network Operating System

Input Program

Channel M

anager

Packet Decapsulator

1

Packet Encapsulator

ProtocolStack

Control Plane Data Plane

1

Outside NS4

Real-world ControllerApplication

Figure 1: NS4 design overview.

. Developers simulate a controller by instantiating a ‘ControllerModel‘ and simulate a P4 device by instantiating a ‘ProgrammableData Plane Model‘. Traditional devices like routers or switches arealso supported in NS4 but omitted in the �gure.

Work�ow. The procedures to simulate a P4-enabled networkare shown as numbers in Figure 1 : (1) con�gure the behavior ofdata plane by inputting a compiled P4 program to the P4 pipelinecon�gurator; (2) create control plane and populate table entries toP4 devices, by either implementing a controller application insidethe controller model or simply running an arbitrary controller appli-cation (such as ONOS) outside NS4; (3) add ports (maybe connectedto various channels) to the PDP model. At this point, we have thisPDP model con�gured and functional as a P4 device. Next stepsare building network topology, installing applications at terminalnodes and triggering the simulator.

Control Plane. A controller does not directly manipulate tableentries in P4 devices via function calls. Instead, it is created as anindependent network component and populates tables to P4 devicesvia packets transmission, just in the real-world way. Also, we noticethe fact that when focusing on simulating P4 devices, developinga controller application just to populate table entries can be anarduous but unnecessary work, so we enable the controller modelto communicate with a controller application running outside NS4process. This bridge connecting from P4 devices in NS4 process andcontrollers outside NS4 process eliminates unnecessary work ofdeveloping controller applications for simulation environment andalso provides a method of testing general controller applications.

Programmable Data Plane. Unlike �xed-function devices, P4devices need to set up simulation environment to de�ne their behav-iors (see work�ow paragraph above). The core of the PDP model isa complete P4 pipeline which contains a parser, match-action tables,a deparser and bu�ers amid them. We then add a channel managerand a packet de/encapsulator beyond link layer to mask details ofunderlying channels and provide a uniform interface for the P4pipeline. The channel manager expands the scope of simulatableP4 devices, from devices connected via NICs to ones connected viavirtually any channel.

P4 Node Server

Figure 2: Topology of the demo.

Note that the path from P4 devices to a controller is not shown inthe �gure for simplicity, but this can be easily established throughthe reverse controller path.

3 DEMOIn order to further demonstrate the e�ectiveness and convenienceof NS4, We simulate a user case of a data center network miniature,as depicted in Figure 2. The data center network is scalable andconsidered hard to simulate by real tra�c because of its complexstructure and high performance infrastructure, not to mentionintroducing P4 into simulation can bring a considerable overhead.We hope to demonstrate the scalability of NS4 by including a largenumber of P4 nodes in the demo.

During demonstration, we plan to demonstrate the detailedprocess of simulating a data center network as described aboveusing a laptop. On site, we will showcase at length how to applyP4 codes to NS4 PDP models and how to conduct simulation basedon them. We will also exhibit performance comparison betweenNS4 and mininet, especially in their scalability of network size andtransfer speed.

106

NS4: A P4-driven Network Simulator SIGCOMM Posters and Demos ’17, August 22–24, 2017, Los Angeles, CA, USA

REFERENCES[1] Pat Bosshart, Dan Daly, Glen Gibb, Martin Izzard, Nick McKeown, Jennifer Rexford,

Cole Schlesinger, Dan Talayco, Amin Vahdat, George Varghese, and David Walker.P4: Programming protocol-independent packet processors. SIGCOMM Comput.Commun. Rev., 44(3):87–95, July 2014.

[2] ns-3. https://www.nsnam.org/.[3] P4 Language Consortium. P4-bmv2. Website. https://github.com/p4lang/

behavioral-model.[4] Bob Lantz, Brandon Heller, and Nick McKeown. A network in a laptop: Rapid

prototyping for software-de�ned networks. In Proceedings of the 9th ACM SIG-COMM Workshop on Hot Topics in Networks, Hotnets-IX, pages 19:1–19:6, NewYork, NY, USA, 2010. ACM.

[5] Barefoot Networks. https://barefootnetworks.com/media/white_papers/Barefoot-Worlds-Fastest-Most-Programmable-Networks.pdf. (Accessed on07/09/2017).

[6] Bob Lantz et al. What are mininet’s limitations? https://github.com/mininet/mininet/wiki/Introduction-to-Mininet#limits. (Accessed on 07/09/2017).

107