What is the service

Slide 1

Qualità di servizio in reti IP Tecnologie e Protocolli per Internet II

rev 0.8

Andrea Detti

Electronic Engineering dept.

E-mail: [email protected]

Ringraziamenti: devo un ringraziamento al Prof. Nicola Blefari-

Roberto Mameli, autori di presentazioni da cui sono state tratte parte delle seguenti slides.

Slide 2

Introduzione

+ Una rete supporta Qualità del Servizio (QoS) se fornisce un trasferimento di informazioni garantendo specifiche prestazioni

+ I parametri prestazionali di interesse sono:

Ritardo medio, massimo, percentile non superato

Jitter (RFC 3550)

Jitter tra pacchetto i e j, D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) Con Ri (Si) instante di tempo di ricezione (invio) pacchetto x

Stima Jitter --> J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16

Throughput : banda (bps) end-to-end garantita

Packet Loss Rate: probabilità di perdita di pacchetto=rapporto pachetti persi su pacchetti trasmessi

+ La necessità di avere una garanzia prestazionale su un parametro ed il suo relativo valore garantito dipendono dal tipo di applicazione.

Slide 3

Introduzione

+ La fornitura di QoS su Internet è problematica poiché

IP offre un servizio best effort, senza connessione e senza garanzie di affidabilità di consegna del pacchetto (reliability)

Non controllo , ovvero il modo di trasferimento è a domanda

Internet è caratterizzata da una interconnessione di reti (INTER-NETwork) fortemente eterogenee in termini di prestazioni (e.s. Gigabit Ethernet vs collegamenti diretti a 10 Mbps)

La reliability è assicurata per il trasferimento dati dal TCP, ma il TCP non è in grado di assicurare nulla in termini di ritardo, jitter e throughput.

Slide 4

+ Disciplina di coda (scheduling):

Algoritmi e insieme di code (buffer) attraverso i quali un nodo differenzia tra i pacchetti delle sessioni comunicative

Linux : qdisc (queue discipline)

+ Classificatore (Classifier) :

Permette ad un nodo di classificare i pacchetti (diretti verso una specifica interfaccia di uscita) in classi di servizio

Ogni classe di servizio è servita da una specifica coda

Una classe di servizio può essere associata ad una singola sessione comunicativa o a più sessioni comunicative caratterizzate da uno stesso parametro comune (es. Transport Layer == UDP)

Linux : filter

Elementi chiave di un framework di QoS

Slide 5

+ Policer / Shaper

Policer: rende il traffico in ingresso conforme agli accordi di QoS stabiliti, eliminando (o riclassificando come best effort) i pacchetti non conformi

Shaper: come il policer ma invece di eliminare/riclassificare i pacchetti non conformi, li ritarda in un buffer (finchè può)

Linux : ingress qdisc (policer), qdisc (shaper)

+ Architettura di QoS

Definisce e dove gli elementi di cui sopra sono posizionati nella rete e come questi funzionano

Elementi chiave di un framework di QoS

source shaper policer classifier

Queue #1

Queue # 2

Queue #3

Scheduler

