## 5 Proof-of-Concept Results
### The P4 Algorithm  
Our P4 program consists of three primary stages: (1) the parser stage which is responsible for interpreting incoming bits from bundles and representing them in structured fields, (2) the match-action pipeline which is where the translation logic is applied and fields are modified, \"digest\" data about the bundle is tracked to be later sent to the controller, and egress ports are determined using match-action tables that are initialized by a controller, and (3) the deparser stage which sends the digest data to the controller, recalculates and updates checksums, and emits the bundle out the egress port. Note that as shown in Figure 8, our parser was restricted to only handle the sets of protocols required for our experimental setup, i.e., Ethernet, IPv4, UDP, BPv6, and BPv7, as parsing other protocols such as TCP. LTP. and IPv6 were out of the scope of this work. The details of these individual stages are explained here, with an overview of these steps shown in Algorithm 1 (Code to be made available pending release process). After Ethernet, IPv4, and UDP are appropriately parsed, in Step 1.4, our program uses the lookahead functionality to examine the upcoming 8-bits of data, which sends the parser to either the BPv6 parsing (if 0x06 is seen), or BPv7 parsing (if 0x9F is seen, the start code of a CBOR indefinite-length array). Implementing Step 1.5, where our parser actually interprets bundle bits and stores them into P4 fields, is where we faced the most issues due to the variable-width nature of BPv6 and BPv7 bundles; we explain this further in Section 5.2. As a result of these issues, the P4 fields and headers are fixed-width and are in a specific format that is not generalizable to all possible bundle configurations; a diagram of the bundles that our program is able to accept is shown in Figures 9 and 10. After Step 1.5 is completed, the P4 program sets a flag that communicates to future stages of the P4 program which version of the bundle that was ingested. Step 1.7 marks the end of  
Figure 8: Parser state machine for Bundle Translator. The parser stage of a P4 program is coded as a series of states that are transitioned between using data from fields of the packet being parsed. Figure 7: Physical configuration of setup. the parser stage where the bundle is accepted and the bundle is sent to the match-action pipeline for further processing. If any of the previous steps experienced an issue in parsing a bundle, the bundle would be rejected and dropped. The match-action pipeline handles several important components for verifying parsing, initializing data to be sent to the SDN controller, modifying bundles, and applying logic received from the controller via match-action tables. Verifying the validity of bundle headers to ensure it was parsed or not parsed, Step 2.1, is something that in actuality happens throughout the various next steps of match-action pipeline as various fields are attempted to be used, but it is placed first for simplicity. Step 2.2 is responsible for storing any data that should be sent to the controller in a P4 struct, this can include data from any fields such as the bundle age or EIDs. Step 2.3 is where translation begins, new BP headers are declared (BPv7 if BPv6 was ingested into the switch, or vice versa), and data are transferred from one version of the BP headers to the new BP headers. Once the new headers are ready, in Step 2.4, the old BP headers are invalidated and the new BP headers are validated so that the translated bundle will be sent (An implementation dealt to note is that only the headers for the payload data are reused for both BPv6 and BPv7, so that they have no need to be invalidated and copied over). Then, the length fields in the IPv4 and UDP headers are updated to accurately reflect the new bundle size (since BPv6 and BPv7 headers have different sizes). Lastly, an egress port for this bundle is determined by matching data to the match-action table entries; this table is filled by the SDN controller.