(IST-1999-10077) Adaptive Resource Control for QoS Using an IP-based Layered Architecture
description
Transcript of (IST-1999-10077) Adaptive Resource Control for QoS Using an IP-based Layered Architecture
(IST-1999-10077)
Adaptive Resource Control for QoSAdaptive Resource Control for QoSUsing an IP-based Layered ArchitectureUsing an IP-based Layered Architecture
AQUILA
Bert F. KochBert F. Koch
Stefano SalsanoStefano Salsano
http://www-st.inf.tu-dresden.de/aquila/http://www-st.inf.tu-dresden.de/aquila/
TEQUILA Workshop25-26 Jan 2001
Amsterdam
Internet Design for SLS Delivery
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
2
AQUILA
Outline
Project IntroductionProject Introduction
AQUILA QoS ArchitectureAQUILA QoS Architecture
Traffic Engineering AspectsTraffic Engineering Aspects
Further Project ActivitiesFurther Project Activities
AQUILA Approach to SLSAQUILA Approach to SLS
Future PlansFuture Plans
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
3
AQUILA
Outline
Project IntroductionProject Introduction
AQUILA QoS ArchitectureAQUILA QoS Architecture
Traffic Engineering AspectsTraffic Engineering Aspects
Further Project ActivitiesFurther Project Activities
AQUILA Approach to SLSAQUILA Approach to SLS
Future PlansFuture Plans
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
4
AQUILA
ConsortiumSAGSAG Siemens (Co-ordinator), GermanySiemens (Co-ordinator), Germany
BAGBAG Bertelsmann mediaSystems, GermanyBertelsmann mediaSystems, GermanyDTADTA T-Nova Deutsche Telekom, GermanyT-Nova Deutsche Telekom, GermanyTAATAA Telekom Austria, AustriaTelekom Austria, AustriaELIELI Elisa Communications, Finland Elisa Communications, Finland TPSTPS Polish Telecom, PolandPolish Telecom, Poland NTUNTU National Technical University of Athens, GreeceNational Technical University of Athens, GreeceWUTWUT Warsaw University of Technology, PolandWarsaw University of Technology, PolandCORCOR CoRiTel, Italy CoRiTel, Italy TUDTUD Dresden University of Technology, GermanyDresden University of Technology, GermanySPUSPU Salzburg Research, AustriaSalzburg Research, Austria
QSYQSY Q-Systems, GreeceQ-Systems, Greece
I&C I&C manufacturermanufacturer
Internet ServiceInternet ServiceProvidersProviders
andandNetwork OperatorsNetwork Operators
UniversitiesUniversitiesandand
ResearchResearchInstitutesInstitutes
Web applicationWeb applicationproviderprovider
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
5
AQUILA
Work Break Down Structure
Workpackage 0: Project ManagementWorkpackage 0: Project Management Workpackage Group 1: System Architecture and Traffic IssuesWorkpackage Group 1: System Architecture and Traffic Issues
• WP 1.1: Requirement Analysis
• WP 1.2: Specification
• WP 1.3: Traffic Studies and Engineering
Workpackage Group 2: Prototype ImplementationWorkpackage Group 2: Prototype Implementation• WP 2.1: Service and Resource Control
• WP 2.2: QoS aware Applications and User Services
• WP 2.3: Distributed QoS Measurements
Workpackage Group 3: Integration and TrialWorkpackage Group 3: Integration and Trial• WP 3.1: System and Network Integration
• WP 3.2: Trials and Measurements
• WP 3.3: Exploitation and Business Models
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
6
AQUILA
Main Objectives
Investigate dynamic end-to-end QoS Provisioning in IP Investigate dynamic end-to-end QoS Provisioning in IP
NetworksNetworks
Implement Prototypes of a QoS Architecture for a Carrier Grade Implement Prototypes of a QoS Architecture for a Carrier Grade
DiffServ Core NetworkDiffServ Core Network
Support a wide Range of Applications by providing a QoS Support a wide Range of Applications by providing a QoS
Toolkit / API Toolkit / API
Continuously analyse Customer Requirements, Market Continuously analyse Customer Requirements, Market
Situations and Technological Trends and develop Business Situations and Technological Trends and develop Business
ModelsModels
Contribute to Standardisation Bodies like IETF, ITU, ETSI, etc.Contribute to Standardisation Bodies like IETF, ITU, ETSI, etc.
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
7
AQUILA
Main Innovations
ResourceControl Layer
DiffServ DomainISP A
ISP Internet Service ProviderRCL Resource Control Layer
DiffServ DomainISP B
ED
Inter-Domain QoS
RCL
Scalable and flexible
Admission Control and
Resource Management End-user Application Toolkit to request QoS
Host
Host
EdgeDevice
EdgeDevice
CoreRouter
CoreRouter
CoreRouter
EdgeDevice
Web-Server
Distributed QoS Measurement
Distributed QoS Measurement
Evaluation of Admissionand Traffic Control
Algorithms
end-to-end Quality of Service
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
8
AQUILA
Design Goals
Scalable ArchitectureScalable Architecture• Distributed building blocks
• Autonomous operation of elements
Failure ProofFailure Proof• Failure of an element should only degrade (if at all), not disable the
operation of other elements
Based on DiffServ Core NetworkBased on DiffServ Core Network• Use of existing, commercial routers
• Enable migration path from current networks
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
9
AQUILA
Outline
Project IntroductionProject Introduction
AQUILA QoS ArchitectureAQUILA QoS Architecture
Traffic Engineering AspectsTraffic Engineering Aspects
Further Project ActivitiesFurther Project Activities
AQUILA Approach to SLSAQUILA Approach to SLS
Future PlansFuture Plans
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
10
AQUILA
Resource Control Layer (RCL)
Tasks of the Resource Control LayerTasks of the Resource Control Layer• Admission Control to limit the amount of prioritised traffic
• Resource Management
• QoS Interface
Design GoalsDesign Goals• Simpler than ATM (no explicit reservation along the data path)
• Scalable approach for Admission Control (distributed Admission Control, separation of Admission Control and Resource Management)
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
11
AQUILA
Scalable Architecture for RCL
ISP Domain
Edge Router
Core Router
Core Router
Core Router
Access Network
Edge Router
Resource Control Layer
Access Network
Admission ControlAdmission Control
QoS R
eque
st
Set
tings
Admission Control Agent
Set
tings
Admission Control Agent
QoS RequestEnd-userApplication
Toolkit
End-userApplication
Toolkit
QoS Request
setti
ngs
(rou
ting.
..)
Used resources
resources
Resource Control Agent
Resource ControlResource Control
Consideration of Network LoadConsideration of Network Load MonitoringProbingResults
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
12
AQUILA
Resource Control Layer (1)
Basic Idea of DiffServ NetworkBasic Idea of DiffServ Network• Provide some (fixed) prioritised traffic classes within the network
• Guarantee QoS by limiting amount of prioritised traffic at the network edge (limited resources)
Additional Benefit of the Resource Control LayerAdditional Benefit of the Resource Control Layer• Dynamically shift resources between network edges ( resource
pools)
• Take into account the actual resource usage of the network(2nd Trial)
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
13
AQUILA
Resource Control Layer (2)
Admission Control AgentAdmission Control Agent• Authenticates user
• Authorises and checks request
• Locates ingress and/or egress edge router ( roles)
• Requests resources from the resource control agent
• Admits / rejects new flows
• Installs policies in ingress router
Resource Control AgentResource Control Agent• Manages resources
• Checks availability of requested resources
• (Re-)distributes resources as needed
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
14
AQUILA
Resource Pools
Resource LimitsResource Limits• Limit amount of QoS
traffic from each edge router
Group neighboured Group neighboured RoutersRouters• Limit amount of QoS
traffic from each group
Dynamic DistributionDynamic Distribution• Dynamically shift
resources within group
Hierarchical StructureHierarchical Structure• “Groups of groups”
Domainsub-area
subordinatedsub-area
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
15
AQUILA
Outline
Project IntroductionProject Introduction
AQUILA QoS ArchitectureAQUILA QoS Architecture
Traffic Engineering AspectsTraffic Engineering Aspects
Further Project ActivitiesFurther Project Activities
AQUILA Approach to SLSAQUILA Approach to SLS
Future PlansFuture Plans
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
16
AQUILA
Network Services
CharacterisationCharacterisation• Delivery of services to the customer
• Defined by the network operator
• Provides a specific QoS, expressed by statistical or deterministic statements about delay, loss, ...
ImplementationImplementation• A network service is implemented by a traffic class
UsageUsage• The End-user Application Toolkit maps application demands to
network services
Example: Premium CBR for IP Telephony and Voice TrunkingExample: Premium CBR for IP Telephony and Voice Trunking
Goal: only a few Network Services to allow clear service
Differentiation (wrt QoS objectives)
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
17
AQUILA
Overview of Traffic Handling Approach
PROVISIONING
Configuration ofTRAFFIC
CONTROL
Limits forADMISSIONCONTROL
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
18
AQUILA
Traffic Classes (1)
Network ServicesNetwork Services
CustomerCustomer
Network operatorNetwork operator
Traffic ClassesTraffic Classes
The network operator offersthe NS to the customer
Network services are mappedinto traffic classes
DSCP, scheduling and queuingalgorithms (e.g. WFQ, RED), router
configuration, admission control rules
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
19
AQUILA
Traffic Classes (2)
Five Traffic Classes have been specifiedFive Traffic Classes have been specified
… … as well as the related Traffic Control Mechanisms in the as well as the related Traffic Control Mechanisms in the RoutersRouters
Networkservice
Premium CBR Premium VBR PremiumMultiMedia
PremiumMission Critical
Standard
Traffic class TCL 1 TCL 2 TCL 3 TCL 4 TCL STD
PQPacketarrives
TCL 3
TCL 2
TCL 4
TCL 1
Classifier
Packetdeparts
WFQ
TCL STD
High priority
Low priority
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
20
AQUILA
Admission Control
Traffic CharacterisationTraffic Characterisation
based on token bucket parameters declarationbased on token bucket parameters declaration
Admission Control AlgorithmsAdmission Control Algorithms
take into account the traffic parameters specified in the take into account the traffic parameters specified in the reservation request and compare with the provisioned admission reservation request and compare with the provisioned admission control rate limits and the already allocated resources.control rate limits and the already allocated resources.
Specific Admission Control AlgorithmsSpecific Admission Control Algorithms
have been defined for the different traffic classes and different have been defined for the different traffic classes and different (high speed / low speed) access links.(high speed / low speed) access links.
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
21
AQUILA
ACrate limits
Provisioning Initial ProvisioningInitial Provisioning
Building Resource PoolsBuilding Resource Pools• Resource pools are built when it is useful to dynamically share a bottleneck link among a set of access links
Initial provisioningalgorithm
Constraints on Traffic Classusage per Link
Expected traffic matrix
Topology and routing
Provisionedrates per
link
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
22
AQUILA
Outline
Project IntroductionProject Introduction
AQUILA QoS ArchitectureAQUILA QoS Architecture
Traffic Engineering AspectsTraffic Engineering Aspects
Further Project ActivitiesFurther Project Activities
AQUILA Approach to SLSAQUILA Approach to SLS
Future PlansFuture Plans
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
23
AQUILA
End-user Application Toolkit (EAT)
Middleware between QoS Network and ApplicationMiddleware between QoS Network and Application• Front end for access network
• QoS portal for application (legacy and QoS aware)
• Alternative, flexible approach for evaluating QoS reservations
EAT is requester of QoS reservationEAT is requester of QoS reservation• The requester may be the sender, receiver or a third party
• The requester initiates the reservation
• The requester is charged for the service
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
24
AQUILA
Objectives
Enable Access to QoS to non QoS Enable Access to QoS to non QoS aware aware Legacy ApplicationsLegacy Applications
Support Support QoS aware ApplicationsQoS aware Applications (RSVP, DiffServ) / Support various (RSVP, DiffServ) / Support various QoS Request MethodsQoS Request Methods
Provide a Methodology and a Provide a Methodology and a Programming Interface to support Programming Interface to support the Construction of the Construction of new QoS aware new QoS aware ApplicationsApplications
Provide an Provide an End-user friendly QoS End-user friendly QoS AccessAccess
Pro
xies
AP
I Network
Control plane
Data plane
End-user Application Toolkit
QoS
ACA
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
25
AQUILA
Distributed QoS MeasurementsPacket Level
Measurement of end-to-end Parameters via ProbesMeasurement of end-to-end Parameters via Probes• Examples: one-way delay, delay variation, packet loss
Collection of Performance Monitoring and QoS Parameters Collection of Performance Monitoring and QoS Parameters from Routersfrom Routers
Definition and Implementation of Synthetic Flow Load Definition and Implementation of Synthetic Flow Load Generators for Measurements of end-to-end QoSGenerators for Measurements of end-to-end QoS
Storage of all Measurement Data in Measurement DatabaseStorage of all Measurement Data in Measurement Database
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
26
AQUILA
E2E E2ESynthetic End-
Synthetic End-
to-End Load
to-End Load
Measurements
Host Host
CoreRouter
measurementdatabase
test description
ProbeProbe
ProbingProbing
EdgeDevice
EdgeDevice Core
RouterCore
Router
MonitoringMonitoring
ResultsResults
Reser-vation
EAT
Resource ControlTraffic Control
Admission Control
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
27
AQUILA
Tasks in the First Trial (Feb/Mar 2001)
Use Real Life Applications to “get a feel”Use Real Life Applications to “get a feel”
To supplement the Environment with generated Quality To supplement the Environment with generated Quality
TrafficTraffic
To measure the achieved Network Traffic CharacteristicsTo measure the achieved Network Traffic Characteristics
To complement the measured Data with subjective User To complement the measured Data with subjective User
Impressions of the Applications‘ Performance/BehaviourImpressions of the Applications‘ Performance/Behaviour
To evaluate the measured Data To evaluate the measured Data
To process all Information and provide Feedback to the To process all Information and provide Feedback to the
othre WPs for further Developments/Refinementsothre WPs for further Developments/Refinements
To support the Dissemination of the ResultsTo support the Dissemination of the Results
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
28
AQUILA
Trial at Three Different Sites
Warsaw (Polish Telecom)Warsaw (Polish Telecom)• Reference Site
• Special Focus on Streaming Media / Video on Demand
Helsinki (Elisa Communications)Helsinki (Elisa Communications)• Site with various Access Technologies (ADSL, 10 Mbps Ethernet,
WLAN) • Special Focus on realistic customer/end-user environments and
different environments and usage (home, office, public access zone)
Vienna (Telekom Austria)Vienna (Telekom Austria)
• Site with homogenous Layer 2 (Ethernet)
• Special Focus on low bandwidth real-time applications, VoIP, Multi-user network games
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
29
AQUILA
Outline
Project IntroductionProject Introduction
AQUILA QoS ArchitectureAQUILA QoS Architecture
Traffic Engineering AspectsTraffic Engineering Aspects
Further Project ActivitiesFurther Project Activities
AQUILA Approach to SLSAQUILA Approach to SLS
Future PlansFuture Plans
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
30
AQUILA
Standardisation Issues
IETF ActivitiesIETF Activities• Joint preparation with TEQUILA and CADENUS for a BoF session
at the Dec 2000 IETF Meeting in San Diego
• Goal is to start a new Working Group on Service Level Specification (SLS)
• AQUILA EAT-ACA interface modelled in accordance to the TEQUILA draft (draft-tequila-sls-00.txt)
• AQUILA draft on Network Services submitted(draft-salsano-aquila-sls-00.txt)
• Contribution to SLS framework draft(draft-manyfolks-sls-framework-00.txt)
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
31
AQUILA
AQUILA Approach to SLS
In the AQUILA architecture a “Reservation Request” is sent to the Admission Control Agent (ACA) by the “End-In the AQUILA architecture a “Reservation Request” is sent to the Admission Control Agent (ACA) by the “End-user Application Toolkit” (EAT)user Application Toolkit” (EAT)
A Reservation Request specifies a Service Level AgreementA Reservation Request specifies a Service Level Agreement
H – Host
QMTool
Application
EAToolkit
Core DiffServ Network
ACA
ACA
RCA
Application
EAToolkit
HAccessNetwork ED
BR
ED
CR
CR
CR
CR
ISP
AccessNetwork
H
ED – Edge DeviceBR – Border RouterCR – CoreRouter
ACA
Reservation Request
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
32
AQUILA
AQUILA SLS Draft to IETF
Following input from TEQUILA (draft “Following input from TEQUILA (draft “Service Level Specification Semantics and Parameters”) we have Service Level Specification Semantics and Parameters”) we have described the semantic content of our SLS trying to align the terminology (see section 3 of our draft)described the semantic content of our SLS trying to align the terminology (see section 3 of our draft)
Most of the concepts are very similarMost of the concepts are very similar
The most interesting difference is the concept of “predefined SLS types”The most interesting difference is the concept of “predefined SLS types”
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
33
AQUILA
Semantic Content of SLS
draft-aquila draft-tequila
SLS typeSLS type
ScopeScope
Flow IdentificationFlow Identification
Traffic description and conformance testTraffic description and conformance test
--
Performance GuaranteesPerformance Guarantees
Service scheduleService schedule
--
--
ScopeScope
Flow IdentificationFlow Identification
Traffic conformance testTraffic conformance test
Excess TreatmentExcess Treatment
Performance GuaranteesPerformance Guarantees
Service scheduleService schedule
ReliabiltyReliabilty
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
34
AQUILA
Network Services
There has been lot of discussion in the SLS mailing list on the There has been lot of discussion in the SLS mailing list on the
issue of “Well Known Services” vs. “Custom Services”issue of “Well Known Services” vs. “Custom Services”
““Well Known Services” restrict the definition of new services, Well Known Services” restrict the definition of new services,
but are very simple to handlebut are very simple to handle
““Custom” network services allow freedom in specifying the Custom” network services allow freedom in specifying the
QoS parameters ... , but may be very difficult to handleQoS parameters ... , but may be very difficult to handle
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
35
AQUILA
Predefined SLS Types (1)
AQUILA Network Services are defined in terms of predefined values for the parameters (e.g. traffic descriptors, QoS AQUILA Network Services are defined in terms of predefined values for the parameters (e.g. traffic descriptors, QoS requirements…) and of restrictions on the allowed combination of parametersrequirements…) and of restrictions on the allowed combination of parameters
A “predefined SLS type” is defined in terms of the generic SLS descriptionA “predefined SLS type” is defined in terms of the generic SLS description
A "predefined SLS type" simplifies the generic SLS description as it fixes values (or range of values) for a subset of the A "predefined SLS type" simplifies the generic SLS description as it fixes values (or range of values) for a subset of the parameters in the generic SLS. It may also fix some relationships or dependencies between some parametersparameters in the generic SLS. It may also fix some relationships or dependencies between some parameters
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
36
AQUILA
Predefined SLS Types (2)
This approach simplifies the SLS negotiation procedures and the SLS mapping into network internal mechanisms, yet it is more flexible than This approach simplifies the SLS negotiation procedures and the SLS mapping into network internal mechanisms, yet it is more flexible than having “globally well known” serviceshaving “globally well known” services
The framework is flexible enough to support both Custom Services and Predefined ServicesThe framework is flexible enough to support both Custom Services and Predefined Services
Predefined Services may play a fundamental role in SLS negotiationPredefined Services may play a fundamental role in SLS negotiation
The use of Predefined Services is an option to the network providerThe use of Predefined Services is an option to the network provider
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
37
AQUILA
Outline
Project IntroductionProject Introduction
AQUILA QoS ArchitectureAQUILA QoS Architecture
Traffic Engineering AspectsTraffic Engineering Aspects
Further Project ActivitiesFurther Project Activities
AQUILA Approach to SLSAQUILA Approach to SLS
Future PlansFuture Plans
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
38
AQUILA
Future Project Plans (1)
ArchitectureArchitecture• Inter-Domain scenarios
– SIBBS
– SLS between ISPs
– Reservation aggregation
• MPLS
– VPN
– QoS traffic engineering
– MPLS-DiffServ interworking
• Multicast reservations
• Resource control loop (feedback from measurement to resource control)
(c) 2000 AQUILA consortium. TEQUILA Workshop, 25-26.01.2001
39
AQUILA
Future Project Plans (2)
Support of ApplicationsSupport of Applications• RSVP as QoS signalling protocol
• Application Programming interface (API)
ManagementManagement• Administration of network services
• Control of resource distribution parameters
MeasurementMeasurement• Improved load generators for service verification
• Provide measurements for RCL feedback
(IST-1999-10077)
Adaptive Resource Control for QoSAdaptive Resource Control for QoSUsing an IP-based Layered ArchitectureUsing an IP-based Layered Architecture
AQUILA
http://www-st.inf.tu-dresden.de/aquila/http://www-st.inf.tu-dresden.de/aquila/
Thank you forThank you foryour attention !your attention !