Why NPL?

Network Programming Language (NPL)

Mohan Kalkunte

With the decoupling of the control plane from the data plane, it is now possible to configure the network elements from a SDN Controller. OpenFlow was the first attempt to describe the data plane of a switch using table semantics. In the last few years, there has been effort to define the data plane functionality in a high-level language. One such language is P4 which is an open source language which continues to evolve.

At Broadcom, network switches have evolved from a fixed function to highly configurable devices. These configurable devices provide significant number of features with a highly efficient pipeline architecture. Broadcom’s Trident family of switches provides a feature rich set of capabilities for Enterprise and Campus data center. The Trident 3 series family is semi-programmable with a tool chain that is factory enabled. This allows Broadcom to introduce new features with a different flex code and not incur the long ASIC development cycle.

The DNX line of devices have long supported programmability starting from the Petra devices since 2010. With every generation of the DNX packet processor, the programmability aspect of the pipeline has improved with Jericho2 device being fully programmable.


Figure: XGS/DNX Device Programmability Progression

Following Trident 3, the next step in the XGS family was to build a highly efficient and programmable pipeline for data plane and instrumentation which led to the recently announced Trident 4. Existing languages did not provide the rich construct needed to express XGS and DNX architectures. Expressing the intent of the data plane for efficient packet processing led us to develop a new programming language called NPL (Network Programming Language) that can efficiently address multiple silicon architectures for switching, routing and appliances.

The key goal of NPL was to have a rich set of constructs to enable highly efficient pipeline architecture. By this we mean the cost of providing programmability over a fixed function should be minimal for the same feature set and table scale. In addition, the need to define the language constructs at a faster pace without being tied to an external standards organization was also a key concern.

NPL at a high level provides the following capabilities: 1) Basic Constructs 2) Advanced Constructs 3) Special functions 4) Instrumentation and 5) Runtime programmability.

Figure: NPL Constructs

Figure: NPL Constructs

Decoupling the action from table lookup and using functions to express complex logic makes for efficient silicon implementation. Key advanced constructs such as multiple table lookups and executing them in parallel is important to deliver a low latency pipeline while delivering high feature capacity. The ability to resolve multiple table lookup decisions based on a programmable strength gives user the freedom to express the capability in a flexible manner. Special functions are like engines which are hardware optimized for specialized functions such as hashing, LAG resolution etc. The inputs to these functions can be defined in NPL by the user and the outputs can be flexibly interpreted by the user and can be expressed in NPL. Runtime programmability is especially important for instrumentation which allows to dynamically attach objects of interest to counters at runtime.

The NPL language is completely open and more information can be found at The NPL front-end tool chain is available on GitHub. Currently, NPL is supported on Trident 4 and Jericho 2 devices.