technische quality of service universitÄt ilmenau · basic functions to provide qos admission...

TECHNISCHE UNIVERSITÄTILMENAU

Inte

grat

ed H

ard-

and

Softw

are

Syst

ems

http

://w

ww

.tu-il

men

au.d

e/ih

s

Quality of Service

QoS requirementsQoS in networksBasic QoS mechanismsQoS in IP networks

IntServDiffServMPLS

Wireless Internet 2Andreas Mitschele-Thiel 6-Apr-06

QoS Basics

QoS attributes:data rate (throughput)error rate (packet loss)delay (latency)delay variation (jitter)

Mechanisms to ensure QoS?reservation of „dedicated“ resources for a connection (e.g. CS voice, IntServ/RSVP)differentiation (e.g. priorization) of the use of a shared resource by different connections (e.g. DiffServ)overprovisioning, i.e. dimensioning of the network such that all offered (or accepted) traffic can be handled (e.g. Ethernet LAN)

Basic functions to provide QoSadmission control (possibly including resource reservation)traffic classificationtraffic conditioning (traffic shaping and policing)schedulingoverload control

Goal of QoS-enabled networks:

Enable predictable service delivery to certain classes or types of traffic independent of other factors, e.g. other traffic or link conditions

Goal of QoS-enabled networks:

Enable predictable service delivery to certain classes or types of traffic independent of other factors, e.g. other traffic or link conditions


QoS Requirements – User (end-to-end) Requirements

Summary of applications in terms of requirements

Errortolerant

Errorintolerant

Conversational(delay <<1 sec)

Interactive(delay approx.1 sec)

Streaming(delay <10 sec)

Background(delay >10 sec)

Conversationalvoice and video Voice messaging Streaming audio

and video Fax

E-mail arrivalnotificationFTP, still image,

paging

E-commerce,WWW browsing,Telnet,

interactive gamesAcce

ptab

le e

rror

rate

Delays requirements


End User Performance RequirementsConversational/real-time services

Medium Application Degree of symmetry

Data rate

Key performance parameters and target values

End-to-end One-wayDelay

DelayVariation within a call

Information loss

Audio Conversatio-nal voice

Two-way 4-25 kb/s

<150 msecpreferred<400 msec limit

< 1 msec

< 3% FER

Video Videophone Two-way 32-384 kb/s

< 150 msecpreferred<400 msec limitLip-synch : < 100 msec

< 1% FER

Data Telemetry- two-way control

Two-way <28.8 kb/s

< 250 msec N.A Zero

Data Interactive games

Two-way < 1 KB < 250 msec N.A Zero

Data Telnet Two-way(asymmetric)

< 1 KB < 250 msec N.A Zero

Source: UMTS standards

FER: Frame Error Rate


End User Performance RequirementsInteractive services


Data rate


One-wayDelay

DelayVaria-tion

Information loss

Audio Voice messaging

Primarilyone-way

4-13 kb/s

< 1 sec for playback < 2 sec for record

< 1 msec

< 3% FER

Data Webbrowsing- HTML

Primarily one-way

< 4 sec /page

N.A Zero

Data Transaction services – high priority e.g. e-commerce, ATM

Two-way < 4 sec N.A Zero

DataE-mail(server access)

PrimarilyOne-way

< 4 sec N.A Zero


End User Performance RequirementsStreaming services


Data rate


One-wayDelay

DelayVaria-tion

Information loss

Audio High quality streaming audio

Primarily one-way

32-128 kb/s

< 10 sec < 1 msec

< 1% FER

Video One-way One-way 32-384 kb/s

< 10 sec < 1% FER

Data Bulk data transfer/retrieval

Primarily one-way

< 10 sec N.A Zero

Data Still image One-way < 10 sec N.A Zero

Data Telemetry- monitoring

One-way <28.8 kb/s

< 10 sec N.A Zero


Architectural Requirements

IP-based networks are still expected to increase in

the number of hosts

the number and variety of applications

the capacity of the network infrastructure

This growth is expected to continue for the foreseeable future

=> Need for a scaleable architecture supporting service differentiation

Goal of a QoS enabled network architecture:

Enable predictable service delivery to certain classes or types of traffic regardless of what other traffic is flowing through the network during periods of congestion


