diff --git a/en/Makefile b/en/Makefile index f7bf2f8..35c1e29 100644 --- a/en/Makefile +++ b/en/Makefile @@ -13,7 +13,7 @@ abstract.pdf: abstract.tex abstract.xmpdata pdflatex $< verapdf_report.xml: thesis.pdf abstract.pdf verapdf_profile_UK7987v1c8.xml - verapdf --profile verapdf_profile_UK7987v1c8.xml thesis.pdf abstract.pdf >$@ + verapdf --profile verapdf_profile_UK7987v1c8.xml thesis.pdf abstract.pdf | tee $@ clean: rm -f *.log *.dvi *.aux *.toc *.lof *.lot *.out *.bbl *.blg *.xmpi diff --git a/en/bibliography.bib b/en/bibliography.bib index 88848b0..d481f35 100644 --- a/en/bibliography.bib +++ b/en/bibliography.bib @@ -11,6 +11,111 @@ % % =========================================================================== +@MISC{rfc5838, + shorthand = {{RFC5838}}, + series = {Request for Comments}, + number = 5838, + howpublished = {RFC 5838}, + publisher = {RFC Editor}, + doi = {10.17487/RFC5838}, + url = {https://www.rfc-editor.org/info/rfc5838}, + author = {Michael Barnes and Sina Mirtorabi and Rahul Aggarwal and Abhay Roy and Acee Lindem}, + title = {{Support of Address Families in OSPFv3}}, + pagetotal = 13, + year = 2010, + month = apr, + abstract = {This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs. {[}STANDARDS-TRACK{]}}, +} + +@misc{rfc8042, + series = {Request for Comments}, + number = 8042, + howpublished = {RFC 8042}, + publisher = {RFC Editor}, + doi = {10.17487/RFC8042}, + url = {https://www.rfc-editor.org/info/rfc8042}, + author = {Zhaohui (Jeffrey) Zhang and Lili Wang and Acee Lindem}, + title = {{OSPF Two-Part Metric}}, + pagetotal = 9, + year = 2016, + month = dec, + abstract = {This document specifies an optional OSPF protocol extension to represent router metrics in a multi-access network in two parts: the metric from the router to the network and the metric from the network to the router. For such networks, the router-to-router metric for OSPF route computation is the sum of the two parts. This document updates RFC 2328.}, +} + +@misc{rfc6919, + series = {Request for Comments}, + number = 6919, + howpublished = {RFC 6919}, + publisher = {RFC Editor}, + doi = {10.17487/RFC6919}, + url = {https://www.rfc-editor.org/info/rfc6919}, + author = {Eric Rescorla and Richard Barnes and Stephen Kent}, + title = {{Further Key Words for Use in RFCs to Indicate Requirement Levels}}, + pagetotal = 6, + year = 2013, + month = apr, + day = 1, + abstract = {RFC 2119 defines a standard set of key words for describing requirements of a specification. Many IETF documents have found that these words cannot accurately capture the nuanced requirements of their specification. This document defines additional key words that can be used to address alternative requirements scenarios. Authors who follow these guidelines should incorporate this phrase near the beginning of their document: The key words "MUST (BUT WE KNOW YOU WON\textbackslash{}'T)", "SHOULD CONSIDER", "REALLY SHOULD NOT", "OUGHT TO", "WOULD PROBABLY", "MAY WISH TO", "COULD", "POSSIBLE", and "MIGHT" in this document are to be interpreted as described in RFC 6919.}, +} + +@misc{rfc2328, + series = {Request for Comments}, + number = 2328, + howpublished = {RFC 2328}, + publisher = {RFC Editor}, + doi = {10.17487/RFC2328}, + url = {https://www.rfc-editor.org/info/rfc2328}, + author = {John Moy}, + title = {{OSPF Version 2}}, + pagetotal = 244, + year = 1998, + month = apr, + day = 1, + abstract = {This memo documents version 2 of the OSPF protocol. OSPF is a link- state routing protocol. {[}STANDARDS-TRACK{]}}, +} + +@misc{rfc5340, + series = {Request for Comments}, + number = 5340, + howpublished = {RFC 5340}, + publisher = {RFC Editor}, + doi = {10.17487/RFC5340}, + url = {https://www.rfc-editor.org/info/rfc5340}, + author = {Dennis Ferguson and Acee Lindem and John Moy}, + title = {{OSPF for IPv6}}, + pagetotal = 94, + year = 2008, + month = jul, + abstract = {This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. {[}STANDARDS-TRACK{]}}, +} + +% I have no idea where the abstract is from, but I do not care much. +@misc{rfc1131, + series = {Request for Comments}, + number = 1131, + howpublished = {RFC 1131}, + publisher = {RFC Editor}, + doi = {10.17487/RFC1131}, + url = {https://www.rfc-editor.org/info/rfc1131}, + author = {John Moy}, + title = {{The OSPF Specification}}, + pagetotal = 103, + year = 1989, + month = oct, + abstract = {This RFC is the specification of the Open Shortest Path First (OSPF) Internet routing protocol. OSPF is in the class of Internal Gateway Protocols (IGPs) for distributing routing information between gateways of a single Autonomous System. This routing protocol is based on the link-state approach (in contrast to the distance-vector approach). This specification was developed by the OSPF Working Group of the Internet Engineering Task Force. {[}STANDARDS-TRACK{]}}, +} + +@misc{BIRD, + url={https://bird.network.cz}, + urldate={2023-07-11}, + author={CZ.NIC Labs}, + title={{T}he {BIRD} {I}nternet {R}outing {D}aemon}, + howpublished= {Available at \url{https://bird.network.cz}}, + note={Accessed: 2023-07-11} +} + + +% Keeping the example bibliography for reference. Anything bellow is irrelevant. @BOOK{Andel07, title = {Základy matematické statistiky}, publisher = {Matfyzpress}, diff --git a/en/bibliography.tex b/en/bibliography.tex index 14591e9..c7280e8 100644 --- a/en/bibliography.tex +++ b/en/bibliography.tex @@ -9,8 +9,9 @@ %%% the name of the corresponding style file (*.bst). Both styles %%% mentioned in this template are included in LaTeX distributions. -\bibliographystyle{plainnat} %% Author (year) -% \bibliographystyle{unsrt} %% [number] +%\bibliographystyle{plainnat} %% Author (year) +% I wish I could have RFC-style [RFC6919] as the marker. But I cannot seem to be able to do that. +\bibliographystyle{unsrt} %% [number] \renewcommand{\bibname}{Bibliography} diff --git a/en/chap01.tex b/en/chap01.tex index 35852fd..8b13789 100644 --- a/en/chap01.tex +++ b/en/chap01.tex @@ -1,7 +1 @@ -\chapter{Title of the first chapter} -An~example citation: \cite{Andel07} - -\section{Title of the first subchapter of the first chapter} - -\section{Title of the second subchapter of the first chapter} diff --git a/en/chap02.tex b/en/chap02.tex index cb91071..7c3dd8b 100644 --- a/en/chap02.tex +++ b/en/chap02.tex @@ -1,5 +1,160 @@ -\chapter{Title of the second chapter} +\chapter{\X{Analysis?}} -\section{Title of the first subchapter of the second chapter} +In order to avoid as many problems as possible when visualising and +analysing a OSPF topology, we need to understand several aspects of networking, +the OSPF protocol and its implementation in BIRD. However, the aim of this +thesis is not to be a complete guide to OSPF nor BIRD, so we only describe +enough details to be able to reason about the design of the implementation. -\section{Title of the second subchapter of the second chapter} +\section{OSPF overview} + +OSPF is a link-state routing protocol, which means that routers try to understand +the whole topology of the network and find the best path using an algorithm for +finding the shortest paths. Usually, Dijkstra's algorithm \X{ref?} is used. +OSPF was designed to provide dynamic routing in a whole autonomous system, but +running it on a much smaller scale is also possible. + +OSPF requires routers to share information about the state of the topology in +messages called \emph{Link State Advertisements} (or LSAs for short). The LSAs +contain information about which network segments are adjacent \X{term} to which +router on which interfaces and with which routers it is possible to communicate +on those interfaces. To distinguish between routers, each router is assigned a +32-bit number called \emph{Router ID} by the network administrator \X{term}. +Router IDs are usually written in a quad-dotted notation \X{glos}. + +The LSAs are flooded throughout the system in order to let all the routers know +about the current topology. To avoid overloading the system just with this +routing traffic, OSPF devises several mechanisms of minimising the number of +exchanged messages. First, each network elects a \emph{designated router} (or +DR) which coordinates exchange of the messages in that network segment. +Second, the system can be partitioned into \emph{areas}. That way, the frequent +LSAs are only flooded throughout a limited set of networks; the \emph{area +border routers} send accumulated LSAs into other areas.\footnote{These +inter-area LSAs are called \uv{Summary LSAs}, but there is no requirement that +the routing information is actually aggregated.} These LSAs do not describe the +topology of the originating area. + +The area 0.0.0.0 is called the \emph{backbone area} and all other areas must be +adjacent to it, so that it has all the routing information. When this is +impractical, OSPF allows two routers to be connected using a \emph{virtual +link}. From the routing perspective, this is a point-to-point connection +between the routers in the backbone area. which allows to forward LSAs through +other areas even when these LSAs would not normally leave those areas. + +There are several types of networks that emerge in OSPF topologies. The +\emph{transit} networks are used for forwarding packets in an area. \emph{Stub} +networks only have one router and therefore can only deliver packets +originating from or destinated to that network. For representing routes outside +of the area and the whole system, OSPF recognises \emph{extra-area} and +\emph{external} networks respectively. It is also possible for a router to be +adjacent to an extra-area router through a point-to-point link. + +Once the router has complete information about the topology of an area, it +constructs a graph representation of the network and calculates the shortest path +DAG\footnote{In the specifications, it is called the shortest path \emph{tree}, +but there may be multiple shortest paths and the router is supposed to use all +of them.} rooted at that router. This DAG is then used for finding shortest +paths to routers and networks in that area, including the external, extra-area +and stub networks adjacent to that area. OSPF specifies that the graph has all +the networks and routers as vertices, directed edges lead from each router to the +incident network with the configured cost and from each transit network to +incident routers with cost 0 (except when the two-part metric\cite{rfc8042} is +implemented). There are no edges starting at the external, extra-area or stub +networks, so that the shortest path DAG calculation does not find paths +through them. + +The cost of the edge to an external network can be of two types. Type 1 cost is +specified in the same units as the internal costs, Type 2 cost is larger than +any internal or type 1 cost. + +The OSPF family of routing protocols has undergone long evolution since the +first specification in 1989\cite{rfc1131}, There are currently two versions of +the protocol in use -- versions 2 and 3. While the basic idea is still the +same, OSPFv2 can only handle IPv4 systems. While OSPFv3 claims to be +network-protocol-independent, it is usually only used with IPv6 systems and in +fact, features like virtual links can only be used with that network +protocol\cite{rfc5838}. + +Both OSPF versions have numerous extensions, as can be seen by the number of +RFCs that update the base specifications\cite{rfc2328,rfc5340}. Therefore, we +do not implement the protocol ourself, but rather find a suitable routing +daemon \X{glos} to determine the current topology. + +\section{Routing daemon selection} + +While we were mostly determined to use BIRD\cite{bird} from the start, since we already +had some experience with it, let us present here a short summary of other +possibilities. + +There are several implementations of both versions of the OSPF protocol. +However, many of them are tied to the specific router hardware, which makes it +impractical to connect to a graphical visualisation. Moreover, even evaulating +the feasibility would require us to obtain the specific hardware. Therefore, we +only consider hardware-independent solutions. + +While we are aware of several software implementations, many of these do not +seem to be developed anymore (Quagga\cite{quagga}, XORP\cite{xorp}, +OpenOSPFd\cite{openospfd}). Apart from BIRD, we only found FRRouting\cite{frr} +to be maintained, meaning that it had a release in the past year. While being +maintained is not a strict requirement, it would allow us to use that +implementation in case OSPF is extended again. + +However, even BIRD does not implement all the extensions, for example, the +two-part metric\cite{rfc8042}. + +\section{BIRD interface} + +The BIRD daemon is controlled through a UNIX domain socket using a text +line-based protocol slightly resembling SMTP\X{cite?}. The client may send +commands to the daemon, which provides responses. The response may be long and +possibly formatted into a table. This interface is primarily aimed at human +users, so a rather simple client, \texttt{birdc}, is provided in the BIRD's +package\X{glos?}. + +While there is a note of a machine-readable protocol in the +\texttt{doc/roadmap.md} file in BIRD's source code\cite{bird-src}, it is not +implemented, so we will need to interface using the socket. This has following +consequences, most of which are not very pleasant: + +\begin{itemize} +\item The responses to different formats often have completely different +formats. This necessitates creating a dedicated parsing routines for each kind +of command we want to use. +\item There is no guarantee that the output will not change between versions. +We might need to follow BIRD's development in order to be aware of possible +changes. +\item The output does not contain all details of BIRD's state. For example, we +can not retrieve the shortest path DAG directly from BIRD, nor see the details +of the individual LSAs. +\item There is no way to get notified when the topology changes. +\end{itemize} + +BIRD provides only a few commands that deal with OSPF: + +\begin{itemize} +\item \texttt{show ospf} shows a simple summary of the running instances of + OSPF, like which areas are they in or how many LSAs does BIRD currently + consider. +\item \texttt{show ospf interface} describes a current status of the individual + local interfaces: their configuration, designated routers for the incident + network, etc. +\item \texttt{show ospf neighbors} provides details about the state of + communication with adjacent routers. +\item \texttt{show ospf lsadb} returns details about known LSAs. Unfortunately, + this contains low-level information like checksums and sequence numbers, + but not details about networks or routers. +\item \texttt{show ospf state} shows an overal view of the ospf graph + representation: present routers and networks, costs of links, distances, \dots +\item \texttt{show ospf topology} seems to only provide a subset of the output + of \texttt{show ospf state}. For example, it does not provide info about + any non-transit networks. +\end{itemize} + +Even though some of the commands can have more parameters, parsing the output +of the \texttt{show ospf state} command is still the only the viable option of +getting a topology description. The following subsection describes the syntax of +the response to this command. + + + +\subsection{Retrieving the OSPF state} diff --git a/en/intro.tex b/en/intro.tex new file mode 100644 index 0000000..9eea01d --- /dev/null +++ b/en/intro.tex @@ -0,0 +1,34 @@ +\chapter*{Introduction} +\addcontentsline{toc}{chapter}{Introduction} + +\section{Terminology} + +\section{Notation} + +\section{Structure of the thesis} + +%- motivation +% -tgt audience of birdvisu +% - previous work / other approaches to network monitoring +% - Problem statement / project goals +% - Non-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 +%- Usage +%- Evaluation? +% - Home +% - KAM +%- Conclusion +% +% References? +% +% Glossary +% List of abbreviations diff --git a/en/macros.tex b/en/macros.tex index d2d2616..c658498 100644 --- a/en/macros.tex +++ b/en/macros.tex @@ -85,3 +85,6 @@ %%% Various table goodies \newcommand{\pulrad}[1]{\raisebox{1.5ex}[0pt]{#1}} \newcommand{\mc}[1]{\multicolumn{1}{c}{#1}} + +% Old habbits die hard. +\newcommand{\uv}[1]{\enquote{#1}} diff --git a/en/preface.tex b/en/preface.tex deleted file mode 100644 index b2e07f1..0000000 --- a/en/preface.tex +++ /dev/null @@ -1,3 +0,0 @@ -\chapter*{Introduction} -\addcontentsline{toc}{chapter}{Introduction} - diff --git a/en/thesis.tex b/en/thesis.tex index 2a10da4..140fc01 100644 --- a/en/thesis.tex +++ b/en/thesis.tex @@ -50,6 +50,7 @@ \usepackage{booktabs} % improved horizontal lines in tables \usepackage{paralist} % improved enumerate and itemize \usepackage{xcolor} % typesetting in color +\usepackage{csquotes} %% SPECIMEN % Parts marked as SPECIMEN are used for building the example PDF. @@ -62,31 +63,31 @@ %%% Basic information on the thesis % Thesis title in English (exactly as in the formal assignment) -\def\ThesisTitle{Thesis title \X{as in the formal assignment}} +\def\ThesisTitle{Visualizing OSPF topology} % Author of the thesis -\def\ThesisAuthor{Name Surname} +\def\ThesisAuthor{Pavel Turinský} % Year when the thesis is submitted -\def\YearSubmitted{YEAR} +\def\YearSubmitted{2023} % Name of the department or institute, where the work was officially assigned % (according to the Organizational Structure of MFF UK in English, % or a full name of a department outside MFF) -\def\Department{Name of the department \X{as per Organizational Structure of MFF UK in English}} +\def\Department{Department of Applied Mathematics} % Is it a department (katedra), or an institute (ústav)? \def\DeptType{Department} % Thesis supervisor: name, surname and titles -\def\Supervisor{Supervisor's Name \X{+titles}} +\def\Supervisor{Mgr. Martin Mareš, Ph.D.} % Supervisor's department (again according to Organizational structure of MFF) -\def\SupervisorsDepartment{department} +\def\SupervisorsDepartment{Department of Applied Mathematics} % Study programme and specialization -\def\StudyProgramme{study programme} -\def\StudyBranch{study branch} +\def\StudyProgramme{Computer Science} +\def\StudyBranch{General Computer Science} % An optional dedication: you can thank whomever you wish (your supervisor, % consultant, a person who lent the software, etc.) @@ -122,7 +123,7 @@ Abstract. \X{Recommended length around 80--200 words. This is not a~copy of your \tableofcontents %%% Each chapter is kept in a separate file -\include{preface} +\include{intro} \include{chap01} \include{chap02} diff --git a/en/thesis.xmpdata b/en/thesis.xmpdata index c9babd8..cab42c1 100644 --- a/en/thesis.xmpdata +++ b/en/thesis.xmpdata @@ -1,7 +1,7 @@ % Metadata to be stored in PDF, see documentation of the pdfx package for more details. -\Author{Name Surname} -\Title{Thesis title} +\Author{Pavel Turinský} +\Title{Visualizing OSPF topology} \Keywords{keywords\sep more such\sep yet another} \Subject{Abstract of thesis} \Publisher{Charles University}