Transcript Traffic Generators and Performance Measures for DiffServ

Applicazione del paradigma Diffserv
per il controllo della QoS in reti IP:
aspetti teorici e sperimentali
Stefano Salsano
Università di Roma “La Sapienza” - CoRiTeL
Outline
 QoS in IP networks: Integrated Services and
Differentiated Services approaches
» Mqos Intserv/Diffserv activities
 Bandwidth Brokers for Diffserv networks
» Architectural aspects
» Design and implementation of a protocol
QoS in the IP networks
 “Per Flow” - the Integrated Service Architecture
 “Per Class” - the Differentiated Service Architecture
Intserv Scalability problems
 The Intserv approach suffers from scalability problems,
due to the “per-flow” handling of IP packets
» Data plane
» classifier / policer / scheduler
» Control plane
» processing of RSVP messages
» storage of path/reservation states
Direction of data flow
DiffServ approach
 Scalability
» A differentiated services mechanism must work at the scale of the Internet
(e.g. millions of networks) and at the full range of speeds of the Internet (e.g.,
Gb/s links)
» push all the state to the edges
» force all per-flow work to the edges
» Edge-only state suggests that “simple” service indication must be carried in
the packet: Diff Serv Code Point (DSCP) in the IP header
DSCP marked
at edge
Service Level Agreement (SLA)
defines capacity at each
service level (DSCP)
?
Direction of data flow
Diffserv architecture: main issues
 Data plane
» traffic handling mechanism (policing, scheduling...)
» end-to-end characterization of a Diffserv “aggregate”
» measurements
 Control plane
» it is left undefined in the Diffserv Architecture
» admission control ? - Bandwidth broker
» end-to-end services ? - interworking with Intserv
Mqos Intserv/Diffserv group activities
 Theoretical aspects:
» definition and evaluation of algorithms for traffic control
and admission control
» architectural studies and protocol definition
 Experimental aspects:
» test-bed realization of traffic and admission control
algorithms and of protocols
» measurements
Diffserv data plane
 Data plane
» traffic handling mechanism (policing, scheduling...)
» end-to-end characterization of a Diffserv “aggregate”
» measurements
 Evaluation of scheduling algorithms with implementation



and measurements
Tools for IP traffic generation
Tools for IP traffic measurements
Measurements in Diffserv networks
Diffserv “control plane”
 Control plane
» it is left undefined in the Diffserv Architecture
» admission control ? - Bandwidth broker
» end-to-end services ? - interworking with Intserv
 Who decides what users get to request special service?
 Where is organizational policy on use of limited bandwidth



implemented?
Who tells the edge router what to tag?
Who makes sure that simultaneous uses of special service fit
within allocation?
How to provide end-to-end services ?
Overall scenario for Diffserv QoS
Client
SLA
SLA
Domain
SLA
Domain
SLA
SLA
Client
client
SLA = Service Level Agreement
Domain = Region of shared trust,
administration, provisioning, etc.
client
 Domains provide their customers with the service specified in Service

Level Agreement
Individual domains are free to manage the internal resources,
to fulfill both internal and external obligations
Resource management in the Diffserv
?
 Statically provisioned resources
 Dynamically provisioned resources by RSVP
 Dynamically provisioned resources by a Bandwidth Broker
DSCP marked
at edge
Service Level Agreement (SLA)
defines capacity at each
service level (DSCP)
?
Direction of data flow
Bandwidth Broker (BB) as Resource manager
 The BB is a logical entity residing in each administrative domain
» manages internal demands & resources according to the policy database
» sets up & maintains bilateral agreement with neighbor domains
» controls the traffic entering & going out on border routers
Diffserv
treatment
BB
 Three components:
BB
BB
BB
BB
» Intra-domain protocols
» Inter-domain protocols
» End-to-End Services
Intra-domain protocols
Bandwidth Broker
Host
Edge
Router
 Control relationships
