3rd e3 ist concertation meeting the openise qos approach ntua telecommunications laboratory...

The OPENISE QoS approach3rd E3 IST Concertation Meeting

The OPENISE QoS approach

NTUA Telecommunications Laboratory

Panagiotis G. Stathopoulos


Part A

Introduction to the OPENISE

network platform


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


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


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.


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.


Part B

IP QoS Frameworks & OPENISE 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.


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.


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.


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.


Reference Network architecture

PC

PC

RSVP DiffServRSVP

ER1 IngrR

EgrR1

EgrR2

ER2

ER3

RACA1

DS-BB RACA2

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 NetworkAccess Stub

NetworkPoP


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.


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.


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.


Part C

Application flows requirements &

Classes of Service offered


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.


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)


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


Part C

OPENISE QoS approach details


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.


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


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)


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,


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.


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


CoS to PHB mapping

Class of Service Per Hop Behaviour

Virtual Leased Line EF

Controlled Delay – Low Exp-TBF

Controlled Delay –Medium

Exp-TBF

Forwarding AssuranceLevels

AF group

Best Effort BE


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)

RCQoS =>q


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.


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.


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.


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.


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.


Further information

www.ist-openise.net Annex 1 «Description of work».

D06 Preliminary Network Architecure and Protocols specification.

D07 Experiments Planning and Specifications.

3rd e3 ist concertation meeting the openise qos approach ntua telecommunications laboratory...

Documents

openise platform

openise network platform

rd e3 ist concertation

efficient qos

quantitative qos guarantees

core network

qos monitoring capabilities

broadband ip network