DataTAG WP2 IP Quality of Service Architectures Issues and Proposals

1. DataTAG WP2IP Quality of Service ArchitecturesIssues and Proposals Valentina Capaccio DataTAG Meeting Amsterdam - June 20, 2002 Valentina Capaccio

2. Agenda • Towards QoS • IP QoS frameworks • Intserv • Diffserv • Intserv/Diffserv • Admission Control • Centralized Approach • Distributed Approach • Policy – Based Network Management • Possible architecture and its interaction with GARA • Conclusions Valentina Capaccio

3. Internet QoS • Best - Effort Service • It can be suitable for traditional Internet applications • e.g.,file transfers, web browsing, e-mail • Certainly unsuitable for emerging applications ! • e.g., IP telephony, audio and video streaming, multimedia conferencing Valentina Capaccio

4. IETF Solutions • Integrated Services Architecture [RFC1633] • a revolutionary approach • attempts to transform IP network in a reservation-based network • per-flow philosophy • Differentiated Services Architecture [RFC2475] • an evolutionary approach • pushes all the complexity to the edge of the network • per-aggregate philosophy Valentina Capaccio

5. Intserv Architecture • IS (Integrated Services) Model • to extend the current Internet service model • Reference Implementation Framework • to realize the IS model • Architectural model comprised of two elements: Valentina Capaccio

6. IS Model(three service classes specified) Best Effort service Guaranteed delay service Controlled Load service • Assured level of • bandwidth • Mathematically • bounded end-to-end • delay • No queuing losses • for conforming • packets • QoS achieved: • similar to that • achievable by • best-effort • traffic • in an unloaded • network Tspec, Rspec Tspec RSVP’s definitions Tspec = Traffic specification Rspec = Reserve specification Valentina Capaccio

7. IS Reference Implementation Framework • Four components: • Packet scheduler • Classifier • Admission control routine Traffic Control Mechanisms • Reservation setup protocol Valentina Capaccio

8. RSVP/Intserv Reservation Model • A reservation request is identified by the couple Flowspec Filterspec Specifies the desired QoS Identifies the set of data packets “Flowdescriptor” Valentina Capaccio

9. Intserv Flowspec • Flowspec is made up of : • Tspec ( Controlled Load Service) • Tspec, Rspec ( Guaranteed Service ) Tspec takes the form of a token bucket specification plus other parameters: Rspec is identified by: - a rate R - a slack term S The Rspec terms (R,S) are selected to obtain: - the desired bandwidth - delay guarantees r r - token bucket rate b - token bucket size p - peak rate M - maximum datagram size m - minimum policed unit b Valentina Capaccio

10. RSVP approachSoft States , Receiver - Oriented PATH RESV • PATH • provides information about Sender_Tspec • creates PATH states in routers • carries routers info (Adspec) to Receiver • RESV • in each router, if request can be accepted, creates a RESV state • updates Packet Classifier • updates Packet Scheduler Sender Receiver PATH & RESV states stated in routers need a periodical refresh otherwise expire! Valentina Capaccio

11. Critics to RSVP • Scalability • Each reservation requires a non-trivial amount of message exchange, computation and memory resources in each router • many soft states must be periodically refreshed • many individual queues must be managed by a scheduler • Back Compatibility • requires intra – routers communication agreement • different vendors must intercommunicate with fixed standard • requires a router – centric approach • intelligencegets concentrated in intermediate systems Valentina Capaccio

12. Diffserv Architecture • Which QoS need ? • ISPs want finer control of “relative” allocated traffic, expecially under heavy load • to provide a “better” service to some traffic • Which QoS solution ? • to push the complexity to the network edges • to force all per-flow work to the edges • Very simple semantic ! • packet label differentiation Valentina Capaccio

13. Differentiated Services Code Point DSCP CU 6 bit 2 bit VERSION IHL TOS TOTAL LENGTH IDENTIFICATION FLAGS FRAGMENT OFFSET TIME TO LIVE PROTOCOL HEADER CHECKSUM SOURCE ADDRESS DESTINATION ADDRESS IPv4 Header Valentina Capaccio

