From dac376e8da50657acea4500684c9b38cbc316af6 Mon Sep 17 00:00:00 2001 From: Nico Schottelius Date: Thu, 22 Aug 2019 15:01:14 +0200 Subject: [PATCH] Re-read newly written part --- doc/Results.tex | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/Results.tex b/doc/Results.tex index e9a59c4..dfcc1cd 100644 --- a/doc/Results.tex +++ b/doc/Results.tex @@ -28,7 +28,7 @@ is more feature rich. For this thesis the parsing capabilities of P4 were adequate. However P4, at the time of writing, cannot parse ICMP6 options in general, as the upper level protocol does not specify the number -of options that follow and parsing of an undefined number +of option blocks that follow. Parsing of an unspecified number of 64 bit blocks is required, which P4 does not support. The language has some limitations on the placement of @@ -235,7 +235,7 @@ the controller and vice versa. As we consider both features to be portable, we also consider the NAT64 session feature to be portable. P4/NetFPGA does not offer calculating the checksum over the payload -and thus calculating the checksum over the payload to create +and thus calculating the checksum over the payload creating a reply for an neighbor solicitation packet is not possible. However, as the payload stays the same as in the request, our delta based checksum approach can be reused in this situation. With the same @@ -249,7 +249,7 @@ any changes. While the P4/NetFPGA target currently does not support accessing the payload or creating checksums over it, there are two possibilities to extend the platform: either by creating an HDL module or by -modify the generated the PX +modifying the generated PX program.~\cite{schottelius:_exter_p4_netpf} Due to the existing code complexity of the P4/NetFPGA platform, using the HDL module based approach is likely to be more sustainable.