The OPENISE QoS approach NTUA Telecommunications Laboratory Panagiotis G. Stathopoulos

1. The OPENISE QoS approach NTUA Telecommunications Laboratory Panagiotis G. Stathopoulos The OPENISE QoS approach

2. Part A Introduction to the OPENISE network platform The OPENISE QoS approach

3. OPENISE • Objectives: • To define, set-up, integrate and experiment with an open, flexible and scalable end-to-end platform for the networked delivery of enhanced interactive services. • Key project features: • MPEG4 content production and streaming. • Broadband IP network featuring efficient QoS and multicast capabilities. • High speed access networks (ADSL & Radio P-MP). The OPENISE QoS approach

4. An OPENISE platform use case • Network Architecture for a “Broadband Portal”... • …i.e. for an ISP providing MM services over its network to users with high-speed access. • Three cases(in the order of relevance to OPENISE): • ISP owns Servers, Core network and PoPs. • ISP owns Core network and PoPs; other Service Providers attach the Servers directly to core network. • ISP owns only the Backbone (it’s just a transit network). The OPENISE QoS approach

5. OPENISE applications • MPEG4 synthetic and natural content streaming. • MPEG4 streaming server/player. Related Applications: • Interactive TV. • Tour in Virtual Monuments. • MPEG4 3D video & data conferencing. The OPENISE QoS approach

6. OPENISE network requirements • Provide IP applications with quality appropriate for multimedia and business purposes. • Offer an open & scalable solution for providing QoS guarantees. • Select solutions from emerging Internet standards and integrate innovative mechanisms. • Offer advanced IP multicast, combined with QoS monitoring capabilities. • Broadband access on copper and radio. The OPENISE QoS approach

7. Part B IP QoS Frameworks & OPENISE approach The OPENISE QoS approach

8. Integrated Services • Applications reserve resources using RSVP signaling. • Sending hosts send PATH messages describing the type of traffic to be offered. • All intermediate routers should implemented a number of per flow operations: • PATH state installation, Admission Control, Multifield Classification, Packet scheduling. • IntServ framework provides end to end QoS guarantees. • It does not scale well, since it poses a significant processing overhead to each RSVP-IntServ capable router. The OPENISE QoS approach

9. Differentiated Services • Defines aggregate traffic handling mechanisms. Per flow operations are required only at the the boundaries of the DiffServ domain. • Traffic is classified depending on the DSCP codepoint. • Offers a set of predefined Per Hope Behaviors at each DiffServ domain node. • Does not pose signaling overhead and per flow processing - It overcomes scalability problems of IntServ. • End to end quantitative QoS guarantees can be offered through appropriate routing. The OPENISE QoS approach

10. OPENISE Actions • Specify a reference network topology suitable for the project’s objectives. • Specify protocols and frameworks that will be used. • Specify application flows requirements. • Specify levels and granularity at which the QoS will be offered. • Specify the requirements for the Network Elements(Scheduling, Shaping, Marking, etc.) • Identify adaptations needed at the end-systems. The OPENISE QoS approach

11. High level network architecture • The overall network reference architecture consists from: • Two relatively simple and properly dimensioned stub networks: • Server farm SAN network • and access ADSL and Radio P-MP networks. • The more demanding in terms of scalable QoS provision transit core network. • RSVP and DiffServ are seen as complementary technologies in the pursuit of end to end QoS. The OPENISE QoS approach

12. PC PC Reference Network architecture Access Stub Network Transit Core Network Server Stub Network PoP DS-BB RACA2 EgrR1 ER2 RACA1 RACA3 ER1 IngrR DSLAM EgrR2 ER3 RSVP RSVP DiffServ RACA = RSVP Admission Control Agent ER = Edge Router IngrR = Ingress Router DS-BB = DiffServ Bandwidth Broker EgrR = Egress Router The OPENISE QoS approach