QoS in Networks – End-to-end QoS

ISP

Backbone Network

Backbone Network

LAN or wireless

End-to-end QoS

Edge-to-edge QoSEdge-to-edge QoS Edge-to-edge QoSEdge-to-edge QoS

... ...RouterLink

Network-layer QoS depends on

routers along the path

characteristics of each link´s technology (layer 1 and 2)

Data Link layer QoS


Edge-to-edge QoS

Processing delays experienced within each routerTransmission delays across each link (fairly predictable)

Introduced within routers by unrelated traffic passing through shared resources at congestion points (queueing delays)

Routers provide only finite buffering capacity (congestion points)

Latency

Jitter

Packet loss

FIFO Queue

Port n

Port m

„Best-Effort“ RouterYn pps

Ym pps

Output PortX pps

...

Dominant influence of routers on achieved network-level QoS


QoS-aware Router

A queue for each class of trafficQueue managementDifferent packet discard functions

Queues must share finite capacity of output link → scheduler

Classification of packets (Traffic classes)

Port mYm pps

Classify

....

Port nYn pps

Output PortX pps

Schedule

Queue

Queue

Queue

Queue

Queue

Queue


Scalable QoS Architecture

Design of a good QoS architecture is generally non-trivial

Edge routers: complex but slower software implementation being able to classify and independently queue hundreds of traffic classes

Core routers: speed-optimized hardware implementation of a limited number of queues for handling all traffic classes

Capacity problem:

Needed granularity is available at the edges, but not in the core!

Multiple traffic classes have to share queues within the core routers

To reduce unpredictable mutual interference in the core, a level of predictabilitymust be imposed on the traffic before entering the core

Solution: Edge routers manipulate the temporal characteristics of individual traffic classes


Basic QoS Mechanisms – Traffic Shaping and Policing

Traffic ShapingPlacing an upper bound on the maximum bandwith available to a traffic class

PolicingIf too many packets arrive in a given time interval, some are simply dropped

MarkingPackets are marked if they exceed a burstiness threshold

The core can schedule such packets with lower priority

In case of transit congestion, marked packets are dropped first

ReorderingWithin one queue unmarked packets are scheduled before marked ones


Metering

Policing and Marking share a common component – a metering function detecting whether a packet is „in“ or „out of profile“

Example: Token Bucket Meter

Tokens are added with some fixed rate X (tokens per second)

Token Bucket with fixed depth of Y

tokens

Whenever a packet arrives, one token is removed from the bucket

and the packet is marked to be „in profile“Data

Packet 1Data

Packet 2Data

Packet 3Data

Packet 4Data

Packet 5Data

Packet 6

Whenever a packet arrives and no token is available in the bucket,

the packet is marked to be „out of profile“


Metering

Policing and Marking share a common component – a metering function detecting whether a packet is „in“ or „out of profile“

Example: Token Bucket Meter

Allows a small degree of burstiness

Enforces a lower average rate limit

Arriv

al R

ate

( pps

)

Elapsed Time

„in profile“ „in profile“„out of profile“


Packet Dropping

Ran

dom

Ear

ly D

etec

tion

(RE

D)

Dro

ppin

g

Prob

abilit

y

Average Occupancy

100%

1

maxp

minth maxth

Never drop

Non-zero and

increasing likelyhood

of drop

Always drop

Dro

ppin

g

Prob

abilit

y

Average Occupancy

100%

1

maxp

minth maxth

Never drop

Non-zero and

increasing likelyhood

of drop

Always drop

Wei

ghte

d R

ando

m

Ear

ly D

etec

tion

min1thmin2th max1thmax2th

Marked Packets

Regular Packets

different dropping probabilitiesfor different traffic (TOS field)


QoS in IP Networks – IP Packet Marking (TOS Field)

Packet Marking assigns a priority level to each packet

Devices supporting traffic priorisation can use this information to provide traffic shaping capabilities enabling QoS

In IP-based networks this priority level is stored in the Type of Service (TOS) field (8 bits) of the IP header:

Type of Service field

Precedence field: denotes the importance or priority of a packet

TOS field: denotes how a device should handle the tradeoff between throughput, delay, reliability and cost to provide the appropriate service for a packet

