## 4 Proof-of-Concept Background and Setup
### Programmable Data Planes and P4  
Traditional SDN network operators configure their control plane to manage the behavior of vendor-defined networking switches (the data plane). However, there are no vendor-defined switches that can understand BP. Therefore, processing bundles natively within hardware and creating a SDDTN node requires the capability of a relatively new networking paradigm for network operators: data plane programming. With data plane programming, network operators are able to customize the data plane for their specific use case, e.g., to program a data plane that is able to understand custom protocols. One of the data plane programming languages available is Programming Protocol-independent Packet Processors (P4). With the P4 language, code can be written to program data plane behavior and at compile-time a control plane Application Programming Interface (API) will be generated. Programs written in the P4 language can be compiled for a variety of targets, e.g., ASICs, FPGAs, and software switches, and have been used to implement a large variety of novel networking application in topics such as traffic management and congestion control, routing and forwarding, enabling machine learning, and network security [32]. For a brief overview of how the P4 language works and P4-specific terminology see Appendix A (Also see Available online: [[https://p4.org/learn/](https://p4.org/learn/)]([https://p4.org/learn/](https://p4.org/learn/)) (accessed on 1 September 2022) for more learning resources). The P4 language's ability to configure both the data plane and control plane, its open source nature and large ecosystem, and its proven role in creating novel networking applications makes it an attractive choice as a tool to implement a SDDTN node. However, P4 has a known limitation in handling variable-width fields that makes applying it to BP, a protocol with mostly variable-width fields, a non-trivial task (For more information, see Sections 7.1.6.4, 7.2.2, 8.9, and 13.8.2 of version 1.2.3 of the P4\({}_{16}\) language specification). A P4 program treats packets as a collection of headers which are user-defined and encompass the various header types that the user expects to handle, e.g., Ethernet headers and IP headers. Headers are a collection of user-defined fields, where a field is typically declared as a primitive bit<w> data type with a pre-defined field size of w bits. For example, an IPv4 source address field would be declared as a bit<32>. For packet fields that have variable-widths, there is a varbit<w> data type with a user-defined upper bound size of w bits. There are a restricted set of operations that can be performed on varbits that make it difficult to work with compared to fixed-width bitstrings: a varbit<w> can be assigned to another varbit<w> if w is the same, and varbits can be compared for equality [33]. Notable operations that are not currently possible include the ability to read bits from a varbit, modify bits within a varbit, and the ability to manually initialize a varbit [34]. These restrictions are not ideal for protocols like BP that rely on variable-width fields, however there are discussions in the P4 Language Design Working Group to add more operations to varbit types in future iterations of the language [34]. For handling variable-width fields, the suggested alternative to varbits is to declare several fixed-width headers, one each for every possible width that is expected to be encountered [35]. This works because fixed-width fields are less restricted in the operations that can be applied, however this increases the amount of coding overhead in order tomanually handle all possible cases. A case study for what this looks like in practice can be seen in the work done to implement Meta4, a P4 application to monitor Domain Name System (DNS) traffic in the data plane for the Intel Tofino target [36]. Domain names have variable widths which proved to be a challenge as they had to account for both hardware memory constraints along with the P4 restrictions.