|
|
|
|
@ -11,8 +11,62 @@ software solutions as well as for our hardware implementation. As the
|
|
|
|
|
objective of this thesis was to demonstrate the high speed |
|
|
|
|
capabilities of NAT64 in hardware, no benchmarks were performed on the |
|
|
|
|
P4 software implementation. |
|
|
|
|
% ok |
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\section{\label{results:p4}P4 based implementations} |
|
|
|
|
All planned features could be realised with P4 and a controller. |
|
|
|
|
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 64 bit blocks is required. |
|
|
|
|
|
|
|
|
|
The language has some limitations on where the placement of |
|
|
|
|
conditional statements (\texttt{if/switch}).\footnote{In general, |
|
|
|
|
if and switch statements in actions lead to errors, |
|
|
|
|
but not all constellations are forbidden.} |
|
|
|
|
Furthermore P4/BMV2 does not support for multiple LPM keys in a table, |
|
|
|
|
however it supports multiple keys with ternary matching, which is a |
|
|
|
|
superset of LPM matching. |
|
|
|
|
|
|
|
|
|
When developing P4 programs, the reason for incorrect behaviour we |
|
|
|
|
have seen were checksum problems. This is in retrospective expected, |
|
|
|
|
as the main task our implementation does is modify headers on which |
|
|
|
|
the checksums depend. In all cases we have seen Ethernet frame |
|
|
|
|
checksum errors, the effective length of the packet was incorrect. |
|
|
|
|
|
|
|
|
|
The tooling around P4 is somewhat fragile. We encountered small |
|
|
|
|
language bugs during the development~\cite{schottelius:github1675}, |
|
|
|
|
\ref{appendix:expressionbug} |
|
|
|
|
or found missing features~\cite{schottelius:github745}, |
|
|
|
|
~\cite{theojepsen:_get}: it is at the moment impossible to retrieve |
|
|
|
|
the matching key from table or the name of the action called. Thus |
|
|
|
|
if different table entries call the same action, it is impossible |
|
|
|
|
within the action, or if forwarded to the controller, within the |
|
|
|
|
controller to distinguish on which match the action was |
|
|
|
|
triggered. This problem is very consistent within P4, as not even the |
|
|
|
|
matching table name can be retrieved. While these information can be |
|
|
|
|
added manually as additional fields in the table entries, we would |
|
|
|
|
expect a language to support reading and forwarding this kind of meta |
|
|
|
|
information. |
|
|
|
|
|
|
|
|
|
While in P4 the P4 code and the related controller are tightly |
|
|
|
|
coupled, their data definitions are not. Thus the packet format |
|
|
|
|
definition that is used between the P4 switch and the controller has |
|
|
|
|
to be duplicated. Our experiences in software development indicate |
|
|
|
|
that this duplication is a likely source of errors in bigger software |
|
|
|
|
projects. |
|
|
|
|
|
|
|
|
|
The supporting scripts in the P4 toolchain are usually written in |
|
|
|
|
python2. However python2 ``is |
|
|
|
|
legacy''~\cite{various:_shoul_i_python_python}. During development |
|
|
|
|
errors with unicode string handling in python2 caused |
|
|
|
|
changes to IPv6 addresses.~\ref{appendix:p4:python2unicode} |
|
|
|
|
|
|
|
|
|
P4os - reusable code |
|
|
|
|
|
|
|
|
|
% idomatic problem: Security issue: not checking checksums before |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
****** TODO IPv6 udp -> IPv4 |
|
|
|
|
- Got 4-5 tuple ([proto], src ip, src port, dst ip, dst port) |
|
|
|
|
@ -25,54 +79,6 @@ allows us to closest resemble any other translation implementation.
|
|
|
|
|
Only supporting /96, not other embeddings as described in |
|
|
|
|
section \ref{background:transition:prefixnat}. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
All planned features could be realised with P4 and a controller. |
|
|
|
|
The language has some limitations on where if/switch statements can be |
|
|
|
|
used.\footnote{In general, if and switch statements in actions lead to |
|
|
|
|
errors, but not all constellations are forbidden.} |
|
|
|
|
|
|
|
|
|
For this thesis the parsing capabilities of P4 were adequate. However |
|
|
|
|
P4 at the time of writing cannot parse ICMP6 options, as the upper |
|
|
|
|
level protocol does not specify the number of options that follow and |
|
|
|
|
parsing of 64 bit blocks is required. |
|
|
|
|
|
|
|
|
|
P4/BMV2 does not support for multiple LPM keys in a table, however it |
|
|
|
|
supports multiple keys with ternary matching. |
|
|
|
|
|
|
|
|
|
When developing P4 programs, the reason for incorrect behaviour was |
|
|
|
|
most often found in checksum problems. If frame checksum errors where |
|
|
|
|
displayed by tcpdump, usually the effective length of the packet was |
|
|
|
|
incorrect. |
|
|
|
|
|
|
|
|
|
FIXMe: IPv6: NDP: not easy to parse, as unknown number of following fields |
|
|
|
|
|
|
|
|
|
The tooling around P4 is still fragile, encountered many bugs |
|
|
|
|
in the development.~\cite{schottelius:github1675} |
|
|
|
|
|
|
|
|
|
or missing features (~\cite{schottelius:github745}, |
|
|
|
|
~\cite{theojepsen:_get}) |
|
|
|
|
|
|
|
|
|
Hitting expression bug (FIXME: source) |
|
|
|
|
|
|
|
|
|
1) Impossible to retrieve key from table: LPM: addr + mask -> addr and |
|
|
|
|
mask might be used in controller |
|
|
|
|
|
|
|
|
|
2) retrieving information from tables : no meta information, don't |
|
|
|
|
know which table matched |
|
|
|
|
|
|
|
|
|
3) type definitions separate Code sharing (controller, switch) |
|
|
|
|
|
|
|
|
|
No switch in actions, No conditional execution in actions |
|
|
|
|
|
|
|
|
|
Not directly related to P4, but supporting scripts are usually written in python2, however python2 |
|
|
|
|
handles unicode strings differently and thus effects like an IPv6 |
|
|
|
|
address ``changing'' happen. ~\cite{appendix:p4:python2unicode}. |
|
|
|
|
|
|
|
|
|
P4os - reusable code |
|
|
|
|
|
|
|
|
|
idomatic problem: Security issue: not checking checksums before |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\subsection{\label{Results:BMV2}BMV2} |
|
|
|
|
The software implementation of P4 has most features, which is |
|
|
|
|
@ -408,11 +414,43 @@ Jool kernel module
|
|
|
|
|
Integration with iptables |
|
|
|
|
Requires routing |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\section{\label{results:benchmark}NAT64 Benchmarks - FIXME: explain |
|
|
|
|
numbers} |
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\subsection{\label{results:benchmark:design}Benchmark Design} |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.5]{softwarenat64design} |
|
|
|
|
\centering |
|
|
|
|
\caption{Benchmark design for NAT64 in software implementations} |
|
|
|
|
\label{fig:softwarenat64design} |
|
|
|
|
\end{figure} |
|
|
|
|
We use two hosts for performing benchmarks: a load generator and a |
|
|
|
|
NAT64 translator. Both hosts are equipped with a dual port |
|
|
|
|
Intel X520 10 Gbit/s network card. Both hosts are connected using DAC |
|
|
|
|
without any equipment in between. TCP offloading is enabled in the |
|
|
|
|
X520 cards. Figure \ref{fig:softwarenat64design} |
|
|
|
|
shows the network setup. |
|
|
|
|
When testing the NetPFGA/P4 performance, the X520 cards in the NAT64 |
|
|
|
|
translator are disconnected and instead the NetPFGA ports are |
|
|
|
|
connected, as show in figure \ref{fig:netpfgadesign}. The load |
|
|
|
|
generator is equipped with a quad core CPU (Intel(R) Core(TM) i7-6700 |
|
|
|
|
CPU @ 3.40GHz), enabled with hyperthreading and 16 GB RAM. The NAT64 |
|
|
|
|
translator is also equipped with a quard core CPU (Intel(R) Core(TM) |
|
|
|
|
i7-4770 CPU @ 3.40GHz) and 16 GB RAM. |
|
|
|
|
The first 10 seconds of the benchmark are excluded to avoid the TCP |
|
|
|
|
warm up phase.\footnote{iperf -O 10 parameter, see section \ref{design:tests}.} |
|
|
|
|
\begin{figure}[h] |
|
|
|
|
\includegraphics[scale=0.5]{netpfgadesign} |
|
|
|
|
\centering |
|
|
|
|
\caption{NAT64 with NetFPGA benchmark} |
|
|
|
|
\label{fig:netpfgadesign} |
|
|
|
|
\end{figure} |
|
|
|
|
% ok |
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% ---------------------------------------------------------------------- |
|
|
|
|
\section{\label{results:benchmark}NAT64 Benchmarks - FIXME: explain numbers} |
|
|
|
|
We successfully implemented P4 code to realise |
|
|
|
|
NAT64~\cite{schottelius:thesisrepo}. It contains parsers |
|
|
|
|
for all related protocols (ipv6, ipv4, udp, tcp, icmp, icmp6, ndp, |
|
|
|
|
|
Nico Schottelius
3 years ago