Merge branch 'markdown' into 'master'

Markdown

See merge request cocsn/gosdn!1

documentation/README.md

+# Markdown Design Document
+
+Uses [pandoc](https://pandoc.org/MANUAL.html#pandocs-markdown) flavoured markdown.
+
+``` sh
+pandoc --filter pandoc-citeproc --bibliography=paper.bib --variable papersize=a4paper -s *.md -o paper.pdf
+```
+
+## Resources
+
+[How to 1](https://gist.github.com/maxogden/97190db73ac19fc6c1d9beee1a6e4fc8)
+
+[How to 2](https://v4.chriskrycho.com/2015/academic-markdown-and-citations.html)
+
+[How to 3](https://medium.com/@krzysztofczarnecki/i-wrote-my-thesis-in-markdown-heres-how-it-went-3f60140dfe65)
\ No newline at end of file

documentation/design-documentation/chapters/chapter01.tex

-\chapter{Introduction}
-\label{ch:intro}
-Lorem ipsum at nusquam appellantur his, labitur bonorum pri no \citep{dueck:trio}. His no decore nemore graecis. In eos meis nominavi, liber soluta vim cu. Sea commune suavitate interpretaris eu, vix eu libris efficiantur.
-
-%
-% Section: Motivation
-%
-\section{Motivation}
-\label{sec:intro:motivation}
-
-%
-% Section: Ziele
-%
-\section{Overarching Project Goals}
-\label{sec:intro:goal}
-
-\begin{enumerate}
-\item Keep It Simple, Stupid (KISS)
-\item Reuse existing technologies bits wherever possible
-\item Integrate state-of-the-art technologies and methodologies
-\item Document, Document, Document
-\item Automate almost everything right from the beginning
-\item be an excellent citizen: test, test, test
-\end{enumerate}
-
-Some unsorted thoughts the be ordered yet:
-\begin{enumerate}
-\item Storage of information in some external database, make use of database features, e.g., for state replication
-\item eye towards web-technologies/features, such as externalisation of state
-\item one API to "talk"  administratively to the network controller
-\item core of controller should be kept simple/lean, i.e., just the basic primitives
-\item core should be extended by modules to add functionality beyond basics
-\item modules should be loaded (or unloaded) during runtime of the controller core
-\end{enumerate}
-
-%
-% Section: Struktur der Arbeit
-%
-\section{Structure of this Memo}
-\label{sec:intro:structure}
-.

documentation/design-documentation/chapters/chapter02.tex

-\chapter{Related Work}
-\label{ch:related-work}
-Non vices medical da. Se qui peano distinguer demonstrate, personas internet in nos. Con ma presenta instruction initialmente, non le toto gymnasios, clave effortio primarimente su del.\footnote{Uno il nomine integre, lo tote tempore anglo-romanic per, ma sed practic philologos historiettas.} Nullam facilisis, massa ut faucibus vulputate, enim velit luctus nulla, a elementum ipsum metus eu sem. Sed a auctor quam. Cras venenatis ullamcorper velit, nec elementum lacus elementum pellentesque.
-
-%
-% Section: Der erste Abschnitt
-%
-\section{Der erste Abschnitt des Kapitels}
-\label{sec:background:first_section}
-Sia ma sine svedese americas. Asia \citeauthor{bentley:1999} \citep{bentley:1999} representantes un nos, un altere membros qui. De web nostre historia angloromanic. Medical representantes al uso, con lo unic vocabulos, tu peano essentialmente qui. Lo malo laborava anteriormente uso.
-
-\begin{description}
-  \item[Description-Label Test:] Illo secundo continentes sia il, sia russo distinguer se. Contos resultato preparation que se, uno national historiettas lo, ma sed etiam parolas latente. Ma unic quales sia. Pan in patre altere summario, le pro latino resultato.
-  \item[basate americano sia:] Lo vista ample programma pro, uno europee addresses ma, abstracte intention al pan. Nos duce infra publicava le. Es que historia encyclopedia, sed terra celos avantiate in. Su pro effortio appellate, o.
-  \item[Cras venenatis:] Purus et posuere lacinia, nisl sapien dapibus metus, a ornare enim odio in ipsum. Quisque imperdiet nibh metus, in fringilla tellus. Duis varius dui eget orci commodo ac sollicitudin est placerat. Cras varius tincidunt arcu, quis imperdiet nibh rhoncus vel. Sed non justo orci, non accumsan felis. Maecenas condimentum convallis. 
-\end{description}
-Tu uno veni americano sanctificate. Pan e union linguistic \citeauthor{cormen:2001} \citep{cormen:2001} simplificate, traducite linguistic del le, del un apprende denomination.
-
-\subsection{Ein Unterabschnitt}
-\label{subsec:background:first_section:first_subsection}
-Uno pote summario methodicamente al, uso debe nomina hereditage ma. Iala rapide ha del, ma nos esser parlar. Maximo dictionario sed al. Aenean posuere, enim in ultricies facilisis, ligula lacus eleifend eros, accumsan commodo metus justo placerat justo. Donec sit amet mauris dolor, at imperdiet lacus. In laoreet pretium condimentum. Proin ut varius diam. Fusce ipsum ipsum, elementum id porttitor at, pharetra congue nisi.
-
-\subsection{Ein weiterer Unterabschnitt}
-\label{subsec:background:first_section:second_subsection}
-Deler utilitate methodicamente con se. Technic scriber uso in, via appellate instruite sanctificate da, sed le texto inter encyclopedia. Ha iste americas que, qui ma tempore capital. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Proin vitae urna id metus vestibulum lobortis. Duis rhoncus pulvinar massa, eget venenatis justo dapibus sed. 
-
-%
-% Section: Der Zweite Abschnitt
-%
-\section{Ein zweiter Abschnitt}
-\label{sec:background:second_section}
-Phasellus ut ipsum nulla, vitae venenatis augue. Suspendisse potenti. Mauris suscipit justo a dolor laoreet lacinia. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Aliquam commodo commodo dui, nec auctor mi malesuada et. Aenean tortor erat, semper eu ullamcorper non, dignissim sed lectus. Praesent et pretium leo. 
-
-\subsection{Ein Unterabschnitt}
-\label{subsec:background:second_section:first_subsection}
-Vivamus at massa ut turpis dignissim mattis. Vivamus odio metus, venenatis vitae malesuada et, dignissim sed nunc. Mauris a nisl id massa viverra mattis in ultrices odio. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Curabitur quis metus ac sem venenatis dignissim nec.
-
-\subsubsection{Ein Unter-Unterabschnitt}
-\label{ssubsec:background:second_section:first_subsection:first_subsubsection}
-Sed vel ante vel quam commodo cursus. Class aptent taciti sociosqu ad litora torquent per conubia nostra, per inceptos himenaeos. Duis non turpis eget quam rutrum scelerisque. Duis nec quam metus. Curabitur purus dui, sagittis vel mattis a, elementum vitae risus. Pellentesque a tellus lacus, id gravida lectus.
-

documentation/design-documentation/chapters/chapter03.tex

-\chapter{Theoretical Underpinnings for SDN controllers}
-\label{ch:underpinnings}
-
-\section{What is a network at all?}
-\label{ch:underpinnings:network}
-
-Some loose thoughts for this chapter, as data networks consists out of:
-\begin{enumerate}
-	\item interfaces
-	\item links connecting interfaces
-	\item (network elements, or short elements. This comprises all types of devices attached to a network, such as hosts and (optical) switches
-	\item hosts having at least or n interfaces
-	\item hosts with ability to do forwarding decisions, e.g., an IP router on layer 3, an Ethernet-switch on layer 2, or an optical switch on layer 1 (i.e., wavelength)
-	\item differentiation between physical and logical links is needed, as
-	\begin{enumerate}
-		\item physical links cannot be changed by a software, as some entity has to change the physical connection, i.e., either a human or by robots (see~\cite{de-cix:robots} as one possible example).
-		\item logical links can be changed by a software, but the ways of doing so depend on~\ref{ch:underpinnings:network:changes}. 
-	\end{enumerate}
-	\item a logical link is tight to a physical link or to an underlying logical link (a case of recursion)
-	\item basic properties of links: directionality (uni or bi)
-		\begin{enumerate}
-		\item directionality (uni or bi)
-		\item point-to-point
-		\item point-to-multipoint (multicast or broadcast)
-		\item multi-point-to-multipoint (multicast or broadcast) (XXX is this really true?)
-	\end{enumerate}
-	\item configuration of interfaces
-	\item configuration of hosts
-	\item configuration of services on hosts
-	\item configuration of global parameters, i.e., the network
-\end{enumerate}
-
-\subsection{Can the network be changed during operation?}
-\label{ch:underpinnings:network:changes}
-
-Changes of device or service configurations -- this is intended for semi-static configurations:
-\begin{enumerate}
-	\item classical way: physical links can be changed by a software via the command line interface (CLI), e.g., a router can create a new IP~subnetwork on an interface via the CLI.
-	\item SDN way: physical links can be changed by a software via an Application Programming Interface (API), e.g., a router can create a new IP~subnetwork via an API
-\end{enumerate}
-
-Changes of forwarding behavior -- this is intended for dynamic configurations that require to keep state in the network:
-\begin{enumerate}
-	\item classical way: not possible, as human interaction is just too slow for any reaction.
-	\item network build-in: the control plane of a network device autonomously decides to change the flow forwarding behavior. Examples are: IP routing, firewalls and Network Address Translators (NATs). 
-	\item SDN way: forwarding behavior of the network can be changed via an API
-\end{enumerate}
-
-
-\subsection{Network Management}
-\label{ch:underpinnings:network:management}
-
-ISO/IEC ISO/IEC 7498-4, FCAPS, ITIL, Assets, configuration, etc 
-Configuration: Set, Query, Change etc. of configuration parameters
-
-\section{Requirements}
-\label{ch:underpinnings:requirements}
-
-Some requirements to be filed here. 
-
-\subsection{Basic properties of networks}
-\begin{enumerate}
-	\item recursion
-	\item abstraction
-\end{enumerate}

documentation/design-documentation/chapters/chapter05.tex

-\chapter{Implementation Aspects of the goSDN Controller}
-\label{ch:implementation-aspects}
-
-\section{Why we do this in go}
-

documentation/design/01-introduction.md

+---
+title: "goSDN"
+subtitle: "A networking drama"
+author: 
+  - "Martin Stiemerling"
+  - "Manuel Kieweg"
+bibliography: [./bibliography.bib]
+---
+
+# Introduction
+Lorem ipsum at nusquam appellantur his, labitur bonorum pri no [@dueck:trio]. His no decore nemore graecis. In eos meis nominavi, liber soluta vim cu. Sea commune suavitate interpretaris eu, vix eu libris efficiantur.
+
+## Motivation
+
+## Overarching Project Goals
+
+* Keep It Simple, Stupid (KISS)
+* Reuse existing technologies bits wherever possible
+* Integrate state-of-the-art technologies and methodologies
+* Document, Document, Document
+* Automate almost everything right from the beginning
+* be an excellent citizen: test, test, test
+
+Some unsorted thoughts the be ordered yet:
+
+* Storage of information in some external database, make use of database features, e.g., for state replication
+* eye towards web-technologies/features, such as externalisation of state
+* one API to "talk"  administratively to the network controller
+* core of controller should be kept simple/lean, i.e., just the basic primitives
+* core should be extended by modules to add functionality beyond basics
+* modules should be loaded (or unloaded) during runtime of the controller core
+
+
+## Structure of this Memo

documentation/design/02-related-work.md

+# Related Work
+
+## This
+
+### And that
\ No newline at end of file

documentation/design/03-theoretical-background.md

+# Theoretical Underpinnings for SDN controllers
+
+## What is a network at all?
+
+Some loose thoughts for this chapter, as data networks consists out of:
+
+* interfaces
+* links connecting interfaces
+* (network elements, or short elements. This comprises all types of devices attached to a network, such as hosts and (optical) switches
+* hosts having at least or n interfaces
+* hosts with ability to do forwarding decisions, e.g., an IP router on layer 3, an Ethernet-switch on layer 2, or an optical switch on layer 1 (i.e., wavelength)
+* differentiation between physical and logical links is needed, as
+	* physical links cannot be changed by a software, as some entity has to change the physical connection, i.e., either a human or by robots (see [@de-cix:robots] as one possible example).
+	* logical links can be changed by a software, but the ways of doing so depend on [network changes](#can-the-network-be-changed-during-operation). 
+	
+* a logical link is tight to a physical link or to an underlying logical link (a case of recursion)
+* basic properties of links: directionality (uni or bi)
+	* directionality (uni or bi)
+	* point-to-point
+	* point-to-multipoint (multicast or broadcast)
+	* multi-point-to-multipoint (multicast or broadcast) (XXX is this really true?)
+	* configuration of interfaces
+	* configuration of hosts
+	* configuration of services on hosts
+	* configuration of global parameters, i.e., the network
+
+
+### Can the network be changed during operation?
+
+Changes of device or service configurations -- this is intended for semi-static configurations:
+
+* classical way: physical links can be changed by a software via the command line interface (CLI), e.g., a router can create a new IP~subnetwork on an interface via the CLI.
+* SDN way: physical links can be changed by a software via an Application Programming Interface (API), e.g., a router can create a new IP~subnetwork via an API
+
+
+Changes of forwarding behavior -- this is intended for dynamic configurations that require to keep state in the network:
+
+* classical way: not possible, as human interaction is just too slow for any reaction.
+* network build-in: the control plane of a network device autonomously decides to change the flow forwarding behavior. Examples are: IP routing, firewalls and Network Address Translators (NATs). 
+* SDN way: forwarding behavior of the network can be changed via an API
+
+### Network Management}
+
+ISO/IEC ISO/IEC 7498-4, FCAPS, ITIL, Assets, configuration, etc 
+Configuration: Set, Query, Change etc. of configuration parameters
+
+## Requirements
+
+Some requirements to be filed here. 
+
+### Basic properties of networks
+
+* recursion
+* abstraction
+

documentation/design-documentation/chapters/chapter04.tex → documentation/design/04-conceptual-design.md

-\chapter{Conceptual Design of a SDN Controller as Network Supervisor}
-\label{ch:conceptual-design}
+# Conceptual Design of a SDN Controller as Network Supervisor
+
+
+## Conceptual Structures
 
-\section{Conceptual Structures}
-\label{ch:conceptual-design:structures}
 
 This section discusses the basic conceptual organization forms for data networks, as this seems to not clear in many contexts. The main purpose is to clarify what in a network has to be managed, how it has to be managed and by what entity it has to be managed. 
 
-\subsection{Principal Network Domain (PND)}
+### Principal Network Domain (PND)
 
 Any network consists out of basic components that are the collection of (network) elements used to form such particular network. These components, let it be any device attached to this network and the (physical) links, with their control-, data-, and management planes, form the Principal Network Domain (PND). A network controller can be
-\begin{enumerate} 
-\item directly in charge of the devices in the PND and thus be able to manage these network elements directly,
-\item or connect to a different lower network controller. The network controller would be only able to indirectly communicate with the network elements via the lower network controller or even, in case of a recursion of network controllers, only be able to talk to an even lower level network controller. 
-\end{enumerate}
+
+* directly in charge of the devices in the PND and thus be able to manage these network elements directly,
+* or connect to a different lower network controller. The network controller would be only able to indirectly communicate with the network elements via the lower network controller or even, in case of a recursion of network controllers, only be able to talk to an even lower level network controller.
 
 The differentiation between the PND and the following definitions of network domain, e.g., IP network, etc is important for the design of a network controller that is supervising a network in its whole. The PND is the concept used by the network controller to keep track of all hosts and links associated~\footnote{XXXwhat means \emph{associated} exactly?} to this controller. 
 
 A single controller may be in charge of multiple PNDs. 
 
-\subsection{Network Domain (ND)}
+### Network Domain (ND)
 
 A network domain is the collection of network elements and links connecting the elements while these entities, i.e., the elements and links, can be either physically or logical. Examples for
-\begin{enumerate} 
-\item physical entities: an Ethernet switch with Ethernet links or an optical switch with fibre connections
-\item logical entities: a VLAN-enabled Ethernet switch where the VLANs from a logical topology on top of the physical infrastructure. 
-\end{enumerate}
+
+* physical entities: an Ethernet switch with Ethernet links or an optical switch with fibre connections
+* logical entities: a VLAN-enabled Ethernet switch where the VLANs from a logical topology on top of the physical infrastructure. 
+
 
 A network domain is bound to a single PND. Network domains can be part of network domains, i.e., this is a case of recursion. 
 
-\section{Building Blocks}
-\label{ch:conceptual-design:collection}
+## Building Blocks
 
 Some conceptual building blocks for a network supervisor:
-\begin{description}
-	\item [principal element inventory] \hfill \\ This contains all known elements (such as end-hosts or network element as optical switches), independent of their relationship, of the network. This includes their hardware configuration, such as, interfaces attached to a particular host.
-	\item [principal topology inventory] \hfill \\  This contains all known links and their connection to interfaces of elements out of the principal element inventory.
-	\item [domain element inventory] \hfill \\ This contains the elements part of a particular network domain and it has to be a (sub)-set of the elements of the principal element inventory or a logical abstraction, such as a container or a virtual machine. 
-	\item [domain topology inventory] \hfill \\  This contains all known logical links and their connection to interfaces of elements out of the domain element inventory.
-	\item [host configuration] \hfill \\  This is based on the information provided by the host inventory and contains the actual operational configuration of the hosts. This will probably contain only the configuration of the network devices, such as, switches and routers, potentially also servers, but not end-hosts.		
-	\item [Network ] \hfill \\ 
-	\item [Network Configuration)] \hfill \\ 
-	\item [Southbound Interface (SBI)] \hfill \\ 
-	\item [Northbound Interface (SBI)] \hfill \\ 
-	\item [East-West-bound Interface (SBI)] \hfill \\ 
-\end{description}
+
+* **principal element inventory**
+	
+	This contains all known elements (such as end-hosts or network element as optical switches), independent of their relationship, of the network. This includes their hardware configuration, such as, interfaces attached to a particular host.
+
+* **principal topology inventory**
+
+	This contains all known links and their connection to interfaces of elements out of the principal element inventory.
+
+* **domain element inventory**
+
+	contains the elements part of a particular network domain and it has to be a (sub)-set of the elements of the principal element inventory or a logical abstraction, such as a container or a virtual machine. 
+
+* **domain topology inventory**
+
+  This contains all known logical links and their connection to interfaces of elements out of the domain element inventory.
+
+
+* **host configuration**
+
+  This is based on the information provided by the host inventory and contains the actual operational configuration of the hosts. This will probably contain only the configuration of the network devices, such as, switches and routers, potentially also servers, but not end-hosts.	
+
+* **Network**
+
+* **Network Configuration)** 
+
+* **Southbound Interface (SBI)** 
+
+* **Northbound Interface (SBI)** 
+
+* **East-West-bound Interface (SBI)**

documentation/design/05-implementation.md

+# Implementation Aspects of the goSDN Controller
+
+
+## Why we do this in go
+