MBZ field: must be zeroBit: 0 1 2 3 4 5 6 7

There is no standard for interpreting the TOS field in the IP header!


Advanced Network Services

Integrated Services (IntServ, or IS)

Differentiated Services (DiffServ, or DS)

Multiprotocol Label Switching (MPLS)

A number of concepts are common to each of these network models


links

Common Concepts

Network architectures comprise

edge routers

core routers


Common Concepts

Edge routers

accept customer traffic into the network

characterize, police, and/or mark traffic, being admitted to the network

may decline requests signaled by outside sources (admission control)


Common Concepts

Core routers

provide transit packet forwarding service between other core and/oredge routers

differentiate traffic insofar as necessary to cope with transient congestion within the network


Integrated Services (IntServ, or IS)

Two classes of applications are supported by IntServ:

Real-time applications

Traditional applications expecting a service best described as best effort „under unloaded conditions“

IntServ architecture focuses on supporting individual applications by

per flow traffic handling at every hop along an applications end-to-end path

an a-priori signaling of each flow‘s requirements (setup of the flow)

An IntServ flow (a common QoS treatment) is defined as a stream of packets with common

source address, destination address and port number

Signaling in the IntServ architecture to set up the flow is supported by the ReSerVation Protocol (RSVP)


IntServ – Service Models

IntServ defines these service models:

Controlled Load

• Approximates the behavior visible to applications receiving best-effort service „under unloaded conditions“ (private best effort)

• Supports nominal end-to-end latency bounds

• There is some likelihood of moderate to extreme jitter

Guaranteed Service

• Datagrams will arrive within the guaranteed delivery time

• Datagrams will not discarded due to queue overflow(provided that the flow‘s traffic stays within its specified traffic parameters)

Best Effort


IntServ – Network Model

Before a flow is allowed to use the network resources it is subjected to admission control of each network element along the proposed path (local per hop decision)A flow is admitted only when each network element along the path indicates it can support the request

Network elements on the edge of the network limit an applications capability to inject traffic exceeding its negotiated traffic profile (possibly rate shaping)

Each router on the established path maintains state information on the flow


Token Bucket: Rate (bytes/s) and

size (bytes)

Peak data rate

Minimum policed unit

Maximum packet size

IntServ – Reservation Protocol

Path

message

Path

message

Path

message

Path

message

Path

message

Path

message

Path messagefrom Sender

contains Traffic Specification

that profiles the flow to be sent

Each RSVP-enabled router installs Path state and forwardsPATH message to

next hop on route to receiver

Receiver cannot make a

reservation request until it receives PATH

message

RESV messagecontains resource

reservation request

RESV

message

RESV

message

RESV

message

RESV

message

RESV

messageRESV

message

The RESV message goes upstream following the

Source Route provided in PATH message. EachRSVP-enabled router makes the requested

reservation

Sender

Receiver


IntServ – Reservation Protocol

RSVP is receiver-initiated (receiver of data flow is responsible for the initiation of the resource reservation)

RSVP supports heterogeneous receivers in a multicast group

multicast group membership changes dynamically

→ reservation must be renewed

multicast group members „switch channels“

[Compare to sender-initiated approach: the sender would be responsible for resource reservation for all multicast group members!]

Periodic Path messages are forwarded along the routing trees provided by the routing protocol (routing from source to sinks based on regular IP mechanism)

Reservation refresh messages are forwarded along the sink trees (based on state information maintained by each router) to maintain current reservation state (identical to first request)


IntServ – Summary

Pros

Provides the highest possible level of QoS

Cons

Each flow must be handled and maintained by each router on the data path even in the core network (scalability problem: consider that millions of flows have to be managed by a Gigabit router)

Signaling overhead due to RSVP soft-state behavior

Shortest path routing (OSPF) may not be optimal

No fairness, i. e. fair distribution of limited resources among aspirants

Violation of IP principle to keep individual states of connections in the edges (hosts) only


Differentiated Services (DiffServ, or DS)

DS Boundary Node

DS Interior Node

DS Ingress Node

DS Egress Node

DS Domain

Edge-and-core architecturecomplex decision making is pushed to the edgesedge-to-edge services are built from a small set of core router behaviors

Terminology

Ideas:

alternative to the high complexity of the IntServ architecture

