% $Id: intro.tex 4520 2006-11-29 03:41:36Z gokhale $

\section{Introduction}
\label{sec:intro}

Distributed real-time and embedded (DRE) platforms are at the core of many
mission critical systems such as shipboard computing, avionics,
intelligence, surveillance and reconnaissance.
Such systems must
collaborate with multiple sensors, provide on-demand browsing and
actuation capabilities for human operators, and possess a wide range
of non-functional attributes including predictable performance, security
and fault tolerance. 

{\em QoS-enabled component middleware}, such as CIAO~\cite{Schmidt:04w},
and Qedo~\cite{Ritter:03}, are increasingly
used to develop and deploy next-generation DRE systems.
QoS-enabled component middleware leverages conventional component
middleware (e.g., J2EE, .NET, CCM) capabilities that include:   
(1) standardized interfaces for application component interaction, 
(2) standards-based mechanisms with clear separation of concerns for
the different lifecycle stages of applications including developing,
installing, initializing, configuring and deploying application
components, and 
(3) declarative as opposed to programmatic approaches to the lifecycle
management activities, such as assembly, configuration and
deployment. QoS-enabled component middleware platforms overcome
shortcomings of conventional component middleware by explicitly
separating QoS provisioning aspects of applications from their
functionality, thereby yielding DRE systems that are
less brittle and costly to develop, maintain, and
extend~\cite{Schmidt:04w,Jordan:04}.

%For example, QoS-enabled component
%middleware~\cite{Jordan:04} provides mechanisms to enable
%applications to leverage CPU and memory resources of an end system
%thereby providing different processor priorities to applications.

% An important trait of DRE systems of particular interest to us is the 
% presence of multiple data flows through the interacting entities 
% (even between the same two entities)  of the DRE system that need 
% different network-level QoS treatment.
% The design and implementation of these systems must therefore be able
% to leverage advances in the network subsystem QoS and resource
% management mechanisms, such as integrated services
% (IntServ)\cite{RSVP}, differentiated services
% (DiffServ)~\cite{DS:97} and multi-protocol label switching
% (MPLS)~\cite{MPLS:01} architectures that support flow-level QoS 
% differentiation to some degree.

Advances in QoS-enabled component middleware to date are, however, 
limited to managing CPU and memory resources in the operating system.
Although there exist standard mechanisms to support network QoS
including integrated services (IntServ)\cite{RSVP} and differentiated
services (DiffServ)~\cite{DiffServ:98}, there are limited or no
capabilities in current QoS-enabled component middleware to (1)
specify, enable and enforce 
network QoS at the level of individual flow communication (even
between the same two components different QoS may be required at
different times to satisfy different needs e.g., voice and video
communications have different latency and jitter requirements.), (2)
configure network elements, specifically routers and  
switches of different types, in a consistent manner regardless of their low 
level provisioning and monitoring interfaces, and (3) enforce
QoS with functions such as policing for usage compliance so all flows 
get their required treatment.

To overcome these limitations, our QoS-enabled component middleware 
includes mechanisms to: (1) declaratively specify
network QoS requirements (in terms of priority, reliability, bandwidth
required, latency and jitter) of different communication flows in a
DRE system, (2) assure network resources for communications within a
DRE system based on the specified QoS, especially for critical
communications, (3) automatically mark application packets for classification
(with DSCPs) at the entrance to the network, and (4) police for usage
compliance at the ingress points of the network so that QoS is assured
for all admitted traffic. 

Earlier work of the authors at Vanderbilt University on 
a declarative QoS provisioning framework has focused on developing the
following capabilities: 
(1) a model-driven engineering (MDE)~\cite{Schmidt:06a}
tool suite called CoSMIC~\cite{CoSMIC}, which alleviates many
accidental complexities associated with developing, deploying and
configuring QoS-enabled component-based DRE systems,
(2) a deployment and configuration engine
(DAnCE)~\cite{Schmidt:05y} that provides standards-based
deployment and configuration mechanisms to deploy systems
for component middleware platforms, such as our
CIAO~\cite{Schmidt:03m} lightweight CORBA Component Model
(LwCCM)~\cite{LWCCM} implementation,
(3) a dynamic resource allocation and control engine
called RACE~\cite{Schmidt:05u} to allocate and control resources for DRE
applications, and
(4) reflective middleware techniques
within CIAO to support runtime adaptive CPU and memory QoS
management~\cite{Schmidt:00c}. 

% I modified the para below so that the bullet points are full sentences.
% This only really was needed for point (2), which was way too long
% and rambling.  Feel free to change it back if you can find a better
% way to deal with point (2)

This paper describes how we addressed the aforementioned limitations of 
QoS-enabled component middleware to provide network QoS management and
control by extending our standardized QoS-enabled provisioning framework.
Our main contributions are as follows: 

\sqzpar
\paragraph*{$\bullet$} We extend the CoSMIC tool suite to enable
modeling of network QoS requirements of DRE applications.  The QoS
modeling is seamlessly integrated with existing capabilities for
specifying the interfaces, communication and assembly details of the
DRE system.    

\sqzpar
\paragraph*{$\bullet$} We extend RACE to integrate with the Bandwidth
Broker (BB)~\cite{Das:2005,Das:2006} developed by the Telcordia
team.  Bandwidth Broker assures network resources for flows by using
an admission control process that tracks network capacity against
bandwidth commitments.  Its Flow Provisioner provisions ingress
routers to police traffic at the level of a flow.   

\sqzpar
\paragraph*{$\bullet$} We extend the CIAO and DAnCE frameworks to
allow configuring application communications with network QoS markings
determined by the Bandwidth Broker so that the applications and
network elements have the same view on the importance of a
communication flow.

Although much of this network QoS technology is
developed and validated for the DARPA ARMS program for shipboard
computing, we will illustrate the technology using an easily
understood commercial
application: a modern office/\-enterprise network
environment described in Section~\ref{sec:office-casestudy}.
The remainder of the paper is organized as
follows: Section~\ref{sec:challenges} uses a representative DRE system
case study as a guide to describe the challenges in provisioning 
network QoS for DRE systems;  Section~\ref{sec:solution} describes the
novel solutions we have developed in the context of our existing QoS
provisioning framework;  Section~\ref{sec:results} provides
experimental validation of our approach;  Section~\ref{sec:relwork}
compares our work with related research; and
Section~\ref{sec:conclusions} provides concluding remarks, lessons
learned and future work.
