Vyatta NOS documentation

Learn how to install, configure, and operate Vyatta Network Operating System (Vyatta NOS), which helps to drive our virtual networking and physical platforms portfolio.

Show Page Sections

Dataplane API

The dataplane API is made up of different libraries.

Pipeline plugin API

The dataplane pipeline plugin API is used by the dataplane pipeline framework to talk to plugins. The plugins are loaded at runtime before constructing the dataplane's pipeline graph.  

The feature plugin layer is designed to allow features for the dataplane to be plugged in without having to modify the core dataplane code. Plugin libraries are installed in a known location and the dataplane will search for them when it starts up.  

The pipeline is the part of the feature plugin that interacts with packets. When a packet is received it enters the pipeline where it makes its way through the nodes in a graph. Each node processes the packet before passing it on to the next node

After the packet reaches an output node it is finished. The graph is constructed at dataplane start, using all the builtin nodes plus any that are added by the feature plugins. 

FAL plugin API

The forwarding abstraction layer, FAL, is designed to provide abstraction around a forwarding layer that is independent from the dataplane forwarding path. This is typically a hardware forwarding chip, but can be used to implement specialized software forwarding paths too.

The dataplane is referred to as the application and the implementation of the FAL API that talks to the specialized forwarding path/hardware forwarding chip is referred to as the FAL plugin. The plugin is a shared object library that lives within the application address space. 

In order to fit with the model that dataplane-type interfaces are backed by a DPDK port and to provide a high-speed punt path, switchports are correspondingly backed by a DPDK port and it is expected that the FAL plugin react to operations on the DPDK port as driven by the dataplane accordingly and in preference to, possibly conflicting, FAL operations. 

A hardware platform may choose to implement a punt path via one or more DPDK-supported host-CPU-connected interfaces in order to provide a high-speed punt path. In this case, traffic from all switch ports will be multiplexed over the interface(s) and as such requires a header that gives the original input interface.

The format of this header is dependent on the switch chip and its FAL plugin. Similarly, traffic being sent out of a switch-port will be multiplexed over the same DPDK-supported host-CPU-connected interface and will need to have a header inserted that identifies the output interface. These facilities are known as the RX/TX framers.