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