# P4-KBR: A Key-Based Routing System for P4-Programmable Networks
## 5 P4-KBR Implementation
### Control Plane  
Our proposal uses ONOS to implement the SDN control plane. ONOS controller allows programmers to use existing pipeline-agnostic apps (apps that program the network using pipeline unaware abstractions known as FlowObjectives) but also to write and use new pipeline-aware apps (apps that are dedicated for a given dataplane). In this work, we used the built-in network discovery service to obtain the network information, which is necessary to configure the P4 switches adequately. We also coded a pipeline-aware app called the P4-KBR-system app, which implements the P4-KBR-based communication system. The P4-KBR-system app is described in Figure 6. The initialization module obtains an unique application ID and adds a packet processor to the list of packet processors in order to process the received PacketIns. The P4 NodeDB maintains information about each network element (mainly, its virtual identifier, predecessor and finger table), information that is used by the P4-KBR module and the Inbound packet processing module to configure the tables defined in the ingress pipeline of each P4-switch. The inbound packet processor module processes the incoming packets. In particular, this module processes the PacketIn messages containing the _join_packets_ sent by the P4-switches during the end-point joint procedure. After obtaining the _join_packet_, this module will include an entry in the _key_routing_ table of the P4-switch that generates the PacketIn to enable it to forward packets to the joined end-host.It will also include an entry in the _host_name_resolution_ table of the P4-switch in charge of preforming the end-point name resolution. The last module implements the core of the P4-KBR functionality. The following tasks are executed for each node in the network topology. Firstly, a _join_process_ table entry is inserted to allow the network device to detect any _join_packet_ sent by a connected end-point, leading to the sending of a PacketIn to the controller. Next, this module will make use of the discovered network topology (obtained by the build-in ONOS service) to update the P4 Node database with the information required to obtain the wildcarded ranges and the associated actions. The last step is to translate the obtained ranges into the set of required _mps_forward_ table entries and _key_routing_ table entries that are necessary to implement the forwarding actions associated to each range. Although ONOS was designed considering fixed-function dataplanes and fixed and well-known forwarding behaviors, the integration of P4 programs with ONOS was possible thanks to the develop of the PI Framework (Program/Pipeline Independent Framework) (see Figure 7). In order to allow ONOS to manage and deploy a pipeline on the devices, it is necessary to define an element called _ONOS pipecont_ that, in fact, is an ONOS app (.oar,  
Figure 6: Description of the pipeline-aware P4-KBR-SYSTEM app. ONOS app archive) that includes some required Java files, the P4 compiled output and the P4 Info file. The PipelineInterpreter is the ONOS driver behavior used to map ONOS internal data structures (i.e., OpenFlow-derived ONOS header/actions) to P4 program-specific entities. In our proposal, Packet-In messages are used to implement the join process. Therefore, by implementing _InterpreterImpl.java_, the ONOS metadata name of the import is adapted to be consistent with our P4 program. In addition, related to the pipeline-specific behaviour, _PipeconfLoader.java_ and _PipelinerImpl.java_ are included. The first one, _PipeconfLoader.java_, is a component that registers the pipeconf at app activation. _PipelinerImpl.java_ is an implementation of Pipeline driver behavior. The Pipelineer is a wrapper used to map forwarding objectives defined by built-in apps to pipeline-aware P4 tables. As said before, we make use of the built-in lldpprovider app to discover the topology information.