13. OPENISE Framework - Summary (1) • RSVP signalling combined with IntServ QoS classes is used only on the Server and Access stub networks. • Server and Access stub networks are properly dimensioned. • Scalable DiffServ approach in the Core Network (i.e. resources provisioned for fixed number of PHBs/CoSs). • In parallel, application level protocols (RTP/RTCP) and mechanisms are introduced for QoS monitoring and traffic regulation with special focus on the multicast case. The OPENISE QoS approach

14. OPENISE Framework - Summary (2) • For the initial experiments the DiffServ domain is statically configured: • Resource allocation, explicit path routing and node configuration is performed manually. • At the second platform release dynamic or semi-static provisioning will be offered: • Admission Control done on the basis of initial resource allocation. Bandwidth Broker monitors flow rejections and may re-allocate resources periodically. The OPENISE QoS approach

15. OPENISE Framework • This novel approach offers both strict per flow QoS guarantees and high network scalability. • Per flow operations are restricted to the DiffServ’s domain Edge Routers. • This way per flow complexity lies only at the boundaries of the DiffServ Domain. • Inside the DiffServ Domain only simple per aggregate functionality is required. • Since RSVP signaling is restricted between end hosts and Edge Routers a pure DiffServ mode operation can also be offered. This way even greater scalability and flexibility is achieved. The OPENISE QoS approach

16. Part C Application flows requirements & Classes of Service offered The OPENISE QoS approach

17. Classes of Service • The overall platform will offer small pre-defined set of QoS levels, (Classes of Service - CoS). • Classes of Service definition is based on innovative app’s requirements and flows such as: • OPENISE applications: • videoconference • virtual guided tour • interactive TV • Typical Internet applications are also considered (WWW, ftp, popular MM applications) in order to provide a generic framework. The OPENISE QoS approach

18. Application flows • Application flows characterization • Delay • Elastic: no delay bounds, but usually reliable transport to handle losses. (e.g. 3D scenes over TCP transfer) • Real Time Tolerant: weak bounds on delay => statistical or even qualitative guarantees, optional admission control. (i.e video streams using buffering) • Real Time Intolerant: guaranteed bounds on latency & jitter => per-flow QoS, quantitative guarantees, admission control mandatory. (e.g. “live” communication, videoconferencing) The OPENISE QoS approach

19. Classes of Service definition • Quantitative CoS (Quantitative QoS guarantees) • Virtual Leased Line: bounded delay, adm. control required => RTI applications • Also the two variant CoS, Controlled Delay – Low & Medium, based on the effective BW notion will be evaluated. Features: • statistically bounded delay, adm. control recommended => RTT and RTI applications • Qualitative CoS, (Qualitative QoS offered, “better best effort”) • Forwarding Assurance Levels (set of CoSs): packet drop probability control, no strict delay demands => RTT and Elastic applications • Best Effort => Elastic applications The OPENISE QoS approach

20. Part C OPENISE QoS approach details The OPENISE QoS approach

21. RSVP - DiffServ Interoperation • RSVP provides per flow signalling information for end to end QoS guarantees, between hosts and Edge Routers. • RSVP and IntServ are separable. • Only the Edges of the DiffServ domain are required to process RSVP messages. • For the OPENISE framework extensive IntServ capable stub networks, will not be used. • This solution is more generic and scalable, while it does not preclude future extensions. The OPENISE QoS approach

22. RSVP functionality • Per-flow Admission Control on the DiffServ domain resources, based on RSVP RESV messages, is performed at the Edge Routers. • Set-up of Multi-Field (MF) Classifiers, Markers & Shapers at Edge Routers. • Classification, Marking & Shaping can also be performed by the host. • Sets up the Policing function at the Border router in case it’s needed (e.g. Server Provide  Network Provider). The OPENISE QoS approach

23. DiffServ core network (1) • SLS = Ingr. & Egr. Point + CoS + Resources (B/w). • End to end QoS = RSVP stubs + SLS through DiffServ core. • Quantitative CoS quantitative PHB + signaling + admission control + explicit path routing, for end-to-end delay control and load control. • Explicit paths (tunnels) for multicast traffic. Specification of point to multi point SLS. The OPENISE QoS approach

