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 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}
\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, firewwalls 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 

\section{Requirements}
\label{ch:underpinnings:requirements}

Some requirements to be filed here.