Applicazione del paradigma Diffserv per il controllo della QoS in reti IP: aspetti teorici e sperimentali

1. Applicazione del paradigma Diffserv per il controllo della QoS in reti IP: aspetti teorici e sperimentali Stefano Salsano Università di Roma “La Sapienza” - CoRiTeL

2. 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

3. QoS in the IP networks • “Per Flow” - the Integrated Service Architecture • “Per Class” - the Differentiated Service Architecture

4. Direction of data flow 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

5. 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)

6. 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

7. 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

8. 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

9. 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 ?

10. Overall scenario for Diffserv QoS Client client SLA = Service Level Agreement SLA SLA Domain Domain SLA SLA SLA Client 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

11. Direction of data flow 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)

12. 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 BB • Three components: • Intra-domain protocols • Inter-domain protocols • End-to-End Services BB BB BB

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

14. Resource allocation requests Resource allocationrequests ? Resource Control CoreRouter EdgeRouter EdgeRouter Control mechanisms (e.g. RSVP ?) Scope (p2p/p2anywhere…) “Size” granularity (per flow/aggregated) Time granularity (static/dynamic) ?

15. Outsourcing vs. provisioning models Outsourcing model Query (2) Provisioning model Trigger event Bandwidth Broker (Policy Decision Point) (1) Response (3) Events Edge Router (Policy Enforcement Point) Notifications Events Bandwidth Broker (Policy Decision Point) Configuration commands Edge Router (Policy Enforcement Point) Trigger events, Notifications andConfiguration commands are asynchronous

16. A possible end-to-end approach Intserv operations over Diffserv network Diffserv Core Routers RSVP capable Router RSVP capable Router Intserv Network Intserv Network Tx Rx ER ER Diffserv Core Edge Router (RSVP aware) 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

17. 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

18. 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>

19. 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

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

21. Intserv over Diffserv using COPS-ODRA BB/PDP Resources & topologyDBs “Integrated services over DiffServnetwork using COPS-ODRA” <draft-mameli-issll-is-ds-cops-00.txt> Decision element COPSserver COPS-ODRA protocol “COPS Usage for OutsourcingDiffserv Resource Allocation” <draft-salsano-issll-cops-odra-00.txt> COPSclient COPS client API RSVPdaemon ER/PEP “The CCAPI (COPS Client API)” <draft-mameli-issll-cops-api-00.txt>

22. Test-Bed • All the components have been developed on Linux platforms

23. 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...

24. Open points / Current work • Combination of outsourcing and provisioning to enhance scalability • Hierarchy of PEP/PDP could be used PDP PEP PEP PDP PDP COPS-ODRA PEP PEP PEP PEP

25. Open points / Current work • Extension to inter-domain PDP PEP PEP PDP PDP PDP COPS-ODRA PEP PEP PEP PEP