incremental improvements on the best-effort service model

remove complexity from the core nodes => scalability


DiffServ – Traffic ClassificationEdge-and-core architecture requires mapping of a wide variety of traffic into a restricted set of core router behaviors within the DS Ingress Node

Wide variety of end-to-end

services

Restricted set of core router behaviors

PHBs

DS Ingress Node

Two primary types of DiffServ classifiers (applied in ingress node):Behavior Aggregate (BA)

packet classification solely based on DiffServ field (Differentiated Services Code Point – DSCP values) in IP header (former TOS field)

Multi-Field (MF)packet classification based on multiple fields of the header, e.g.

source and destination addressessource and destination portsprotocol ID

Within a DiffServ domain many microflows will share a single DSCP


DiffServ – Traffic ConditioningTraffic conditioning:

Meteringmonitoring if traffic meets the profile (based on classification)

Markingsetting of the DS field

Classifier BA/MF

Marker

Meter

Shaper / Dropper

Traffic Profile

Traffic Conditioner

Router

Shaper/dropper queueingpriority degradation or dropping where negotiated rate is exceeded


DiffServ – Per-hop Behaviors (PHBs)

PHBs are a description of the externally observable forwarding behavior of a DS node applied to a particular Behavior Aggregate (BA):

resources (buffer, bandwith, ...)

priority relative to other PHBs

relative observable traffic characteristics (delay, loss, ...)

→ no constraints with respect to implementation!

PHBs are indicated by specific values in the DSCP

PHBs are building blocks for edge-to-edge services

Note: DiffServ allows to map multiple DSCP values onto the same PHB

Two PHBs have been standardized by IETF:

Expedited Forwarding (EF)

Assured Forwarding (AF)

(Class Selector Per-hop Behaviors)


DiffServ – Expedited Forwarding (EF) PHBEF PHB requests every router along the path to service EF packets at least as fast as the rate at which EF packets arrive

Rate shape or police EF traffic on entry to the DS Domain, to limit the rates at which EF traffic may enter the network core

Configure the EF packet-servicing interval at every core router to exceed the expected aggregate arrival rate of EF traffic

EF packet-servicing intervals must be unaffected by the amount of non-EF traffic waiting to be scheduled at any given instant

Output Port

ScheduleQueue

Queue

Queue

Queue

Queue

Queue

DSCP (locally mapped onto EF PHB)

Other PHBs

0 01 1 11

EF PHB is a building block for low-losslow-latencylow-jitter

edge-to-edge services


DiffServ – Assured Forwarding (AF) PHBGroup of PHBs for building edge-to-edge services

Relative bandwidth availability

Packet drop characteristics

Output Port

Queue

Queue

Queue

Queue

Queue Assignment

Drop Weighting

n 0n m mn

Per Queue RED-like

Packet Dropper

Parameters (drop probabilities, queue sizes, scheduling parameters) are assigned by the network operator allowing him to build desired end-to-end services


DiffServ – Two-tier Architecture

DS Egress Node

To permit services which span across domains

Establish Service Level Agreements (SLA) including Traffic Conditioning Agreements – TCA

Common service provisioning policy

DS Ingress Node DS Domain

DS Ingress Node

DS Egress Node

DS Domain

DS Ingress Node

DS Egress Node

DS Domain

Resource Management is performed at two levels

Inside administrative domainsBetween neighboring domains (Bandwidth Broker – BB)

BB

BBBB

Concatenation of bilateral agreements leads to end-to-end QoS delivery paths But: Agreements are bilateral only!

SLA 1

SLA 2


DiffServ – Summary

Wide variety of services

Easy introduction of new services in already existing DS enablednetworks

Decoupling of services from application in use

Avoid per-microflow or per-customer state handling within core network nodes => scalability

Interoperability with old network nodes

Supports incremental deployment

Division of forwarding path and management plane


Multi-Protocol Label Switching (MPLS)

Convergence of connection-oriented forwarding techniques and the Internet routing protocols

MPLS is not primarily a QoS mechanism!

Important tool for backbone providers

Allows traffic engineering of non-shortest-path routes within a network

Simplifies the mechanics of packet processing within core routers

Provides high-speed tunnels between non-label-switched domains

Make DiffServ architecture more reliable!


