% $Id: netqos_planner.tex 4523 2006-11-29 04:06:54Z gokhale $

\subsection{Providing Deployment-time Network Resource Reservation and Device Configuration}
\label{sec:resource_reserve}

\paragraph*{Context:}
Section~\ref{sec:mw-challenges} describes how
network QoS provisioning mechanisms keep track of 
all the available paths and link capacities between 
any two pair of hosts, to provision network resources
to satisfy the QoS requirements of component communications.
This allows the network QoS provisioning mechanisms to determine
if a network QoS can be provided or not, given the source and destination
nodes of communicating components.

\paragraph*{Problem:}
In QoS-enabled component middleware, deployment
decisions to identify the hosts where the components
will be deployed are usually made using intelligent component placement
algorithms~\cite{Rajkumar:05,Schmidt:06m}, based on details including
component CPU resource profiles. Bandwidth Broker (BB)~\cite{Das:2005}
provides with mechanisms to configure the network resources
including switches and routers, to provision network QoS
to applications. Hence network QoS provisioners like
Bandwidth Broker must work with component placement algorithms
to provide a well-integrated network allocation and
placement algorithm that provides an opportunity to retry a component
placement decision if the network QoS cannot be met with a particular
placement decision. At deployment time, DRE applications can therefore be
provided with required resources at the host and network layer,
so that application end-to-end QoS can be assured.

\paragraph*{Solution Approach: Network resource allocation planners.}
Section~\ref{overview-race} described how RACE~\cite{Schmidt:05u} 
uses standard component middleware mechanisms to allocate CPU resources 
to applications~\cite{Schmidt:06m} and control DRE system performance 
once applications are deployed and running.  Since RACE provides
mechanisms to plug in a series of resource allocation algorithms, we
extended RACE to add a network resource allocator that utilizes the
Bandwidth Broker (BB)~\cite{Das:2005}.  
%\begin{floatingfigure}{0.6\columnwidth}
\begin{wrapfigure}{r}{0.6\columnwidth}
%\begin{figure}[htb]
  \centering
  \includegraphics[width=0.58\columnwidth]{figs/BB-RACE}
  \caption{RACE Network Planning and Configuration}
  \label{fig:bb-race}
%\end{figure}
\end{wrapfigure}
%\end{floatingfigure}
This provides our QoS-enabled
component middleware framework  with network QoS provisioning
capabilities that (1) allocate network resources for component
communication flows, (2) provide per-flow configurations, specifically
for marking/\-remarking and policing functions at the edges of the
network,  (3) communicate with the QoS-enabled component middleware on
behalf of the component with desired QoS settings, specifically DSCP
codepoints chosen for the various flows originating from the
component so that the components and the network elements have the
same view of the DSCP markings.  


% Folks, I do not think we should go into so many details here. I
% moved bits and pieces of BB to the overview section - Andy
% \iffalse
% ************ Commented out and parts moved elsewhere **************
Figure~\ref{fig:bb-race} illustrates now BB is integrated as a RACE 
{\em network resource allocator}. The BB leverages widely 
available vendor mechanisms that support layer-3 DiffServ 
(Differentiated Services) and layer-2 CoS (Class of Service) 
features in commercial routers and switches. DiffServ and CoS have 
two major QoS functionality/enforcement mechanisms: 
\begin{itemize}
\item At the ingress of the network, traffic belonging to a flow is 
classified, typically based on the 5-tuple (source IP address and 
port, destination IP address and port, and protocol) or any subset 
of this 5-tuple information.  The classified traffic is marked with a 
DSCP codepoint as belonging to a particular class and may be policed 
or shaped to ensure that traffic does not exceed a certain rate or 
deviate from a certain profile.
\item In the network core, based on the DSCP marking, traffic is 
placed into different classes and provided differentiated, but consistent 
per-class treatment.  This includes scheduling mechanisms that assign
weights or priorities to different traffic classes (such as weighted
fair queuing  and/or priority queuing), and buffer management
techniques that include assigning relative buffer sizes for different
classes and packet discard algorithms such as Random Early Detection
(RED) and Weighed Random Early Detection (WRED).
\end{itemize}

% folks, even these are details about what BB already does. We should
% be saying these things in the overview section in brief and in this
% section simply discussing what is it that we did for this paper.
These two features by themselves are insufficient to guarantee
end-to-end network QoS because the traffic presented to the network
must be made to match the network capacity.  What is also needed is an
adaptive admission control entity that ensures there are adequate
network resources for a given traffic flow on any given link that the
flow may traverse.  The admission control entity should be aware of
the path being traversed by each flow, track how much bandwidth is
being committed on each link for each traffic class, and estimate
whether the traffic demands of new flows can be accomodated.  In
Layer-3 network, it is the shortest path that is used for
communication between any two hosts.  We employ Djkstra's allpair
shortest path algorithms.  In Layer-2 network, we discover the VLAN
tree to find the path between any two hosts.  In MPLS networks, we can
force a path for a particular flow with the use of a MPLS label for
that path, and of course, the routers in the path have to be
configured for the next hop correctly using the MPLS label.

