\chapter{Traffic Management}
\label{ch:physical}

This chapter discusses data communications in IP networks at OSI network layer and link layer levels. Section~\ref{sec:qos_and_gos} describes different types of IP network traffic, introducing terms Quality of Service and Grade of Service. In section~\ref{sec:service_model}, the development of a new service model for IP networks is discussed. Section~\ref{sec:performancemanagement} discusses performance management and performance related issues.

\section{Communications in IP networks}
\label{sec:qos_and_gos}

Data communications in IP networks can be divided into \textit{connectionless} and \textit{connection-oriented communications}. Communications based on the Internet Protocol (IP) is connectionless by nature. This means that no end-to-end connection is established before data is transmitted by the protocol~\cite[page 13]{a41}. In IP networks, \textit{Quality of Service (QoS)} \index{Quality of Service (QoS)} is defined in terms of parameters such as bandwidth, delay, delay variation (jitter), and packet loss probability~\cite{a43}.

Connection-oriented communications in IP networks is enabled by protocols built upon the connectionless IP. This means that a logical connection between communicating network nodes is established before transmission~\cite[page 20]{a41}. \textit{Grade of Service (GoS)} \index{Grade of Service (GoS)} \footnote{Grade of Service (GoS) is traditionally related to \textit{connection-oriented telecommunications}. In this document, GoS is used also in the context of IP networks.} is defined in terms of connection blocking probability (i.e. the probability of failing to establish a connection). Connection blocking can be controlled using \textit{Connection Admission Control} (see page~\pageref{cac}).


\subsection{Different types of traffic}

Traffic in IP networks is composed of individual transactions and flows. A flow is a sequence of packets belonging to an instance of application running between hosts. Flows can be divided into two categories: \textit{stream flows} \index{Flows!stream flows} and \textit{elastic flows} \index{Flows!elastic flows}.

\textbf{Stream flows} are generated by real-time audio and video applications such as Internet phone and video conferencing. These applications may require a minimum level of QoS in order to function properly, and thus would benefit from guaranteed QoS.

\textbf{Elastic flows} are generated by non-real-time applications (e.g. e-mail and FTP). They don't state critical demands on QoS, but adjust their rates to make full use of QoS available~\cite{a45}.



\section{New service model for IP networks}
\label{sec:service_model}

The current IP architecture does not support any QoS guarantees because routing is traditionally based on a best-effort principle. This means that each packet of information is treated independently and processed in the order of arrival~\cite{a43}.

The diversity of applications and their requirements raises a need to develop a new service model for IP networks. The purpose would to satisfy the requirements of rigid real-time applications while avoiding costs of over-provisioning\footnote{According to S. Shenker in~\cite{148}, over-provisioning is not cost-effective in networks with real-time applications because of high variance in traffic.} This could be done by introducing a service model with several classes of QoS instead of a single class of best-effort service.

The Internet Engineering Task Force (IETF) has three working groups developing the new service model or network architecture. These working groups are described and compared in following subsections. Also Traffic Engineering/Constraint-based Routing approach is discussed. The relationship between OSI layers and concepts described in this section are illustrated in figure~\ref{fig:qos_framework}.


\begin{figure}[htb]
\begin{center}
\epsfxsize1.0\textwidth
\epsfbox{kuvat/qos_framework}
\caption{The relationship between OSI layers and concepts described in section~\ref{sec:service_model}~\cite{a49}.}
\label{fig:qos_framework}
\end{center}
\end{figure}


\subsection{IETF Integrated Services architecture}