MPLS

MPLS Edge MPLS EdgeMPLS Core

MPLS Domain

Customer B

Customer C

Customer A

Customer A

Customer A

Customer C

Customer B

Customer B

Label switched Router

Edge LSR

Label = 17

Label = 10

Label = 200

Label = 35

Label = 17

Label = 17

On each physical link, a Label Switched Path (LSP) is represented by a particular label

One LSP may be represented by different labels on other links along its path

Association between actual label values and LSP at any hop is created on-demand by the Label Distribution Protocol (LDP)


MPLS – Forward Equivalence Class (FEC)

Forward Equivalence Class (FEC)A group of packets that share the same requirements for their transport (e.g. with the same forwarding treatment, over the same path)

LabelA label identifies the Label Switched Path (LSP) a packet should traverse

The Label is carried or encapsulated in a Layer-2 header

Comparison of DiffServ- and MPLS-based forwarding

IP Dest. Addr. IP (L3) Dest. Label

FEC (QoS)

DiffServ (Core handling)

MPLS (Core handling)

MPLS (Edge handling)

DiffServ (Edge handling)

DSCP (QoS)DSCP (QoS)Label

IP Dest. Addr.

…


MPLS – Label Switched Paths (LSP)

Label Switched Paths (LSPs)Hop-by-hop routing

• each LSR independently selects the next hop for a given FEC(method is similar to that currently used in IP networks)

Explicit routing (ER)

• a kind of source routing: Ingress LSR specifies the list of nodes through which the ER-LSP traverses

• specified path could be non-optimal (Traffic Engineering)

• resources may be reserved to ensure QoS

Label Switched Path MergingTwo or more incoming labels map to a single downstream label at a core LSR

Traffic belonging to the same FEC but entering from different Ingress LSRs are merged onto a single LSP at some point in the middle of the network


AdvantagesMPLS forwarding can be done by simple switches

Only label lookup and replacement must be performed

Not necessary to analyze the network layer header (e.g. IP header) within the MPLS enabled network

A packet is assigned to a FEC only once when entering the networkInformation carried in the packet header can be used for FEC mapping (incoming port, ...)

FEC mapping can become more and more complicated without any impact on the routers that only forward labeled packets

MPLS provides explicit routing (traffic engineering)

The label may represent a combination of the FEC, a class of service and other forwarding criteria

MPLS is applicable to any network layer protocol

MPLS can support a hierarchical routing design (label stack)

FECs can range from „IntServ“ to „DiffServ“

Virtual Private Network support


No distinction between packets within the network

(if no resources are available packets are queued or dropped)

Minimalist counterpart to IntServ, throwing out everything that isn‘t

essential to the provision of some aggregate service

levels

Summary 1

Relative QoS level

Best effort

Best effort

Activated by: -

Packet Marking

Packetmarking

Net

Each packet is marked with a request for a type of

service; nodes select routing paths and/or forwarding behaviors to satisfy the

service request

Integrated Services

Integrated Services (RSVP)

Net + App

First attempt of IETF to develop a service model that supports

per-flow QoS guarantees; requires complex architecture along any edge-to-edge path

Differentiated Services

Differentiated Services

Net Net

Multiprotocol Label Switching

MPLS

Can build upon Diffserv and adds support for explicitly

constructed, non-shortest-path routing of traffic


Summary 2 – Apply a mix of techniques to provide E2E QoS

IntServ

(Transit Network)

DS DomainDS Domain

DS DomainMPLS

IntServ

IntServ

(Transit Network)

IntServ in the access network DiffServ/MPLS in the backbone


QoS on the Air Interface

QoS has to be provided end-to-endbut, different mechanisms may be used on different parts of the end-to-end connectionapplication of the mechanisms to the air interface

reservation(IntServ)

differentiation(DiffServ)

overprovisioning

UMTS provides a mix (variety) of the techniques in different parts (levels) of the system

=> appropriate where the amount of resources and the number of connections is small and the QoS requirements are hard

=> appropriate where a large number of connections has to be handled or QoS requirements are moderate

=> appropriate where resources are abandon(typically not true for air interface) or traffic volume is known (may hold for access network)

technische quality of service universitÄt ilmenau · basic functions to provide qos admission...

Documents