The BB is responsible for assigning the appropriate traffic class to each flow, 
and, using the Flow Provisioner, provisioning complex parameters for policing 
and marking, such that a contracted flow obtain end-to-end QoS and makes use of 
no more resources than allocated to it.  The Flow Provisioner translates 
technology-independent configuration directives generated by the Bandwidth Broker 
into vendor-specific router and switch commands to classify, mark and police packets 
belonging to a flow.  

Configuration in each router/switch for scheduling and buffer management, 
resulting in the same per hop forwarding behavior is done not at
deployment time but at the time of network engineering or
re-engineering.  The Bandwidth Broker is aware of these
configuration decisions/restrictions including the number of traffic
classes supported, the QoS semantics of each class  
and the capacity in each link, independently of CQML.  Much of this 
information is input to the Bandwidth Broker as reference data. 
The network topology itself is discovered by the Bandwidth Broker. 
CQML currently does not address this pre-deployment configuration 
issues.

Currently, the Bandwidth Broker provides these functions to support 
deployment decisions:
\begin{itemize}
\item {\bf Flow Admission Functions:} Reserve, commit, modify, and delete flows.
\item {\bf Queries:} Bandwidth availability in different classes among pairs of 
pools and subnets.
\item {\bf Bandwidth Allocation Policy Changes:} In support of mission-mode changes.
\item {\bf Feedback/Monitoring Services:} Feedback on flow performance using metrics 
such as average delay.
\end{itemize}

The Bandwidth Broker admission decision for a flow is not based solely on 
requested capacity or bandwidth on each link traversed by the flow, but it is 
also based on delay bounds requested for the flow.  The delay bounds for new 
flows need to be guaranteed without damaging the delay guarantees for previously 
admitted flows and without redoing the expensive job of readmitting every 
previously admitted flow.  We have developed computational techniques to provide 
both deterministic and statistical delay-bound
guarantees~\cite{Das:2006}. Delay guarantees  
raise the level of abstraction of the Bandwidth Broker to application or 
higher-level resource management components and enable these components to 
provide better end-to-end mission guarantees. The basic framework we have 
developed is capable of dealing with any number of priority classes and, 
within a priority class, any number of weighted fair queuing subclasses. 
These guarantees are based on relatively expensive computations of occupancy 
or utilization bounds for various classes of traffic, performed only at the 
time of network configuration/reconfiguration, and relatively inexpensive 
checking for a violation of these bounds at the time of admission of a new 
flow. 

\paragraph*{Bandwidth Broker Integration into RACE}
% ************ Commented out upto here **************
% \fi

% Jai, I moved half of the above commented stuff to overview and
% pertinent stuff I merged in here. I think the process described here
% tells a good story of how things operate. - Andy
Figure~\ref{fig:bb-race} illustrates the architecture of the BB and
shows how it is integrated as a RACE {\em network resource allocator}.
As noted earlier, the BB leverages widely  available vendor mechanisms
that support layer-3 DiffServ (Differentiated Services) and layer-2
CoS (Class of Service) features in commercial routers and switches.  
RACE's CPU resource allocators need to determine the hardware nodes
in which the components are deployed, and then check if the determined
hardware nodes can also satisfy the network QoS requirements of the
various communication flows among components deployed on those hardware
nodes. Currently, it is a sequential process. The CPU resource allocator
makes the hardware node decisions. The Bandwidth Broker is then invoked for
the network QoS viability and reservation. 
\iffalse
% this is a future work bullet
Currently, the BB's querying
features for resource availability is not used by the CPU resource
allocator to ensure that the host deployment decisions made have a
good chance of meeting the bandwidth availability requirements so that
BB can succeed in making reservations for most if not all the critical
flows. We plan to accomplish in the near future.
\fi

The BB in turn is responsible for assigning the appropriate traffic
class to each flow,  and, using the Flow Provisioner module,
provisioning complex parameters for policing  and marking, such that a
contracted flow obtains end-to-end QoS and makes use of  no more
resources than allocated to it.  The Flow Provisioner translates
technology-independent configuration directives generated by the
Bandwidth Broker  into vendor-specific router and switch commands to
classify, mark and police packets belonging to a flow. 

The BB returns a DSCP marking for each flow, which the QoS-enabled component 
middleware needs to use to mark the IP header of each packet whenever such a 
flow is initiated by the source component.  RACE updates the component
deployment metadata to capture the DSCP marking returned by BB as part
of the  component connection description so that DAnCE can configure
the applications with those QoS settings when remote communications
are made. 
