From 53d7a0dbf3bc02c6ff97bd789ea6af92c1fc45cf Mon Sep 17 00:00:00 2001 From: Pavel 'LEdoian' Turinsky Date: Fri, 14 Jul 2023 17:02:10 +0200 Subject: [PATCH] More intro --- en/intro.tex | 108 ++++++++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 103 insertions(+), 5 deletions(-) diff --git a/en/intro.tex b/en/intro.tex index 955169f..41f58aa 100644 --- a/en/intro.tex +++ b/en/intro.tex @@ -1,19 +1,116 @@ \chapter*{Introduction} \addcontentsline{toc}{chapter}{Introduction} -\section{Terminology} +Network administrators need to be aware of the +current state of their networks. While routing protocols like OSPF often need +to have complete information about the state of the networks, we did not find +an existing project that would visualise this data easily. We have therefore +created a rather simple program called Birdvisu, which aims to fill this hole. -\section{Notation} +Apart from visualising the topology, we provide the user with basic analysis +tools like showing the shortest path DAGs for routers. Furthermore, the +architecture of Birdvisu will allow enhancing the data from the routing +protocol with additional data, e.g. the utilization of particular links. -% Also note the use of Cisco icons +\X{mov?}While the primary motivation for implementing Birdvisu was the need of the +author, we believe that it might be useful for various OSPF deployments like +community wireless networks or homelabs\X{2x glos}. -\section{Structure of the thesis} +\section*{Terminology} +\addcontentsline{toc}{section}{Terminology} + +In this thesis, we use the word \emph{host} to mean a device connected to a +network and capable of processing (sending, receiving, forwarding, \dots) IP packets. + +An \emph{administrator} is a person or a group of people, who provide the +routers with configuration and who make sure that the routers (and other +infrastructure) functions correctly. + +The word \emph{network} will always denote a set of hosts, that can exchange +packets \uv{directly}, without forwarding, under normal circumstances. While +this is somewhat synonymous with the term \emph{network segment}, when the +network splits, there may be multiple link-layer segments belonging to the same +network. + +We say that a router is said to be \emph{incident} to a network when it has an +interface into it. For simplicity, we also say that that network is incident to +that router (that is, the incidence relation is symmetrical). We say that +a router is a \emph{neighbour} of another router, when they are incident to a +shared network, and conversely, that two networks are neighbours when they +share a router. + +We will use the word \emph{network system} (or just \emph{system}) to describe a +set of network managed by a single administrator, which is intended to forward +packets across it. This can mean the whole autonomous system\footnote{This is +where we borrowed the word \uv{system} from.}, but often this is a much smaller +part. When we speak about routing using OSPF, a system is only the set of +networks that run a single instance of OSPF. + +By the term \emph{IP} we mean the Internet Protocol of either version 4 or 6. +When it is important to distinguish, we explicitly write \emph{IPv4} or +\emph{IPv6}. IP may also denote an IP address, as in \uv{a router has an IP}, +but this usage should be clear from the context. + +We distinguish between \emph{routing} as the act of finding next hops\X{glos}, +and \emph{forwarding}, the act of sending a received packet through an +interface according to a \emph{routing table}. (Whether the routing table is +distinct from the network-layer forwarding table is an implementation detail.) + +A \emph{topology} describes the connections in the network system, i.e. which +router is connected to which networks, with what costs etc. We use the term +\emph{graph} only when talking about visualisation of the network to +distinguish between the real state and a virtual one. Moreover, in +section~\ref{s:net-idiosyncracies} we will see that a topology is in fact not a +graph (as understood by graph theory). + +\medskip + +We will be using many other networking terms, which we hope are well-known, but +for the sake of completeness, we provide a \hyperref[ch:glossary]{glossary} and +a \hyperref[ch:abbrs]{list of abbreviations} at the end of this thesis. + +\section*{Notation} +\addcontentsline{toc}{section}{Notation} + +We write filenames and commands in monospace font, like in \texttt{rm -rf +/bin}. Snippets of code are also written in monospace, but when we speak of a +particular class in text, it is only capitalised, as in \uv{The keys of the +dictionary are VertexIDs}. + +For network diagrams, we use the Network topology icons from +Cisco\cite{cisco-icons}. The basic icons are shown on +Figure~\ref{fig:basic-icons}. + +\begin{figure}[h] + \centering + \begin{subfigure}[b]{0.3\textwidth} + \centering + \X{Router} + \caption*{Router} + \end{subfigure} + \begin{subfigure}[b]{0.3\textwidth} + \centering + \X{Network} + \caption*{Network} + \end{subfigure} + \begin{subfigure}[b]{0.3\textwidth} + \centering + \X{Switch} + \caption*{Switch} + \end{subfigure} + \caption{Basic Cisco network icons} + \label{fig:basic-icons} +\end{figure} + +\section*{Structure of the thesis} +\addcontentsline{toc}{section}{Structure of the thesis} %- motivation % -tgt audience of birdvisu % - previous work / other approaches to network monitoring +% - And why we do not like them % - Problem statement / project goals -% - Non-goals +% - Non-goals and future goals %- Analysis / Survey (behaviour of computer networks) % - gennet as a method of testing behaviour % - OSPF @@ -24,6 +121,7 @@ % - Project structure / overview % - Annotators % - handles +% - Handling expected expansion %- Usage %- Evaluation? % - Home