Related Work

First, we’ll talk about diffserv technologies. There has been a great interest  in  Diffserv architectures both by operators and industry  [Gio03]. But,  it couldnot achieve large-scale deployment because of missing pieces in DiffServ architecture which are :
1.Absence of proper service definitions provided by the network.

2.Dynamic service creation and automatic configuration management.

3.Traffic Engineering like the way it is done in MPLS.

4.Dynamic ServiceInvocation.


6.Inter-domain QoS aspects.

All above factors are explained in detail in [Gio03].

To deal with above issues, European University has founded 3 projects in the area of QoS support in large IP networks:

AQUILA, TEQUILA and CADENUS. These projects try to extend DiffServ architectures to meet above requirements and resolve above mentioned issues. [Pro]is  a  quite  interesting  work,  but  there  model  maps application level APIs to network services which are then mapped to traffic classes. They have assumed the network to be DiffServ and then their middleware acts as an extention to DiffServ to provide service guarantees which DiffServ alone is incapable of providing. There middeware is divide into 3 layers:
1)  Resouce Contol Agent.

2)  Resource Admission Control.

3)  EAT (End-user Application Toolkit).

EAT is the part that deals with creation of APIs at the application level. The actual mapping of service level requirements to network QoS is done by resouce control agent. [Cor]discusses the QoS contol architecture for DiffServ over MPLS.

[Cam] suggests that work on QoS-driven end-system architecture must be integrated with network configurable QoS services and protocols to meet application-to-application requirements.

In recognition of this, researchers have recently proposed new communication architectures which are broader in scope and cover both network and end-system domains. The [JN] does  an  extensive  survey  on  the  state-of-art  of  the  QoS architectures and mentions following projects:

Extended Integrated Reference Model (XRM), which is being developed at Columbia University;

OSI QoS Framework, which is being developed by the ISO SC21 QoS Working Group;

OMEGA Architecture, which is being developed at theUniversity of Pennsylvania;

Heidelberg QoS Model, which is being developed at IBMs European Networking Center;

Tenet  Architecture,  which  is  being  developed  at  theUniversity of California at Berkeley

End System QoS Framework, which is being developed at Washington University;

IETF QoS Manager (QM), which is being developed by the int-serv group as part of its strategy for an integrated services Internet;

INA QoS Framework, which is being developed by the TINA Consortium; and

MASI End-to-End Architecture, which is being developed at Universit Pierre et Marie Curie.

We now discuss Aquila architecture in detail here.

1) Aquila Architecture:

The general AQUILA network architecture is based on the DiffServ network concept.

The objective of the project is to provide dynamic control to QoS based traffic. This is done by creating an architecture with a layer resource control layer forcontrolling network resources above the DiffServ network. It maintains the distribution of network resources between different network entities, especially the network access points. So it can be assured, that  the  underlying  IP  network  can  provide  the  assumed Quality of Service for the specific network services. On top of this technology, admission control and resource management mechanisms are built Dynamic adaptation of resource allocation to user requests enables the overall architecture to scaleto very large networks.

Resource Control Layer(RCL)

The RCL is responsible for the management of QoS resources inside the AQUILA network. This can be split in three main tasks and modules:

End-user Application Toolkit  (EAT)

A graphical user interface is  offered to the  end-user directlyi 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. It 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 net-work. 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 forIP 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.

Problem Approach

We aim to provide the mapping mechanism for SLA to QoS parameters mapping for MPLS networks. We discuss the ideas of Aquila mapping and architecture in the next section as is important in our context, and analyze their approach. And then elaborate an approach and strategy for our work.