algorithm (solo sul primo

Sorgente

Nodo di rete (QoS enabled)

Fo

rward

ing

IP layer

Slide 6

+ Il traffico offerto puntuale può temporaneamente superare la capacità

+ Senza coda questo traffico sarebbe perso

+ La coda permette di memorizzare di traffico e quindi rilanciarlo successivamente

+ Lo scheduling definisce quante code per interfaccia e da quale coda prelevare il prossimo

pacchetto che deve essere trasmesso

+ Esempi di scheduler

FIFO

Priority Queue (PQ)

Weighted Round Robin (WRR)

Deficit Round Robin (DRR)

Generalized Process Sharing (GPS)

Weighted Fair Queueing (WFQ)

Hierarchy Token Bucket (HTB)

Scheduling

Slide 7

FIFO

+ Strategia di coda più semplice (basso processing) ed utilizzata di default

+ Si trasmettono i pacchetti seguendo di arrivo (a meno di perdite)

+ Un elevato carico può aumentare molto il ritardo di coda compromettendo comunicazioni interattive

+ Molto spesso le implementazioni gestiscono lo spazio di memoria dedicato ad una FIFO su base pacchetto invece che su base byte, poichè vi è una forte semplificazione sul processing (es. circular buffer)

Nel caso di packet-based la memoria è suddivisa in blocchi pari al Maximum Packet Size ed uno ed un solo pacchetto è memorizzato in un blocco con un possibile spreco di memoria

Slide 8

Prestazioni di una coda FIFO

+ Le prestazioni di una coda FIFO peggiorano

drasticamente quando il carico (bitrate

offerto/bitrate linea) supera una certa soglia

+ Questa soglia dipende dalla burstiness del

traffico in ingresso

La burstiness misura i pacchetti arrivano

insieme

Burstiness = 0 significa pacchetti equispaziati, cioè

traffico CBR

Burstiness grande significa che i pacchetti spesso

arrivano insieme e poi silenzio

Un burstiness elevata si ha quando il traffico in

ingresso è molto correlato temporalmente (long

range dependence --> la funzione di autocorrelazione

non è sommabile)

Il traffico Internet segue un comportamento di tipo

self-similar e long range dependent

+ Maggiore è la burstiness del traffico, più bassa

è la soglia, ovvero peggiori le prestazioni

+ OVERPROVISIONING

Per assicurare basso ritardo, il carico

deve essere fortemente limitato (es. 50 %)

burstiness

Avg. Queue length

Interface load

10 % 50 % 100 %

Slide 9

Self-Similar

Frattale Traffico

Le caratteristiche statistiche sono invariati (a meno di un fattore moltiplicativo)

alla scala di osservazione

Slide 10

Self-Similar vs Poisson

Slide 11

Ottimizzazione FIFO per traffici TCP: Random Early Detection (RED)

+ Scarto randomico di alcuni pacchetti con probabilita di scarto proporzionale allo stato attuale della coda

+ Elimina la sincronizzazione delle connessioni TCP grazie alla randomicità delle perdite di pacchetto

MIN-thr

MAX-thr

1.0

maxp

MIN-thr

MAX-thr

P(drop)

qlen-avg

RED Enabled

Slide 12

Priority Queuing (PQ)

Traffic Destined

for Interface

Interface Buffer Resources

Transmit Queue

Output Line

Interface Hardware Ethernet Frame Relay ATM Serial Link Etc.

High

Medium

Normal

Low

Q Length Defined by Q Limit

Classify

Absolute Priority Scheduling

High Empty?

Send packet

from High

Medium Empty? Normal Empty?

Send Packet

from Medium

Send Packet

from Normal

Send Packet

from Low

Low Empty?

Y Y Y Y

N N N N

Slide 13

Priority Queuing (PQ) - Esempio

Due code: una per traffico UDP Traffic (high) e una per traffico TCP (low)

UDP

TCP

t

Delay

Maximum delay

for

real-time

FIFO

UDP

TCP

Delay PQ

t

Slide 14

Priority Queuing (PQ) : Problemi

+ Non un limite superiore alla banda utilizzata dalla classe ad alta priorità

+ Elevato rischio di per le classi a bassa priorità

Slide 15


Traffic Destined

for Interface

Interface Buffer

Resources

Q Length Deferred by Queue Limit

Up to 16

3/10

1/10

Weighted Round Robin Scheduling

Allocate Proportion of

Link Bandwidth

Classify

Interface Hardware Ethernet Frame Relay ATM Serial Link Etc.

2/10

3/10

2/10

Link Utilization Ratio

Transmit Queue

Output Line

Slide 16


+ Weighted round-robin

Differenti pesi wi per coda

Coda j può trasmettere wj pacchetti in un ciclo.

Ciclo di durata massima pari alla trasmissione di wj

pacchetti

+ Problemi

Pacchetti di dimensioni variabili

Impredicibilità sull uso della banda

Impredicibilita sulla durata dei ritardi

Slide 17

+ Ogni coda ha un deficit counter che memorizza il numero di crediti in bytes ed ha un valore iniziale pari a zero

+ Si definisce un quantum di bytes da scaricare da una coda prima di passare alla prossima

+ Ogni volta che si seleziona una coda, provenendo dalla precedente del giro, si incrementa il deficit counter di quantum

+ Per ogni pacchetto in testa alla coda selezinata,

Se la dimensione L è <= deficit counter

si trasmette il pacchetto,

si decrementa il deficit counter di L

Si passa al prossimo pacchetto della stessa coda

Altrimenti si passa alla coda successiva.

+ Se non c nessun pacchetto da trasmettere si azzera il deficit counter (per ottenere fairness)

+ Facile implementazione

+ Differenziazione delle classi di servizio attraverso quantum differenti per coda (WDRR)

Più grande il quantum, maggiore la percentuale di banda dedicata


Slide 18

+ 1st Round

A s count : 1000

B s count : 200 (served twice)

C s count : 1000

+ 2nd Round

A s count : 500 (served)

B s count : 0

C s count : 800 (served)


1500

300

1200

2000 1000

Second

Round

First

Round

Head of

Queue

A

B

C

0

Quantum size : 1000 byte

500

Slide 19

+ Metodologia ideale:

Ipotizzare che si possa inviare una parte infinitesimale di pacchetto (i.e., un singolo bit o un insieme di bit)

Round robin fra le code a livello di bit (i.e., ogni bit si passa alla coda successiva).

+ Politica ideale per la suddivisione equa della banda anche nel breve periodo

+ GPS non è implementabile è utilizzato principalmente come benchmark

+ Il numero di bit inviabili per round definisce i rapporti di capacità di trasferimento fra le varie classi di servizio


)(

*_

tACTIVEk k

j

jw

wlineaCapacitatCapacità

Slide 20


GPS examlpe 1

0

10

20

30

40

time

qu

eu

e s

ize A

B

C

Pacchetti di tre classi di dimensioni 10, 20 & 30

arrivano al tempo 0 e tutte le code hanno un

peso pari ad 1 bit

Slide 21

Weighted Fair Queueing

+ Non possiamo implementare il GPS

+ Pertanto, cerchiamo di emularlo

+ Si ordinano i pacchetti in base al loro expected virtual departure time del loro ultimo bit, calcolato applicando le regole del GPS

+ Elevato processing di ordinamento rispetto agli altri approcci, ogni nuovo pacchetto entrante bisogna ordinare di nuovo

Slide 22

Scheduling gerarchico

+ Gli scheduler possono essere organizzati in modo gerarchico.

+ Gli scheduler foglia prelevano i pacchetti dalle code quando lo scheduler di ordine superiore, a sua volta, preleva un pacchetto da loro

S1

S1.1 S1.2 S1.3

WFQ

DRR FIFO PQ

Flow fair queuing

+ Garanzie equità (fairness) di servizio ai vari flussi (i.e. sessioni UDP,TCP)

+ Linux SFQ, Cisco fair-queue

Slide 23

Queue 1

Queue 2

Queue N

HASH function on socket parameters

Fair scheduling

(DRR, WFQ, etc)

Packet output

Packet in

Slide 24

Cisco - Low Latency Queuing (LLQ)

+ Scheduler implementato in molti router Cisco

+ Utilizzato per fornire basso ritardo ai pacchetti real time e differenziare la capacità rimanente in classi di servizio

PQ

FIFO WFQ Costrittore di

capacità (Token

Bucket)

utilizzato per evitare

la starvation

(interviene solo nei

casi in cui la WFQ

vuole banda-

workconserving) Traffico dati a diversa priorità

Traffico voce

High priority Low priority

aka CB-WFQ

Cisco Routers- Scheduling

+ Strumenti:

Policy-map

Specifica politiche di trattamento dei pacchetti appartenenti ad una certa classe

Scheduling

CQ-WFQ (class-based WFQ)

Si configura la banda di ogni classe

LLQ

Una classe priority + altre classi in CW-WFQ

Marking

Shaping

Policing

Class (Classifier)

Specifica i criteri di matching che definiscono di un pacchetto ad una classe

Access-List (Classifier e policer)

Specifica dei criteri flessibili basati su L3/L4 che definiscono di un pacchetto ad un access group

Specifica se accettare o meno questi pacchetti

Slide 25

Cisco Routers- Scheduling gerarchico

Slide 26

output fastEthernet 1/0

Policy-map parent

class-default

Shape 2Mbit/s

Service-policy children

Policy-map children (CBWFQ)

VoIP

bandwidth 1500 kbit/s

Class-default

Bandwidth 500 kbit/s

Slide 27

Classifier

+ Classificazione:

Esamina il pacchetto e determina in base a delle specifiche regole quale è la coda dello scheduler su cui accodare

La classificazione è fatta in base ai campi dei packet headers:

Multi Field (MF) Classification:

Matching basuato su una tupla del packet header

Processing intensivo

Granularità fina

Behavior Aggregate (BA) Classification

Matching basato su un solo campo di un header (e.s., IP protocol type o IP TOS)

più semplice e più veloce della MF

granularità grossa

Interface based Classification

Matching basato

Slide 28

Policer and Shaper

+ Sono meccanismi utilizzati per il Traffic control. Limitano dei dati iniettato da una sorgente in accordo ad uno specifico profilo di traffico, concordato durante la richiesta di QoS

+ I profili di traffico sono spesso definiti in termini di un meccanismo di rate-limiting denominato Token Bucket, che può essere utilizzato sia come policer che come shaper

+ Shaper:

Ritarda i pacchetti fuori profilo in modo da rendere il flusso compatibile con il profilo di traffico

Uno shaper ideale è un Token Bucket con coda infinita

+ Policer:

Scarta o declassa i pacchetti fuori profilo

Può essere implementato con un Token Bucket con coda nulla

Slide 29

Token Bucket

r

Tokens

b Overflow

Tokens

Packets

Arriving Conform

Exceed

b Burst Size (byte)

r Token Arrival Rate (bit/sec)

Slide 30

Traffic mask post Token Bucket

t

Amount of

transfered

bits at time t

A(t)

b

r

Slide 31

Dual Token Bucket

+ First Token bucket control the average

+ Second Token bucket control the maximum duration of transmission at peak rate

yes

NO: Police Action

L y ? L x ?

x b

L bytes

NO: Delay

y M

YES: Transfer

buffer size

Shaper Policer

A(T)=min[pt+M, rt+b]

r bit/s p bit/s

Slide 32

Traffic mask post Dual Token Bucket

t

Amount of

transfered

bits at time t

b

r

Amount of

transfered

bits at time t

A(t)

M (often equal to the maximum packet size)

p

References per laboratorio QoS

+ Linux:

http://linux-ip.net/articles/Traffic-Control-HOWTO/classless-qdiscs.html

http://linux-ip.net/articles/Traffic-Control-HOWTO/classful-qdiscs.html

http://lartc.org/howto/

+ Cisco

http://startccna.blogspot.it/

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfintro.html

http://www.cisco.com/en/US/docs/ios/12_2/qos/configuration/guide/qcfcbshp.html

Slide 33




























































Slide 34

Resource Reservation Framework

+ Is the set of protocols, mechanisms and devices used to reserve and use bandwidth along a network path

+ We discuss:

Integrated Services Architecture (IntServ)

Differentiated Services Architecture (DiffServ)

Multi Protocol Label Switching

+ All of them are based on the concept of Collective pre-assignment (connection oriented) of resources

+ The first two are integrated in the IP layer; instead MPLS is another layer below IP

Slide 35

IntServ Architecture

Integrated Service (IntServ) architecture provides:

QoS support

Multicast support

Controlled link sharing

Slide 36

Intserv approach

Direction of data flow

An Integrated Services Architecture requires:

Traffic Control Mechanisms (Admission Control, Classifier, Scheduler)

Reservation Setup Protocol

The Intserv is based on the - handling of IP packets (both on User plane and on Control Plane)

Slide 37

IntServ Key Concepts

Flow

A distinguishable stream of related datagrams that

results from a single user activity and requires the same

QoS (e.g., a TCP connection or a UDP session)

Service Class

Specifies the type of service experienced by a flow

Currently IntServ Architecture provides 3 Service Classes

Best Effort delivery

Guaranteed Service

Controlled Load Service

Slide 38

Traffic Control Mechanisms

Admission Control

Decides whether accepting a QoS request based on

available resources

Requires the knowledge of

QoS parameters

Current state of the network

Slide 39

Traffic Control Mechanisms

Packet Classifier

recognizes the flow to which incoming datagrams belong to

the class (i.e. flow or a set of flows) is defined locally and can differ in different network nodes

Packet Scheduler

schedules incoming datagrams for transmission based on their service class

uses queue management and other mechanisms (e.g. timers)

may also apply traffic policing and/or shaping

Slide 40

IntServ Router Model

Packet Classifier

Packet Scheduler

Forwarding Path

Inbound link Outbound link

Background

functions

Routing Protocol Admission Control

Reservation

Protocol

Management

Agent

Routing DB Tr. Ctrl. DB

Slide 41

IntServ Guaranteed Service

Guaranteed Service is thought for real time applications

with tight delay requirements

Guaranteed Service QoS implies

assured level of bandwidth

mathematically bounded end-to-end delay

no queuing losses for conforming packets

The applications involved specify both traffic characteristics

(Tspec) and reservation characteristics (Rspec)

Slide 42

IntServ Guaranteed Service

Traffic policing

incoming traffic must conform to Tspec

non conforming traffic is discarded or treated as best effort

policing is executed at network borders

Traffic shaping

bursty traffic is shaped in order to fit it into Tspec

shaping may be executed inside the network

Guaranteed Service traffic is subject to

Traffic policing

Traffic shaping

Slide 43

IntServ Controlled Load Service

Controlled Load Service is thought for adaptive tolerant real time

traffic

Controlled Load Service guarantees a QoS similar to those achievable

by a best effort traffic in an unloaded network

Applications involved specify only Tspec (no Rspec required)

Traffic policing and shaping are required. Non conforming traffic is

treated as best effort

Slide 44

IntServ Tspec

Applications must always specify traffic characteristics

(Tspec) in order to let the network reserve a proper amount

of resources

The profile is expressed in terms of the Dual Token Bucket

Tspec parameters:

r = average rate (bytes/s)

b = bucket size (bytes)

p = peak rate (bytes/s)

M = max. datagram length

m = min. datagram length

Slide 45

IntServ Guaranteed Delay

Theorem

if

flows are characterized and are enforced by a token bucket Tspec

WFQ queuing discipline used in all the routers of the network

a reserved rate R not less than average token bucket rate r (R r)

it can be proved that the maximum end-to-end queuing delay DMAXQ is mathematically upper bounded (Parekh and Gallager, 1993)

Slide 46


Maximum end-to-end delay is given by:

DMAX = DFIX + DMAXQ

DFIX is related to fixed delays (transmission, propagation)

DMAXQ is the maximum end-to-end queuing delay

In a perfect fluid model the flow sees a dedicated wire of bandwidth R between source and destination

In this case the maximum end-to-end queuing delay should be:

b DMAXQ =

R b: bucket depth

R: reserved rate (R r)

Slide 47


To allow for deviations from the perfect fluid model two error terms are

introduced:

b DMAXQ =

R

C

R + D +

C: rate dependent error term (e.g. datagram assembling from ATM cells)

D: rate independent error term (e.g.

processing routing updates)

Considering peak rate limitation p and maximum packet size M, the

maximum end-to-end delay becomes:

DMAXQ =

(b-M)(p-R)

R(p-r)

M+CTOT

R + DTOT +

M+CTOT

R + DTOT

p > R r

R p r

Ctot, Dtot: sum of C and D parameters of the nodes of the path

Lossless buffer size at node i = b+Csum(i)+Dsum(i)*R

Csum(i)=sums of C until node i

Slide 48

IntServ Traffic Classes

Template

Components Guaranteed Service Controlled Load Service

End-to-End behavior

Typical Applications

Network Elements

involved

Parameters requested

Exported Information

Policing

Guaranteed max. delay Guaranteed throughput

No queuing losses

Real time applications

Fluid model using R (requested bandwidth) and

B (buffer size)

Tspec: r, b, p, M, m

Rspec: R, S

(C,D), i.e. values which measure deviation from the

ideal fluid model

M + min [p T, r T + b-M]

Min. datagram length: m

Approximates Best Effort

over unloaded network

Applications sensitive to

network congestion

Admission Control

Tspec: r, b, M, m

(p is not required)

No exported information

r T + b

Slide 49

RSVP Design Goals

RSVP has been designed according to several goals:

Unicast and Multicast capabilities

Heterogeneous receivers support

Source and sub-stream filtering capabilities

Dynamic multicast group changes capability

Efficient use of resources

Protocol overhead limitation

Connectionless and dynamic routing environment adaptability

Modularity

Slide 50

RSVP Design Principles

The following design principles have been adopted:

Receiver initiated reservation

Soft-state

Reservation styles and merging

Opaque information transport

Independence from underlying routing protocol

Slide 51

RSVP Key concepts

Flow Descriptor

obtained joining Filter Spec and Flow Spec

Flow

Descriptor

Filter

Spec

Flow

Spec

identifies packets of a flow

updates classifier

Service class Tspec (r,b,p,m,M) Rspec (R,S) updates scheduler

Slide 52

RSVP Messages

RSVP messages are carried inside IP datagrams (protocol ID 46)

Seven message types:

Path (downstream)

Resv (upstream)

PathErr (upstream)

ResvErr (downstream)

PathTear (downstream)

ResvTear (upstream)

ResvConf (downstream)

Slide 53

Unicast Reservation

1st step: PATH messages are sent downstream

RSVP Enabled

Host (SND)

RSVP Enabled

Host (RCV) RSVP Router RSVP Router

PATH

At the reception of a PATH message

RSVP router creates a path state associated to the corresponding session

RSVP router refeshes the timer associated to this path state

RSVP router updates Phop and Adspec objects and then forwards Path message towards next

Slide 54

At the reception of a RESV message an RSVP router

analyzes FlowSpec for Admission Control; if accepted a resv state is created

restarts the timer associated to the resv state

forwards Resv message to the previous node of the path (Phop)

2nd step: RESV messages are sent back upstream

RSVP Enabled

Host (SND)

RSVP Enabled

Host (RCV) RSVP Router RSVP Router

RESV

Unicast Reservation

Slide 55

RSVP Messages

Path message

sent downstream from sender towards receiver(s)

provides information about sender(s) Tspec and end-to-end path characteristics

creates path states in each router along the path

contains the following objects:

Session: destination IP address, port and protocol ID

Phop: address of previous RSVP node

Sender_Template: IP address and port of the sender

Sender_Tspec: sender traffic characteristics (including dual token bucket parameters)

Adspec (optional): One Pass With Advertisement (OPWA) information updated by routers along the path

Update MAX MTU if smaller

Parameters C and D of delay formula summed to the one just contained in the packet (Csum, Dsum)

Slide 56

RSVP Messages

Resv message:

sent upstream from receiver(s) towards sender(s)

carries reservation requests to the routers along the distribution tree

Resv messages originating from receivers of the same multicast group are merged together before being forwarded upstream

contains the following objects:

Session: destination IP address, port and protocol ID

Reservation style: it can be FF, SE or WF

Flow descriptor: Filter spec and Flow spec (including rate R)

ResvConf (optional): IP address of the receiver, used to allow the sender to acknowledge reservation

Slide 57

Intserv Scalability Problem

RSVP per-flow reservation model and soft-state philosophy are particularly suitable for multicast broadband applications (e.g. videoconference and video broadcasting)

When used for point-to-point narrowband purposes (e.g. IP telephony) these choices implies large processing overhead in routers and great amount of traffic generation for periodic refreshes

Example:

ADPCM coding requires 32 kb/s for a voice channel. Neglecting packet overhead a single OC-12 interface of a backbone router (622 Mb/s) should support up to 20000 flows, implying that:

packet scheduler has to manage 20000 queues

up to 20000 states must be periodically refreshed

Slide 58

Intserv Scalability Problem

Solutions

Flows aggregation (SRP - Scalable Reservation Protocol, currently under study)

Use of RSVP limited to the Access Network (IP based), with interconnection among IP domains relying on other QoS capable technologies (e.g. ATM)

Differentiated Services Approach

Combination of RSVP/IntServ in the Access Section and DiffServ in the backbone Internet

Slide 59

DiffServ approach

+ Scalability

A differentiated services mechanism must work at the scale of the Internet (e.g. millions of networks) and at the full range of speeds of the Internet (e.g., Gb/s links)

push all the state to the edges

force all per-flow work to the edges

Edge-only state suggests that service indication must be carried in the packet: Diff Serv Code Point (DSCP) in the IP header

Direction of data flow

DSCP marked

at edge

Service Level Agreement (SLA)

defines capacity at each

service level (DSCP)

?

Slide 60

+ Domains provide their customers with the service specified in Service Level Agreement

+ Individual domains are free to manage the internal resources,

to fulfill both internal and external obligations

Client

SLA

Domain

Client

SLA

SLA Domain

client

client SLA = Service Level Agreement

Domain = Region of shared trust,

administration, provisioning, etc.

SLA

SLA

Overall scenario for Diffserv QoS

Slide 61

Overall scenario for Diffserv QoS

Service

Level

Agreement

End-to-end congestion control

Traffic Conditioner meter, mark, shape, drop

Per-Hop Behavior active queue management, scheduler

SLA SLA SLA ISP ISP ISP

Slide 62

DiffServ approach

What problem are we solving ?

Give service to some traffic (at the expense of giving worse service to the rest)

What is the service ?

Better best effort

ISPs want finer control of relative bandwidth allocation, particularly under heavy load

Virtual leased line

Users want an end-to-end absolute bandwidth allocation, independent of other traffic

Slide 63

DiffServ approach

+ Standardizing or Packet Forwarding ?

If the answer is everyone has to agree on what constitutes a useful service and every router has to implement the machinery for it (i. e., to deploy a new service, you have to upgrade the world)

Since a router actually do that many different things to a packet, it makes more sense to standardize forwarding behavior (e. g., this packet or this packet

Behaviors + Rules = Services

Slide 64

Architectural Model

+ Diff-serv architecture implements scalable service differentiation in the Internet

+ A defines some significant characteristics of packet transmission across a set of one or more path within a network

+ Service differentiation is desired to accommodate heterogeneous application requirements and user expectations, and to permit differentiated pricing.

Slide 65

DiffServ Architecture Components

+ Functional elements in the network nodes

a small set of -hop forwarding

packet classification functions

traffic conditioning functions (metering, marking, shaping and policing)

+ To achieve scalability

complex classification and conditioning functions are implemented only at network boundary nodes

per-hop behavior are applied to aggregate of traffic marked using the DS in the IP header

Slide 66

DiffServ Field in the IP header

+ IP datagram header

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

|Version| IHL |Type of Service| Total Length |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Identification |Flags| Fragment Offset |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Time to Live | Protocol | Header Checksum |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Source Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Destination Address |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Options | Padding |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Slide 67


+ Historical

TOS field

Bits 0-2: Precedence.

Bit 3: 0 = Normal Delay, 1 = Low Delay.

Bits 4: 0 = Normal Throughput, 1 = High Throughput.

Bits 5: 0 = Normal Reliability,1 = High Reliability.

Bit 6-7: Reserved for Future Use.

0 1 2 3 4 5 6 7

+-----+-----+-----+-----+-----+-----+-----+-----+

| | | | | | |

| PRECEDENCE | D | T | R | 0 | 0 |

| | | | | | |

+-----+-----+-----+-----+-----+-----+-----+-----+

011 - Flash

010 - Immediate

001 - Priority

000 - Routine

Precedence

111 - Network Control

110 - Internetwork Control

101 - CRITIC/ECP

100 - Flash Override

Slide 68


+ The DS field replaces the IPv4 TOS octet (and the corresponding IPv6 Traffic Class octet)

0 1 2 3 4 5 6 7

+---+---+---+---+---+---+---+---+

| DSCP | CU |

+---+---+---+---+---+---+---+---+

DSCP: differentiated services codepoint

CU: currently unused

The DS code point MUST be used as an index to a table

The DS field structure is the following

Slide 69


+ Codepoint for the PHB (i.e. Best effort) is: 000000

+ IP Precedence/Class selector code points (for backward compatibility)

0 1 2 3 4 5 6 7

X X X 0 0 0 CU

+ NO backward compatibility for the DTR bits

Slide 70

Services vs. PHBs vs. DS code points

+ Services are the composition of PHBs

+ DS code points are mapped into PHBs available in a

given node

+ A PHB is realized by an implementation mechanism

internal to the node

Slide 71

Differentiated Service Domain

+ A DS domain is a contiguous set of DS nodes which operate with a common service provisioning policy and a set of PHB groups implemented in each node

DS interior

node

DS boundary

node

DS boundary

Slide 72

Service Level Agreements (SLAs)

+ A Service Level Agreement (SLA) is a service contract between a customer and a service provider that specifies the forwarding service a customer should receive

+ A customer may be a user organization (source domain) or another DS domain (upstream domain)

+ A SLA may include traffic conditioning rules which constitute a Traffic Conditioning Agreement (TCA)

+ The SLA typically specifies the TCA, plus:

availability/reliability

encryption services

routing constraint

authentication mechanisms

service monitoring mechanisms

pricing and billing

Slide 73

Traffic classification and conditioning

Classifier Marker Shaper/

Dropper

Meter

Slide 74


+ Classifiers can be

Behavior Aggregate (BA)

based on the DS codepoint only

Multi-Field (MF)

based on the combination of one or more header field such as source address, destination address, DS field, protocol IP, source and destination port number and on other information such as incoming interface

Slide 75

+ Traffic profiles specify the temporal properties of a traffic stream selected by a classifier

+ A Traffic Conditioner can be composed by the following elements

meter

marker

shaper and dropper

+ The meter measure the traffic pattern against the traffic profile and can interact with marker and shaper/dropper


Slide 76

Service taxonomy: quantitative vs. qualitative

+ Clearly qualitative (IntServ-controlled load , DiffServ EF)

Level A traffic will be delivered with low latency

Level B traffic will be delivered with low loss

+ Clearly quantitative (IntServ - guaranteed service)

90% of in profile traffic will experience no more than 50msec latency

95% of in profile traffic will be delivered

+ Not readily categorized (relative) (DiffServ - AF)

Traffic offered at service level E will be allotted twice the bandwidth of service level F traffic

Traffic with drop precedence AF12 has a lower probability of delivery than traffic with drop precedence AF13

Slide 77

Dynamic vs. Static SLAs

+ Static SLAs are considered at present time

+ They are agreed after negotiation between human agents

+ They can be periodically renegotiated (days weeks )

+ The SLA can specify a time varying services (times of day)

+ Dynamic SLAs may change frequently, as a result from variations in offered traffic load or from changes in pricing offered by the provider

+ Dynamic SLAs change without human intervention and require an automated agent and protocol

Bandwidth Broker

Slide 78

Bandwidth Broker (BB)

+ A BB is responsible within a DiffServ domain for the handling of the network resources

+ The BB guarantees the SLAs negotiated with users

Access

network

Access

network

BB

CR

CR

ER

ER

Access

network

ER

CR

ER

BB

Dominio

DiffServ

Dominio

DiffServ

Slide 79


+ The BB is a logical entity residing in each administrative domain

manages internal demands & resources according to the policy database

sets up & maintains bilateral agreement with neighbor domains

controls the traffic entering & going out on border routers

BB

BB

BB BB

BB

Diffserv

treatment + Three components:

Intra-domain protocols

Inter-domain protocols

End-to-End Services

Slide 80


+ Tasks of a BB

Interaction with ER e CR for QoS signalling handling

Interaction with other BBs for QoS signalling handling

Handling of the information database concerning

SLAs negotiated with users

congestion status of network resources

Flow admission control

Router configuration

Slide 81

Per-hop forwarding behaviors

+ Class selector compliant PHBs

+ Expedited Forwarding (EF) PHB

+ Assured Forwarding (AF) PHB group

Slide 82

Class selector compliant PHBs

+ 8 code points 000

+ At least two different PHBs

+ Any PHB selected by a higher code-point should give higher probability of timely forwarding than a PHB selected by a lower code-point

+ Code-points 11x000 must be mapped in a PHB than 000000

Slide 83

Expedited Forwarding PHB

+ The EF PHB can be used to build an end-to-end service through DS domains characterized by

low-loss

low-latency, low-jitter

assured bandwidth

Queuing must be avoided

aggregate maximum arrival rate is less than that aggregate minimum departure rate

Slide 84


+ Nodes must be configured so that the aggregate has a - (i.e. independent of other traffic on the

node) minimum departure rate (EF PHB)

+ The aggregate must be configured (via policing and shaping) so that its arrival at any node is always less than the configured minimum departure rate

+ To create the low-loss, low delay service

Slide 85


+ The departure rate of aggregate must equal or exceed a configurable rate

+ The EF traffic should receive this rate independent of other traffic

+ The rate should average at least the configured rate when measured over any time interval equal to or longer than a packet time at the configured rate

+ Description of the EF PHB

Slide 86


+ Mechanisms to implement EF PHB

Simple priority queue

A queue from a pool served by weighted round robin

Class Base Queuing (CBQ)

101110

+ Recommended code-point

Slide 87

Assured forwarding PHB group

+ The AF PHB group provides delivery of IP packets in four independently forwarded AF classes

AFxy x=1,2,3,4

+ Within each AF class, an IP packet can be assigned one of three different levels of drop precedence

AFxy y=1,2,3

+ A DS node does not reorder IP packets of the same microflow if they belong to the same AF class

+ Packets of AF class x do not have higher probability of timely forwarding than class y packets, if x < y

+ Within an AF class, a packet with drop precedence p must not be forwarded with smaller probability than a packet with drop precedence q, if p < q

Slide 88

Assured forwarding PHB group

AF1x

AF2x

AF3x

AF4x

Drop thresholds (Weighted RED)

AF11,12,13

better

service

Priority queueing

Slide 89

Multiple class over-provisioning 1/2

+ Different classes with different bandwidth and delay requirements

+ Link BW distributed through over-provisioned bandwidth constraint realised through advanced scheduling (e.g., WDRR, WFQ, etc.)

+ Lower delay, more over-provisioning

Class x

class y

Offered traffic

Maximum

reservabe

capacity

on output interface

Class x

Class y

Planned reservation

Delay class x < Delay class y

Free BW for best-effort

Slide 90

Multiple class over-provisioning 2/2

+ Ingress shaping and Link BW distributed through priority queing

Condition: Sum of shaped offered traffic enougth lower than output capacity

+ Russian Dolls Model

Priority queueing leads class x to see all capacity, class y to see the maximum capacity less the one takens by x class

+ Problem: limit ingress traffic (e.g., shaping) to avoid starvation

This may involve resource usage inefficiency, since a class can not exploits temporary remaining capacity due to the shaping

Class x

Class y

Offered traffic

Maximum

reservabe

bandwidth

Planned reservation

Class x

Class x

+

Class y

Slide 91

Multi Protocol Label Switching

Slide 92

MPLS: architettura

+ alla base di tale architettura è quella di associare a tutti i pacchetti un breve identificativo di lunghezza fissa, detto Label, con cui gli apparati di internetworking possono effettuare un instradamento veloce basato sulla commutazione di etichetta (label swapping)

+ MPLS è indipendente sia dalla sottorete di trasporto (Frame Relay, ATM, etc.) sia dai protocolli di rete adottati

20 bit

3 bit

8 bit

1 bit

Label

Exp

S

TTL

Label

Exp

S

TTL

Label

Exp

S

TTL

Pacchetto

IP

20 bit

3 bit

8 bit

1 bit

Label

Exp

S

TTL

Label

Exp

S

TTL

Label

Exp

S

TTL

Pacchetto

IP

Slide 93

Il nodo di

rete MPLS Forwarding component (L2 switch)

Control component (router + LDP)

Label Switch = +

Nodo MPLS

+ Control Component

Insieme di moduli demandati delle Label ed al binding delle Label tra nodi adiacenti

di livello 3 (IP addressing, IP routing)

+ Forwarding Component

Inoltro secondo il paradigma label swapping

+ Le due componenti devono essere indipendenti: posso sviluppare differenti protocolli su qualsiasi mezzo

+ La Control Component viene talvolta realizzata come parte integrata (SW o HW) del nodo di rete, talvolta come controllore esterno

Slide 94

Label encoding

Packet Over SONET/SDH

Header cella ATM

MPLS Header PPP Header Layer 3 Header

HEC

MPLS Header

DATA CLP PTI VCI GFC VPI

+ Se il livello data-link supporta nativamente un campo per la label (ATM con VPI/VCI, Frame Relay con DLCI) in questo campo viene inserita la label MPLS

+ Se i livello data-link non supporta un tale campo, la label MPLS viene incapsulata in un MPLS header che viene inserito tra header di livello 2 e quello di livello 3

Label CoS S TTL

20 bit 3 bit 8 bit 1 bit

Slide 95

Terminologia

+ Label Edge Router (LER): router di frontiera per una rete MPLS; svolgono

funzionalità di instradamento da e verso applicando e rimuovendo le

label ai pacchetti in ingresso ed uscita dalla rete

+ Label Switching Router (LSR): switch che operano la commutazione di etichetta

(label) della rete e prevedono il supporto di funzionalità di

instradamento

+ Label Distribution Protocol (LDP): in congiunzione con i protocolli di routing

tradizionali, LDP è utilizzato per distribuire le label tra i dispositivi della rete

+ Forwarding Equivalence Class (FEC): un insieme di pacchetti IP che vengono

instradati allo stesso modo (ad es., lungo lo stesso percorso, con lo stesso

trattamento)

+ Label Switched Path (LSP): Il percorso attraverso uno o più LSRs segutio da un

pacchetto appartenente ad un certa FEC

Slide 96

Funzionamento

+ Il LER di ingresso al backbone MPLS analizza IP del pacchetto, classifica il pacchetto,

aggiunge la label e lo trasmette al next hop LSR

+ Nella nuvola di LSRs il pacchetto viene instradato lungo il LSP in accordo alla label

+ Il LER di uscita rimuove la label ed il pacchetto viene instradato in base IP di destinazione

Slide 97

Label Switching Operation: Control

+ LDP è utilizzato per distribuire le associazioni <label, prefisso>

LDP stabilisce le associazioni

tra le route e le label, che

vengono memorizzate in una

tabella denominata LIB (Label

Information Base)

LER

LER

LER LER

LER

LSR

LSR

LSR

LSR

LSR LSR

Slide 98

LDP: Downstream on Demand

i/f 1

i/f 0

i/f 1

i/f 0

i/f 0

128.89.10.0

171.69.0.0

128.89.10.0 0

171.69.0.0 1

addr. prefix i/f remote

label

local

label

128.89.10.0 0


label

local

label

x

171.69.0.0 0


label

local

label

x

128.89.10.0 1

171.69.0.0 1


label

local

label

x

x

Data Flow

Label Request

<128.89.10.0>

<171.69.0.0>

LER

LER

LER

LSR

Slide 99

i/f 1

i/f 0

i/f 1

i/f 0

i/f 0

128.89.10.0

171.69.0.0

128.89.10.0 0

171.69.0.0 1

addr. prefix i/f

128.89.10.0 0

addr. prefix i/f

x

171.69.0.0 0

addr. prefix i/f

x

128.89.10.0 1

171.69.0.0 1

addr. prefix i/f

x

x

Data Flow

Label Mapping

<3,128.89.10.0>

<4,171.69.0.0>

4

3

4

3

remote

label

local

label

remote

label

local

label

remote

label

local

label

remote

label

local

label

LER

LER

LER

LSR


Slide 100

i/f 1

i/f 0

i/f 1

i/f 0

i/f 0

128.89.10.0

171.69.0.0

128.89.10.0 0

171.69.0.0 1

addr. prefix i/f

128.89.10.0 0

addr. prefix i/f

x

171.69.0.0 0

addr. prefix i/f

x

128.89.10.0 1

171.69.0.0 1

addr. prefix i/f

x

x

Data Flow

4

3

4

3

5

7

7

5

remote

label

local

label

remote

label

local

label

remote

label

local

label

remote

label

local

label

LER

LER

LER

LSR


Slide 101

Label Switching Operation: Forwarding

i/f 1 i/f 0

i/f 1

128.89.10.0 0

171.69.0.0 1

addr. prefix i/f

171.69.0.0 0

addr. prefix i/f

x

128.89.10.0 1

171.69.0.0 1

addr. prefix i/f

x

x 4

3

4

3

7

7

5

171.69.12.1 dati 171.69.12.1 dati 4

171.69.12.1 dati 7

171.69.12.1 dati Il primo LER

aggiunge la label

Il LSR instrada il pacchetto

in base alla label

rimuove la label

remote

label

local

label

remote

label

local

label

remote

label

local

label

LER

LER

LER

LSR

Slide 102

Label Stacking

+ Le label MPLS possono essere messe in stack per aggregare, su un tratto di rete, due o piu LSP in un unico LSP di ordine gerarchico superiore

+ di una label prende il nome di label push

+ La rimozione di una label prende il nome di label pop

+ è fatto sempre in base alla label di ordine superiore; se la label non si instrada a livello IP

IP L=x

IP L=y

LSR IP L=x

L=z

L=z

IP L=y PUSH label z

IP L=x

IP L=y

POP label

Slide 103

MPLS: realtà

+ Perchè un ISP dovrebbe impiegare MPLS?

Il vantaggio principale di MPLS è che consente ad un ISP di offrire nuovi servizi che non possono essere supportati semplicemente attraverso le tecniche di routing convenzionale

+ Attualmente possono essere individuate tre applicazioni di MPLS nel core degli ISP:

Traffic Engineering (MPLS-TE)

Traffic Engineering with QoS (MPLS DS-TE)

Virtual Private Networks (VPN)

Slide 104

MPLS-TE

+ Traffic Engineering consente ad un ISP di instradare un certo flusso di traffico lungo un percorso differente da quello calcolato dal protocollo di routing in modo da utilizzare (qualora sia necessario) un percorso fisico meno congestionato

+ Ciò consente agli ISP per bilanciare il carico sui vari link e nodi della rete in modo che nessuno di questi componenti sia sovrautilizzato o sottoutilizzato

+ MPLS-TE estende il funzionamento di base di MPLS introducendo:

dei meccanismi per il recupero delle informazioni di occupazione dei link

Dei meccanismi di segnalazione RSVP-TE, CR-LSP per il setup di LSP con un routing forzato

Slide 105

Traffic Engineering: come?

+ Normalmente un LSP viene instaurato in base al calcolo del percorso a costo minore effettuato dal protocollo di routing utilizzato sul backbone

+ Questa modalità non offre nessun valore aggiunto in termini di traffic engineering

+ Possono essere utilizzati diversi meccanismi per instaurare un LSP differente da quello determinato attraverso il protocollo di routing:

configurazione statica di tutti i LSR nel LSP (in modo analogo a come viene configurato un backbone IP/ATM tradizionale)

configurazione del LER con il percorso completo. Il LER poi utilizza una versione modificata del protocollo RSVP per installare le LIB in ciascuno dei LSR lungo il percorso (LSP)

Slide 106

Routing di un LSP

+ Il percorso che un LSP deve seguire affinché attraversi link con {opportuna capacità riservabile, scarichi} è solitamente pre-calcolato da un tool off-line

+ necessaria la conoscenza dello stato di occupazione delle varie interfacce di uscita dei LER

A) Soluzioni proprietarie che sfruttano query dello LSR MIB

B) Estensione dei protocolli di routing link-state (flooding delle informazioi delle interfacce), IGP di tipo OSPF o IS-IS, in modo che trasportino anche lo stato di occupazione delle risorse. Conseguentemente i LER (o una entità centralizzata di management) conoscono topologia e occupazione della rete