24. DiffServ core - Access networks • ATM switching technologies in the core. • PVCs & MPLS for explicit routes set-up will be investigated. • ATM switching also at the ADSL & Radio P-MP access networks. • ATM inherent QoS support provides a strong QoS framework. • Appropriate mapping of OPENISE CoS to ATM’s Service Categories, The OPENISE QoS approach

25. DiffServ domain provisioning • Dynamic or semi-static provisioning: manages the DiffServ core resources in order to offer the QoS needed. • A DiffServ BB may reallocate resources, if a high or low water threshold of per flow reservations is exceeded. • RSVP for aggregates will be used as a basis for developing a DiffServ BB. • This approach is considered open, flexible and conforming to emerging Internet standards. The OPENISE QoS approach

26. CoS implementation • Quantitative CoS implementation examples: • Virtual Leased Line Class = EF (top priority) + TB shaping (low shaping delay). • Controlled DelayClasses (1,…,N) = exp-TB (NTUA’s packet spacing algorithm: longer shaping delay but controlled queuing delay for bursty traffic). • Qualitative CoS implementation examples: • Assured Forwarding Classes = AF (RED/RIO) (e.g. “Better Best-Effort” for higher quality Web browsing,…). • Best Effort. The OPENISE QoS approach

27. CoS to PHB mapping The OPENISE QoS approach

28. Shaper #1 (Rate R, QoS q) Flow #1 Aggregate stream QoS =>q . Aggregate or Individual flows (Shaped at Edge Routers/Hosts) . . Shaper #N (Rate R, QoS q) Router queue (controlled as an M/G/1 system) Flow # Ν exp-TBF - Basic Concept The OPENISE QoS approach

29. Rate regulation need - QoS Monitoring • In the IP world application level mechanisms contribute significantly to: • detection and avoidance of network congestion. • Traffic load regulation to optimal value. • Especially for: • Qualitative CoS were Admission Control is not performed • and for the pure DiffServ scenario. • In OPENISE RTP/RTCP rate regulation mechanisms will be exploited in parallel with network level protocols and mechanisms. The OPENISE QoS approach

30. Rate regulation mechanisms • Receiver driven adaptation. • Layer coded content. • Rate adaptation is accomplished by switching to different transmission quality layers • trade off between granularity in the rate levels, extra complexity and management traffic overhead! • The same approach is also applicable to the multicast scenario. • each layer corresponds to a multicast address. The OPENISE QoS approach

31. Implementation overview (1) • Core: Widely deployed commercial IP routers (Cisco) + ATM switching equipment. • Edge Routers : Linux based. Open source code software + availability of advanced networking mechanisms such as RSVP, DiffServ etc. • PHBs Implementation: Priority queuing (e.g. CBQ, per-class WRR or WFQ), buffer management scheme (RED, …) • DS-BB: Linux based. RSVP for aggregates implementation. The OPENISE QoS approach

32. Implementation overview (2) • End systems: Win2000 based incorporating RSVP, traffic control and multicast (IGMP) capabilities. • Functionality can be alternatively distributed between hosts, edge routers and border routers. • (i.e on aggregates or per flow policing, DSCP marking, shaping etc.) • Depends on the policy decision method and the administrative status of the stub and the core domains. The OPENISE QoS approach

33. Conclusions • Actual implemention of an Internet End to End Enhanced Interactive Services Platform, offering QoS support: • Scalable RSVP-DiffServ interoperation. • Also offers a pure DiffServ operation mode for end systems without RSVP capabilities. • Application level rate regulation for qualitative QoS support, suitable even for a plain best effort network. • Open and flexible network platform, based on emerging protocols. • High speed, QoS aware access networks. The OPENISE QoS approach

34. Further information • www.ist-openise.net • Annex 1 «Description of work». • D06 Preliminary Network Architecure and Protocols specification. • D07 Experiments Planning and Specifications. The OPENISE QoS approach

35. Ευχαριστώ - Thank you! The OPENISE QoS approach