14. Basic Diffserv Model Core Network Edge Router Senders ISP ISP • Classification • Traffic Conditioning Receivers • Scalability : intelligence at the edge of the network ! Valentina Capaccio

15. Diffserv Building Blocks • PHB • the externally observable forwarding behavior applied at each DS node to a traffic aggregate • Service • composition of PHBs • DSCP • mapped into a PHB in a given domain • SLA • service contract agreement between customer and domain or intra - domain. It specifies the forwarding service a customer should receive. Valentina Capaccio

16. TCA (Traffic Conditioning Agreement) Meter packets Shaper/Dropper Classifier Marker • Specifies classifying rules and metering, marking, discarding and/or shaping rules • to be applied to the traffic stream Valentina Capaccio

17. Critics to Diffserv • Lack of a signalling mechanism • to convey the status of core routers to the end points • to take learned admission control decisions • Static forms of admission control applying provisioning policies at network elements • if they do protect the network to some degree • they can be quite ineffective ! Valentina Capaccio

18. Complementary Approaches ! • [RFC2998] and [RFC2990] recognize that: • both IntServ and DiffServ architectures have some critical elements in terms of their current definition which appear to be acting as deterrents to widespread deployment, • there appears to be no single comprehensive service environment that possesses both service accuracy and scaling properties, • further refinement of the QoS architecture is required to integrate DiffServ network services into an end-to-end service delivery model with the associated task of resource reservation, • it is then suggested to define an admission control function which can determine whether to admit a service differentiated flow along a nominated network path. Valentina Capaccio

19. Reference Framework [RFC2998] RESV RESV PATH PATH Receiver Sender ER1 BR1 BR2 ER2 Access Network Domain Access Network Domain DiffServ Domain Admission control processing • RSVP is used as an “explicit setup mechanism” to improve the service the network provides to applications • If Diffserv Border Routers are RSVP-aware admission control is part of the Diffserv region • changes in the capacity available in the Diffserv region are signalled outside via RSVP Valentina Capaccio

20. Resource Management in Diffserv • Two possible approaches to dinamically provision resources in Diffserv region and to take admission control decisions • Centralized Approach (traditional) • use of a Bandwidth Broker that has sufficient knowledge of resource availability and network topology • Distributed Approach (evolutionary) • Endpoint Admission Control (EAC) based on a pure end-to-end operation involving only the source and destination host. Valentina Capaccio

21. Bandwidth Broker Functional Blocks(QBone approach) Adjacent BB Adjacent BB - SLA information - Current reservations - Resource allocations - Configurations for routers - Service mapping - DSCP mapping - Policy information - Authorization and authentication database for users and peers Application Server Inter-Domain Data Store “Simple” Policy Services User/ host User/App Iface Routing Info Network Operator Intra-Domain Diffserv Border Router Diffserv Border Router Valentina Capaccio

22. Endpoint Admission Control PROBING 1 Source Destination 2 ACK DATA 3 Destination host monitors probing packets statistics for a given period of time Basic Principle: use lack of timely response to estimate congestion status of the network Valentina Capaccio

23. Gauge&Gate Reservation with Independent Probing (GRIP) GRIP: Measure & Decision Gate open or closed PROBING Source 1 Destination 2 ACK DATA 3 I D E A (Bianchi-Blefari Melazzi) • Implicitly convey signalling information via loss of packets • Drive packet losses on the basis of run-time measurements locally taken by each network router Valentina Capaccio

24. Towards a Policy-Based Network Architecture • No explained architecture allows to make reservation in advance ! • [RFC2753] recognizes that: • Network managers and service providers must be able to monitor, control and enforce use of network resources on the basis of fixed policies derived from criteria such as • identity of users and applications • traffic/bandwidth requirements • time of day/week • security considerations Valentina Capaccio

