The technical approach taken by the project integrates all relevant aspects for future integrated services networks based on the Internet. Therefore it covers economical aspects, technological concepts, aspects of network planning and analysis, aspects of network service creation and administration as well as aspects of end-user service provision. For all these aspects, the project applies a common philosophy of taking the best available concepts and technologies, integrating them into a holistic view of future telecommunication services and providing tools for migration from the current to the future situation. In terms of networking technology, the project assumes the DiffServ architecture as the most promising starting point for its work.

On top of this technology, a hierarchically structured Resource Control Layer is built, which applies admission control and resource management to the network. Dynamic adaptation of resource allocation to user requests enables the overall architecture to scale to very large networks.

For end-user applications, the project attempts to make its infrastructure available to a large class of already existing applications based on Internet technology. So the project will not attempt to develop end-user applications "from the scratch", but will instead develop a toolkit, which can be used to make existing applications aware of the QoS capabilities of the underlying network. The usability of the toolkit for migration and adaptation of applications will be demonstrated by developing applications to be used in the trial phases.

	End-user Application Toolkit (EAT) A graphical user interface is offered to the end-user directly or to the applications run by the user. Using this, any application can request certain resources from the network to run with a specified QoS. The EAT is the interface to the AQUILA QoS infrastructure.
	Admission Control Agent (ACA) Performs policy and admission control at the network edges. Each edge router or border router is controlled by an ACA. Each ACA gets a certain amount of resources by the RCA enabling the ACA to perform admission control autonomously. The ACAs receive requests for new IP flows with specific QoS requirements. Their task is to authorise the requests and to check, if the network is able to support the new flow. For this task, they closely interact with the second main entity, the so-called Resource Control Agents.
	Resource Control Agent (RCA) Monitors and controls the available resources in the network. It is the ultimate authority for the resource handling in the AQUILA network. Based on the prior history of resource usage and actual requests, the RCAs distribute resource shares to the Admission Control Agents.

End-users access the Resource Control Layer by using the End-user Application Toolkit. The EAT does not constitute a new signalling protocol for IP networks. Instead, it can be described as a QoS middleware that brings the functionality of the Resource Control Agents Network into the end-user terminals and servers. The internal signalling protocol used between user terminals and the main network can be based on existing schemes (e.g. RSVP) or even on CORBA or DCOM interfaces depending on application needs. In any case, the Edge Device (ED) analyses the user request and executes the user policy control and the local admission control operations in order to determine whether the specific user has the administrative rights and whether there are enough internal resources for the handling of the particular request. However, end-to-end guaranties can be provided only if the level of available resources of all intermediate routers until the final destination is known. Therefore, the ED uses its interface with the Resource Control Agents Network for performing the network admission control operation.
The following figure illustrates a schematic QoS scenario of the project. End-users as well as content providers are connected via EDs, which control the access to the core network.

• A user, who wants to set up a call, uses the means of EAT to set up a reservation request first. The request is received by the corresponding "requester" ACA. Usually, the request specifies at least the source and destination hosts, and the information about which class of service shall be used. Based on this information, the requester ACA maps the offered network service to so-called Traffic Classes, performs the policy control and resolves the involved sender and receiver ACAs (the receiver and sender ACA can be the same machine !). Then, the requester ACA sends a reservation request to the sender ACA (which is located at the ingress of the network) as well as to the receiver ACA.


• The main task of the sender ACA is to make a flow based admission control decision on the ingress side. The specific operations required for such a decision depend on the algorithm used, and depend on the resource configuration controled by the RCA. If there are sufficient resources available, the sender ACA configures the appropriate edge device accordingly.


• The previous step is repeated for the receiver ACA that has to make the same operations at the egress side.


• After the reservation of the resources, the sender may start sending data traffic to the receiver with the desired QoS. The QoS reservation will be kept until a disconnect message is sent out by any of the involved parties.

Multi Domain Aspect

While the previous figure depicts the Resource Control Layer for a single domain, additional mechanisms are necessary to extend this architecture over multiple domains. The project is developing such mechanisms, based on the BGRP proposal, and extends the architecture by an additional inter-domain layer.

AQUILA is designed to fit in real Internet scenarios, where several Internet Service Providers (ISP) are connected via border routers (BR), and different access networks are connected via edge routers (ER). Extending the more schematic view above, the following figure depicts the seamless integration of the AQUILA architecture into these structures.

The innovative architectural concepts require novel algorithms for traffic control, admission control and traffic engineering in order to optimize the network performance and achieve efficient usage of the network resources. A goal of the project is to define a clear reference framework to operate with the different facets of traffic handling in a consistent way. Traffic handling is used here as a general term for a set of coordinated mechanisms that operate at different time scales:

• Traffic control refers to the mechanisms operating at milliseconds time scale like packet scheduling, policing, queue management.
• Admission control refers to the algorithms to decide about the acceptance of a new flow in the network, operating at the time scale of seconds to tens of minutes.
• Resource Pools refers to the algorithm for short term resource redistribution, to cope with local fluctuations in offered traffic, operating at the time scale of tens of minutes to hours.
• Provisioning refers to the algorithm for medium/long term resource allocation and redistribution, operating at the time scale of hours to days.

A simplified pictorial view of the relationships between the different mechanisms as defined for the first phase of the AQUILA project is shown in the following picture.

The first trial specification of traffic handling mechanisms foresees feed-forward operations, i.e. there are no automatic control loops from the measurements into the operation of traffic handling mechanisms.

The second trial specification introduces feedback at different levels as depicted in the following picture.

A set of Network Services have been pre-defined in the AQUILA project, which represent the services sold by the provider to its customers: Premium Constant Bit Rate (PCBR), Premium Variable Bit Rate (PVBR), Premium Multimedia (PMM), Premium Mission Critical (PMC) and Standard Best Effort (STD). Each Network Service is meant to support a class of applications with substantially similar requirements and characteristics. The Network Services are internally mapped by the operator into a set of Traffic Classes. The Traffic Classes use DiffServ based packet handling mechanisms and are defined in terms of queuing and scheduling mechanisms in the routers.

The End-user Application Toolkit (EAT) is a distributed middleware architecture that aims to provide users and applications with access to the QoS facilities of the AQUILA architecture. The EAT specifies the QoS interfaces, both human and programmatic, that users and applications may use in order to get QoS support from the network. Therefore, its main purpose is to bridge the gap between applications/users and the network, playing the role of a QoS portal.

The EAT aims to support a variety of application genres and needs. However, it focuses on legacy applications: non QoS-aware applications that cannot be modified to leverage the AQUILA QoS functionality. Specific mechanisms are being developed in order to QoS-enable such applications:

• Application profiles capture the QoS needs of individual service components (audio, video, data) of applications both in terms of network-level as well as of application-level parameters.
• Protocol translators or Proxies intervene in the operation of standard connection establishment protocols (SIP, H.323) in an effort to extract QoS-relevant information from the protocol messages (dynamically negotiated IP port numbers, information on audio and video codecs etc.). Such information is used in reservation requests to the network.
• A generic reservation request mechanism is specified and implemented in CORBA. However, other QoS signalling protocols (especially RSVP) are also supported by the AQUILA architecture: specific translators terminate QoS signalling originating from hosts and map it to an appropriate AQUILA service class inside the core network.
• A web-based approach is adopted for the presentation of the above information to the end-user. Java Server pages are dynamically created from application profiles and present users with all the available reservation options for a particular application. Therefore, only a web browser is needed for the operation of the EAT and no software installation on end-hosts is necessary.

Overview

Within AQUILA active and passive measurements are performed. Passive measurement (or "monitoring") is a method, where no additional measurement packets are created, active measurement ("probing") uses test packets for measuring the QoS parameters. The results of the measurements are used by the ACA to enable measurement based admission control (MBAC). Additionally application-like load generators measure end-2-end-QoS at the application level to validate the QoS targets for the different network services.

Measurement Architecture

The measurement architecture is divided into two major parts: the measurement management station and several measurement client stations for executing active measurements.

The measurement management station is responsible for distributing the test scenarios among the measurement client stations, storing the scenarios and measurement results in the measurement database (MDB) and hosting the web-server for the GUI.

Two management processes are running on the measurement management station (MPa, MPp). One for the probing measurement agents (MAp) and one for the application-like measurement agents (MAa). The management processes request the measurement database in regular intervals for new test scenarios and distribute these scenarios to the specified measurement agents. Furthermore, they retrieve the result reports from the measurement agents and write them into the measurement database.

To be able to measure exact one-way delays of the measurement packets, the measurement agents use the time information provided by the Global Positioning System (GPS). Therefore the hosts need to be equipped with GPS cards, which are connected to GPS antennas.

In the case of monitoring large networks with active network probing, the MPp can be distributed into different network regions. In this case, the measurement agents (MAp) will report the results to the nearest management process, which then reports aggregated results back to the measurement database.

The router monitor (RM) uses passive measurements to obtain QoS-related statistics from the router. It distinguishes between core and the edge routers. In the core routers of the network the statistics about traffic classes, into which the flows in AQUILA are mapped, are monitored. At the edge routers of the network each single flow reservation can be monitored. The routers are polled in configurable time intervals. Examples of monitored parameters are the queue lengths, number of conforming / exceeding packets and bytes, number of dropped packets and the average CPU utilization.

Support for Resource Control

The support for resource control is based on information gathered by the router monitor at the edge routers. This information is used to improve the admission control handled by the Admission Control Agent (ACA) from declarative based admission control (DBAC) to measurement based admission control (MBAC). The MBAC algorithm used in AQUILA is based on the estimation of the mean rate by polling the router in configurable intervals.