+ Calcolo del percorso attraverso constraint-based, shortest path first (CSPF)

Algoritmo shortest-path calcolato sulla topologia di rete con esclusione dei link che non possono supportare la banda B dello LSP di cui si sta facendo il setup

+ Setup manuale o attraverso RSVP-TE / CR-LDP

Slide 107

LSP: configurazione statica

R1 R2

LSR1

R3 R4

LSR2 LSR3

45 Mbps 1.5 Mbps

45 Mbps

Configurazione statica:

R2 R4 ha bisogno di 1 Mbps



Slide 108

LSP: configurazione con RSVP-TE

Setup: Path (R1->R2->R6->R7->R4->R9)

Reply: RESV (Comunica le label)

Pop

22

49

17

R8

R2

R6

R3

R4

R7

R1 R5

R9

32

Slide 109

RSVP-TE

Slide 110

LSP: configurazione con CR-LDP

Setup: Label Request (R1->R2->R6->R7->R4->R9)

Reply: Label mapping

22

49

17

R8

R2

R6

R3

R4

R7

R1 R5

R9

32

Slide 111

MPLS & QoS

+ del traffico implica una pianificazione delle risorse al fine di permettere un efficace trasferimento dei dati appartenenti agli LSP

+ Pertanto il traffic engineering tenta di rendere i link scarichi

