Browse Source

++doc

master
Nico Schottelius 2 years ago
parent
commit
695f4ed94c
  1. 10
      doc/Background.tex
  2. 71
      doc/Conclusion.tex
  3. 149
      doc/Design.tex
  4. 5
      doc/Introduction.tex
  5. 2
      doc/Makefile
  6. 50
      doc/Results.tex
  7. 36
      doc/graphviz/netpfgadesign.dot
  8. BIN
      doc/graphviz/netpfgadesign.png
  9. 19
      doc/graphviz/switchdesign.dot
  10. BIN
      doc/graphviz/switchdesign.png
  11. 18
      doc/plan.org
  12. 26
      doc/refs/refs.bib
  13. 2
      p4src/actions_nat64_generic.p4

10
doc/Background.tex

@ -103,6 +103,11 @@ the two protocols for this thesis are:
\label{fig:ipv4header}
\end{figure}
% ----------------------------------------------------------------------
\section{\label{background:arpndp}ARP and NDP - FIXME}
Required for finding host.
ARP who has
NDP similar -- add traces here
% ----------------------------------------------------------------------
\section{\label{background:transition}IPv6 Translation Mechanisms}
While in this thesis the focus was in NAT64 as a translation mechanism,
there are a variety of different approaches, some of which we would
@ -304,6 +309,5 @@ IPv6 only networks are in our opinion the best choice for long term
deployments. The reasons for this are as follows: First of all hosts
eventually will need to support IPv6 and secondly
IPv6 hosts can address the whole 32 bit IPv4 Internet mapped in
a single /96 IPv6 network, whithout the need for address extension or
higher protocol dependent translations\footnote{Higher level protocols
like TCP, UDP, ICMP6/ICMP.}
a single /96 IPv6 network. IPv6 only networks also allow the operators
to focus on one IP stack.

71
doc/Conclusion.tex

@ -9,20 +9,89 @@ Sum up what you have done and recapitulate your key findings.
\section{\label{conclusion:softwarenat64}Software based NAT64}
\section{\label{conclusion:general}General}
Many misleading
\section{\label{conclusion:bmv2}BMV2}
maybe remove
\section{\label{conclusion:P4}P4}
checksumming a frequent problem and helper
Many possibilities
Protocol independent
Easy architecture
Limitations in
if in action limitations
Limits if 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.
switch cannot be used in actions
\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}
\section{\label{conclusion:netpfga}NetFGPA}
or missing features (\cite{schottelius:github745},
\cite{theojepsen:_get})
Hitting expression bug
\section{\label{conclusion:netpfga}NetFGPA - all HERE}
personal note here
long compile process
error prone compile process
many dependencies
lpm not supported!
Netpfga live,
Vivado
SDNET
xx k lines of supporting code
no payload accessq
Many workarounds
Table size 63, table size 64,
Table entries require arguments of all possible actions, not only used
one.
Compile time hours
Silent errors
Unclear errors: broken board
Due to the very fragile nature of the build framework from the
NetFPGA-Live repository,
Renaming VARIABLES in the definition of
Reproducibility:
\section{\label{conclusion:realworld}Real world applications}
Can be deployed using the netpfga. Or Barefoot or Arista.

149
doc/Design.tex

