Re-read newly written part

This commit is contained in:
Nico Schottelius 2019-08-22 15:01:14 +02:00
parent a0cf251917
commit dac376e8da

View file

@ -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.