nico/master-thesis
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity

Fix capitalisations

Browse source
This commit is contained in:
Nico Schottelius 2019-08-22 12:01:24 +02:00
parent 86de73a26e
commit 1b2717168f
5 changed files with 15 additions and 15 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

8
doc/Background.tex
View file

@ -449,7 +449,7 @@ circumvent. In the following sections, we describe the limitations and
explain how a translation mechanism like our NAT64 implementation
should be deployed.
% ----------------------------------------------------------------------
\subsection{\label{background:networkdesign:ipv4}IPv4 only network limitations}
\subsection{\label{background:networkdesign:ipv4}IPv4 Only Network Limitations}
As shown in figures \ref{fig:ipv4header} and \ref{fig:ipv6header}
the IPv4 address size is 32 bit, while the IPv6 address size is 128
bit.
@ -462,8 +462,8 @@ dependent translations can try to minimise the impact, accessing all
IPv6 addresses independent of the protocol is not possible.
% ok
% ----------------------------------------------------------------------
\subsection{\label{background:networkdesign:dualstack}Dualstack network
maintenance}
\subsection{\label{background:networkdesign:dualstack}Dualstack Network
Maintenance}
While dualstack hosts can address any host in either IPv6 or IPv4
networks, the deployment of dualstack hosts comes with a major
disadvantage: all network configurations double. The required routing
@ -480,7 +480,7 @@ So while there is the instant benefit of not requiring any transition mechanism
or translation method, we argue that the added complexity (and thus
operational cost) of running dual stack networks can be significant.
% ----------------------------------------------------------------------
\subsection{\label{background:networkdesign:v6only}IPv6 only networks}
\subsection{\label{background:networkdesign:v6only}IPv6 Only Networks}
IPv6 only networks are in our opinion the best choice for long term
deployments. Our reasons for this are the following: First of all hosts
eventually will need to support IPv6 and secondly

2
doc/Design.tex
View file

@ -353,7 +353,7 @@ with 20 sessions\\
\end{center}
\end{table}
% ----------------------------------------------------------------------
\section{\label{design:configuration}IPv6 and IPv4 configuration}
\section{\label{design:configuration}IPv6 and IPv4 Configuration}
The following sections refer to host and network configurations. In
this section we describe the IPv6 and IPv4 configurations as a basis
for the discussion.

2
doc/Introduction.tex
View file

@ -21,7 +21,7 @@ current state of IPv4 exhaustion and IPv6 adoption and describe how
it motivates our work to support to ease transition to IPv6 networks.
% ----------------------------------------------------------------------
\section{\label{introduction:ipv4ipv6}IPv4 exhaustion and IPv6 adoption}
\section{\label{introduction:ipv4ipv6}IPv4 Exhaustion and IPv6 Adoption}
The Internet has almost completely run out of public IPv4 space. The
5 Regional Internet Registries (RIRs) report IPv4 exhaustion worldwide
\cite{ripe_exhaustion},

4
doc/Results.tex
View file

@ -13,7 +13,7 @@ capabilities of NAT64 in hardware, no benchmarks were performed on the
P4 software implementation.
% ok
% ----------------------------------------------------------------------
\section{\label{results:p4}P4 based implementations}
\section{\label{results:p4}P4 Based Implementations}
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,
@ -386,7 +386,7 @@ to compilation errors. The P4 function syntax is not supported. For this
reason our implementation uses \texttt{\#define} statements instead of functions.
%ok
% ----------------------------------------------------------------------
\section{\label{results:softwarenat64}Software based NAT64}
\section{\label{results:softwarenat64}Software Based NAT64}
Both solutions Tayga and Jool worked flawlessly. However as expected,
both solutions are CPU bound. Under high load
scenarios both solutions utilise one core fully. Neither Tayga as a

14
doc/appendix.tex
View file

@ -35,7 +35,7 @@ Both tools need to be installed to \texttt{/opt/Xilinx/},
as paths are hardcoded in various places.
% ok
% ----------------------------------------------------------------------
\section{\label{chapterminus1:thesis}P4/NetFGPA support scripts}
\section{\label{chapterminus1:thesis}P4/NetFGPA Support Scripts}
To be able to compile P4 source code to the NetFPGA the collection of
scripts, Makefiles and sample code of P4-NetFGPA is required.
The repository \url{git@github.com:NetFPGA/P4-NetFPGA-live.git} needs
@ -63,7 +63,7 @@ v1.3.1-46-g97d3aaa
\end{verbatim}
% ok
% ----------------------------------------------------------------------
\section{\label{appendix:netfpga:compile}P4/NetFGPA compilation process}
\section{\label{appendix:netfpga:compile}P4/NetFGPA Compilation Process}
After having setup the compile host as described above, the script
\texttt{bin/do-all-steps.sh} that is included in the thesis' git
repository. With a NetFPGA card installed in the host, this script
@ -144,7 +144,7 @@ listening on enp2s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
\end{tiny}
% ok
% ----------------------------------------------------------------------
\subsection{Test 2: IPv6 egress}
\subsection{Test 2: IPv6 Egress}
This test shows how setting the egress port based on the IPv6 address
works with the NetPFGA. Similar to the previous test, we first the
the Integer values of the IPv6 addresses:
@ -221,7 +221,7 @@ listening on enp2s0f1, link-type EN10MB (Ethernet), capture size 262144 bytes
\end{tiny}
The packets are successfully seen by tcpdump.
% ----------------------------------------------------------------------
\section{\label{appendix:bmv2}P4/BMV2 environment and tests}
\section{\label{appendix:bmv2}P4/BMV2 Environment and Tests}
All BMV2 based compilations were made with the following compiler:
\begin{verbatim}
p4@ubuntu:~$ p4c --version
@ -361,7 +361,7 @@ nico@nsg-System:~/projects/P4-NetFPGA/contrib-projects/sume-sdnet-switch/project
\end{tiny}
% ok
% ----------------------------------------------------------------------
\section{\label{appendix:netfpgalogs:kernelmodule}NetFPGA Kernel module}
\section{\label{appendix:netfpgalogs:kernelmodule}NetFPGA Kernel Module}
After a successful flash, loading the kernel module will enable nf
devices to appear in the operating system.
\begin{tiny}\begin{verbatim}
@ -432,7 +432,7 @@ nico@nsg-System:~$
\end{verbatim}
\end{tiny}
% ----------------------------------------------------------------------
\section{\label{appendix:netfpgalogs:compilelogs}NetFPGA compile logs}
\section{\label{appendix:netfpgalogs:compilelogs}NetFPGA Compile Logs}
% ----------------------------------------------------------------------
This section shows a compilation of of NetFPGA compile output and errors.
@ -1220,7 +1220,7 @@ p4c 0.5 (SHA: 5ae30ee)```
%----------------------------------------------------------------------
\chapter{\label{benchmark}Benchmark Logs}
% ----------------------------------------------------------------------
\section{\label{benchmark:offset}Enabling hardware offloading}
\section{\label{benchmark:offset}Enabling Hardware Offloading}
The following commands enable hardware offloading even though error
messages are printed:
\begin{verbatim}