@ -2,29 +2,148 @@
Description of the theory/software/hardware that you designed.
%** Design.tex: How was the problem attacked, what was the design
% the architecture
In this chapter we describe the architecture of our solution.
Maybe figures here? controller,
% ----------------------------------------------------------------------
\section{\label{Design:General}General}
There are a variety of possible network layouts for realising
NAT64. In this thesis two different layouts where taken into account:
routed translation and transparent in network translation.
The high level design can be seen in figure \ref{fig:switchdesign}: a
P4 capable switch is running our code to provide NAT64
functionality. The P4 switch cannot manage its tables on it own and
needs support for this from a controller. If only static table entries
are required, the controller can also be omitted. However stateful
NAT64 requires the use of a control to create session entries in the
switch tables.
\begin{figure}[h]
\includegraphics[scale=0.5]{switchdesign}
\centering
\caption{General Design}
\label{fig:switchdesign}
\end{figure}
The P4 switch can use any protocol to communicate with controller, as
the connection to the controller is implemented as a separate ethernet
port. The design allows our solution to be used as a standard NAT64
translation method or as an in network NAT64 translation (compare
figures \ref{fig:v6v4innetwork} and \ref{fig:v6v4standard}). The
controller is implemented in python, the NAT64 solution is implemented
in P4.
% ----------------------------------------------------------------------
\section{\label{Design:BMV2}BMV2}
Development of the thesis took place on a software emulated switch
that is implemented using Open vSwitch \cite{openvswitch}
and the behavioral model
\cite{_implem_your_switc_target_with_bmv2}. The development followed
closely the general design shown in section
\ref{Design:General}. Within the software emulation checksums can be
computed with two different methods:
\begin{itemize}
\item Recalculating the checksum by inspecting headers and payload
\item Calculating the difference between the translated headers
\end{itemize}
The BMV2 model is rather sophisticated and provides many standard
features including checksumming over payload. This allows the BMV2
model to operate as a full featured host, including advanced features
like responding to ICMP6 Neighbor discovery requests \cite{rfc4861}
that include payload checksums.
A typical code to create the checksum can be found in figure
\ref{fig:checksum}.
\begin{figure}[h]
\begin{verbatim}
/* checksumming for icmp6_na_ns_option */
update_checksum_with_payload(meta.chk_icmp6_na_ns == 1,
{
hdr.ipv6.src_addr, /* 128 */
hdr.ipv6.dst_addr, /* 128 */
meta.cast_length, /* 32 */
24w0, /* 24 0's */
PROTO_ICMP6, /* 8 */
hdr.icmp6.type, /* 8 */
hdr.icmp6.code, /* 8 */
hdr.icmp6_na_ns.router,
hdr.icmp6_na_ns.solicitated,
hdr.icmp6_na_ns.override,
hdr.icmp6_na_ns.reserved,
hdr.icmp6_na_ns.target_addr,
hdr.icmp6_option_link_layer_addr.type,
hdr.icmp6_option_link_layer_addr.ll_length,
hdr.icmp6_option_link_layer_addr.mac_addr
},
hdr.icmp6.checksum,
HashAlgorithm.csum16
);
\end{verbatim}
\centering
\caption{IPv4 Pseudo Header}
\label{fig:checksum}
\end{figure}
% ----------------------------------------------------------------------
\section{\label{Design:NetPFGA}NetFPGA}
While the P4-NetFPGA project \cite{netfpga:_p4_netpf_public_github}
allows compiling P4 to the NetPFGA, the design slightly varies.
In particular, the NetFPGA P4 compiler does not support reading
the payload. For this reason it also does not support
creating the checksum based on the payload.
To support checksum modifications in NAT64 on the NetFPGA, the
checksum was calculated on the netpfga using differences between
the IPv6 and IPv4 headers. Figure \ref{fig:checksumbydiff} shows an
excerpt of the code used for calculating checksums in the netpfga.
\begin{figure}[h]
\begin{verbatim}
action v4sum() {
bit<16> tmp = 0;
Netpfga live,
Vivado
SDNET
xx k lines of supporting code
tmp = tmp + (bit<16>) hdr.ipv4.src_addr[15:0]; // 16 bit
tmp = tmp + (bit<16>) hdr.ipv4.src_addr[31:16]; // 16 bit
tmp = tmp + (bit<16>) hdr.ipv4.dst_addr[15:0]; // 16 bit
tmp = tmp + (bit<16>) hdr.ipv4.dst_addr[31:16]; // 16 bit
\section{todo}
tmp = tmp + (bit<16>) hdr.ipv4.totalLen -20; // 16 bit
tmp = tmp + (bit<16>) hdr.ipv4.protocol; // 8 bit
\begin{verbatim}
***** Verschiedene design Möglichkeiten
***** Proxy und co.
***** Generell vs. spefizisch
meta.v4sum = ~tmp;
}
/* analogue code for v6sum skipped */
action delta_tcp_from_v6_to_v4()
{
v6sum();
v4sum();
bit<17> tmp = (bit<17>) hdr.tcp.checksum + (bit<17>) meta.v4sum;
if (tmp[16:16] == 1) {
tmp = tmp + 1;
tmp[16:16] = 0;
}
tmp = tmp + (bit<17>) (0xffff - meta.v6sum);
if (tmp[16:16] == 1) {
tmp = tmp + 1;
tmp[16:16] = 0;
}
hdr.tcp.checksum = (bit<16>) tmp;
}
\end{verbatim}
\centering
\caption{Calculating checksum based on header differences}
\label{fig:checksumbydiff}
\end{figure}
The checksums for IPv4, TCP, UDP and ICMP6 are all based on the
``Internet Checksum'' (\cite{rfc791}, \cite{rfc1071}). Its calculation
can be summarised as follows:
\begin{quote}
The checksum field is the 16-bit one's complement of the one's
complement sum of all 16-bit words in the header. For purposes of
computing the checksum, the value of the checksum field
is zero.\footnote{Quote from Wikipedia\cite{wikipedia:_ipv4}.}.
\end{quote}
As the calculation mainly depends on on (1-complement) sums, the
checksums after translating the protocol can be corrected by
subtracting the differences of the relevant fields. It is notable that
not the full headers are used, but the pseudo headers (compare figures
\ref{fig:ipv6pseudoheader} and \ref{fig:ipv4pseudoheader}).
To compensate the carry bit, our code uses 17 bit integers for
correcting the carry.

