# P4-KBR: A Key-Based Routing System for P4-Programmable Networks
## 5 P4-KBR Implementation  
### Data Plane  
The design of the P4-KBR data plane is presented in Figure 5. After being parsed in the _Ingress Parser_ module, packets are passed to the _Ingress Pipeline_ module, where  
Figure 4: Physical path implementation of a virtual link using MPLS technology.  
four match-action tables are defined: the _join_process_ table, the _host_name_resolution_ table, the _key_routing_ table and the _mpls_forward_ table, as described below.  
In addition to the key-based routing mechanism itself, we define a joining of end-points mechanism and a distributed name resolution service to implement a host/service/content-centric communication service that makes use of the P4-KBR routing mechanism. The _join_process_ table and the _host_name_resolution_ table are used to implement both mechanisms. Regarding the first one, when an end-point wants to join the system, it sends a specific _join_packet_ (a packet whose source key is the vid of the joining end-point, and the destination is the vid of the switch to which it is connected). By matching the _join_process_ table, a _join_packet_ will be identified, and then it will be sent to the controller (_send_to_cpu_() action) so that it can install the _host_name_resolution_ table entries required by the name resolution mechanism. This second mechanism allows the communication between end-points just needing to know the end-point's name and not its virtual identifier (see [4] for a detailed explanation of both mechanisms).  
As detailed in Section 4.3, the key contribution of this paper is focused on the network-level key-based routing mechanism. The _key_routing_ table and the _mpls_routing_ table are used for this purpose, being populated by the controller after obtaining the set of equivalent ranges and forwarding actions. As can be seen in the figure, the set of possible actions as result of a _key_routing_ table matching are the forwarding to the next virtual node by setting of the required egress_port (if the next hop in the key-based routing path is a physically connected node) or the forwarding to the next virtual node through the corresponding mpls tunnel (if the next hop in the key-based routing path is not a physically connected node). As can be deduced, the _mpls_forwarding_ table is used to maintain the required mpls tunnels.  
Turning to the _join_process_ table, the _send_to_cpu_ action invokes the forwarding of the _join_packet_ to the controller using the P4 Runtime API. Packets sent to the defined CPU_PORT within the P4 device are used by the P4 Runtime server to populate the Packetn message that will be sent to the controller. Here, the standard annotation _@controller_header(\"packet_in\")_ is used to defined the Packetn message metadata fields, in this case just the original ingress port whereby the packet was received.  
Figure 5: Tables and actions in the ingress pipeline.  
Any additional table is defined in the egress pipeline. During the egress pipeline, the egress parser serializes the header objects back into the packet, and then the packet is forwarded through the corresponding output port which is defined by the egress port value.