Cleanups, update bib
This commit is contained in:
parent
6393127e84
commit
9eff2bf045
5 changed files with 91 additions and 51 deletions
|
@ -264,7 +264,7 @@ As described in section \ref{background:ip}, one of the major
|
|||
differences between IPv6 and IPv4 is the address length. As the whole
|
||||
IPv4 Internet can be represented in only 32 bits, it is a common
|
||||
practice to assign an IPv6 prefix for IPv6 hosts that represents a
|
||||
mapping to the whole IPv4 Internet. In RFC6052~\cite{rfc6502} the well
|
||||
mapping to the whole IPv4 Internet. In RFC6052~\cite{rfc6052} the well
|
||||
known prefix \textit{64:ff9b::/96} is defined that can be used for
|
||||
this purpose. One possibility to map
|
||||
an IPv4 address into the prefix is by adding its integer value to the
|
||||
|
@ -326,7 +326,7 @@ algorithm of RFC6052''.
|
|||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{background:transition:dns64}DNS64}
|
||||
Tightly related to NAT64 is a technology known as
|
||||
DNS64~\cite{rfc6174}. DNS64 tries to solve the problem of addressing
|
||||
DNS64~\cite{rfc6147}. DNS64 tries to solve the problem of addressing
|
||||
IPv4 only hosts from IPv6 only hosts
|
||||
by adding a ``fake'' IPv6 (AAAA) DNS resource record, as shown in
|
||||
figure \ref{fig:dns64}.
|
||||
|
|
|
@ -12,23 +12,24 @@ Our implementation has been shown to be portable
|
|||
between 2 different P4 targets and we expect it to be portable
|
||||
to other P4 targets, potentially at much higher speeds.
|
||||
Our in-network solution allows novel translations
|
||||
without involving external routers, without involving
|
||||
external routers.\footnote{Compare
|
||||
without involving external routers.\footnote{Compare
|
||||
figures \ref{fig:v6v4standard} and \ref{fig:v6v4mixed}.}
|
||||
We expect this to support migration to IPv6 only networks.
|
||||
|
||||
% P4
|
||||
P4 has been proven to us as a suitable programming language for
|
||||
network equipment with great potential. However in the current state
|
||||
network equipment and we think it has great potential for solving new
|
||||
and existing problems at line rates.
|
||||
However, in the current state
|
||||
the tooling and frameworks are still immature and need significant
|
||||
work to become usable for solving day-to-day challenges or supporting
|
||||
large scale projects. Even with the current state drawbacks, P4 is a
|
||||
very convincing language that has wide range of applications due to
|
||||
its protocol independence and easy to understand architecture.
|
||||
The availability of protocol independent programmable network
|
||||
equipment opens up many possibilities in network
|
||||
equipment opens up many possibilities for in-network
|
||||
programming. While this thesis focused on NAT64, the accompanying
|
||||
technology DNS64~\cite{rfc6147} could also be implemented in P4, thus
|
||||
technology DNS64 could also be implemented in P4, thus
|
||||
completing the translation mechanism.
|
||||
|
||||
% NetPFGA
|
||||
|
@ -41,13 +42,13 @@ render productive deployments difficult.
|
|||
% ----------------------------------------------------------------------
|
||||
% Outlook
|
||||
|
||||
While the project concluded successfully, there are a variety of
|
||||
While the project concluded successfully, we see
|
||||
possible improvements to our work as well to the used toolchains.
|
||||
|
||||
% Implementation
|
||||
The implementation of our algorithm uses the IPv4-Compatible
|
||||
IPv6 Address~\cite{rfc4291} to embed IPv4 addresses.
|
||||
However RFC6052~\cite{rfc6052} defines different
|
||||
IPv6 Address defined in RFC4291 to embed IPv4 addresses.
|
||||
However RFC6052 defines different
|
||||
embeddings depending on the prefix size. A future version should
|
||||
not only support more flexible embeddings, but also consider more in
|
||||
depth translation like ICMP/ICMP6 specifics.
|
||||
|
|
|
@ -364,17 +364,17 @@ NetPFGA mailing list, the NetFPGA only supports 1500 byte frames at
|
|||
the moment and additional work is required to implement support for
|
||||
bigger frames.
|
||||
|
||||
Our P4 source code required contains Xilinx
|
||||
Our P4 source code requires to 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 exceed the specified size:
|
||||
the output packet, if the incoming packets exceed the maximum packet size:
|
||||
\begin{itemize}
|
||||
\item The output packet is longer than the original packet.
|
||||
\item The output packet is corrupted.
|
||||
\end{itemize}
|
||||
|
||||
While most of the P4 language is supported on the netpfga, some key
|
||||
techniques are missing or not supported.
|
||||
While most of the P4 language is supported on the NetFPGA, some key
|
||||
techniques are currently missing or not supported.
|
||||
\begin{itemize}
|
||||
\item Analysing / accessing payload is not supported
|
||||
\item Checksum computation over payload is not supported
|
||||
|
@ -382,7 +382,7 @@ techniques are missing or not supported.
|
|||
\item Depending 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
|
||||
to compilation errors. The P4 function syntax is not supported. For this
|
||||
reason our implementation uses \texttt{\#define} statements instead of functions.
|
||||
%ok
|
||||
% ----------------------------------------------------------------------
|
||||
|
@ -400,7 +400,7 @@ and summarise the benchmarking results.
|
|||
% ----------------------------------------------------------------------
|
||||
\subsection{\label{results:benchmark:design}Benchmark Design}
|
||||
\begin{figure}[h]
|
||||
\includegraphics[scale=0.5]{softwarenat64design}
|
||||
\includegraphics[scale=0.6]{softwarenat64design}
|
||||
\centering
|
||||
\caption{Benchmark design for NAT64 in software implementations}
|
||||
\label{fig:softwarenat64design}
|
||||
|
@ -449,30 +449,34 @@ recorded by iperf for UDP based benchmarks, as TCP packets are confirmed and
|
|||
resent if necessary.
|
||||
|
||||
Tayga has the highest variation of results, which might be due to
|
||||
being fully CPU bound even in the simplest benchmark. Jool has less
|
||||
being fully CPU bound, even in the non-parallel benchmark. Jool has less
|
||||
variation and in general the P4/NetFPGA solution behaves almost
|
||||
identical in different benchmark runs.
|
||||
|
||||
The CPU load for TCP based benchmarks with Jool was almost negligible,
|
||||
however for UDP based benchmarks one core was almost 100\%
|
||||
utilised. In all benchmarks with tayga, one CPU was fully
|
||||
utilised. And as the translation for P4/NetFPGA happens within the
|
||||
utilised. When the translation for P4/NetFPGA happens within the
|
||||
NetFPGA card, there was no CPU utilisation visible on the NAT64 host.
|
||||
|
||||
We see lower bandwidth for translating IPv4 to IPv6 in all solutions.
|
||||
We suspect that this might be due to slighty increasing packet sizes that
|
||||
occur during this direction of translation. Not only does this vary
|
||||
the IPv4 versus IPv6 bandwidth, but it might also cause fragmentation
|
||||
to slowdown the process.
|
||||
that slows down.
|
||||
|
||||
During the benchmark with 1 and 10 parallel connections, no
|
||||
During the benchmarks with up to 10 parallel connections, no
|
||||
significant CPU load was registered on the load generator. However
|
||||
with 20 parallel connections, each of the two iperf
|
||||
processes\footnote{One for sending, one for receiving.} partially
|
||||
spiked to 100\% cpu usage, which with 50 parallel connections the cpu
|
||||
load of each process hit 100\% often.
|
||||
processes\footnote{The client process for sending, the server process for receiving.} partially
|
||||
spiked to 100\% cpu usage. With 50 parallel connections the cpu
|
||||
load of each process hit 100\% often. For this reason we argue that
|
||||
the benchmark results of the benchmarks with 20 or more parallel
|
||||
connections might be affected by the load generator limits. While
|
||||
there is no visible evidence in our results, this problem might become
|
||||
more significant with higher speed links.
|
||||
|
||||
While tayga's performance seems to reduce with the growing number of
|
||||
While tayga's performance is reduced with the growing number of
|
||||
parallel connections, both Jool and our P4/NetFPGA implementations
|
||||
vary only slighty.
|
||||
|
||||
|
|
BIN
doc/Thesis.pdf
BIN
doc/Thesis.pdf
Binary file not shown.
|
@ -1,73 +1,87 @@
|
|||
@Misc{ripe_exhaustion,
|
||||
author = {RIPE},
|
||||
title = {IPv4 Exhaustion},
|
||||
howpublished = {\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion}}}
|
||||
howpublished = {\url{https://www.ripe.net/publications/ipv6-info-centre/about-ipv6/ipv4-exhaustion}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{apnic_exhaustion,
|
||||
author = {APNIC},
|
||||
title = {APNIC’s IPv4 pool status},
|
||||
howpublished = {\url{https://www.apnic.net/community/ipv4-exhaustion/graphical-information/}}}
|
||||
howpublished = {\url{https://www.apnic.net/community/ipv4-exhaustion/graphical-information/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{google:_ipv6_googl,
|
||||
author = {Google},
|
||||
title = {IPv6 - Google},
|
||||
howpublished = {\url{https://www.google.com/intl/en/ipv6/statistics.html}}}
|
||||
howpublished = {\url{https://www.google.com/intl/en/ipv6/statistics.html}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{lacnic:_ipv4_deplet_phases,
|
||||
author = {LACNIC},
|
||||
title = {IPv4 Depletion Phases},
|
||||
howpublished = {\url{https://www.lacnic.net/1039/1/lacnic/ipv4-depletion-phases}}}
|
||||
howpublished = {\url{https://www.lacnic.net/1039/1/lacnic/ipv4-depletion-phases}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{afrinic:_afrin_ipv4_exhaus,
|
||||
author = {AFRINIC},
|
||||
title = {AFRINIC IPv4 Exhaustion},
|
||||
howpublished = {\url{https://afrinic.net/exhaustion}}}
|
||||
howpublished = {\url{https://afrinic.net/exhaustion}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{arin:_ipv4_addres_option,
|
||||
author = {ARIN},
|
||||
title = {IPv4 Addressing Options},
|
||||
howpublished = {\url{https://www.arin.net/resources/guide/ipv4/}}}
|
||||
howpublished = {\url{https://www.arin.net/resources/guide/ipv4/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{vyncke:_ipv6_deploy_aggreg_status,
|
||||
author = {Eric Vyncke},
|
||||
title = {IPv6 Deployment Aggregated Status},
|
||||
howpublished = {\url{https://www.vyncke.org/ipv6status/}}}
|
||||
howpublished = {\url{https://www.vyncke.org/ipv6status/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{cisco:_ipv6,
|
||||
author = {CISCO},
|
||||
title = {6lab - The place to monitor IPv6 adoption},
|
||||
howpublished = {\url{https://6lab.cisco.com/stats/}}}
|
||||
howpublished = {\url{https://6lab.cisco.com/stats/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{akamai:_ipv6_adopt_visual,
|
||||
author = {Akamai},
|
||||
title = {IPv6 Adoption Visualization},
|
||||
howpublished = {\url{https://www.akamai.com/us/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp#countries}}}
|
||||
howpublished = {\url{https://www.akamai.com/us/en/resources/our-thinking/state-of-the-internet-report/state-of-the-internet-ipv6-adoption-visualization.jsp#countries}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{wikipedia:_ipv6,
|
||||
author = {Wikipedia},
|
||||
title = {IPv6 transition mechanism},
|
||||
howpublished = {\url{https://en.wikipedia.org/wiki/IPv6_transition_mechanism}},
|
||||
note = {As requested on 2019-08-08}}
|
||||
note = {Requested on 2019-08-08}}
|
||||
|
||||
@Misc{_implem_your_switc_target_with_bmv2,
|
||||
author = {BMV2},
|
||||
title = {IMPLEMENTING YOUR SWITCH TARGET WITH BMv2},
|
||||
howpublished = {\url{http://www.bmv2.org/}}}
|
||||
howpublished = {\url{http://www.bmv2.org/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{netfpga:_p4_netpf_public_github,
|
||||
author = {NetFPGA},
|
||||
title = {P4-NetPFGA-Public repository at Github},
|
||||
howpublished = {\url{https://github.com/NetFPGA/P4-NetFPGA-public}}}
|
||||
howpublished = {\url{https://github.com/NetFPGA/P4-NetFPGA-public}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{networks:_tofin,
|
||||
author = {Barefoot Networks},
|
||||
title = {Barefoot Tofino2},
|
||||
howpublished = {\url{https://barefootnetworks.com/products/brief-tofino-2/}}}
|
||||
howpublished = {\url{https://barefootnetworks.com/products/brief-tofino-2/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{networks:_tofin1,
|
||||
author = {Barefoot Networks},
|
||||
title = {Barefoot Tofino},
|
||||
howpublished = {\url{https://www.barefootnetworks.com/products/brief-tofino/}}}
|
||||
howpublished = {\url{https://www.barefootnetworks.com/products/brief-tofino/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{networks:_arist_series,
|
||||
author = {Arista Networks},
|
||||
|
@ -78,22 +92,29 @@
|
|||
@Misc{lutchansky:_tayga_simpl_nat64_linux,
|
||||
author = {Nathan Lutchansky},
|
||||
title = {TAYGA - Simple, no-fuss NAT64 for Linux},
|
||||
howpublished = {\url{http://www.litech.org/tayga/}}}
|
||||
howpublished = {\url{http://www.litech.org/tayga/}}
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{mexico:_jool_open_sourc_siit_nat64_linux,
|
||||
author = {NIC Mexico},
|
||||
title = {Jool an Open Source SIIT and NAT64 for Linux.},
|
||||
howpublished = {\url{https://www.jool.mx/en/index.html}}}
|
||||
howpublished = {\url{https://www.jool.mx/en/index.html}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{vanbever:_progr_networ_data_planes,
|
||||
author = {Laurent Vanbever},
|
||||
title = {Programming Network Data Planes},
|
||||
howpublished = {\url{https://github.com/nsg-ethz/p4-learning/blob/master/slides/02_p4_env.pdf}}}
|
||||
howpublished = {\url{https://github.com/nsg-ethz/p4-learning/blob/master/slides/02_p4_env.pdf}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{ungleich:_ipv4,
|
||||
author = {ungleich},
|
||||
title = {Die IPv4, die!},
|
||||
howpublished = {\url{https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/}}}
|
||||
howpublished = {\url{https://ungleich.ch/en-us/cms/blog/2019/01/09/die-ipv4-die/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{ungleich:networkinfrastructure,
|
||||
|
@ -105,12 +126,17 @@
|
|||
@Misc{nginx:_nginx_high_perfor_load_balan,
|
||||
author = {NGINX},
|
||||
title = {NGINX | High Performance Load Balancer, Web Server, \& Reverse Proxy},
|
||||
howpublished = {\url{https://www.nginx.com/}}}
|
||||
howpublished = {\url{https://www.nginx.com/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{openvswitch,
|
||||
author = {Linux Foundation},
|
||||
title = {Open vSwitch},
|
||||
howpublished = {\url{https://www.openvswitch.org/}}}
|
||||
howpublished = {\url{https://www.openvswitch.org/}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
|
||||
@Misc{wikipedia:_ipv4,
|
||||
author = {Wikipedia},
|
||||
|
@ -121,17 +147,22 @@
|
|||
@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}}}
|
||||
howpublished = {\url{https://github.com/p4lang/p4c/issues/1765}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{schottelius:github745,
|
||||
author = {Nico Schottelius},
|
||||
title = {Add access to table keys},
|
||||
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/745}}}
|
||||
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/745}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
@Misc{theojepsen:_get,
|
||||
author = {theojepsen},
|
||||
title = {Get size of header},
|
||||
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/660}}}
|
||||
howpublished = {\url{https://github.com/p4lang/p4-spec/issues/660}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{wikipedia:_solic,
|
||||
author = {Wikipedia},
|
||||
|
@ -142,8 +173,8 @@
|
|||
@Misc{schottelius:thesisrepo,
|
||||
author = {Nico Schottelius},
|
||||
title = {High speed NAT64 in P4 (git repository)},
|
||||
howpublished = {\url{https://gitlab.ethz.ch/nsg/student-projects/ma-2019-19_high_speed_nat64_with_p4}}}
|
||||
|
||||
howpublished = {\url{https://gitlab.ethz.ch/nsg/student-projects/ma-2019-19_high_speed_nat64_with_p4}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{nico18:_implem_layer_ipv4_ipv6_rever_proxy,
|
||||
|
@ -155,12 +186,16 @@
|
|||
@Misc{schottelius:_exter_p4_netpf,
|
||||
author = {Nico Schottelius},
|
||||
title = {Extern for checksum'ing payload (P4-NetPFGA-public)},
|
||||
howpublished = {\url{https://github.com/NetFPGA/P4-NetFPGA-public/issues/13}}}
|
||||
howpublished = {\url{https://github.com/NetFPGA/P4-NetFPGA-public/issues/13}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{hendrik:_p4_progr_fpga_semes_thesis_sa,
|
||||
author = {Hendrik Züllig, Supervisor; Prof. Dr. Laurent Vanbever; Tutor: Tobias Bühler},
|
||||
title = {P4-Programming on an FPGA, Semester Thesis SA-2019-02},
|
||||
howpublished = {\url{https://gitlab.ethz.ch/nsg/student-projects/sa-2019-02_p4_programming_sume_netfpga/blob/master/SA-2019-02.pdf}}}
|
||||
howpublished = {\url{https://gitlab.ethz.ch/nsg/student-projects/sa-2019-02_p4_programming_sume_netfpga/blob/master/SA-2019-02.pdf}},
|
||||
note = {Requested on 2019-08-22}}
|
||||
|
||||
|
||||
@Misc{wikipedia:_jumbo,
|
||||
author = {Wikipedia},
|
||||
|
|
Loading…
Reference in a new issue