»
»
»
»
Core
Router
Diffserv Domain
BB to ER to signal resource allocation requests
BB to CR / ER for configuration / monitoring
Host to BB for signaling (?)
Host to ER for signaling (?)
Slide 13
Resource allocation requests
Resource allocation
requests
Resource Control
Edge
Router
Core
Router
Control mechanisms (e.g. RSVP ?)
Scope (p2p/p2anywhere…)
“Size” granularity (per flow/aggregated)
Time granularity (static/dynamic)
Edge
Router
Outsourcing vs. provisioning models
Outsourcing model
Trigger event
(1)
Query (2)
Bandwidth Broker
(Policy Decision Point)
Response (3)
Edge Router
(Policy Enforcement Point)
Events
Provisioning model
Events
Notifications
Bandwidth Broker
(Policy Decision Point)
Configuration
commands
Edge Router
(Policy Enforcement Point)
Trigger events, Notifications and
Configuration commands are asynchronous
A possible end-to-end approach
Intserv operations over Diffserv network
RSVP capable Router
Diffserv Core Routers
RSVP capable Router
Intserv
Network
Intserv
Network
Tx
Edge Router
(RSVP aware)
ER
ER
Rx
Diffserv Core
see
draft-ietf-issll-diffserv-rsvp-04.txt
Goal: preserve end-to-end signaling and scalability
This solution does not prescribe how resources are
managed in the Diffserv Region
Achievements
 Intra domain protocol:
a protocol (COPS-ODRA) to support intra-domain
admission control based on the outsourcing model has
been defined (for BB-to-ER relationship or BB-to-host)
 End-to-end model using RSVP over Diffserv and COPS for
managing resources in the Diffserv domain
 Test-bed implementation of:
» RSVP-Diffserv interworking
» COPS protocol server side and client side
» Admission control procedures in the BB
Intra-domain protocol: COPS-ODRA
 The Common Open Policy Server (COPS) is a client-server
protocol originally designed to support exchange of policy
control information between a policy server (PDP - policy
Decision Point) and its clients (PEP - Policy Enforcement
Points)
 COPS is flexible: different “client types” can be defined to
support different scenarios
 We have defined a new client type called:
Outsourcing Diffserv Resource Allocation (ODRA)
 Information elements, messages and procedures are
described in <draft-salsano-issll-cops-odra-00.txt>
Resource allocation aspects
 No “per request” state is kept in the Bandwidth Broker
 The requests are aggregated by the Bandwidth Broker per
class and per ingress-egress pair
 The Bandwidth Broker should use topology and routing
information to achieve maximum allocation efficiency
 The Bandwidth Broker can also use measurements
Intserv over Diffserv using COPS-ODRA
BB
COPS-ODRA
Tx
Path
Path
Resv
Resv
Path
Resv
Ingress
ER
Path
Path
Resv
Resv
Egress
ER
Diffserv Core
 The Admission control is based on the Outsourcing model
» performed by the BB based on overall information
» very simple for the ER
» the BB does not keep per flow state, just per (ingress,egress) pair
Rx
Intserv over Diffserv using COPS-ODRA
BB/PDP
“Integrated services over DiffServ
network using COPS-ODRA”
<draft-mameli-issll-is-ds-cops-00.txt>
Decision
element
Resources
& topology
DBs
COPS
server
COPS-ODRA protocol
COPS
client
COPS client API
“COPS Usage for Outsourcing
Diffserv Resource Allocation”
<draft-salsano-issll-cops-odra-00.txt>
RSVP
daemon
ER/PEP
“The CCAPI (COPS Client API)”
<draft-mameli-issll-cops-api-00.txt>
Test-Bed
Bandwidth Broker
(COPS Server)
Edge Router
(COPS Client)
DiffServ
RSVP
RSVP/DiffServ
Edge Router
(COPS Client)
DiffServ
RSVP/DiffServ
DiffServ
RSVP
 All the components have been developed on Linux platforms
Alternative scenario for COPS-ODRA
 COPS client could be moved down to the application:
no need to use RSVP
BB
PDP
COPS-ODRA
PEP
SIP server,
H323 gatekeeper...
Open points / Current work
 Combination of outsourcing and provisioning to enhance
scalability
 Hierarchy of PEP/PDP could be used
PDP
PEP
COPS-ODRA
PEP
PEP
PDP
PDP
PEP
PEP
PEP
Open points / Current work
 Extension to inter-domain
COPS-ODRA
PEP
PDP
PEP
PDP
PDP
PEP
PEP
PEP
PDP
PEP