 |
 |
 |
 |
|
 |
 |
|
 |
Our objective henceforth should be to be able to provide such a mapping
function that does the following: Mapping QoS parameters (which are mentioned in
SLAs) to NPMs (Network Performance Metrics) for different application specification as
these mapping function would be dependent on applications for MPLS networks. We
might also, explore possiblities and mapping mechanism in DiffServ over MPLS
networks.
B. 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.
5.Monitoring
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
 |
|
 |
|