IETF Integrated Services (IntServ) \index{Integrated Services (IntServ)} working group\footnote{http://www.ietf.org/html.charters/intserv-charter.html} is currently defining an enhanced service model which involves creating two service classes in addition to best-effort service: \textit{Guaranteed service} for applications requiring fixed delay bound, and \textit{controlled-load service} for applications that require reliable and enhanced best-effort service. The model is based on resource reservation initiated by applications. This could be done e.g. using \textit{Resource Reservation Protocol}\footnote{See~\cite{rfc2210} for the use of Resource Reservation Protocol with Integrated Services architecture.}~\cite{a46,a49}.

\textbf{Resource Reservation Protocol (RSVP)} \index{Resource Reservation Protocol (RSVP)} is used to signal routers in the network to reserve resources and set up a path for a flow~\cite{a48, a49}. If RSVP is used in the network, there should be a mechanism to manage resource reservation policies of applications that initiate the reservation.  RSVP and resource reservation are further discussed in~\cite[ch. 13]{a48} and in~\cite{123}. Standardization of RSVP can be found in~\cite{rfc2205}.

\label{cac}
To provide QoS allocated by a reservation protocol, \textbf{Connection Admission Control (CAC)} \index{Connection Admission Control (CAC)} should be used in routers.  CAC functions by blocking incoming stream flows\footnote{ According to L. Massouli� and J. Roberts in~\cite{a42}, CAC should also be used for elastic flows. They argue that there is a minimum acceptable level of throughput for elastic flows, below which users gain no utility. Besides preserving QoS, CAC would also prevent instability and congestion collapses caused by uncontrolled retransmission of lost packets~\cite[pages 33--34]{a42}.  }if the increase in traffic would drop QoS below an acceptable level for that or any previously accepted flow. On the other hand, CAC affects also on GoS, as the level of GoS is decreased when connections are refused~\cite[page 33]{a42}.

Besides the benefits, CAC bears one disadvantage: Implementation of CAC would increase the complexity of networks, already complex enough. Discussion on the benefits and disadvantages of CAC can be found in~\cite{148}.

According to~\cite{a49} the Integrated Services architecture has several problems: It doesn't scale well, states high requirements on routers, and requires ubiquitous deployment for guaranteed service. According to~\cite{a57} the architecture is suitable only for small networks (e.g. corporate networks or Virtual Private Networks (VPNs)), not for Internet backbone networks.


\subsection{Differentiated Services architecture}

The approach of IETF Differentiated Services (DiffServ) \index{Differentiated Services (DiffServ)} working group\footnote{http://www.ietf.org/html.charters/diffserv-charter.html} involves creating distinct Classes of Service (CoS), each with reserved resources. The basic difference between IntServ and DiffServ architectures is that while IntServ provides an absolute level of QoS, DiffServ is a relative-priority scheme\footnote{Admission Control is not used in DiffServ architecture. Thus only priorities between different classes are guaranteed. Within each class, packets receive best-effort service.}. Secondly, in DiffServ the QoS in each CoS is defined by an agreement between customer and service provider. This eliminates the need of each application to signal their QoS needs at run time. It also provides better scalability as there is no need to maintain per flow state information in routers~\cite{a47,a49,a52}.

In Differentiated Services, each packet of information is classified by marking the \textit{DS field} \index{Differentiated Services (DiffServ)!DS field} \footnote{The DS field stands for Type of Service (TOS) byte in IPv4 and for Traffic Class byte in IPv6.} in IP datagram. Packets receive their forwarding treatment, or per-hop behavior, according to the classification. The use of the DS field is standardized in~\cite{rfc2474} and in~\cite{rfc2475}. A small number of per-hop behaviors will also be defined by the working group~\cite{a47,a49}.

According to~\cite{a49}, DiffServ is more scalable, requires less from routers, and is easier to deploy than IntServ architecture. In~\cite{a57} the DiffServ architecture, it's possible drawbacks, and related issues are discussed more widely.


\subsection{Multi-protocol Label Switching architecture}
\label{subsec:mpls}

Multi-protocol Label Switching (MPLS) \index{Multi-protocol Label Switching (MPLS)} architecture is being standardized by IETF MPLS working group\footnote{http://www.ietf.org/html.charters/mpls-charter.html}. MPLS is a forwarding scheme that is based on a label-swapping forwarding (label switching) paradigm instead of standard destination-based hop-by-hop forwarding paradigm~\cite{a53,a51}.

Each packet arriving to an ingress router of an MPLS domain\footnote{An MPLS domain consists of MPLS-capable routers, called Label Switching Routers (LSRs).} is routed, classified, and given a label\footnote{Labels are distributed to set up Label Switched Paths (LSPs) using Label Distribution Protocol (LDP)~\cite{a49}.}. Inside the MPLS domain forwarding decisions are made using the label instead of processing the packet header and running a routing algorithm. The label is used as an index to a forwarding table\footnote{Forwarding table is constructed as the result of label distribution~\cite{a49}.} where the next hop and a new label can be found. The old label is replaced with the new one and the packet is forwarded. The label is removed as the packet leaves the MPLS domain~\cite{a50}.

MPLS labels can be used to provide forwarding along an explicit route, and to identify packets to receive certain QoS. An efficient tunneling mechanism is also provided. These features make MPLS useful for traffic engineering~\cite{a49,a53}.

A disadvantage of MPLS is that it should be extensively deployed, i.e. the MPLS domain of the network should be relatively big. Otherwise MPLS offers no benefit.

% Explicit routes may be useful to support policy routing and traffic
% engineering~\cite{a50}.


%\textbf{Management aspects:}
%\begin{itemize}
%\item Does MPLS add something to management?
%\end{itemize}


\subsection{Traffic Engineering and Constraint-based Routing}

Dynamic routing protocols such as RIP \index{Dynamic routing protocols!RIP} \footnote{Routing Information Protocol, see~\cite[ch. 4]{a48}.}, OSPF \index{Dynamic routing protocols!OSPF} \footnote{Open Shortest Path First, see~\cite[ch. 5]{a48}.}, and IS-IS \index{Dynamic routing protocols!IS-IS} \footnote{Intra-Domain Intermediate System to Intermediate System Routing, see~\cite[ch. 6]{a48}.} can cause uneven traffic distribution. \textit{Traffic Engineering} is the process of arranging how traffic flows through the network so that congestion caused by uneven network utilization can be avoided''~\cite{a49}.

\textit{Constraint-based Routing} \index{Constraint-based Routing} can be used to make the traffic engineering process automatic. It enables computing routes that are subject to multiple constraints such as resource availability, QoS requirements, and other policies~\cite{a49}.

Constraint-based Routing increases the size of routing tables, and may introduce instability as routing tables change frequently~\cite{a49}. Thus it should be considered whether it offers any benefit or just consumes more resources.


\subsection{Difficulties in development of a new service model}

The nature of the Internet is decentralized and heterogenous. This causes several problems that need to be solved before new technologies can be deployed:

\begin{itemize}

\item Inter-domain QoS guarantees, CoS classifications, and the involved interaction between Internet Service Providers (ISPs) may represent problems due to different policies and diverse architectures of underlying networks.

\item Usage of new services should be charged, otherwise they offer no benefit\footnote{Charging would ensure only the most performance-sensitive applications would request higher service.}. Charging for network usage in the Internet with a large number of ISPs might be difficult.

\item Some proposed technologies demand ubiquitous deployment in order offer any benefit. However, big changes to the best-effort architecture currently in use are difficult, perhaps impossible to deploy.

\end{itemize}

Some of these problems and other aspects related to development of new service model are addressed in~\cite{148} and it's references 4, 8, 30, and 37.



% Liisan viitteet
%
%1. RFC 1633: Integrated Services in the Internet Architecture: an Overview
%   ftp://ftp.isi.edu/in-notes/rfc1633.txt
%2. Ursula Schwantag: An Analysis of the Applicability of RSVP
%   http://network-services.uoregon.edu/~ursula/thesis/thesis.html
%

\section{Performance management}
\label{sec:performancemanagement}

\index{Performance management} Performance management is used to evaluate the behavior of managed objects and the efficiency of communications activities. It is collecting statistical data, analyzing it, and where appropriate, predicting trends of communications between open systems~\cite{b42}.

A network performance management system must be able to provide reports on the efficiency of the system and its current and previous performance. Reports on a daily, monthly and annual basis are needed.

Performance management is also controlling traffic in the network. It consumes resources, and thus a separate control station is usually needed to collect and analyze traffic statistics. However, controlling traffic is a reliable and cost-effective method to find out problems before they exist. Traffic controlling can be limited to the most important parts of the network~\cite{b2}.

Performance management is related also to configuration management. It is easier for the operator to plan modifications of the network when the usage of the network is known.

\subsection{Performance analysis}

Network performance analysis \index{Performance management!performance analysis} becomes important when the network increases in size and complexity. Analyzers are used for traffic monitoring, protocol analysis and statistics collection and interpretation of performance-related data. Analyzers are understood as troubleshooting tools, but they should be used as proactive indicators as well.

The analyzers available typically gather and display large volumes of detailed data rather than interpret and highlight the meaning of the data. Many of these tools also look at a single element rather than the network as a whole. Data becomes information when it is organized, correlated and presented in a way that clarifies it's meaning, helping the network manager make the best decisions~\cite{b16}. Managers must also predict future trends based on historical network trends and business information.

Until the introduction of expert systems, alarms and events were checked manually by the operators. Now expert systems are tested in the automation of this process. There are several artificial techniques that can be used, such as Rule-Based Reasoning (RBR), Bayesian Networks (BN), Neural Networks (NN), Case-Based Reasoning (CBR), Qualitative Reasoning (QR) and Model-Based Reasoning (MBR)~\cite{b1}.

\subsection{Performance metrics}

Generally, network performance metrics \index{Performance management!performance metrics} are classified into two areas: network-centric metrics and end-to-end measurements~\cite{b43}. Network-centric metrics are:
\begin{itemize}
\item \textbf{Router and switch metrics}

These metrics deal with operation of routers and switches; queuing packets, processing them, and placing them on the appropriate outbound link queue. The metrics include Offered load, Dropped traffic, and Average queue lengths (to assess queuing delays and potential dropped packets at a router).

\item \textbf{Link metrics}

These metrics describe the network capacity. They include e.g. Bandwidth Utilization.

\item \textbf{Metrics for the routing sub-system}

These metrics describe the impact of the routing traffic and fluctuations on the network performance. The rate of route changes characterizes the stability of the network system.

\end{itemize}

End-to-end metrics are:
\begin{itemize}
\item End-to-end latency and jitter,
\item Effective throughput, usually measured as a function of the packet size and the window size, and
\item Packet loss probaility.
\end{itemize}

The tools and techniques required to measure performance characteristics in these two categories are different. In the Internet performance analysis it has been difficult to define metrics, that reflect both perspectives.

\subsection{Performance management control}

\index{Performance management!Performance management control} Performance management control is responsible for controlling the performance of a network. It includes such areas as network traffic management policies, traffic control, traffic administration, performance administration, execution of traffic control, and audit reporting~\cite[page 56]{a30}.

Traffic control needs resources. Usually a separate control station is needed to collect and analyze traffic statistics. There should be a method to link a control station so that the traffic information is collected from the network. Controlling the traffic is, however, a reliable and cost effective method for finding out problems before they exist. Traffic controlling can be limited to the most important parts of the network~\cite{b2}.

Performance management is also related to the configuration management. It is easier for the operator to plan modifications of the network, when the use of the network is known. Operator finds out which connections and services are used and which are needed.
