\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) 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}\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.} (GoS) 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} and \textit{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) 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) 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) 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) 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}\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}

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\footnote{Routing Information
Protocol, see~\cite[ch. 4]{a48}.}, OSPF\footnote{Open Shortest Path
First, see~\cite[ch. 5]{a48}.}, and 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} 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}

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 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 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}

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]{b34}.

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.
