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 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 Client SLA Domain client SLA = Service Level Agreement Domain = Region of shared trust, administration, provisioning, etc. 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 Diffserv treatment  Three components: »Intra-domain protocols »Inter-domain protocols »End-to-End Services

Slide 13 Intra-domain protocols Diffserv Domain Edge Router Bandwidth Broker Host Core Router  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 (?)

Edge Router Resource Control Core Router Edge Router Resource allocation requests 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 Broker Notifications Configuration commands Events Trigger events, Notifications and Configuration 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 scalability  This solution does not prescribe how resources are managed in the Diffserv Region see draft-ietf-issll-diffserv-rsvp-04.txt Diffserv Core Intserv Network RSVP capable Router Diffserv Core Routers ER Edge Router (RSVP aware) Intserv Network 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

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 Resv Tx Intserv over Diffserv using COPS-ODRA Diffserv Core Ingress ER Path Resv  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 Egress ER Path Resv Rx COPS-ODRA

Intserv over Diffserv using COPS-ODRA COPS client COPS server Decision element COPS-ODRA protocol RSVP daemon COPS client API Resources & topology DBs “COPS Usage for Outsourcing Diffserv Resource Allocation” “The CCAPI (COPS Client API)” “Integrated services over DiffServ network using COPS-ODRA” BB/PDP ER/PEP

Test-Bed  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 PDP COPS-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 PDP COPS-ODRA PEP

PDP Open points / Current work  Extension to inter-domain PEP PDP PEP PDP COPS-ODRA PEP