+ Come ci si comporta in caso di classi di servizio diverse ?

+ Regola Empirica: Nel caso in cui la somma delle capacità richieste da tutti gli LSP su una interfaccia di uscita di un LSR sia inferiore o uguale alla metà della capacità della linea, tutti i LSP subiranno un ritardo molto basso e non necessità di impiego di meccanismi di scheduling (e.g., WDRR)

+ Quando però, post traffic engineering, le capacità delle interfacce in gioco cominciano a lavorare con carichi >>0.5, allora è necessario differenziare il trattamento del traffico

+ MPLS si integra con DiffServ

Slide 112

MPLS e DiffServ

+ Quale è il criterio di classificazione che un LSR adotta per determinare la coda dello scheduler (ovvero il forwarding-behaviour DiffServ) ?

+ Due soluzioni:

Exp inferred LSP (E-LSP)

La classificazione per lo scheduler avviene attraverso il campo Exp (3 bit) MPLS

Forwarding behaviour e drop precedence dedotto dalla codifica del campo Exp

Pachetti di LSP diversi con lo stesso campo Exp sono trattati ugualmente

Richiede al massimo 8 code dello scheduler, tante quanto le possibili combinazioni dl campo EXP

Label inferred LSP (L-LSP)

Forwarding behaviour dedotto dalla label, drop precedence dedotto dal campo Exp

