update all
Signed-off-by: Nico Schottelius <nico@nico-notebook.schottelius.org>
This commit is contained in:
Nico Schottelius
parent
7fb8a36a03
commit
df2c52a37f
46 changed files with 393 additions and 237 deletions
|
|
@ -9,14 +9,14 @@ bits that are parsed and then accessible in the (self) defined
|
|||
structures, also called headers. The general flow can be seen in
|
||||
figure \ref{fig:p4fromnsg}: a parser parses the incoming packet and
|
||||
prepares it for processing in the switching logic. Afterwards the
|
||||
packets is output and deparsing of the parsed data might follow.
|
||||
packets are output and deparsing of the parsed data might follow.
|
||||
In the context of NAT64 this is a very important feature: while the
|
||||
parser will read and parse in the ingress pipeline one protocol
|
||||
(f.i. IPv6), the deparser will output a different protocol (f.i. IPv4).
|
||||
\begin{figure}[h]
|
||||
\includegraphics[scale=0.9]{p4-from-nsg}
|
||||
\centering
|
||||
\caption{P4 protocol independence, \cite{vanbever:_progr_networ_data_planes}}
|
||||
\caption{P4 protocol independence~\cite{vanbever:_progr_networ_data_planes}}
|
||||
\label{fig:p4fromnsg}
|
||||
\end{figure}
|
||||
The \textit{target independence} is the second very powerful feature
|
||||
|
|
@ -24,10 +24,12 @@ of P4: it allows code to be compiled to different targets. While in
|
|||
theory the P4 code should be completely target independent, in reality
|
||||
there are some modifications needed on a per-target basis and each
|
||||
target faces different restrictions. The challenges arising from this
|
||||
are discussed in section \ref{conclusion:P4}.
|
||||
are discussed in section \ref{results:p4}.
|
||||
|
||||
As opposed to general purpose programming languages, P4 lacks some
|
||||
features, most notably loops. However within its constraints, P4 can guarantee
|
||||
features, most notably loops, floating point operations and the
|
||||
modulo operator.
|
||||
However within its constraints, P4 can guarantee
|
||||
operation at line speed, which general purpose programming languages
|
||||
cannot guarantee and also fail to achieve in reality
|
||||
(see section \ref{results:softwarenat64} for details).
|
||||
|
|
|
|||
|
|
@ -52,3 +52,14 @@ technologie DNS64\cite{rfc6147} could also be implemented in P4, thus
|
|||
completing the translation mechanism.
|
||||
|
||||
Proxies / higher level protocols could be next level
|
||||
|
||||
Add helper in P4 to support checksum analysis a frequent problem and
|
||||
helper
|
||||
Allow ICMP6 option parsing: specify xtimes 64 bit blocks resulting in
|
||||
an array
|
||||
|
||||
Adding support for passing on meta information to controller: key or
|
||||
table
|
||||
|
||||
Support a meta language to define used types and/or export to popular languages.
|
||||
Long term supporting python3 would be helpful. P4OS.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,9 @@
|
|||
|
||||
\chapter{\label{introduction}Introduction}
|
||||
In this chapter we give an introduction about the topic of the master
|
||||
thesis, the motivation and problemes that we address.
|
||||
thesis, the motivation and problemes that we address. We explain the
|
||||
current state of IPv4 exhaustion and IPv6 adoption and describe how
|
||||
it motivates our work to support ease transition to IPv6 networks.
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{introduction:ipv4ipv6}IPv4 exhaustion and IPv6 adoption}
|
||||
|
|
|
|||
337
doc/Results.tex
337
doc/Results.tex
|
|
@ -12,7 +12,7 @@ objective of this thesis was to demonstrate the high speed
|
|||
capabilities of NAT64 in hardware, no benchmarks were performed on the
|
||||
P4 software implementation.
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{results:p4}NAT64 Overview - FIXME: verify numbers}
|
||||
\section{\label{results:p4}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,
|
||||
|
|
@ -24,47 +24,114 @@ 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}
|
||||
\begin{tabular}{| c | c | c | c |}
|
||||
\begin{tabular}{| c | c | c | c | c |}
|
||||
\hline
|
||||
Solution & \multicolumn{3}{|c|}{Parallel connections} \\
|
||||
& 1 & 20 & 3 \\
|
||||
Implementation & \multicolumn{4}{|c|}{min/avg/max in Gbit/s} \\
|
||||
\hline
|
||||
Tayga & 3.02 & 3.28 & 2.85\\
|
||||
Tayga & 2.79 / 3.20 / 3.43 & 3.34 / 3.36 / 3.38 & 2.57 / 3.02 / 3.27 &
|
||||
2.35 / 2.91 / 3.20 \\
|
||||
\hline
|
||||
Jool & 6.67 & 16.8 ?? & 20.5 udp?\\
|
||||
Jool & 8.22 / 8.22 / 8.22 & 8.21 / 8.21 / 8.22 & 8.21 / 8.23 / 8.25
|
||||
& 8.21 / 8.23 / 8.25\\
|
||||
\hline
|
||||
P4 / NetPFGA & 9.28 & 9.29 & 9.29\\
|
||||
P4 / NetPFGA & 9.28 / 9.28 / 9.29 & 9.28 / 9.28 / 9.29 & 9.28 / 9.28
|
||||
/ 9.29 & 9.28 / 9.28 / 9.29\\
|
||||
\hline
|
||||
Parallel connections & 1 & 10 & 20 & 50 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{minipage}
|
||||
\caption{NAT64 Benchmark (client: IPv6, server: IPv4), all results in Gbit/sec (\%loss)}
|
||||
\caption{IPv6 to IPv4 TCP NAT64 Benchmark}
|
||||
\label{tab:benchmarkv6}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
|
||||
During the benchmarks the client -- CPU usage
|
||||
\begin{table}[htbp]
|
||||
\begin{center}\begin{minipage}{\textwidth}
|
||||
\begin{tabular}{| c | c | c | c |}
|
||||
\begin{tabular}{| c | c | c | c | c |}
|
||||
\hline
|
||||
Solution & \multicolumn{3}{|c|}{Parallel connections} \\
|
||||
& 1 & 20 & 3 \\
|
||||
Implementation & \multicolumn{4}{|c|}{min/avg/max in Gbit/s} \\
|
||||
\hline
|
||||
Tayga & 3.36 & 3.29 & 3.11 \\
|
||||
Tayga & 2.90 / 3.15 / 3.34 & 2.87 / 3.01 / 3.22 &
|
||||
2.68 / 2.85 / 3.09 & 2.60 / 2.78 / 2.88 \\
|
||||
\hline
|
||||
Jool & 8.24 & 8.26 & 8.29\\
|
||||
Jool & 7.18 / 7.56 / 8.24 & 7.97 / 8.05 / 8.09 &
|
||||
8.05 / 8.08 / 8.10 & 8.10 / 8.12 / 8.13 \\
|
||||
\hline
|
||||
P4 / NetPFGA & 9.28 & 9.29 & 9.29\\
|
||||
P4 / NetPFGA & 8.51 / 8.53 / 8.55 & 9.28 / 9.28 / 9.29 & 9.29 / 9.29 /
|
||||
9.29 & 9.28 / 9.28 / 9.29 \\
|
||||
\hline
|
||||
Parallel connections & 1 & 10 & 20 & 50 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{minipage}
|
||||
\caption{NAT64 Benchmark (client: IPv4, server: IPv6), all results in Gbit/sec (\%loss)}
|
||||
\caption{IPv4 to IPv6 TCP NAT64 Benchmark}
|
||||
\label{tab:benchmarkv4}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
|
||||
\begin{table}[htbp]
|
||||
\begin{center}\begin{minipage}{\textwidth}
|
||||
\begin{tabular}{| c | c | c | c | c |}
|
||||
\hline
|
||||
Implementation & \multicolumn{4}{|c|}{avg bandwidth in gbit/s / avg loss /
|
||||
adjusted bandwith} \\
|
||||
\hline
|
||||
Tayga & 8.02 / 70\% / 2.43 & 9.39 / 79\% / 1.97 & 15.43 / 86\% / 2.11
|
||||
& 19.27 / 91\% 1.73 \\
|
||||
\hline
|
||||
Jool & 6.44 / 0\% / 6.41 & 6.37 / 2\% / 6.25 &
|
||||
16.13 / 64\% / 5.75 & 20.83 / 71\% / 6.04 \\
|
||||
\hline
|
||||
P4 / NetPFGA & 8.28 / 0\% / 8.28 & 9.26 / 0\% / 9.26 &
|
||||
16.15 / 0\% / 16.15 & 15.8 / 0\% / 15.8 \\
|
||||
\hline
|
||||
Parallel connections & 1 & 10 & 20 & 50 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{minipage}
|
||||
\caption{IPv6 to IPv4 UDP NAT64 Benchmark}
|
||||
\label{tab:benchmarkv4}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
|
||||
\begin{table}[htbp]
|
||||
\begin{center}\begin{minipage}{\textwidth}
|
||||
\begin{tabular}{| c | c | c | c | c |}
|
||||
\hline
|
||||
Implementation & \multicolumn{4}{|c|}{avg bandwidth in gbit/s / avg loss /
|
||||
adjusted bandwith} \\
|
||||
\hline
|
||||
Tayga & 6.78 / 84\% / 1.06 & 9.58 / 90\% / 0.96 &
|
||||
15.67 / 91\% / 1.41 & 20.77 / 95\% / 1.04 \\
|
||||
\hline
|
||||
Jool & 4.53 / 0\% / 4.53 & 4.49 / 0\% / 4.49 & 13.26 / 0\% / 13.26 &
|
||||
22.57 / 0\% / 22.57\\
|
||||
\hline
|
||||
P4 / NetPFGA & 7.04 / 0\% / 7.04 & 9.58 / 0\% / 9.58 &
|
||||
9.78 / 0\% / 9.78 & 14.37 / 0\% / 14.37\\
|
||||
\hline
|
||||
Parallel connections & 1 & 10 & 20 & 50 \\
|
||||
\hline
|
||||
\end{tabular}
|
||||
\end{minipage}
|
||||
\caption{IPv4 to IPv6 UDP NAT64 Benchmark}
|
||||
\label{tab:benchmarkv4}
|
||||
\end{center}
|
||||
\end{table}
|
||||
|
||||
UDP load generator hitting 100\% cpu at P20.
|
||||
TCP confirmed.
|
||||
Over bandwidth results
|
||||
|
||||
Feature comparison
|
||||
speed - sessions - eamt
|
||||
can act as host
|
||||
|
|
@ -74,15 +141,17 @@ ping6 support
|
|||
ndp
|
||||
controller support
|
||||
|
||||
netpfga consistent
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{Results:BMV2}BMV2}
|
||||
\section{\label{Results:BMV2}BMV2 - FIXME: write better}
|
||||
The software implementation of P4 has most features, which is
|
||||
mostly due to the capability of checksumming the payload: Acting
|
||||
as a ``proper'' participant in NDP, requires the host to calculate
|
||||
checksums over the payload.
|
||||
|
||||
List of features:
|
||||
|
||||
List of features BMV2 \cite{tab:p4bmv2features}
|
||||
|
||||
\begin{table}[htbp]
|
||||
\begin{center}\begin{minipage}{\textwidth}
|
||||
|
|
@ -144,6 +213,7 @@ Responds to icmp, icmp6
|
|||
ndp \cite{rfc4861}
|
||||
arp
|
||||
|
||||
very easy to use
|
||||
|
||||
Fully functional host
|
||||
Can compute checksums on its own.
|
||||
|
|
@ -160,19 +230,9 @@ table entries.
|
|||
|
||||
Jool and tayga are supported by
|
||||
|
||||
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}
|
||||
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{results:netpfga}NetFPGA}
|
||||
\section{\label{results:netpfga}NetFPGA - FIXME: writing}
|
||||
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
|
||||
|
|
@ -393,105 +453,28 @@ 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.
|
||||
|
||||
|
||||
\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-v4
|
||||
+ echo from-v4-ok
|
||||
+ socat - TCP:10.0.0.66:2345
|
||||
TCPv6-ok
|
||||
nico@ESPRIMO-P956:~/master-thesis/bin$ ./socat-listen-tcp-v6
|
||||
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_ipv4_esprimo.sh
|
||||
nico@ESPRIMO-P956:~/master-thesis/bin$ ./set_ipv4_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}
|
||||
FIXME:
|
||||
|
||||
General result: limited NAT64 is working, however
|
||||
|
||||
No Payload
|
||||
checksumming - requires controller
|
||||
|
||||
Hash funktion in Arbeit
|
||||
|
||||
No NDP, no ARP - focused on key factors of NAT64 translation,
|
||||
No Payload ; checksumming - requires controller
|
||||
Hash funktion in Arbeit ; No NDP, no ARP - focused on key factors of NAT64 translation,
|
||||
other features can be supported by controller
|
||||
|
||||
|
||||
Needed to debug internal parsing errors
|
||||
|
||||
debugging generated tcl code to debug impl1 error
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{results:tayga}Tayga}
|
||||
\section{\label{results:softwarenat64}Software NAT64 with Tayga and
|
||||
Jool}
|
||||
Both cpu bound.
|
||||
|
||||
During the benchmark cpu bound, single thread
|
||||
tayga: Single threaded
|
||||
easy to use
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{results:jool}Jool}
|
||||
kernel module
|
||||
|
||||
100% cpu usage on 1 core for udp
|
||||
|
||||
Jool kernel module
|
||||
100\% cpu usage on 1 core for udp
|
||||
0\% visible cpu usage for tcp, might be tcp offloading
|
||||
Integration with iptables
|
||||
|
||||
Requires routing
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
|
|
@ -514,24 +497,7 @@ most often found in checksum problems. If frame checksum errors where
|
|||
displayed by tcpdump, usually the effective length of the packet was
|
||||
incorrect.
|
||||
|
||||
|
||||
NDP parsing problem
|
||||
|
||||
checksumming a frequent problem and helper
|
||||
|
||||
|
||||
IPv6: NDP: not easy to parse, as unknown number of following fields
|
||||
|
||||
if things don't work, often a checksum problem.
|
||||
|
||||
\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}
|
||||
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}
|
||||
|
|
@ -539,107 +505,22 @@ in the development.\cite{schottelius:github1675}
|
|||
or missing features (\cite{schottelius:github745},
|
||||
\cite{theojepsen:_get})
|
||||
|
||||
Hitting expression bug
|
||||
Hitting expression bug (FIXME: source)
|
||||
|
||||
1) Impossible to retrieve key from table: LPM: addr + mask -> addr and
|
||||
mask might be used in controller
|
||||
|
||||
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’t have is the IPv6 address and mask put into the table by the control plane.
|
||||
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’t think of a way other than the action parameter hack.
|
||||
|
||||
nico [2:26 PM]
|
||||
Oh, ok
|
||||
Is it because the information is "lost in hardware"?
|
||||
|
||||
Nate Foster [2:31 PM]
|
||||
No you’re right that most implementations have the value in memory. And one can imagine a different table API that allowed one to retrieve it in the data plane.
|
||||
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}
|
||||
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
|
||||
|
||||
\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
|
||||
|
|
|
|||
BIN
doc/Thesis.pdf
BIN
doc/Thesis.pdf
Binary file not shown.
214
doc/appendix.tex
214
doc/appendix.tex
|
|
@ -2324,6 +2324,92 @@ Proof of stuff working, reference for each stage / feature
|
|||
|
||||
Stuff that needs to be cleaned up
|
||||
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{P4/BMV NAT64 Delta based traces}
|
||||
\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}
|
||||
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}
|
||||
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{P4/NetFPGA NAT64 Delta based traces}
|
||||
\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-v4
|
||||
+ echo from-v4-ok
|
||||
+ socat - TCP:10.0.0.66:2345
|
||||
TCPv6-ok
|
||||
nico@ESPRIMO-P956:~/master-thesis/bin$ ./socat-listen-tcp-v6
|
||||
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}
|
||||
|
||||
Bigger packets
|
||||
\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_ipv4_esprimo.sh
|
||||
nico@ESPRIMO-P956:~/master-thesis/bin$ ./set_ipv4_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}
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
\subsection{\label{introduction:taskdescription}The Task}
|
||||
|
|
@ -2362,6 +2448,134 @@ Describe your task.
|
|||
|
||||
\end{verbatim}
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\section{\label{appendix:p4}P4 notes}
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{appendix:p4:keyretrieval}Key retrieval chat log}
|
||||
\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’t have is the IPv6 address and mask put into the table by the control plane.
|
||||
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’t think of a way other than the action parameter hack.
|
||||
|
||||
nico [2:26 PM]
|
||||
Oh, ok
|
||||
Is it because the information is "lost in hardware"?
|
||||
|
||||
Nate Foster [2:31 PM]
|
||||
No you’re right that most implementations have the value in memory. And one can imagine a different table API that allowed one to retrieve it in the data plane.
|
||||
But unless I am missing something obvious, P4 hides it…
|
||||
|
||||
\end{verbatim}
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{appendix:p4:tableretrieval}Table retrieval problem}
|
||||
\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}
|
||||
|
||||
\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}
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{appendix:p4:datadefinition}Data definition
|
||||
redundancy}
|
||||
\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}
|
||||
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{appendix:p4:python2unicode
|
||||
}Python2 unicode issue}
|
||||
|
||||
\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}
|
||||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{appendix:p4:p4os}P4 OS}
|
||||
|
||||
\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}
|
||||
|
||||
|
||||
|
||||
%---------------------------------------------------------------------------------------------------------
|
||||
\printnomenclature
|
||||
\abbrev{ARP}{Address resolution protocol}
|
||||
|
|
|
|||
52
doc/plan.org
52
doc/plan.org
|
|
@ -3372,7 +3372,6 @@ nico@ESPRIMO-P956:~/master-thesis/iperf/run7-jool$
|
|||
|
||||
../../bin/benchmark-run.sh tayga 2001:db8:23::a00:2a 2345
|
||||
|
||||
|
||||
* TODO Thesis documentation
|
||||
** Introduction
|
||||
*** Related work
|
||||
|
|
@ -9345,10 +9344,57 @@ nico@nsg-System:~/projects/P4-NetFPGA/contrib-projects/sume-sdnet-switch/project
|
|||
| Introduction | 1 day | okayish |
|
||||
| Background | 1 day | okayish |
|
||||
| Design | 1-2 days | okayish |
|
||||
| Results | 2-3 days | 2019-08-13 |
|
||||
| Conclusion | 1 day | 2019-08-14 |
|
||||
| Results | 2-3 days | okayish |
|
||||
| Conclusion | 1 day | okayish |
|
||||
| Proof reading | 2-3 days | until 2019-08-17 |
|
||||
| SUM(max) | 12d | |
|
||||
** Big steps
|
||||
*** TODO Enhance Design section
|
||||
*** TODO Write / describe results
|
||||
*** TODO Fix smaller bugs
|
||||
*** TODO Cleanup appendix
|
||||
*** TODO Put figures and code into context
|
||||
** Corrections v2
|
||||
*** TODO Perhaps you could place figure 1.3 and 1.4 next to each other (as subfigures). Would make it easier to see the differences.
|
||||
*** DONE Will there be an overview section in 1? E.g., about the next chapters.
|
||||
CLOSED: [2019-08-18 Sun 12:35]
|
||||
*** DONE P 13: the packets is -> the packets are
|
||||
CLOSED: [2019-08-18 Sun 12:36]
|
||||
*** DONE P 13: missing references to other sections
|
||||
CLOSED: [2019-08-18 Sun 12:37]
|
||||
*** DONE P 13: perhaps mention some more missing features, e.g. floating point operations
|
||||
CLOSED: [2019-08-18 Sun 12:38]
|
||||
*** TODO P 13: detail, make sure that spacing around citations is consistent. I would use: text~\cite{...}
|
||||
*** TODO P 13: missing closing parentheses after [13]
|
||||
*** TODO P 14: figures 2.3 and 2.2 -> 2.2 and 2.3
|
||||
*** TODO P 14: why do you compare ARP and NDP to P4?
|
||||
*** TODO P 15: missing reference
|
||||
*** TODO P 15: the quote - perhaps put it in quotation marks. Instead of the footnote perhaps a bib entry?
|
||||
*** TODO P 15: mtu vs. MTU (I would write MTU)
|
||||
*** TODO P 16: missing reference
|
||||
*** TODO P 16: tcp -> TCP
|
||||
*** TODO P 17: the checksums for TCP and UDP is -> are
|
||||
*** TODO P 17: I’m not sure if it is completely true that you cannot access the payload in the NetFPGA. It is perhaps just not yet implemented…
|
||||
*** TODO P 18: missing closing parentheses
|
||||
*** TODO P 18: missing references
|
||||
*** TODO P 18: Perhaps the network design section should be moved out of the background section as it already contains ideas/discussion related to your implementation?
|
||||
*** TODO P 21: on it own -> on its own
|
||||
*** TODO P 21: the use of a control -> of a controller
|
||||
*** TODO P 22+: passive -> active voice
|
||||
*** TODO P 22: if you show code, make sure you also explain it in the text
|
||||
*** TODO P 22: add quotation marks to the quote. Make sure you cite it in the same way as the previous quote
|
||||
*** DONE P 23: perhaps move benchmark results to chapter 4?
|
||||
CLOSED: [2019-08-17 Sat 15:01]
|
||||
*** TODO P 25: missing reference
|
||||
*** TODO P 25: explain/interpret the reported numbers
|
||||
*** TODO P 25/26: personally, I would report things such as the BMV2 feature list (table 4.3) before the result section. Obviously these are „results” but not really e.g., measurements.
|
||||
*** TODO P 28: this „crashes” -> these
|
||||
*** TODO P 28: NetFGPA -> NetFPGA
|
||||
*** TODO P 28: here you speak about the speed of your system that is nearly at the line rate of the NetFPGA but I’m not really sure if you previously introduced what the NetFPGA is capable of. Perhaps you could have a short section in the background section?
|
||||
*** TODO P 29: Section 4.3.4: Although very interesting contentwise, the text could be a bit better structured/combined. Perhaps you can also adapt the title. Once again I’m not completely sure if the results section is the best place for this text. Perhaps you would need an additional chapter between design and results.General:
|
||||
*** TODO I’m not a huge fan of placing the figures in the middle of ongoing text (sometimes even breaking ongoing sentences). I would rather place them e.g., at the top of the page.
|
||||
*** TODO A lot of figure captions are quite pointless, e.g. „IPv6 Pseudo Header”. Try to extend them a bit.
|
||||
*** TODO I know that the design section is probably not yet finished but it would be nice if it would be a bit longer. After all, this is your main work.
|
||||
* DONE Initial administration
|
||||
** DONE Clarify PDF / form with Denise Spicher: free form description
|
||||
** DONE Create task description to be handed in mystudies
|
||||
|
|
|
|||
Loading…
Reference in a new issue