From 1b2717168ff334e637ad08343d9a10eab784e398 Mon Sep 17 00:00:00 2001 From: Nico Schottelius Date: Thu, 22 Aug 2019 12:01:24 +0200 Subject: [PATCH] Fix capitalisations --- doc/Background.tex | 8 ++++---- doc/Design.tex | 2 +- doc/Introduction.tex | 2 +- doc/Results.tex | 4 ++-- doc/appendix.tex | 14 +++++++------- 5 files changed, 15 insertions(+), 15 deletions(-) diff --git a/doc/Background.tex b/doc/Background.tex index 27bdfbf..ddfa812 100644 --- a/doc/Background.tex +++ b/doc/Background.tex @@ -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 diff --git a/doc/Design.tex b/doc/Design.tex index 48f8ed9..9492fde 100644 --- a/doc/Design.tex +++ b/doc/Design.tex @@ -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. diff --git a/doc/Introduction.tex b/doc/Introduction.tex index f2d190e..2abe633 100644 --- a/doc/Introduction.tex +++ b/doc/Introduction.tex @@ -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}, diff --git a/doc/Results.tex b/doc/Results.tex index 2c89fc7..e8413f5 100644 --- a/doc/Results.tex +++ b/doc/Results.tex @@ -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 diff --git a/doc/appendix.tex b/doc/appendix.tex index 8d104e7..6edd2a0 100644 --- a/doc/appendix.tex +++ b/doc/appendix.tex @@ -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}