1. 3rd E3 IST Concertation Meeting The OPENISE QoS approach NTUA Telecommunications Laboratory Panagiotis G. Stathopoulos

2. 3rd E3 IST Concertation Meeting The OPENISE QoS approach Part A Introduction to the OPENISE network platform

3. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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).

4. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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).

5. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

6. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

7. 3rd E3 IST Concertation Meeting The OPENISE QoS approach Part B IP QoS Frameworks & OPENISE approach

8. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

9. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

10. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

11. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

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

13. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

14. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

15. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

16. 3rd E3 IST Concertation Meeting The OPENISE QoS approach Part C Application flows requirements & Classes of Service offered

17. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

18. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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)

19. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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

20. 3rd E3 IST Concertation Meeting The OPENISE QoS approach Part C OPENISE QoS approach details

21. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

22. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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).

23. 3rd E3 IST Concertation Meeting The OPENISE QoS approach  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. DiffServ core network (1)

24. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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,

25. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

26. 3rd E3 IST Concertation Meeting The OPENISE QoS approach  Quantitative CoS implementation examples:  Virtual Leased Line Class = EF (top priority) + TB shaping (low shaping delay).  Controlled Delay Classes (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. CoS implementation

27. 3rd E3 IST Concertation Meeting The OPENISE QoS approach CoS to PHB mapping

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

29. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

30. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

31. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

32. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

33. 3rd E3 IST Concertation Meeting The OPENISE QoS approach 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.

34. 3rd E3 IST Concertation Meeting The OPENISE QoS approach Further information  www.ist-openise.net  Annex 1 «Description of work».  D06 Preliminary Network Architecure and Protocols specification.  D07 Experiments Planning and Specifications.

35. 3rd E3 IST Concertation Meeting The OPENISE QoS approach