5
doc/Introduction.tex

@ -80,7 +80,6 @@ approach and \ref{fig:v6v4innetwork} shows our solution.
\caption{In Network NAT64 translation}
\label{fig:v6v4innetwork}
\end{figure}
\begin{figure}[h]
\includegraphics[scale=0.7]{v6-v4-standard}
\centering
@ -89,9 +88,9 @@ approach and \ref{fig:v6v4innetwork} shows our solution.
\end{figure}
Currently network operators have to focus on two network stacks when
designing networks: IPv6 and IPv4. While in a small scale setup this
might not introduce significant complexity, however figure
might not introduce significant complexity, figure
\ref{fig:v6v4mixed} shows how the complexity quickly grows
quickly with the number of nodes.
with the number of hosts.
\begin{figure}[h]
\includegraphics[scale=0.4]{v6-v4-mixed}
\centering

2
doc/Makefile

@ -9,7 +9,7 @@ all: all-graphviz
pdflatex $(FILE)
clean:
rm -f *.dvi *.log *.aux *.bbl *.blg *.toc *.lof *.lot *.cb *.~
rm -f *.dvi *.log *.aux *.bbl *.blg *.toc *.lof *.lot *.cb *.~ *.ilg *.nlo *.nls *.out *.glo
all-graphviz:
for dot in graphviz/*.dot; do make $${dot%%.dot}.png; done

50
doc/Results.tex

@ -2,53 +2,41 @@
%** Results.tex: What were the results achieved including an evaluation
%
The results from your evaluations.
\section{\label{results:general}General}
Parser for all protocols (udp,tcp,icmp,icmp6)
BMV2: more feature rich, but software only solution
NetFPGA: capabale of line speed Nat64, focused port on nat64
\begin{itemize}
\item Solution in P4/BMV2
\item Solution in P4/NetFPGA
\end{itemize}
\section{\label{Results:BMV2}BMV2}
Responds to icmp, icmp6
ndp
arp
test framework openvswitch
Fully functional host
Can compute checksums on its own.
\section{\label{results:tayga}Tayga}
\section{\label{Results:NetPFGA}NetFPGA}
General result: limited NAT64 is working, however
\subsection{\label{Results:NetPFGA:challenge-checksum}No Payload
checksumming}
Hash funktion in Arbeit
\subsection{\label{Results:NetPFGA:challenges}Other Challenges}
Many workarounds
3gbit
Table size 63, table size 64,
\section{\label{results:jool}Jool}
Table entries require arguments of all possible actions, not only used
one.
Compile time hours
Silent errors
Unclear errors: broken board
Due to the very fragile nature of the build framework from the
NetFPGA-Live repository,
Renaming VARIABLES in the definition of
\section{\label{Results:NetPFGA}NetFPGA}
General result: limited NAT64 is working, however
Reproducibility:
No Payload
checksumming - requires controller
\section{\label{Results:P4}P4}
Hash funktion in Arbeit
Limits if in actions
No NDP, no ARP - focused on key factors of NAT64 translation,
other features can be supported by controller
\section{\label{results:softwarenat64}NAT64 in Software}
Tayga, Jool

36
doc/graphviz/netpfgadesign.dot

@ -0,0 +1,36 @@
graph G {
node [ shape="box"];
rankdir="LR";
x520_1 [ label="X520: IPv4" ];
x520_2 [ label="X520: IPv6" ];
x520_nsg [ label="X520: Controller" ];
netpfga1 [ label="NetFPGA Port 1" ];
netpfga2 [ label="NetFPGA Port 2" ];
netpfga3 [ label="NetFPGA Port 3" ];
subgraph cluster_esprimo {
label="Load generator";
x520_1;
x520_2;
}
subgraph cluster_nsg {
label="NetFPGA Host";
netpfga1;
netpfga2;
netpfga3--x520_nsg;
}
x520_1--netpfga1;
x520_2--netpfga2;
}

BIN
doc/graphviz/netpfgadesign.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 16 KiB

19
doc/graphviz/switchdesign.dot

@ -0,0 +1,19 @@
graph G {
node [ shape="box"];
v4host [ label="IPv4 hosts" ]
v6host [ label="IPv6 hosts" ]
nat64gw [ label="P4 switch: NAT64" ];
controller [ label="P4 Controller" ];
nat64gw--v4host;
v6host--nat64gw;
nat64gw--controller [ label="custom protocol" ];
{ rank="same" nat64gw, controller };
}

BIN
doc/graphviz/switchdesign.png

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.8 KiB

18
doc/plan.org

@ -9286,15 +9286,15 @@ nico@nsg-System:~/projects/P4-NetFPGA/contrib-projects/sume-sdnet-switch/project
*** TODO Add comparison with other solutions (Results?)
*** TODO Show / create graph of a bigger network
*** Rough time table / effort
| | | Status |
| Abstract | 1 day | okayish |
| Introduction | 1 day | |
| Background | 1 day | |
| Design | 1-2 days | |
| Results | 2-3 days | |
| Conclusion | 1 day | |
| Proof reading | 2-3 days | |
| SUM(max) | 12d | |
| | | Status |
| Abstract | 1 day | okayish |
| Introduction | 1 day | okayish |
| Background | 1 day | okayish |
| Design | 1-2 days | 2019-08-12 |
| Results | 2-3 days | 2019-08-13 |
| Conclusion | 1 day | |
| Proof reading | 2-3 days | |
| SUM(max) | 12d | |
* DONE Initial administration
** DONE Clarify PDF / form with Denise Spicher: free form description
** DONE Create task description to be handed in mystudies

26
doc/refs/refs.bib

@ -83,3 +83,29 @@
author = {NGINX},
title = {NGINX | High Performance Load Balancer, Web Server, \& Reverse Proxy},
howpublished = {\url{https://www.nginx.com/}}}
@Misc{openvswitch,
author = {Linux Foundation},
title = {Open vSwitch},
howpublished = {\url{https://www.openvswitch.org/}}}
@Misc{wikipedia:_ipv4,
author = {Wikipedia},
title = {IPv4 header checksum},
howpublished = {\url{https://en.wikipedia.org/wiki/IPv4_header_checksum}},
note = {Requested on 2019-08-12}}
@Misc{schottelius:github1675,
author = {Nico Schottelius},
title = {Casting bit<16> to bit<32> in checksum causes incorrect json to be generated},
howpublished = {\url{https://github.com/p4lang/p4c/issues/1765}}}
@Misc{schottelius:github745,
author = {Nico Schottelius},
title = {Add access to table keys},
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/745}}}
@Misc{theojepsen:_get,
author = {theojepsen},
title = {Get size of header},
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/660}}}

2
p4src/actions_nat64_generic.p4

@ -1,4 +1,4 @@
#ifndef NICO_NAT64_GENERIC
xf#ifndef NICO_NAT64_GENERIC
#define NICO_NAT64_GENERIC
#include "actions_egress.p4"

Loading…
Cancel
Save