Ogni LSP può essere gestito con un differente forwarding behaviour indipendentemente dal campo EXP

Richiede un numero variabile di code dello scheduler

Più complesso, ma più versatile

< Forwarding behaviour , label > deve essere segnalata esplicitamente durante la fase di setup dello LSP

MPLS & BGP

+ BGP è il protocollo di routing utilizzato tra AS

+ BGP è eseguito dai nodi di bordo di un AS

+ Le tabelle BGP contengono le rotte verso tutte le net

2011 circa 400k rotte (http://bgp.potaroo.net/)

Slide 113

http://bgp.potaroo.net/







MPLS & BGP

Slide 114

+ Problema: come fanno i router interni (e.s. R2) a instradare i pacchetti in transito, i.e. diretti ad una delle 400k reti esterne ?

Replico le tabelle BGP anche nei router interni (router interni costosi)

Faccio dei Label Switched Path MPLS tra router di bordo (full mesh) su cui instrado solo il traffico di transito

I router interni hanno solo tabelle di routing che riguardano gli instradamenti interni

R3

R2

R1

BGP (1) Net a.a.a.a

(400 k) Net z.z.z.z

Large BGP Table

(1) Net a.a.a.a

(400 k) Net z.z.z.z

Large BGP Table BGP

Autonomous system

IGP

(1) Net 1.1.1.1

Small IGP Table

MPLS LSP

Documents

What is the service