\chapter*{Introduction}
\addcontentsline{toc}{chapter}{Introduction}

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.

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.

\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*{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-unusual} 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}

In the \hyperref[ch:motivation]{first} chapter, we explore various approaches of visualising and
monitoring a network system. Then, in chapter \ref{ch:analysis}, we understand the
behaviour of relevant networking technologies. From that, we derive a design
for Bidrvisu in chapter \ref{ch:design}. Chapter \ref{ch:usage} explains usage
of the program. At the end, we demonstrate how the project works in network
systems of various sizes.

%- 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 and future goals
%- Analysis / Survey (behaviour of computer networks)
%	- gennet as a method of testing behaviour
%	- OSPF
%	- BIRD + caveats
%	- Idiosyncracies of
%- Design
%	- Technologies
%	- Project structure / overview
%	- Annotators
%	- handles
%	- Handling expected expansion
%- Usage
%- Evaluation?
%	- Home
%	- KAM
%- Conclusion
%
% References?
%
% Glossary
% List of abbreviations