25. Basic Policy-Based Architecture Policy Decision Point Policy Decision Point Policy Proxy Directory Policy Management Console Policy Repository LDAP LDAP SNMP COPS Path of traffic flow Policy Enforcement Points (PEP) Valentina Capaccio

26. Architecture Components Directory • Directory stores a variety of information • User data • Authentication and access rights • User profiles • Infrastructure data • Static/start-up configuration for devices (e.g., routers, switches) • Server information (e.g., name server) • Policies • Conditions, actions, policy rules (time of day/week, identity of users, etc.) Valentina Capaccio

27. Architecture ComponentsPolicy Console • Policy console • Provides an abstraction of rules to create policies • It is used to define and edit policies • Validates policies • When appropriate, the policy UI is unified with the UI that manages the entities that are the subjects of the policy (e.g., users, computers, devices) Valentina Capaccio

28. Architecture ComponentsPolicy Decision Point • PDP that generally takes the form of a policy server • Makes policy selection getting policy from an LDAP-based directory • Makes policy decisions • Returns the final policy decisions based on admission control request to policy enforcement point Valentina Capaccio

29. Architecture ComponentsPolicy Enforcement Point • Policy Enforcement Point (installed in a router) • Upon receiving a notification that requires a policy decision, • formulates a request and sends it to PDP • Optionally caches policy decisions for future use • Processes traffic per policy decision • Relays events to Policy Decision Point Valentina Capaccio

30. A Possible Architecture(setup phase) RSVP request GARA Resource Manager RSVP-aware network Differentiated service network(s) RSVP-aware network RSL Foreground Reservation  Guaranteed Service Backgroung Reservation  Controlled Load COPS LDAP COPS LDAP COPS LDAP Receiver Valentina Capaccio

31. A Possible Architecture(allocation phase) RSVP answer • Two possible approaches: • A “simplified” BB • EAC algorithms GARA Resource Manager RSVP-aware network Differentiated service network(s) RSVP-aware network Reservation is OK ! Valentina Capaccio

32. Architecture for Resource Co-Allocation (DataGRID – D1.4) • Upon receiving the answer from the network, the Resource Manager notifies the result of the reservation request to the Reservation Agent Resource Broker Information System Reservation Agent Resource Manager Answer from the network Logging & Bookkeeping Valentina Capaccio

33. If reservation “in advance” • GARA network resource manager • Performs the mapping : RSL string  RSVP request • Informs the PDPs that an advance reservation is requested (it behaves like a Policy Console) • If reservation is successful, • Informs the PDPs that reservation was successful and this information will be communicated to LDAP-directories by PDPs • Notifies the Reservation Agent (RA) that reservation was successful An appropriate DSCP will be bounded for the traffic flow that requires reservation in advance Valentina Capaccio

34. If “immediate” reservation • GARA network resource manager • Performs the mapping : RSL string  RSVP request • Forwards the request to the network • If reservation is successful, • Notifies the Reservation Agent (RA) that reservation was successful A DSCP will be assigned to this reservation only if the total amount of bandwidth for that class has not been reserved by a reservation in advance Valentina Capaccio

35. Admission Control in Diffserv Region Mapping : Foreground Reservation  EF PHB Background Reservation  AF PHB • Resources for Advance Reservations are allocated bounding DSCPs • Reservations can be subjected to EAC (e.g., implementing GRIP) to implement a dynamic resource provisioning • A DSCP will be assigned to an Immediate Reservation only if the total amount of bandwidth for that class was not allocated for reservations in advance Valentina Capaccio

36. Conclusions • It is necessary a complex and articulate QoS architecture to satisfy all the needs of network managers and service providers • Existing QoS architectures do not support advance reservation and it is necessary to introduce an additional external mechanism • A lot of explained aspects are actually under investigation • Interaction with GARA architecture to map a RSL string into a RSVP request must be clearer defined Valentina Capaccio