Applicazione del paradigma Diffserv per il controllo della QoS in reti IP: aspetti teorici e sperimentali Stefano Salsano Università di Roma “La Sapienza” - CoRiTeL
Feb 25, 2016
Applicazione del paradigma Diffserv per il controllo della
QoS in reti IP: aspetti teorici e sperimentali
Stefano SalsanoUniversità 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
Direction of data flow
DSCP marked at edge
Service Level Agreement (SLA) defines capacity at each
service level (DSCP)
?
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”
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 ?
Control plane» it is left undefined in the Diffserv Architecture» admission control ? - Bandwidth broker » end-to-end services ? - interworking with Intserv
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
Client
SLA
Domain
ClientSLA
SLA Domain
client
clientSLA = Service Level Agreement
Domain = Region of shared trust, administration, provisioning, etc.
SLA
SLA
Overall scenario for Diffserv QoS
Resource management in the Diffserv
Statically provisioned resources Dynamically provisioned resources by RSVP Dynamically provisioned resources by a Bandwidth Broker
Direction of data flow
DSCP marked at edge
Service Level Agreement (SLA) defines capacity at each
service level (DSCP)
?
?
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
BB
BB
BBBB
BB
Diffservtreatment Three components:
» Intra-domain protocols» Inter-domain protocols» End-to-End Services
Slide 13
Intra-domain protocols
Diffserv Domain
Edge Router
Bandwidth Broker
Host
CoreRouter Control relationships
» 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 (?)
EdgeRouter
Resource Control
CoreRouter
EdgeRouter
Resource allocationrequests
Control mechanisms (e.g. RSVP ?)Scope (p2p/p2anywhere…)“Size” granularity (per flow/aggregated)Time granularity (static/dynamic)
Resource allocation requests
Outsourcing vs. provisioning models
(Policy Enforcement Point)
Trigger event
(Policy Decision Point)(1)
Query (2)
Response (3)
Edge Router
Bandwidth Broker
Edge Router
Events Bandwidth BrokerNotifications
Configurationcommands
Events
Trigger events, Notifications andConfiguration commands are asynchronous
(Policy Decision Point)
(Policy Enforcement Point)
Outsourcing model
Provisioning model
A possible end-to-end approach
Goal: preserve end-to-end signaling and scalabilityThis solution does not prescribe how resources are managed in the Diffserv Region
seedraft-ietf-issll-diffserv-rsvp-04.txt
Diffserv Core
IntservNetwork
RSVP capable Router Diffserv Core Routers
ER ER
Edge Router(RSVP aware)
IntservNetwork
Tx Rx
RSVP capable Router
Intserv operations over Diffserv network
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
Path
Resv
Path
ResvTx
Intserv over Diffserv using COPS-ODRA
Diffserv Core
IngressER
Path Path
ResvResv
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
BB
EgressER
Path
ResvRx
COPS-ODRA
Intserv over Diffserv using COPS-ODRA
COPSclient
COPSserver
Decisionelement
COPS-ODRA protocol
RSVPdaemon
COPS client API
Resources& topology
DBs
“COPS Usage for OutsourcingDiffserv Resource Allocation”
<draft-salsano-issll-cops-odra-00.txt>
“The CCAPI (COPS Client API)” <draft-mameli-issll-cops-api-00.txt>
“Integrated services over DiffServnetwork using COPS-ODRA”
<draft-mameli-issll-is-ds-cops-00.txt>
BB/PDP
ER/PEP
Test-Bed
RSVP RSVP/DiffServ
DiffServ
RSVP/DiffServ
DiffServ
DiffServ RSVP
Bandwidth Broker(COPS Server)
Edge Router(COPS Client)
Edge Router(COPS Client)
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
PEP
PDPCOPS-ODRA
SIP server,H323 gatekeeper...
BB
PEP
PDP
Open points / Current work Combination of outsourcing and provisioning to enhance
scalability
Hierarchy of PEP/PDP could be used
PEP
PDP
PEP
PEP
PDPCOPS-ODRA
PEP PEP
PDP
PDP
Open points / Current work Extension to inter-domain
PEP
PEP
PDPPEP
PEP
PDPCOPS-ODRA
PEP PEP