2019-07-29 17:13:47 +00:00
\chapter { \label { results} Results}
%** Results.tex: What were the results achieved including an evaluation
%
2019-08-14 15:23:12 +00:00
This section describes the achieved results and compares the P4 based
implementation with real world software solutions.
We distinguish the software implementation of P4 (BMV2) and the
hardware implementation (NetFPGA) due to significant differences in
deployment and development. We present benchmarks for the existing
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.
% ----------------------------------------------------------------------
2019-08-15 13:33:08 +00:00
\section { \label { results:p4} NAT64 Overview - FIXME: verify numbers}
2019-08-14 15:23:12 +00:00
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,
arp), supports EAMT as defined by RFC7757 \cite { rfc7757} and is
feature equivalent to the two compared software solutions
tayga\cite { lutchansky:_ tayga_ simpl_ nat64_ linux} and
jool\cite { mexico:_ jool_ open_ sourc_ siit_ nat64_ linux} .
Due to limitations in the P4 environment of the
NetFPGA\cite { conclusion:netfpga} environment, the BMV2 implementation
is more feature rich. Table \ref { tab:benchmark} summarises the
achieved bandwidths of the NAT64 solutions.
\begin { table} [htbp]
\begin { center} \begin { minipage} { \textwidth }
2019-08-14 15:54:07 +00:00
\begin { tabular} { | c | c | c | c |}
2019-08-14 15:23:12 +00:00
\hline
2019-08-14 15:54:07 +00:00
Solution & \multicolumn { 3} { |c|} { Parallel connections} \\
& 1 & 20 & 3 \\
2019-08-14 15:23:12 +00:00
\hline
2019-08-14 15:54:07 +00:00
Tayga & 3.02 & 3.28 & 2.85\\
2019-08-14 15:23:12 +00:00
\hline
2019-08-14 15:54:07 +00:00
Jool & 6.67 & 16.8 ?? & 20.5 udp?\\
2019-08-14 15:23:12 +00:00
\hline
2019-08-14 15:54:07 +00:00
P4 / NetPFGA & 9.28 & 9.29 & 9.29\\
2019-08-14 15:23:12 +00:00
\hline
\end { tabular}
\end { minipage}
2019-08-15 13:33:08 +00:00
\caption { NAT64 Benchmark (client: IPv6, server: IPv4), all results in Gbit/sec (\% loss)}
2019-08-14 15:54:07 +00:00
\label { tab:benchmarkv6}
2019-08-14 15:23:12 +00:00
\end { center}
\end { table}
2019-08-15 13:33:08 +00:00
During the benchmarks the client -- CPU usage
2019-08-14 15:54:07 +00:00
\begin { table} [htbp]
\begin { center} \begin { minipage} { \textwidth }
\begin { tabular} { | c | c | c | c |}
\hline
Solution & \multicolumn { 3} { |c|} { Parallel connections} \\
& 1 & 20 & 3 \\
\hline
Tayga & 3.36 & 3.29 & 3.11 \\
\hline
Jool & 8.24 & 8.26 & 8.29\\
\hline
P4 / NetPFGA & 8.43 & 9.29 & 9.29\\
\hline
\end { tabular}
\end { minipage}
2019-08-15 13:33:08 +00:00
\caption { NAT64 Benchmark (client: IPv4, server: IPv6), all results in Gbit/sec (\% loss)}
2019-08-14 15:54:07 +00:00
\label { tab:benchmarkv4}
\end { center}
\end { table}
2019-07-29 17:13:47 +00:00
2019-08-15 13:33:08 +00:00
Feature comparison
speed - sessions - eamt
can act as host
lpm tables
ping
ping6 support
ndp
controller support
2019-08-14 15:23:12 +00:00
% ----------------------------------------------------------------------
2019-07-31 08:50:30 +00:00
\section { \label { Results:BMV2} BMV2}
2019-08-15 13:33:08 +00:00
The software implementation of P4 has most features, which is
mostly due to the capability of checksumming the payload: Acting
2019-08-14 15:54:07 +00:00
as a ``proper'' participant in NDP, requires the host to calculate
checksums over the payload.
2019-08-12 10:13:59 +00:00
2019-08-15 13:33:08 +00:00
List of features:
\begin { table} [htbp]
\begin { center} \begin { minipage} { \textwidth }
\begin { tabular} { | c | c | c |}
\hline
\textbf { Feature} & \textbf { Description} & \textbf { Status} \\
\hline
Switch to controller & Switch forwards unhandeled packets to
controller & fully implemented\footnote { Source code: \texttt { actions\_ egress.p4} } \\
\hline
Controller to Switch & Controller can setup table entries &
fully implemented\footnote { Source code: \texttt { controller.py} } \\
\hline
NDP & Switch responds to ICMP6 neighbor & \\
& solicitation request (without controller) &
fully implemented\footnote { Source code:
\texttt { actions\_ icmp6\_ ndp\_ icmp.p4} } \\
\hline
ARP & Switch can answer ARP request (without controller) & fully
implemented\footnote { Source code: \texttt { actions\_ arp.p4} } \\
\hline
ICMP6 & Switch responds to ICMP6 echo request (without controller) &
fully implemented\footnote { Source code: \texttt { actions\_ icmp6\_ ndp\_ icmp.p4} } \\
\hline
ICMP & Switch responds to ICMP echo request (without controller) &
fully implemented\footnote { Source code: \texttt { actions\_ icmp6\_ ndp\_ icmp.p4} } \\
\hline
NAT64: TCP & Switch translates TCP with checksumming & \\
& from/to IPv6 to/from IPv4 &
fully implemented\footnote { Source code: \texttt { actions\_ nat64\_ generic\_ icmp.p4} } \\
\hline
NAT64: UDP & Switch translates UDP with checksumming & \\
& from/to IPv6 to/from IPv4 &
fully implemented\footnote { Source code: \texttt { actions\_ nat64\_ generic\_ icmp.p4} } \\
\hline
NAT64: & Switch translates echo request/reply & \\
ICMP/ICMP6 & from/to ICMP6 to/from ICMP with checksumming &
fully implemented\footnote { Source code: \texttt { actions\_ nat64\_ generic\_ icmp.p4} } \\
\hline
NAT64: Sessions & Switch and controller create 1:n sessions/mappings &
fully implemented\footnote { Source code:
\texttt { actions\_ nat64\_ session.p4} , \texttt { controller.py} } \\
\hline
Delta Checksum & Switch can calculate checksum without payload
inspection &
fully implemented\footnote { Source code: \texttt { actions\_ delta\_ checksum.p4} } \\
\hline
Payload Checksum & Switch can calculate checksum with payload inspection &
fully implemented\footnote { Source code: \texttt { checksum\_ bmv2.p4} } \\
\hline
\end { tabular}
\end { minipage}
\caption { P4 / BMV2 feature list}
\label { tab:p4bmv2features}
\end { center}
\end { table}
2019-08-12 10:13:59 +00:00
Responds to icmp, icmp6
2019-08-12 15:36:43 +00:00
ndp \cite { rfc4861}
2019-07-31 08:50:30 +00:00
arp
2019-08-12 10:13:59 +00:00
Fully functional host
Can compute checksums on its own.
2019-07-31 08:50:30 +00:00
2019-08-12 15:36:43 +00:00
focus on typical use cases of icmp, icmp6, the software implementation
supports translating echo request and echo reply messages, but does
not support all ICMP/ICMP6 translations that are defined in
RFC6145\cite { rfc6145} .
Stateful : no automatic removal
2019-08-15 13:33:08 +00:00
Session management not benchmarked, as it is only a matter of creating
table entries.
Jool and tayga are supported by
2019-07-31 08:50:30 +00:00
2019-08-14 15:23:12 +00:00
% ----------------------------------------------------------------------
2019-08-15 14:45:56 +00:00
\section { \label { results:netpfga} NetFPGA}
2019-08-15 13:33:08 +00:00
The reduced feature set of the NetPFGA implementation is due to two
factors: compile time. Between 2 to 6 hours per compile run. No
payload checksum
2019-08-14 15:23:12 +00:00
2019-08-15 14:45:56 +00:00
overview - general translation - not advanced features
% ----------------------------------------------------------------------
\subsection { \label { results:netpfga:features} Features}
2019-08-15 13:33:08 +00:00
\begin { table} [htbp]
\begin { center} \begin { minipage} { \textwidth }
\begin { tabular} { | c | c | c |}
\hline
\textbf { Feature} & \textbf { Description} & \textbf { Status} \\
\hline
Switch to controller & Switch forwards unhandeled packets to
controller & portable\footnote { While the NetFPGA P4 implementation
does not have the clone3() extern that the BMV2 implementation offers,
communication to the controller can easily be realised by using one of
the additional ports of the NetFPGA and connect a physical network
card to it.} \\
\hline
Controller to Switch & Controller can setup table entries &
portable\footnote { The p4utils suite offers an easy access to the
switch tables. While the P4-NetFPGA support repository also offers
python scripts to modify the switch tables, the code is less
sophisticated and more fragile.} \\
\hline
NDP & Switch responds to ICMP6 neighbor & \\
& solicitation request (without controller) &
portable\footnote { NetFPGA/P4 does not offer calculating the checksume
over the payload. However delta checksumming can be used to create
the required checksum for replying.} \\
\hline
ARP & Switch can answer ARP request (without controller) &
portable\footnote { As ARP does not use checksums, integrating the
source code \texttt { actions\_ arp.p4} into the netpfga code base is
enough to enable ARP support in the NetPFGA.} \\
\hline
ICMP6 & Switch responds to ICMP6 echo request (without controller) &
portable\footnote { Same reasoning as NDP.} \\
\hline
ICMP & Switch responds to ICMP echo request (without controller) &
portable\footnote { Same reasoning as NDP.} \\
\hline
NAT64: TCP & Switch translates TCP with checksumming & \\
& from/to IPv6 to/from IPv4 &
fully implemented\footnote { Source code: \texttt { actions\_ nat64\_ generic\_ icmp.p4} } \\
\hline
NAT64: UDP & Switch translates UDP with checksumming & \\
& from/to IPv6 to/from IPv4 &
fully implemented\footnote { Source code: \texttt { actions\_ nat64\_ generic\_ icmp.p4} } \\
\hline
NAT64: & Switch translates echo request/reply & \\
ICMP/ICMP6 & from/to ICMP6 to/from ICMP with checksumming &
portable\footnote { ICMP/ICMP6 translations only require enabling the
icmp/icmp6 code in the netpfga code base.} \\
\hline
NAT64: Sessions & Switch and controller create 1:n sessions/mappings &
portable\footnote { Same reasoning as ``Controller to switch''.} \\
\hline
Delta Checksum & Switch can calculate checksum without payload
inspection &
fully implemented\footnote { Source code: \texttt { actions\_ delta\_ checksum.p4} } \\
\hline
Payload Checksum & Switch can calculate checksum with payload inspection &
unsupported\footnote { To support creating payload checksums, either an
HDL module needs to be created or to modify the generated
the PX program.\cite { schottelius:_ exter_ p4_ netpf} } \\
\hline
\end { tabular}
\end { minipage}
\caption { P4 / NetFPGA feature list}
\label { tab:p4netpfgafeatures}
\end { center}
\end { table}
2019-08-14 14:18:27 +00:00
% ----------------------------------------------------------------------
2019-08-15 13:33:08 +00:00
\subsection { \label { results:netpfga:stability} Stability}
Two different NetPFGA cards were used during the development of the
thesis. The first card had consistent ioctl errors (compare section
\ref { netpfgaioctlerror} ) when writing table entries. The available
hardware tests (compare figures \ref { fig:hwtestnico} and
\ref { fig:hwtesthendrik} ) showed failures in both cards, however the
first card reported an additional ``10G\_ Loopback'' failure. Due to
the inability of setting table entries, no benchmarking was performed
on the first NetFPGA card.
\begin { figure} [h]
\includegraphics [scale=1.4] { hwtestnico}
\centering
\caption { Hardware Test NetPFGA card 1}
\label { fig:hwtestnico}
\end { figure}
\begin { figure} [h]
\includegraphics [scale=0.2] { hwtesthendrik}
\centering
\caption { Hardware Test NetPFGA card 2, \cite { hendrik:_ p4_ progr_ fpga_ semes_ thesis_ sa} }
\label { fig:hwtesthendrik}
\end { figure}
During the development and benchmarking, the second NetFPGA card stopped to
function properly multiple times. In both cases the card would not
forward packets anymore. Multiple reboots (3 were usually enough)
and multiple times reflashing the bitstream to the NetFPGA usually
2019-08-15 14:45:56 +00:00
restored the intended behaviour. However due to this ``crashes'', it
was impossible to complete a full benchmark run that would last for
more than one hour.
2019-08-15 15:08:10 +00:00
Sometimes it was also required to reboot the host containing the
NetFPGA card 3 times to enable successful flashing.\footnote { Typical
output of the flashing process would be: ``fpga configuration failed. DONE PIN is not HIGH''}
2019-08-15 13:33:08 +00:00
% ----------------------------------------------------------------------
\subsection { \label { results:netpfga:performance} Performance}
As expected, the NetFGPA card performed at near line speed and offers
2019-08-15 14:45:56 +00:00
NAT64 translations at 9.28 Gbit/s. Single and multiple streams
performed almost exactly identical and have been consistent through
multiple iterations of the benchmarks.
% ----------------------------------------------------------------------
\subsection { \label { results:netpfga:usability} Usability}
To use the NetFGPA, Vivado and SDNET provided by Xilinx need to be
installed. However a bug in the installer triggers an infinite loop,
if a certain shared library\footnote { The required shared library
is libncurses5.} is missing on the target operating system. The
installation program seems still to be progressing, however does never
finish.
While the NetFPGA card supports P4, the toolchains and supporting
scripts are in a immature state. The compilation process consists of
at least 9 different steps, which are interdependent\footnote { See
source code \texttt { bin/do-all-steps.sh} .} Some of the steps generate
shell scripts and python scripts that in turn generate JSON
data.\footnote { One compilation step calls the script
``config\_ writes.py''. This script failed with a syntax error, as it
contained incomplete python code. The scripts config\_ writes.py
and config\_ writes.sh are generated by gen\_ config\_ writes.py.
The output of the script gen\_ config\_ writes.py depends on the content
of config\_ writes.txt. That file is generated by the simulation
``xsim''. The file ``SimpleSumeSwitch\_ tb.sv'' contains code that is
responsible for writing config\_ writes.txt and uses a function
named axi4\_ lite\_ master\_ write\_ request\_ control for generating the
output. This in turn is dependent on the output of a script named
gen\_ testdata.py.}
However incorrect parsing generates syntactically incorrect
scripts or scripts that generate incorrect output. The toolchain
provided by the NetFGPA-P4 repository contains more than 80000 lines
of code. The supporting scripts for setting table entries require
setting the parameters for all possible actions, not only for the
selected action. Supplying only the required parameters results in a
crash of the supporting script.
The documentation for using the NetFPGA-P4 repository is very
distributed and does not contain a reference on how to use the
tools. Mapping of egress ports and their metadata field are found in a
python script that is used for generating test data.
The compile process can take up to 6 hours and because the different
steps are interdependent, errors in a previous stage were in our
experiences detected hours after they happened. The resulting log
files of the compilation process can be up to 5 MB in size. Within
this log file various commands output references to other logfiles,
however the referenced logfiles do not exist before or after the
compile process.
During the compile process various informational, warning and error
messages are printed. However some informational messages constitute
critical errors, while on the other hand critical errors and syntax
errors often do not constitue a critical
error.\footnote { F.i. ``CRITICAL WARNING: [BD 41-737] Cannot set the
parameter TRANSLATION\_ MODE on /axi\_ interconnect\_ 0. It is
read-only.'' is a non critical warning.}
Also contradicting
2019-08-15 15:08:10 +00:00
output is generated.\footnote { While using version 2018.2, the following
2019-08-15 14:45:56 +00:00
message was printed: ``WARNING: command 'get\_ user\_ parameter' will be removed in the 2015.3
release, use 'get\_ user\_ parameters' instead''.}
2019-08-15 15:08:10 +00:00
Programs or scripts that are called during the compile process do not
necessarily exit non zero if they encountered a critical error. Thus
finding the source of an error can be difficult due to the compile
process continuing after critical errors occured. Not only programs
that have critical errors exit ``successfully'', but also python
scripts that encounter critical paths don't abort with raise(), but
print an error message to stdout and don't abort with an error.
The most often encountered critical compile error is
``Run 'impl\_ 1' has not been launched. Unable to open''. This error
indicates that something in the previous compile steps failed and can
refer to incorrectly generated testdata to unsupported LPM tables.
2019-08-15 14:45:56 +00:00
The NetFPGA kernel module provides access to virtual Linux
devices (nf0...nf3). However tcpdump does not see any packets that are
emitted from the switch. The only possibility to capture packets
that are emitted from the switch is by connecting a physical cable to
the port and capturing on the other side.
2019-08-15 13:33:08 +00:00
2019-08-15 14:45:56 +00:00
Jumbo frames\footnote { Frames with an MTU greater than 1500 bytes.} are
commonly used in 10 Gbit/s networks. According to
\ref { wikipedia:_ jumbo} , even many gigabit network interface card
support jumbo frames. However according to emails on the private
NetPFGA mailing list, the NetFPGA only supports 1500 byte frames at
the moment and additional work is required to implement support for
bigger frames.
2019-08-15 13:33:08 +00:00
2019-08-15 15:08:10 +00:00
Our P4 source code required contains Xilinx
annotations\footnote { F.i. ``@Xilinx\_ MaxPacketRegion(1024)''} that define
the maximum packet size in bits. We observed two different errors on
the output packet, if the incoming packets exceeds the specified size:
\begin { itemize}
\item The output packet is longer then the original packet.
\item The output packet is corrupted.
\end { itemize}
2019-08-15 14:45:56 +00:00
While most of the P4 language is supported on the netpfga, some key
techniques are missing or not supported.
\begin { itemize}
\item Analysing / accessing payload is not supported
\item Checksum computation over payload is not supported
\item Using LPM tables can lead to compilation errors
\item Depening on the match type, only certain table sizes are allowed
\end { itemize}
Renaming variables in the declaration of the parser or deparser lead
to compilation errors. Function syntax is not supported. For this
reason our implementation uses \texttt { \# define} statements instead of functions.
2019-08-13 10:56:15 +00:00
Trace files
\begin { verbatim}
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1555-h3.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1557-h1.pcap
create mode 100644 pcap/tcp-udp-delta-2019-07-17-1558-h3.pcap
\end { verbatim}
\begin { verbatim}
*** DONE 2019-07-21: Proof of v6->v4 working delta based
CLOSED: [2019-07-21 Sun 12:30]
#+BEGIN_ CENTER
pcap/tcp-udp-delta-from-v6-2019-07-21-0853-h1.pcap | Bin 0 -> 4252 bytes
pcap/tcp-udp-delta-from-v6-2019-07-21-0853-h3.pcap | Bin 0 -> 2544 bytes
#+END_ CENTER
\end { verbatim}
\begin { verbatim}
**** DONE Testing v4->v6 tcp: ok (version 10.0)
CLOSED: [2019-08-04 Sun 09:15]
#+BEGIN_ CENTER
nico@ESPRIMO-P956:~/master-thesis/bin$ . / socat - connect - tcp - v 4
+ echo from-v4-ok
+ socat - TCP:10.0.0.66:2345
TCPv6-ok
nico@ESPRIMO-P956:~/master-thesis/bin$ . / socat - listen - tcp - v 6
from-v4-ok
#+END_ CENTER
trace:
netfpga-nat64-2019-08-04-0907-enp2s0f0.pcap
netfpga-nat64-2019-08-04-0907-enp2s0f1.pcap
**** DONE Testing v4->v6 udp: ok (version 10.1)
trace:
create mode 100644 pcap/netfpga-nat64-udp-2019-08-04-0913-enp2s0f0.pcap
create mode 100644 pcap/netfpga-nat64-udp-2019-08-04-0913-enp2s0f1.pcap
\end { verbatim}
\begin { verbatim}
*** DONE 2019-08-04: version 10.1/10.2: new maxpacketregion: v4->v6 works
CLOSED: [2019-08-04 Sun 19:42]
#+BEGIN_ CENTER
nico@ESPRIMO-P956:~/master-thesis/bin$ . / init _ ipv 4 _ esprimo.sh
nico@ESPRIMO-P956:~/master-thesis/bin$ . / set _ ipv 4 _ neighbor.sh
#+END_ CENTER
Test 20 first:
- Does't work -> missed to add table entries
- Does work after setting table entries
- 300 works
- 1450 works
- 1500 does not work
Proof:
create mode 100644 pcap/netfpga-10.2-maxpacket-2019-08-04-1931-enp2s0f0.pcap
create mode 100644 pcap/netfpga-10.2-maxpacket-2019-08-04-1931-enp2s0f1.pcap
\end { verbatim}
\begin { verbatim}
*** DONE 2019-08-04: test v6 -> v4: works for 1420
CLOSED: [2019-08-04 Sun 20:30]
Proof:
#+BEGIN_ CENTER
create mode 100644 pcap/netfpga-10.2-fromv6tov4-2019-08-04-1943-enp2s0f0.pcap
create mode 100644 pcap/netfpga-10.2-fromv6tov4-2019-08-04-1943-enp2s0f1.pcap
\end { verbatim}
2019-08-12 10:13:59 +00:00
General result: limited NAT64 is working, however
2019-08-01 18:59:21 +00:00
2019-08-12 10:13:59 +00:00
No Payload
checksumming - requires controller
2019-07-31 08:50:30 +00:00
2019-08-12 10:13:59 +00:00
Hash funktion in Arbeit
2019-07-31 08:50:30 +00:00
2019-08-12 10:13:59 +00:00
No NDP, no ARP - focused on key factors of NAT64 translation,
other features can be supported by controller
2019-08-15 15:14:35 +00:00
Needed to debug internal parsing errors
debugging generated tcl code to debug impl1 error
2019-08-15 13:33:08 +00:00
% ----------------------------------------------------------------------
\section { \label { results:tayga} Tayga}
During the benchmark cpu bound, single thread
2019-08-13 10:56:15 +00:00
tayga: Single threaded
2019-08-07 13:55:53 +00:00
2019-08-15 13:33:08 +00:00
% ----------------------------------------------------------------------
\section { \label { results:jool} Jool}
kernel module
high cpu usage for udp connetcinos
Integration with iptables
2019-08-15 15:14:35 +00:00
% ----------------------------------------------------------------------
\section { \label { results:p4} P4}
NDP parsing problem
checksumming a frequent problem and helper
if in action limitations
switch cannot be used in actions
python2 only - unicode errors
IPv6: NDP: not easy to parse, as unknown number of following fields
No support for multiple LPM keys in a table, can be solved with
ternary matching.
if things don't work, often a checksum problem.
if frame checksum, then length of packet is broken
\begin { verbatim}
p4c --target bmv2 --arch v1model --std p4-16 "../p4src/static-mapping.p4" -o "/home/p4/master-thesis/p4src"
../p4src/static-mapping.p4(366): error: Program is not supported by this target, because table MyIngress.v6_ networks has multiple successors
table v6_ networks {
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
\end { verbatim}
\begin { verbatim}
ipaddress.ip_ network("2001:db8:61::/64")
IPv6Network(u'3230:3031:3a64:6238:3a36:313a:3a2f:3634/128')
Fix:
from _ _ future_ _ import unicode_ literals
\end { verbatim}
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
retrieving information from tables
\begin { verbatim}
Key and mask for matching destination is in table. We need this
information in the action. However this information is not exposed, so
we need to specify another parameter with the same information as in
the key(s).
Log from slack: (2019-03-14)
nico [1:55 PM]
If I use LPM for matching, can I easily get the network address from P4 or do I have to use a bitmask myself? In the latter case it is not exactly clear how to get the mask from the table
Nate Foster [1:58 PM]
You want to retrieve the address in the packet? In a table?
And do you want to do the retrieving from the data plane or the control plane? (edited)
nico [2:00 PM]
If I have a match in a table that matches on LPM, it can be any IP address in a network
For calculating the NAT64/NAT46 translation, I will need the base address, i.e. network address to do subtractions/additions
So it is fully data plane, what I would like to do
I'll commit sample code to show the use case more clearly
https://gitlab.ethz.ch/nicosc/master-thesis/blob/master/p4src/static-mapping.p4#L73
GitLab
p4src/static-mapping.p4 · master · nicosc / master-thesis
gitlab.ethz.ch
So the action nat64_ static() is used in the table v6_ networks.
In v6_ networks I use a match on `hdr.ipv6.dst_ addr: lpm;`
What I would like to be able is to get the network address ; I can do that manually, if I have the mask
I can also re-inject this parameter by another action argument, but I'd assume that I can somewhere read this out from the table / match
Nate Foster [2:15 PM]
To make sure I understand, in the data plane, you want to retrieve the address in the lpm pattern? (edited)
nico [2:16 PM]
I want to retrieve the key
Nate Foster [2:16 PM]
Wait. The value `hdr.ipv6.dst_ addr` is the thing used in the match.
So you have that.
What you don’
I assume you want the latter, right?
nico [2:17 PM]
For example, if my matching key is 2001:db8::/32 and the real address is 2001:db8::f00, then I would like to retrieve 2001:db8:: and 32 from the table
exactly :slightly_ smiling_ face:
I can "fix" this by adding another argument, but it feels somewhat wrong to do that
Because the table already knows this information
Nate Foster [2:26 PM]
I can’
nico [2:26 PM]
Oh, ok
Is it because the information is "lost in hardware"?
Nate Foster [2:31 PM]
No you’
But unless I am missing something obvious, P4 hides it…
\end { verbatim}
no meta information
\begin { verbatim}
Is there any meta information for "from which table was the action
called" available? My use case is having a debug action that sends
packets to the controller and I use it as a default_ action in various
tables; however know I don't know anymore from which table the action
was called. Is there any kind of meta information which table called
me available?
I could work around this by using if(! .. .hit) { my_ action(table_ id)
} , but it would not work with using default_ action = ...
\end { verbatim}
type definitions separate
Code sharing (controller, switch)
\begin { verbatim}
*** DONE Synchronisation with the controller
- Double data type definition -> might differ
- TYPE_ CPU for ethernet
- Port ingress offset (9 vs. 16 bit)
\end { verbatim}
No switch in actions, No conditional execution in actions
P4os - reusable code
\begin { verbatim}
Not addressed so far: how to create re-usable code fragments that can
be plugged in easily. There could be a hypothetical "P4OS" that
manages code fragments. This might include, but not limited to
downloading (signed?) source code, managing dependencies similar to
Linux package management, handling updates, etc.
\end { verbatim}
idomatic problem: Security issue: not checking checksums before
