Results done.
This commit is contained in:
parent
acbb0836f3
commit
ea2a336c34
2 changed files with 50 additions and 44 deletions
|
@ -3,24 +3,19 @@
|
||||||
% document. What are the highlights of your work.
|
% document. What are the highlights of your work.
|
||||||
% It should conclude by a conclusion.
|
% It should conclude by a conclusion.
|
||||||
|
|
||||||
% General / Review
|
% Intro
|
||||||
The objective of implementing high speed NAT64 in P4 has been
|
The objective of implementing high speed NAT64 in P4 has been
|
||||||
achieved. The implementation at hand has been shown to be portable
|
achieved.
|
||||||
between 2 different P4 targets. It should be portable with minor
|
|
||||||
target specific changes to faster hardware to support NAT64 at much
|
|
||||||
higher line speeds, without any logic changes.
|
|
||||||
|
|
||||||
Our algorithm uses the IPv4-Compatible IPv6 Address~\cite{rfc4291} to
|
% our implementation!
|
||||||
embed IPv4 addresses. However RFC6052~\cite{rfc6052} defines different
|
Our implementation has been shown to be portable
|
||||||
embeddings depending on the prefix size. A future version should
|
between 2 different P4 targets and we expect it to be portable
|
||||||
support these schemes to be compatible to other implementations.
|
to other P4 targets, potentially at much higher speeds.
|
||||||
|
Our in-network solution allows novel translations
|
||||||
PMTU
|
without involving external routers, without involving
|
||||||
handling error cases
|
external routers.\footnote{Compare
|
||||||
No fragmentation
|
figures \ref{fig:v6v4standard} and \ref{fig:v6v4mixed}.}
|
||||||
No address / mac learning
|
We expect this to supporting migration to IPv6 only networks
|
||||||
|
|
||||||
supporting migration to IPv6 only networks
|
|
||||||
|
|
||||||
% P4
|
% P4
|
||||||
P4 has been proven for us as a suitable programming language for
|
P4 has been proven for us as a suitable programming language for
|
||||||
|
@ -30,42 +25,53 @@ work to become usable for solving day-to-day challenges or supporting
|
||||||
large scale projects. Even with the current state drawbacks, P4 is a
|
large scale projects. Even with the current state drawbacks, P4 is a
|
||||||
very convincing language that has wide range of applications due to
|
very convincing language that has wide range of applications due to
|
||||||
its protocol independence and easy to understand architecture.
|
its protocol independence and easy to understand architecture.
|
||||||
|
|
||||||
% NetPFGA
|
|
||||||
The NetFPGA platform is a good showcase for the capabilities of
|
|
||||||
P4, demonstrating almost line speed P4 programs.
|
|
||||||
However the supporting code immaturity, logging ambiguity
|
|
||||||
and enormous complexity of the development process.
|
|
||||||
|
|
||||||
Very time intensive development due to usability problems and
|
|
||||||
uncertainty of functionality (compare sections
|
|
||||||
\ref{results:netpfga:usability} and \ref{results:netpfga:stability}).
|
|
||||||
|
|
||||||
While the port to NetPFGA was significantly more effort then expected,
|
|
||||||
the learnings of the different layers were very much appreciated / liked
|
|
||||||
|
|
||||||
% Outlook OUTLOOK What are the consequences of your work for future work?
|
|
||||||
The availability of protocol independent programmable network
|
The availability of protocol independent programmable network
|
||||||
equipment opens up many possibilities for in network
|
equipment opens up many possibilities for in network
|
||||||
programming. While this thesis focused on NAT64, the accompanying
|
programming. While this thesis focused on NAT64, the accompanying
|
||||||
technology DNS64~\cite{rfc6147} could also be implemented in P4, thus
|
technology DNS64~\cite{rfc6147} could also be implemented in P4, thus
|
||||||
completing the translation mechanism.
|
completing the translation mechanism.
|
||||||
|
|
||||||
Proxies / higher level protocols could be next level
|
% NetPFGA
|
||||||
|
In our opinion, the
|
||||||
|
P4/NetFPGA platform is a good showcase for the capabilities of
|
||||||
|
P4, demonstrating near line speed P4 programs with good capabilities
|
||||||
|
of demonstrating scientific research.
|
||||||
|
However, the supporting code toolchain shows strong weaknesses that
|
||||||
|
render productive deployements difficult.
|
||||||
|
% ----------------------------------------------------------------------
|
||||||
|
% Outlook
|
||||||
|
|
||||||
Add helper in P4 to support checksum analysis a frequent problem and
|
While the project concluded successfully, there are a variety of
|
||||||
helper
|
possible improvements to our work as well to the used toolchains.
|
||||||
Allow ICMP6 option parsing: specify xtimes 64 bit blocks resulting in
|
|
||||||
an array
|
|
||||||
|
|
||||||
Adding support for passing on meta information to controller: key or
|
% Implementation
|
||||||
table
|
The implementation of our algorithm uses the IPv4-Compatible
|
||||||
|
IPv6 Address~\cite{rfc4291} to embed IPv4 addresses.
|
||||||
|
However RFC6052~\cite{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.
|
||||||
|
|
||||||
Support a meta language to define used types and/or export to popular languages.
|
% P4
|
||||||
Long term supporting python3 would be helpful. P4OS.
|
The P4 language has shown maturity, but the usability and ease of use
|
||||||
|
of the provided toolchains can be significantly improved. Additionally
|
||||||
|
we envision a stronger tie between the different tools in the P4
|
||||||
|
environment, like a collection of libraries and modules that could
|
||||||
|
form something on the line of a ``P4OS''. This operating system could
|
||||||
|
spawn over network switches with P4, provide a coherent library and
|
||||||
|
define data definitions that can be used in various programming
|
||||||
|
languages bindings.
|
||||||
|
|
||||||
|
% NetFPGA
|
||||||
|
The NetFPGA, from the hardware point of view,! is a very
|
||||||
|
interesting hardware platform. Reducing the difficulties
|
||||||
|
we experienced with the surrounding toolchain and making
|
||||||
|
development experience more consistent has the potential to not only
|
||||||
|
make NetFPGA, but also the who set of P4 hardware more interesting for
|
||||||
|
developers.
|
||||||
|
|
||||||
- react on FIN/RST (?) -- could be an addition
|
%% PMTU
|
||||||
P4os - reusable code
|
%% handling error cases
|
||||||
|
%% No fragmentation
|
||||||
Future work: session handling
|
%% No address / mac learning
|
||||||
|
%% session handling
|
||||||
|
|
BIN
doc/Thesis.pdf
BIN
doc/Thesis.pdf
Binary file not shown.
Loading…
Reference in a new issue