Internet QoS

RETI INTERNET MULTIMEDIALI
Internet Quality of Service
Il documento è adattato da materiale cortesemente messo a disposizione dai
Prof. Antonio Capone, Flaminio Borgonovo, Paolo Giacomazzi e Stefano Paris
IL PROBLEMA DELLA QoS
Cosa è la QoS
La QoS (Quality of Service) è un indice di qualità che misura la
rispondenza del livello di servizio rispetto alle attese dell’utente
La QoS è associata ai servizi della rete ed ai corrispondenti flussi
informativi ed è influenzata da






Banda disponibile (compressione, rate di trasmissione)
Ritardi
Jitter (varianza) dei ritardi
Packet dropping
Blocking probability
Set-up delay
La QoS può essere definita in modo assoluto o relativo:
 Assoluto: definizione dei valori che devono essere rispettati da un insieme di
parametri prestazionali (es. ritardo massimo, probabilità di perdita di
pacchetti, … )
 Relativo: definizione delle modalità di trattamento di una classe di traffico
rispetto ad altre (es. livello di priorità di servizio, livello di priorità di scarto, …)
La Banda
E’ la velocità di trasferimento (elaborazione)
dell’informazione
 E’ misurata in bit/s (byte/s, pacchetti/s,..)
 Può essere variabile nel tempo
I sistemi trasmissivi fisici hanno banda
costante nel tempo
SDH-fibra -..
TX
RX
La Commutazione di Circuito
Ritaglia un circuito a banda costante (64
kbit/s) end-to-end
Ogni bit è trasferito con la stessa velocità
(servizio sincrono)
(quasi) nessun jitter
La Commutazione di Pacchetto
Trasferisce pacchetti (trame, celle, ..) ossia unità di
più bit
Il trasferimento è asincrono
Le variazioni di traffico variano la banda disponibile
I conflitti introducono ritardi variabili (jitter)
Banda Variabile
pkt/sec
picco
media
t
Si definiscono
 Banda media
 Banda di picco
 etc.
Banda Variabile
banda di generazione
del flusso b
rete a banda B
La rete introduce variabilità
anche nei flussi costanti
B
banda media b
Modello di nodo di rete
QoS in Internet
Attualmente il funzionamento di Internet e di larga parte
delle reti IP è basato sulla modalità primitiva: best-effort
 Nessuna garanzia di consegna (ritardo, fedeltà, certezza, …)
La chiave del successo dell’IP best-effort è la semplicità e
finora ha prevalso la pratica di potenziare le risorse di rete
senza intervenire sulla modalità nativa per fronteggiare
l’esigenza di crescita di traffico e di integrazione di servizi
con requisiti di consegna
 Questa affermazione vale per Internet, mentre nelle reti IP per
le aziende si sono sviluppate le tecniche proposte per arricchire
le reti IP di garanzia di qualità (IP MPLS, IP diffserv, IP intserv, …)
La richiesta di qualità nelle reti IP cresce e si sono
sviluppate soluzioni, standard e prodotti
Requisiti di QoS e Servizi
Disponibilità
 Un requisito tipico delle reti di comunicazioni è la disponibilità:
• percentuale di tempo in cui il servizio di rete eroga la funzionalità
attesa in modo corretto
• Tipicamente espressa con livelli di disponibilità contrattualizzati in
Service Level Agreement (SLA) specificati in percentuale (es. 99,99%)
Per numerosi servizi di comunicazione sono richieste
prestazioni minime di qualità (requisiti) più specifici per
indici di qualità che riguardano:




Ritardo di consegna e varianza del ritardo di consegna (jitter)
Volume di dati consegnati nell’unità di tempo (throughput)
Tasso di perdita (Loss)
Rispetto della sequenza nella consegna dei dati
Servizi real-time ed elastici
I servizi real-time sono sensibili al ritardo (assoluto e
varianza), al throughput ed alla perdita di dati
 Per questi servizi, la consegna tardiva di un dato è
superflua e la ritrasmissione del dato non è praticabile
perché incompatibile con gli obiettivi di ritardo
 Es. VoIP
I servizi elastici sono più tolleranti e robusti rispetto al
ritardo di consegna, ma tipicamente meno tolleranti
rispetto alla perdita e si prestano al riscontro di
avvenuta corretta consegna (ACK) e alla eventuale
ritrasmissione
Servizi real-time playback
Una classe importante dei servizi real-time è definita come
playback (RFC 1633) e raggruppa i casi in cui la sorgente
pacchettizza flussi di dati continui che vengono consegnati con
ritardo variabile dalla rete
In ricezione viene introdotta una funzione di buffering che
consente di compensare la variabilità dei ritardi, svuotando il
buffer con un tasso costante
 Viene definito punto di playback il ritardo fisso che viene introdotto
tra il tempo di partenza del pacchetto alla sorgente e il tempo in cui il
pacchetto viene estratto dal buffer
 I dati che arrivano prima che scada il relativo punto di playback
possono essere usati per ricostruire il flusso, mentre i dati che arrivano
oltre il punto di playback sono inutilizzabili per la costruzione del
flusso
 Il valore dell’offset di ritardo usato per determinare il punto di
playback richiede una valutazione del tempo massimo di consegna dei
dati (upper delay bound)
Latenza e fedeltà
La prestazione di servizi real-time playback si caratterizza secondo
due indicatori:
 Latenza
 Fedeltà
I servizi intolleranti non ammettono violazioni dei requisiti di
playback in modo assoluto e stringente (es. emulazione di circuito)
 IETF ha proposto un trattamento del traffico IP in grado di garantire un
bound sul ritardo (Guaranteed Service Class) proprio per i servizi
intolleranti
I servizi tolleranti ammettono violazioni lievi dei requisiti di
playback (es. VoIP e video streaming)
 IETF ha proposto un trattamento del traffico IP in grado di garantire un
limite più lasco sul ritardo di consegna (Predictive Service Class)
L’imposizione di obiettivi prestazionali meno stringenti favorisce
maggiore efficienza nell’uso delle risorse di rete
Servizi elastici
I servizi elastici sono caratterizzati da non imporre
esigenze particolari in termini di ritardo di consegna
(valore assoluto e varianza)
In questo caso i dati consegnati possono essere
immediatamente utilizzati dall’applicazione ricevente
che attende la consegna dei dati e non necessita di
memorie tampone
La prestazione di questi servizi è legata al tempo
medio di consegna più che alla coda della statistica del
ritardo di consegna
Email, trasferimento file e navigazione Internet
richiedono un servizio elastico
ITU-T G.1010: End-user
multimedia QoS categories
La raccomandazione ITU-T G.1010 definisce una
mappa dei requisiti QoS con riferimento all’esigenza
d’utente
Packet Loss
5%
Conversational
voice and video
0%
Zero
loss
100 ms
Command
/control
(e.g. Telnet,
Interactive games)
Voice/video
messaging
1s
Transactions
(e.g. E-commerce,
Web-browsing,
E-mail access)
Streaming
audio/video
10 s
Messaging,
Downloads
Fax
Delay
100 s
Background
(e.g. Usenet)
(e.g. FTP, still image)
T1213050-02
ITU-T G.1010: End-user
multimedia QoS categories
La raccomandazione ITU-T G.1010 fornisce
anche un modello della QoS con riferimento
all’esigenza d’utente
Error
tolerant
Conversational
voice and video
Voice/video
messaging
Streaming audio
and video
Fax
Error
intolerant
Command/control
(e.g. Telnet,
interactive games)
Transactions
(e.g. E-commerce,
WWW browsing,
Email access)
Messaging,
Downloads
(e.g. FTP, still image)
Background
(e.g. Usenet)
Interactive
(delay <<1 s)
Responsive
(delay ~2 s)
Timely
(delay ~10 s)
Non-critical
(delay >>10 s)
T1213060-02
ITU-T G.1010: End-user
multimedia QoS categories
Table I.1/G.1010 – Performance targets for audio and video applications
Application
Medium
Audio
Audio
Conversationa
l voice
Voice
messaging
Degree of
symmetry
Two-way
Typical
data rates
4-64 kbit/s
Key performance parameters and target values
One-way
delay
Delay
variation
Information
loss (Note 2)
<150 ms
< 1 ms
< 3% packet
loss ratio
(PLR)
< 1 ms
< 3% PLR
<< 1 ms
< 1% PLR
preferred
(Note 1)
Primarily
one-way
4-32 kbit/s
<400 ms limit
(Note 1)
< 1 s for
playback
Other
< 2 s for
record
Audio
High quality
streaming
audio
Primarily
one-way
16-128
kbit/s
Video
Videophone
Two-way
16-384
kbit/s
Video
One-way
One-way
16-384
kbit/s
< 10 s
(Note 3)
< 150 ms
preferred
(Note 4)
<400 ms limit
< 10 s
< 1% PLR
Lipsynch:
< 80 ms
< 1% PLR
NOTE 1 – Assumes adequate echo control.
NOTE 2 – Exact values depend on specific codec, but assumes use of a packet loss concealment algorithm to minimise
effect of packet loss.
NOTE 3 – Quality is very dependent on codec type and bit-rate.
NOTE 4 – These values are to be considered as long-term target values which may not be met by current technology.
ITU-T G.1010: End-user
multimedia QoS categories
Table I.2/G.1010 – Performance targets for data applications
Medium
Application
Typical amount
of data
Key performance parameters and target values
One-way
delay (Note)
Delay
variation
Information loss
Preferred < 2 s /page
N.A.
Zero
~10 KB
– HTML
Primarily oneway
Data
Bulk data
transfer/retrieval
Primarily oneway
10 KB-10 MB
Preferred < 15 s
N.A.
Zero
Data
Transaction services – Two-way
high priority e.g.
e-commerce, ATM
< 10 KB
Acceptable < 60 s
Preferred < 2 s
N.A.
Zero
Data
Data
Command/control
Still image
Two-way
One-way
~ 1 KB
< 100 KB
< 250 ms
Preferred < 15 s
N.A.
N.A.
Zero
Zero
Data
Data
Interactive games
Telnet
Two-way
Two-way
(asymmetric)
Primarily oneway
< 1 KB
< 1 KB
Acceptable < 60 s
< 200 ms
< 200 ms
N.A.
N.A.
Zero
Zero
< 10 KB
Preferred < 2 s
N.A.
Zero
N.A.
Zero
N.A.
<10-6 BER
N.A.
<10-6 BER
N.A.
Zero
N.A.
Zero
Data
Web-browsing
Degree of
symmetry
E-mail (server access)
Data
Data
E-mail (server to
server transfer)
Fax ("real-time")
Acceptable < 4 s /page
Acceptable < 4 s
Acceptable < 4 s
Can be several
minutes
< 30 s/page
Primarily one< 10 KB
way
Primarily oneData
~ 10 KB
way
Can be several
Data
Fax (store & forward) Primarily one~ 10 KB
way
minutes
Low priority
Primarily oneData
< 10 KB
< 30 s
transactions
way
Primarily oneCan be 1 MB or
Can be several
Data
Usenet
way
more
minutes
NOTE – In some cases, it may be more appropriate to consider these values as response times.
RFC 4595
“Configuration Guidelines for DiffServ Service Classes”
http://tools.ietf.org/html/rfc4594
RFC 4595
“Configuration Guidelines for DiffServ Service Classes”
http://tools.ietf.org/html/rfc4594
RFC 4595
“Configuration Guidelines for DiffServ Service Classes”
http://tools.ietf.org/html/rfc4594
Prestazioni
Quale banda B assegnare al flusso b?
Se B < b
 si perdono pacchetti in rete
Se B > b
 si hanno ritardi tanto minori quanto più grande è B
B
banda media b
Prestazioni
Problema: quale banda B occorre assegnare
per garantire i ritardi?
 Non esiste una risposta univoca
 Dipende dal tipo di flusso
Modello di Arrivi di Poisson
Il modello degli arrivi di Poisson consente di calcolare i ritardi medi e i
percentili
In particolare, dalla Pollaczek-Khinchin (P-K) Formula per code M/G/1), il
ritardo medio è dato da:
T = tempo di trasmissione dei pacchetti
b = banda media del flusso
B = banda costante del canale
 2 = varianza del tempo di servizio
  T  T2 
 
  T
Wm 
1    2 2T 
T
Ritardo
medio Wm
b

B
T
1
r
il ritardo massimo non
è garantito
Burstiness
I flussi reali si scostano dal modello di Poisson
Traffico “bursty”
Traffico Poisson
Per indagare i ritardi occorre definire la “variabilità”
(burstiness) (si può fare solo in modo approssimato)
Traffic Conditioning Agreement e
Service level Agreement
Un provider di servizi IP a qualità garantita deve preliminarmente
stabilire con il cliente due “contratti”:
 il Traffic Conditioning Agreement (TCA)
 e il Service Level Agreement (SLA)
Lo SLA specifica la QoS che il provider si impegna a garantire al cliente
per uno specifico insieme di flussi di traffico
Non è possibile, né sensato ipotizzare che l’impegno del provider sulla
garanzia dello SLA possa prescindere dalla quantità di traffico generata
dal cliente
Il TCA specifica il profilo di traffico, inteso come il limite superiore del
traffico offerto dal cliente per cui il provider assicura l’impegno ad
onorare lo SLA
Dato un flusso, la parte del traffico conforme al TCA si chiama traffico IN
o traffico conforme
La parte di traffico che eccede il TCA viene chiamata traffico OUT o nonconforme
Policing, shaping e marking
Il provider deve garantire lo SLA solo per il traffico conforme, mentre
possono essere effettuate diverse strategie di trattamento per il traffico
non conforme
Infatti, il provider deve proteggere gli SLA dei flussi conformi in rete dagli
eccessi di traffico che possono essere immessi da un cliente in violazione
del proprio TCA
Se non si intervenisse sui traffici eccedenti il TCA si potrebbero generare
condizioni di sovraccarico delle risorse di rete che comprometterebbero
gli SLA del traffico conforme
Esempi di trattamento del traffico OUT:
 Policing: il traffico OUT viene scartato
 Shaping: il traffico OUT viene ritardato in modo da attribuire un
comportamento conforme al TCA
 Marking:il traffico OUT viene offerto alla rete con un contrassegno che in caso
di congestione viene eliminato con priorità rispetto al traffico non
contrassegnato
Allocazione delle risorse
La capacità del provider di garantire gli SLA per flussi o aggregati di
flussi si fonda sulla riservazione di un adeguato ammontare di
risorse di rete
La quantità adeguata di risorse dipende sia dai TCA e dagli SLA dei
flussi che condividono ogni risorsa di rete (in particolare ogni linea)
Le risorse riservate sono allocate per il traffico conforme
L’accettazione in rete di traffico non conforme, ad allocazione di
risorse avvenuta sulla base dell’insieme di TCA e SLA, è rischiosa
perché il traffico non conforme potrebbe consumare risorse in
misura tale da compromettere la capacità di garantire gli SLA
L’accettazione in rete di traffico non conforme è operazione
delicata; può essere fatta marcando il traffico in violazione della
conformità per renderlo predisposto allo scarto in caso di
sovraccarico delle risorse (priorità nello scarto) o attribuire priorità
inferiore rispetto al servizio (il traffico non conforme vene servito
solo dopo il traffico conforme)
Traffic Conditioning Agreement
Il TCA può includere una varietà di parametri che
caratterizzano il traffico conforme e non conforme
Tali parametri includono usualmente:
 Velocità o Tasso di picco (Peak rate)
 Velocità o Tasso medio (Average rate)
 Massima lunghezza del burst: massimo numero di
pacchetti consecutivi trasmessi alla velocità di picco del
flusso
 Lunghezza massima dei pacchetti
 Lunghezza minima dei pacchetti
IL TCA specifica il profilo statistico del traffico
conforme
Regolatore del traffico all’ingresso
Stabilito per un flusso il TCA e lo SLA, il traffico offerto alla
rete viene esaminato da un Regolatore che distingue il
traffico in almeno due flussi (traffico conforme e traffico
non conforme al TCA)
Il trattamento del traffico non conforme distingue i diversi
tipi di regolatore
Regolatore
Utente
Rete
Traffico Conforme
Traffico NON Conforme
Regolatore del traffico all’ingresso
POLICER
Regolatore
Utente
Rete
Traffico Conforme
Traffico NON Conforme
SCARTO
SHAPER
MARKER
Regolatore
Utente
Rete
Traffico Conforme
Regolatore
Utente
Rete
Traffico Conforme
Traffico NON Conforme
Traffic conditioner
Un traffic conditioner può
comprendere i seguenti elementi:
meter, marker, shaper e dropper
Un flusso di traffico viene trattato
da un classifier che veicola i
pacchetti a un traffic conditioner,
dopo aver individuato il flusso a
cui appartiene ogni pacchetto
entrante, determinando la classe
di servizio con cui verrà trattato
Un meter misura il traffico con
riferimento ad un profilo di
traffico specificato dal TCA e in
base all’andamento nel tempo del
traffico può determinare il
marking dei pacchetti, lo scarto o
lo shaping
Traffic Conditioner
Meter
Shaper
Classifier
Dropper
Marker
Policing
Il token bucket policing regulator ha un
serbatoio di crediti (token) con dimensione
massima k [unità di traffico]:

token bucket size
L’unità di misura di k può essere bit, byte o
pacchetti
Il serbatoio dei crediti viene incrementato
ogni 1/r s, dove r è il token rate (tasso di
generazione dei token)
Il dispositivo ammette il passaggio di una
unità di traffico offerta (bit, byte o pacchetto)
se il serbatoio dei crediti contiene dei token (il
contatore viene decrementato in ragione
delle unità di credito corrispondenti alle unità
di traffico ammesse)
Se al contrario il serbatoio non dispone di
crediti, le unità di traffico trattate dal
regolatore vengono scartate
r
k
X(t)
Shaping
Il serbatoio dei crediti di uno shaping regulator
opera come nel caso del policer
Un unità di traffico passa direttamente attraverso
il regolatore se al suo arrivo il serbatoio ha
capienza idonea e il buffer di ingresso è vuoto
Altrimenti se il buffer non è vuoto e/o il serbatoio
di token non ha capienza idonea, l’unità di traffico
viene trattenuta nel buffer di ingresso
Quando il buffer di ingresso non è vuoto, una
unità di traffico viene prelevata e inoltrata non
appena viene generata capienza idonea nel token
X(t)
bucket
I parametri r e k di policer e shaper hanno
significato fisico intuitivo:


Il parametro r controlla il tasso medio del traffico che
passa in regolatore, poiché l’uscita non può ammettere
più di r unità di traffico al secondo in media
Il parametro k controlla la lunghezza dei burst
r
k
∞
I regolatori policer e shaper
implementano una funzione
vincolo
La funzione vincolo è la retta k+rt
e rappresenta il numero massimo
di unità di traffico corrispondenti
al traffico conforme che il
regolatore lascia passare in rete
In un periodo di tempo di durata
t, il massimo traffico conforme
che il regolatore lascia passare è
uguale a k+rt
Il traffico in eccesso è non
conforme ed è trattato in modo
diverso da policer e shaper
Traffico cumulativo
Funzione vincolo
Traffico non conforme
(OUT o rosso)
k
t
Traffico conforme (IN o verde)
Un policer scarta il traffico non
conforme
In questo modo, solo il traffico
conforme entra in rete
La curva cumulativa in grassetto
indica il risultato dell’operazione
di policing, ossia il profilo del
traffico conforme cumulato che
entra in rete
Il pattern di traffico è un Linearly
Bounded Arrival Process (LBAP)
Traffico cumulativo
Comportamento del policer
Traffico non conforme
(OUT o rosso)
k
t
Traffico conforme (IN o verde)
Traffico conforme inoltrato dal policer
Uno shaper trattiene il
traffico non conforme nel
buffer e lo serve appena sono
disponibili token in
conformità con il vincolo
upper boound LBAP per il
traffico cumulato
Lo shaper elimina la perdita
di pacchetti all’ingresso ma
aggiunge ritardo
Il policer praticamente non
introduce ritardo ma causa
perdita di pacchetti
Traffico cumulativo
Comportamento dello shaper
k
t
Traffico conforme (IN o verde)
Un token bucket marker
lavora come un policer ma
non scarta il traffico non
conforme
Il traffico non conforme
viene marcato e inoltrato in
rete
In caso di congestione i
pacchetti marcati possono
essere scartati prima del
traffico conforme
Traffico cumulativo
Marker
Traffico non conforme
(OUT o rosso)
k
t
Traffico conforme (IN o verde)
Banda media e di picco
Il tasso di arrivo dei crediti
(token) definisce il tasso medio
del traffico offerto alla rete
r
 Se consideriamo un tasso di r
unità di traffico
(bit/byte/pacchetti al secondo) al
secondo ammesse in rete, il
traffico medio offerto usualmente
si indica come la «banda media» e
viene indicato con b (misurato in
bit/s)
k
X(t)
p
r
La «banda di picco», indicata con
p (misurata in bit/s) indica il tasso
massimo di traffico offerto alla
rete
 Corrisponde alla velocità della
linea (velocità del servente)
 Ovviamente b<p
b
b
k
X(t)
∞
p
Traffico «bursty»
La presenza del serbatoio di crediti
consente al traffico che viene
generato dalla sorgente di essere
ammesso in rete ad una velocità
maggiore della banda media
Il traffico offerto alla rete assume
pertanto un profilo tipicamente
discontinuo che si presenta con
«raffiche» (o «burst» di traffico)
alternate a periodi di inattività
I regolatori controllano la banda
media b=r, la banda di picco p>b e la
durata massima del burst L
Sussiste la relazione seguente:
pL  k  bL


r
b
k
X(t)
p
r
b
k
X(t)
∞
k
L
p b
p
Modello token-bucket completo
Si introducono alcuni parametri addizionali:
 Minimum Policed Unit (m): il policer deve rimuovere almeno m token per ogni
pacchetto conforme (riduce l’overhead di processing per pacchetto e limita
l’overhead dell’header costringendo i pacchetti ad essere almeno di lunghezza
m (byte))
 Maximum Policed Unit (M): il pacchetto di dimensione massima + lungo M
byte
 La quantità di dati offerta alla rete nel tempo T:
• 𝑫 𝑻 ≤ 𝒎𝒊𝒏 (𝒑𝑻 + 𝑴, 𝒓𝑻 + 𝒌)
p
r
Token presenti
quando arriva
il pacchetto = x1
x1
Arriva pacchetto X <x ?
1
lungo X
k
Si: x1 = x1 - X
No: pacchetto
non conforme
Token presenti
quando arriva
il pacchetto = x2
x2
X <x2 ?
M
Si: x2 = x2 - X
No: pacchetto
non conforme
Modello token-bucket completo
 La quantità di dati offerta alla rete nel tempo rappresenta la «curva
degli arrivi»:
• 𝜶 𝒕 ≤ 𝒎𝒊𝒏 (𝒑𝒕 + 𝑴, 𝒓𝒕 + 𝒌)
 Se consideriamo il «fixed delay server» come il modello di servizio che
introduce un ritardo Td (pacchettizzazione ed altre elaborazioni nel
router) e ha un tasso di servizio a velocità B (bit/s) sulla linea si ottiene
la «curva di servizio»:
• 𝜷𝑩, 𝑻𝒅 𝒕 = 𝑩 𝒕 − 𝑻𝒅
+
=
𝑩 𝒕 − 𝑻𝒅 𝒔𝒆 𝒕 > 𝑻𝒅
𝟎 𝒂𝒍𝒕𝒓𝒊𝒎𝒆𝒏𝒕𝒊
slope r
arrival curve 
bits
service curve b
k
dmax
Bmax
M
slope p
slope B
t
Td
Modello token-bucket completo
 Il valore massimo del backlog Bmax è dato da:
• 𝑩𝒎𝒂𝒙 = 𝒌 + 𝒓 ∗ 𝒎𝒂𝒙
( 𝒌 − 𝑴)/(𝒑 − 𝒓)
𝑻𝒅
 Il valore massimo del ritardo dmax è:
𝒌−𝑴
• 𝒅𝒎𝒂𝒙 =
𝑴+ 𝒑−𝒓 𝒑−𝑩
+
𝑩
+ 𝑻𝒅
slope r
arrival curve 
bits
service curve b
k
dmax
Bmax
M
slope p
slope B
t
Td
Risultati per modello Token Bucket
Il traffico è caratterizzato da k, p, b, e da M
(maximum policed unit) e m (minimum policed unit)
Si riesce a controllare il ritardo massimo WM
usando banda B
k M pB M C
WM 

 D
B
p b B B
se B  p
M C

 D
B B
se B  p
tiene conto del burst
http://www.ietf.org/rfc/rfc2212.txt
WM
C e D costanti
Risultati per modello Token Bucket
Bound
WM
ritardo
b
Bm
p
B
Fissato il massimo ritardo ammissibile si può
ricavare il minimo B (Bm) che lo garantisce
Problema: Bm è molto spesso molto più grande di b
Single-rate three-color marker
(srTCM)
Il Single Rate Three Color Marker (srTCM) può essere usato come
regolatore del traffico nel modello Diffserv proposto da IETF
Il regolatore srTCM misura un flusso di traffico e marca i pacchetti
secondo tre parametri del profilo di traffico
 Committed Information Rate (CIR) (green)
 Committed Burst Size (CBS) (yellow)
 Excess Burst Size (EBS) (red)
Un pacchetto viene marcato come green se non eccede il CBS,
yellow se eccede il CBS ma non l’EBS, red altrimenti
Il regolatore può operare sia in condizioni in cui è consapevole di
marcature precedenti o meno, operando in ogni caso la rimarcatura in base alla propria misura
La marcatura viene inserita nel campo DS dell’intestazione del
pacchetto IP, conformemente al Per-Hop-Behaviour del flusso
Impiego del srTCM
Il CIR si misura in bit/s (byte/s) e include l’intestazione IP, ma non l’intestazione del
livello data-link
CBS e EBS sono misurati in bit (byte) e vanno configurati in modo che almeno uno
dei due sia >0 e >= la dimensione del pacchetto di dimensione massima generato
dal flusso IP
I contatori dei token dei due serbatoi CBS e EBS Tc e Te sono aggiornati con una
cadenza di CIR volte al secondo:



Se Tc<= CBS, Tc si incrementa di 1 altrimenti
se Te <EBS, Te si incrementa di 1, altrimenti
Tc e Te non vengono incrementati
Token
CBS
Flusso non
colorato
srTCM operante
in blind-mode
EBS
Flussi colorati
Token
CBS
Flussi colorati
srTCM operante
in color-aware
mode
EBS
Flussi colorati
srTCM blind-mode
Quando un pacchetto di dimensione X byte arriva al tempo
t, se il regolatore srTCM è configurato in blind-mode:
 Se Tc(t)-X >= 0, il pacchetto è green e Tc si decrementa di X fino al
valore minimo pari a 0, altrimenti
 se Te(t)-X >= 0, il pacchetto è yellow e Te si decrementa di X fino
al valore minimo 0, altrimenti
 Il pacchetto è red e Tc e Te non vengono decrementati
Token
CBS
Flusso non
colorato
srTCM operante
in blind-mode
EBS
Flussi colorati
srTCM color-aware-mode
Quando un pacchetto di dimensione X byte arriva al tempo
t, se il regolatore srTCM è configurato in color-aware-mode:
 Se il pacchetto è precolorato green e Tc(t)-X >= 0, il pacchetto è
green e Tc si decrementa di X fino al valore minimo 0, altrimenti
 se il pacchetto è precolorato green o yellow e se Te(t)-X >= 0, il
pacchetto è yellow e Te si decrementa di X fino al valore minimo
0, altrimenti
 il pacchetto è red e Tc eTe non vengono decrementati
Token
CBS
Flussi colorati
srTCM operante
in color-aware
mode
EBS
Flussi colorati
Two-rate three-color marker
(trTCM)
Il Two-Rate Three Color Marker (trTCM) può essere usato come
regolatore del traffico nel modello Diffserv proposto da IETF
Il regolatore srTCM misura un flusso di traffico IP e marca i
pacchetti sulla base di due data rate:
 Peak Information Rate (PIR)
 Committed Information Rate (CIR)
I burst di traffico associati possono essere contrassegnati come:
 Green
 Yellow
 Red
Un pacchetto è marcato Red se eccede il PIR
Altrimenti viene marcato come green o yellow se rispetta o eccede
il CIR rispettivamente
Two-rate three-color marker
(trTCM)
Il trTCM viene configurato rispetto all’operatività su flussi in
ingresso indistinti o colorati (color-blind o color-aware) e
assegnando valori a quattro parametri:
Peak Information Rate (PIR) e l’associato Peak Burst Size (PBS)
Committed Information Rate (CIR) e l’associato Committed Burst
Size (CBS)
PIR e CIR sono misurati in byte al secondo, comprendendo
l’header IP ma non le intestazioni del livello di linea
PIR deve essere maggiore o uguale a CIR
PBS e CBS sono misurati in byte e devono essere maggiori di 0
Si raccomanda che siano maggiori o uguali al pacchetto IP di
dimensione massima
trTCM
Il comportamento del Meter è specificato con il funzionamento dei due token
bucket con i rate CIR e PIR
La massima dimensione del token bucket a rate PIR è PBS e la massima dimensione
del token bucket a rate CIR è CBS
Inizialmente i due token bucket sono pieni, Tp(0) = PBS e Tc(0) = CBS
Successivamente il contatore Tp è incrementato di uno PIR volte al secondo fino a
PBS
Il contatore Tc è incrementato di 1 CIR volte al secondo fino a CBS
Il trTCM opera in blind-mode quando considera il flusso in ingresso non colorato
Token
a rate CIR
CBS
Flusso non
colorato
Token
a rate PIR
PBS
Flussi colorati
trTCM operante
in blind-mode
trTCM blind-mode
Quando un pacchetto di dimensione X byte arriva al tempo
t, il trTCM configurato in blind-mode opera come segue:
 Se Tp(t)-X < 0, il pacchetto è marcato red, altrimenti
 se Tc(t)-X < 0, il pacchetto è marcato yellow e Tp viene
decrementato di X, altrimenti
 Il pacchetto viene marcato come green e sia Tp che Tc sono
decrementati di X
Token
a rate CIR
CBS
Flusso non
colorato
Token
a rate PIR
PBS
Flussi colorati
trTCM operante
in blind-mode
trTCM color-aware-mode
Quando un pacchetto di dimensione X byte arriva al tempo
t, se il regolatore trTCM è configurato in color-aware-mode:
 Se il pacchetto è precolorato red o se Tp(t)-X < 0, il pacchetto è
marcato come red, altrimenti
 se il pacchetto è precolorato yellow o se Tc(t)-X < 0, il pacchetto è
marcato yellow e Tp viene decrementato di X, altrimenti
 il pacchetto è marcato green e Tp e Tc vengono decrementati di X
Token
a rate CIR
CBS
Flussi colorati
Token
a rate PIR trTCM operante
in color-aware
mode
PBS
Flussi colorati
trTCM operante
in blind-mode
Token
a rate CIR
CBS
Flusso non
colorato
Token
a rate PIR
Traffico cumulativo
trTCM blind-mode
PBS
Flussi colorati
PBS/PIR
t
STRUMENTI PER GARANTIRE LA
QoS
Strumenti per garantire la QoS
Per garantire la QoS servono strumenti di
identificazione dei flussi (label, virtual circuit,
etc.) …
flusso 1
Label 1 informazione
Label 1 informazione
flusso 2
Label 2 informazione
Label 2 informazione
Strumenti per garantire la QoS
… e servono strumenti per suddividere la
banda nei router (tecniche di scheduling)
Scheduler
Strumenti per garantire la Banda
Per garantire la banda occorrono strumenti
per fissare i cammini in rete
Garantire la Banda in modo dinamico
Occorrono meccanismi di controllo delle
risorse (CAC: Call Admission Control)
 che possano rifiutare la richiesta se la banda non è
disponibile …
STOP
Garantire la Banda in modo dinamico
... e meccanismi di segnalazione delle risorse
di rete (banda disponibile sui vari cammini)
Controllo del traffico immesso
Il traffico immesso non è vincolato dal mezzo fisico
 è spesso variabile, con banda media b minore di quella di
linea p (picco)
 i contratti tengono conto della media e del picco
(lunghezza del burst)
Strumenti di Policing
Per evitare che la banda venga sottratta occorrono
strumenti di policing
 che controllino il traffico immesso
 verifichino la conformità alle risorse
 prendano provvedimenti in caso di violazione
Viola il
contratto
Packet
discarding
Over-provisioning
Se la banda fosse infinita…
… la QoS non sarebbe un problema
La banda non è infinita (ha un costo)
Le richieste fluttuano nel tempo (si
dimensiona sul picco?)
Le richieste crescono col tempo (previsioni?)
Le richieste prima o poi generano conflitti che
causano perdita di QoS e trattamento iniquo
dei flussi (unfairness)
Traffic Engineering
Con il CAC la QoS può essere garantita su
qualunque rete
Basta limitare il traffico ammesso a un livello
sufficientemente basso
Ma il traffico troppo basso scontenta i gestori
Per questo in aggiunta si usano strumenti di
traffic engineering che consentono di sfruttare
meglio le risorse
e quindi di spostare il livello di traffico a cui far
intervenire il CAC a valori più elevati
SUDDIVISIONE DELLA BANDA
Scheduling
Strumenti per suddividere la banda nei router
(tecniche di scheduling)
Scheduler
Time Division Multiplexing
Code a ogni “giro” (3 slot)
Corrispondenza rigida
fra time-slot e code
3
2
1
3
2
1
2
3
2
1
3
2
1112
2 32 3
t
Non consente il riutilizzo di risorse non usate da un flusso
Round Robin (Fair Queuing)
Suddivisione dinamica ed uguale della banda
ottenuta trasmettendo un pacchetto per ogni flusso
ciclicamente
Code a ogni “giro”
Non vengono sprecati slots
3
2
1
3
2
1
2
3
2
1
3
2
1112 2 32 3
t
Weighted Fair Queuing
Suddivisione dinamica e proporzionale della
banda ottenuta trasmettendo Ki pacchetti per
ogni flusso “i” in modo pseudo ciclico.
Code ogni 4 slot : proporzione 2-1-1
5
3
1
4
2
1
2
3
2
1
3
2
1211 3 42 523
t
Risultati per modello Token Bucket
Il traffico è caratterizzato da k, p, b, e da M (maximum policed unit) e m
(minimum policed unit)
Si riesce a controllare il ritardo massimo W usando Weighted Fair
Queueing che assegna banda B
k M pB
M C
W 


D
B
p b
B
B
se
B p
M
C

D
B
B
se
B  p
W 
http://www.ietf.org/rfc/rfc2212.txt
C e D costanti che dipendono dal tipo di algoritmo usato
C e D sono termini di errore che tengono conto della massima deviazione rispetto al modello teorico fluidico
- C tiene conto della trasmissione a pacchetto nello scheduler WFQ e dell’overhead degli strati inferiori
- D tiene conto del tempo di attesa massimo per la trasmissione di un pacchetto (es. canale slotted)
Suddivisione della Banda
I pacchetti sono unità intere di lunghezza
variabile
La suddivisione è quantizzata
 a pacchetti
 di lunghezza variabile
E’ complicato suddividere esattamente
Si introducono ritardi e jitter
Priorità di Servizio
Suddivisione dinamica preferenziale della banda.
Non garantisce le priorità inferiori
Servizio esaustivo ogni slot:
priorità alta media bassa
3
2
3
3
2
1
1
2
2
1
2
2
1
1
1
1
1
2
2
2
2
2
1122 1 2 33
t
Priorità nelle LAN
Lo standard IEEE 802.1Q (VLAN) introduce
campi di priorità anche per 802.3 e 802.11
(che non servono per l’accesso multiplo)
byte 7
Sync
1
6
SD Destinaz.
6
2
Sorgente
2
0-1500
Length
Type
payload
2
Tag type(0x8100) Tag Control Inf.
4
802.3
FCS
2
2-30
Length/type
RIF (facolt.)
byte
Routing Information Field (RIF)
3
PCP
1
DE
Priority Code Point (PCP) –IEEE 802.1p
Drop Eligible (DE)
VLAN Identifier (VID)
12
VID
bit
Priorità nelle LAN
Fino a 8 priorità di servizio sono state standardizzate in 802.1Q
 Mappano le priorità della trama MAC
Queste sono impostate al momento dell’incapsulamento dei
livelli superiori
 in base alle priorità di questi
 o alla VLAN di appartenenza
 o al tipo di traffico trasportato (livelli 4)
Priorità e Scheduling
Priorità e scheduling vengono effettuate sulla
base di pacchetti interi
 non si possono interrompere le trasmissioni
Se i pacchetti in trasmissione sono lunghi gli
altri ne subiscono il ritardo
Priorità di Servizio
Esempio:
 Rosso alta priorità
 Effetto di un pacchetto verde lungo e di due verdi di
lunghezza metà
trasmissione
LP
HP
attesa
trasmissione
LP
HP
attesa
LP
Trasmissione delle Trame
64 kbit/s
1500 Byte (max Ethernet)
40 Byte (voce)
187.5 ms
5 ms
128 kbit/s
93.75 ms
2.5 ms
512 kbit/s
23.4 ms
0.625 ms
2 Mbit/s
6 ms
0.16 ms
10 Mbit/s
1.2 ms
0.033 ms
Necessità di frammentare su link poco veloci
Modalità di Frammentazione
Ridurre la lunghezza di tutte le trame IP porta ad enormi
inefficienze
Si possono frammentare trame a livello IP solo su
connessioni lente.
 Ma poi IP le ricostruisce solo al destinatario
Occorre un meccanismo a livello 2 sulle connessioni lente
che possa frammentare le trame lunghe in trasmissione e
che le ricomponga in ricezione
IP
IP
Frammentazione
Frammentazione
Linea (HDLC)
Linea (HDLC)
Il protocollo Multilink PPP
http://tools.ietf.org/html/rfc1990
Layer 3
NCP-2
NCP-1
+ 2 byte
Frammentazione e
Layer 2 inverse
multiplexing
LCP-1
MLCP
+ 6 byte
LCP-2
LCP-3
+ 6 byte
Layer 1
Il protocollo Multilink PPP
Gli strati LCP e MLCP incapsulano nella loro trama il
SAP del sottostrato superiore, cosicché in ricezione
la catena viene ripercorsa a rovescio
fragment
fragment
fragment
2
PROTOCOL
2
PROTOCOL
= 003d
Information
1
B E
1
Address
1
Control
Information
3
N
SN
Information
Information
http://tools.ietf.org/html/rfc1990
0-1500
2
Information
FCS
Utilizzo proprietario del protocollo PPP
VOCE
(alta priorità)
Layer 3
Dati
(bassa priorità)
NCP
NCP
Frammentazione
Layer 2
LCP
Alta
priorità
Layer 1
MLCP
LCP
Scheduler
Bassa
priorità
IL CONTROLLO D’ACCESSO
Call Admission Control
Definizione ITU-T Raccomandazione I.371 («Traffic control
and congestion control in B ISDN»)
 Insieme delle azioni intraprese da una rete durante la fase di
instaurazione (set-up) di una connessione (flusso, canale virtuale, …),
o in fase di ri-negoziazione di una connessione, allo scopo di stabilire
se la richiesta possa essere accettata
Lo scopo della procedura di CAC è quello di assicurare che sul
cammino (path) tra sorgente/i e destinazione/i seguito dal
flusso attraverso la rete siano assegnati al flusso su ogni link
del path:
 una porzione della capacità del link (Bandwidth Assignment) e
 una porzione di buffer (Buffer Assignment)
La quantità di banda e di buffer allocata ad un flusso dipende
dai requisiti di QoS
Call Admission Control
La procedura di CAC deve conoscere
 la quantità di risorse richiesta
 la quantità di risorse usata su ogni link
calcolare se esiste un cammino con tale disponibilità
prenotare le risorse in caso di accettazione
STOP
Modalità di calcolo e prenotazione
Le modalità di calcolo e prenotazione
possono essere suddivise in tre gruppi:
 Centralizzata: il CAC viene effettuato da un server
centrale
 Distribuita: Ogni nodo concorre al CAC
 Mista: tecnica che consente il CAC solo ai nodi
d’ingresso della rete
Modalità Centralizzata
Il CAC viene effettuato da un server centrale
 Il server riceve tutte le richieste e conosce tutto
 La segnalazione verso i nodi è semplificata (non
sempre è necessaria)
 Può essere determinato il cammino ottimale
Svantaggi
 Problemi di complessità, scalabilità, affidabilità e
velocità
 Non consona ad IP (se non per sistemi semplici)
 Per il cammino ottimale occorre poter dominare e
segnalare l’instradamento
Modalità Centralizzata
Adatta a piccoli sistemi con server ridondati
in reti di tipo Hub and Spoke
Modalità Distribuita
Ogni nodo conosce le risorse occupate e
concorre al CAC
Caratteristiche
 E’ un sistema robusto
 Occorre un sistema di segnalazione per raccogliere
la disponibilità dei nodi e prenotare (SS7, RSVP)
 E’ molto complesso determinare il cammino
ottimale
Modalità all’ingresso
Il CAC è effettuato dai router all’ingresso
 E’ un sistema misto
 Si può determinare il cammino ottimale (QoS
Routing)
Caratteristiche
 Occorre un sistema di segnalazione per raccogliere
lo stato di occupazione (estensioni di IGP, BGP)
 Occorre un sistema di segnalazione per prenotare
(RSVP)
IL CONTROLLO DELLE RISORSE
IntServ, DiffServ
Meccanismi di controllo delle risorse
Il controllo delle risorse deve utilizzare
meccanismi scalabili e distribuiti
Ci sono due approcci in IETF che si
differenziano per le garanzie che offrono e la
complessità che presentano
 Integrated Services (IntServ)
 Differentiated Services (DiffServ)
INTEGRATED SERVICES
IntServ
Integrated Services
Introducono in IP una modalità di controllo dinamica e
assoluta (RFC 2215) di ciascun flusso d’utente
Offrono due classi di servizio oltre alla classe Best-Effort
 Controlled Load (RFC 2211)
• Emula il “best effort” in una rete non congestionata
 Guaranteed Service (RFC 2212)
• Emula il servizio a circuito con ritardi garantiti
Si basano su modifiche sostanziali all’architettura dei
router
Utilizzano RSVP per prenotare le risorse (RFC 2210)
Modalità assoluta di controllo e
assegnazione delle risorse
E’ il paradigma da sempre utilizzato in
telefonia:




Sistema di prenotazione flusso per flusso a blocco
Le risorse vengono richieste dall’utente
Se esistono vengono prenotate
Se non esistono la richiesta è rifiutata
Miglioramenti introdotti con IP
 Diverse classi di servizio (risorse)
 Utilizzo di risorse prenotate ma non usate
IntServ: funzionalità dei router
Signaling
Signaling
Reservation
Routing
Admission
Packet flow
Packet flow
Classifier
Classificatore
Identifica il flusso a cui
appartiene il pacchetto in
arrivo
Shaper
Shaper
Ritarda flussi che non
rispettano determinate
condizioni
Scheduler
Scheduler
Seleziona il pacchetto
che deve essere inviato
per primo sul link di
uscita
IntServ: prenotazione risorse
RSVP (Resource reSerVation Protocol) - RFC 2205
Trasmette ai router sul cammino informazioni di
richiesta di risorse e QoS relative ogni flusso
I router valutano se le richieste possono essere
accettate
Se si, memorizzano le richieste delle chiamate
accettate in modo da poterle soddisfare all’arrivo
dei flussi
Lo stato nei router ha una validità limitata nel
tempo (soft state)
RSVP – PATH MESSAGE
Fissa il cammino su cui si effettua la riservazione (segue le regole
dell’instradamento IP)
Destinazione
Origine
PATH
PATH
PATH
PATH
La sorgente invia un messaggio di PATH verso la destinazione (messaggi
PATH sono emessi periodicamente per consentire la rivelazione di
eventuali variazioni dell’instradamento)
Ciascun router che riceve un messaggio di PATH mantiene un «path
state»: parametri del flusso a cui si riferisce, indirizzo del nodo
precedente attraversato dal flusso, incoming interface, outgoing interface
RSVP – PATH MESSAGE
Informa i router delle caratteristiche del flusso
PATH
TSPEC
ADSPEC
TSPEC contiene la descrizione del traffico generato
dalla sorgente (per es. attraverso i parametri del
token bucket)
TSPEC non può essere modificato dai router
RSVP – PATH MESSAGE
Raccoglie informazioni preliminari sulla QoS sul
cammino
PATH
TSPEC
ADSPEC
ADSPEC, esaminato e opportunamente modificato ad
ogni hop, sintetizza informazioni sulla QoS
conseguibile sul cammino (es. se ci sono router non
RSVP-compliant, se alcuni classi di servizio non sono
supportate, la MTU minima sul cammino etc.)
RSVP – RESV MESSAGE
Un receiver emette i messaggi RESV verso i sender per effettuare le
richieste di riservazione
I messaggi RESV devono seguire, in verso opposto, lo stesso cammino
(Reverse Path indicato nei messaggi PATH) che seguono i pacchetti dati
emessi dai sender che sono inclusi nella richiesta (l’instradamento dei
messaggi RESV non segue quindi le regole dell’instradamento IP)
Destinazione
Origine
RESV
RESV
RESV
RESV
Sulla base del Sender TSPEC e del campo ADSPEC ricevuto, la
destinazione stabilisce la richiesta di riservazione da effettuare, e la invia
nel campo FLOWSPEC del messaggio RESV verso la sorgente
RSVP – RESV MESSAGE
RESV
FLOWSPEC
(Receiver TSPEC)
(Receiver RSPEC)
In TSPEC sono contenute le descrizioni del traffico,
eventualmente cambiate dal receiver
In RSPEC sono contenute le descrizioni del tipo di
servizio desiderato
Controllo di ammissione
Riceve in input informazioni sul nuovo flusso
 RSPEC: definisce la QoS desiderata (Reserve Spec.)
 TSPEC: descrive il flusso dati (Traffic Spec.)
Conosce l’occupazione delle risorse dovuta a chiamate
già accettate
 Parametri di traffico ‘a priori’ delle chiamate accettate
 ‘misurazioni’ della effettiva occupazione delle risorse
Determina le risorse da assegnare alla nuova chiamata
 Accetta il nuovo flusso se le risorse esistono
 Altrimenti rigetta il flusso
Determina nuove RSPEC da inviare a monte
RSVP – RESV MESSAGE
Decisione al router
Il flusso verrà accettato dalla rete se questa è in grado di soddisfare i parametri
di QoS richiesti dall’utente senza compromettere i contratti di servizio in essere
(Connection Admission Control)
Vengono settati i parametri
di scheduler e classifier
RESV:
FLOWSPEC
si
Tspec
Rspec’
Se accetto il flusso
ci sono abbastanza
risorse per tutti??
si
Tspec
Rspec
Controllo di
ammissione
Scheduler
In caso di accettazione, al flusso vengono virtualmente assegnate le risorse di rete
(banda, buffer) necessari al soddisfacimento dei requisiti di QoS
(Resource Allocation)
REJECT
Controllo del traffico
I Router di frontiera devono effettuare
POLICING sui parametri dichiarati
Meter
singolo flusso
Classifier
Shaper/Dropper
Marker
CONDITIONER
Controllo del traffico
I router interni effettuano
 Classificazione dei pacchetti di ciascun flusso
 Shaping nei casi richiesti per semplificare lo
scheduler
 Scheduling basato sulla QoS richiesta
Packet flow
Packet flow
Classifier
Shaper
Scheduler
Soft State
Lo stato nei router ha una validità limitata nel tempo e controllata
da un timer.
La sorgente e la destinazione inviano quindi periodicamente nuovi
messaggi di PATH / RESV
 Un soft-state è confermato dal destinatario mediante l’invio di
messaggi di refresh e viene cancellato se entro un tempo stabilito non
viene confermato
 Se l’instradamento varia, il ricevente deve riservare esplicitamente le
risorse sul nuovo cammino
Vantaggi:
 recupero da situazioni di errore
 tolleranza alla perdita di pacchetti di segnalazione
 buona adattabilità a cambiamenti del cammino tra sorgente e
destinazione (adatto ad ambito connectionless con routing dinamico)
Svantaggio: segnalazione pesante
Il protocollo RSVP
E’ un protocollo che si colloca a livello 3, anche se
usa i servizi stessi di IP
IP
RSVP
I messaggi RSVP vengono trasmessi all’interno di un
pacchetto IP con protocol ID 46
E’ richiesto che venga limitata la congestione dei
pacchetti di segnalazione, tramite o l’assegnazione
di una quantità di banda per la segnalazione, o
l’utilizzo di meccanismi a priorità
Messaggi RSVP
PATH messaggio iniziale sul cammino di andata
RESV messaggio di prenotazione (reservation) sul
cammino di ritorno
PATH ERR comunica l’identificazione di errori durante
l’elaborazione del messaggio di PATH
RESV ERR indica il fallimento della fase di prenotazione
PATH TEAR abbattimento dello stato instaurato nei router
da un messaggio di PATH
RESV TEAR abbattimento dello stato instaurato nei router
da un messaggio di RESV
RESV CONF è un messaggio inviato alla destinazione per
confermare la riuscita della fase di prenotazione delle
risorse
Formato dei messaggi RSVP
64 bit
Header
Multiplo di 32 bit
Oggetto 1
32 bit
Header di
oggetto
Oggetto N
K*32 bit
Informazioni
Ciascun oggetto (multiplo di 32 bit) raggruppa
informazioni di carattere simile trasportate dal
messaggio (ad esempio la caratterizzazione del
traffico, o dati di policing)
Header dei messaggi RSVP
Vers Flags Msg Type
Send_TTL
Reserved
RSVP Checksum
RSVP Length
Vers indica la versione del protocollo (attualmente 1)
Flags non e’ ancora specificato
Msg Type contiene l’identificatore del tipo di messaggio
(PATH, RESV, etc)
RSVP Checksum verifica l’integrità del contenuto del
messaggio
Send_TTL (tramite il confronto con il TTL dell’header IP
permette di individuare l’attraversamento di nodi non RSVP)
RSVP Length indica la lunghezza del messaggio
Formato degli oggetti RSVP
16 bit
8 bit
8 bit
Lunghezza
Class_NUM
C-Type
Oggetto
Lunghezza indica la lunghezza dell’oggetto in byte
Class_NUM identifica un tipo di oggetto (Es.
FILTER_SPEC, ADSPEC, SENDER_TSPEC, RSVP_HOP,
TIME VALUES, etc.)
C_Type identifica univocamente il tipo di formato
usato per un tipo di oggetto (1  IPv4, 2  IPv6)
Formato dei messaggi di PATH
1
Flag
Send_TTL
1
RSVP Checksum
Reserved
RSVP Length
INTEGRITY (autentic. e integrità)
SESSION (identifica la sessione)
RSVP_HOP (ultimo nodo RSVP compatibile)
TIME_VALUES (refresh)
POLICY_DATA
SENDER_TEMPLATE
(identifica i flussi di ogni SENDER)
TSPEC (caratteristiche del flusso)
ADSPEC (stime raccolte)
Formato dei messaggi di RESV
1
Flag
Send_TTL
2
RSVP Checksum
Reserved
RSVP Length
INTEGRITY (autentic. e integrità)
SESSION (sessione di riferimento)
RSVP_HOP (ultimo nodo RSVP compatibile)
RSV_CONFIRM (rich. conferma alla destinaz)
POLICY_DATA
TIME_VALUES (refresh)
SCOPE (sorgente a cui inviare resv)
STYLE (res singola o multipla)
FLOWSPEC
Guaranteed Service (RFC 2212)
E’ il primo fra due classi di servizio INTSERV
(oltre al best effort) con assegnazione di
risorse e blocco all’ammissione
Emula il servizio a circuito con ritardi garantiti
Garantisce
 perdita nulla nei buffer di trasmissione
 un upper bound al ritardo
Guaranteed Service (RFC 2212)
Si basa sulle formule già viste per il bound sul flusso
i nel router j
Wi 
k  M p  Bi
Bi
p b
M Cj
Wi 

 Dj
Bi Bi

se
M
Bi

Cj
Bi
Bi  p
 Dj
se
Bi  p
Cj e Dj dipendono solo dal
router j
Teorema: il bound sul ritardo end-to-end si ottiene
semplicemente rimpiazzando Cj e Dj con
Ctot   C j
http://www.ietf.org/rfc/rfc2212.txt
Dtot   D j
Guaranteed Service (RFC 2212)
Il guaranteed service viene invocato specificando il traffico (TSpec)
e il servizio desiderato (RSpec) alla rete
TSpec definisce le caratteristiche del traffico richiesto e contiene:
 i parametri del token bucket
• bucket size, b (*) [byte]
• token rate, r [byte/s]
 peak rate, p [byte/s]
• p>r
 maximum packet unit, M [byte]
 minimum policed unit, m [byte]
Rspec comprende i seguenti parametri:
 Requested rate, B [byte/s]
 Slack term o termine di correzione, S [ms]
(*) nelle slide precedenti indicato con k
Guaranteed Service (RFC 2212)
ADSPEC contiene i campi Ctot e Dtot che vengono aggiornati di
router in router
L’elemento di rete k-esimo comunica i valori Csum_k e Dsum_k
all’elemento (k+1)-esimo
Dtot   Dk
Ctot   Ck
Wmax1 
Sorgente
M C1

 D1
B
B
Wmax k 
M C sum _ k

 Dsum _ k
B
B
Wmax_ tot 
M Ctot

 Dtot
B
B
ROUTER 1
ROUTER k
ROUTER N
Buff1  M  C1  BD1
Buff k  M  Csum _ k  BDsum _ k
Buff N  M  Ctot  BDtot
Destinazione
Guaranteed Service (RFC 2212)
Il ricevitore sulla base di ADSPEC determina la banda Bj che i router
devono assegnare al flusso j e lo Slack term S
S = ritardo massimo con la riservazione di banda B – ritardo richiesto
e li invia come RSPEC
Il termine di correzione S indica la differenza tra il ritardo desiderato dalla
sorgente e ritardo ottenuto tramite l’assegnazione della banda B e può
essere utilizzato dalla rete in caso di necessità per allocare una banda
inferiore rispetto a quella richieste dalla sorgente (B’<B)
Se S è positivo, i router a monte possono ridurre Bj e S e aggiornare
RSPEC
Se la banda Bj non è disponibile la chiamata viene rifiutata
Complessità nei moduli funzionali dei router (classifier, shaper,
scheduler) che devono gestire flusso per flusso
E’ il più adatto per la telefonia e per l’emulazione di circuiti
Controlled Load Service (RFC 2211)
Offre un servizio che emula il “best effort” in una rete
non congestionata:
A very high percentage of transmitted packets
will be successfully delivered by the network to
the receiving end-nodes. (The percentage of
packets not successfully delivered must closely
approximate the basic packet error rate of the
transmission medium).
The transit delay experienced by a very high
percentage of the delivered packets will not
greatly exceed the minimum transmit delay
experienced by any successfully delivered packet.
(This minimum transit delay includes speed-oflight delay plus the fixed processing time in
routers and other communications devices along
the path.)
Controlled Load Service (RFC 2211)
Controlled Load Service (CLS) utilizza un
meccanismo di shaping solo all’ingresso
Non garantisce ritardi
La gestione nei nodi è più semplice
Lascia ampio spazio a varianti di
implementazione
Adatto per servizi real-time adattativi
Controlled Load Service (RFC 2211)
TSPEC contiene la descrizione del token bucket
ADSPEC è privo di parametri QoS
FLOWSPEC non contiene RSPEC
In pratica ogni router decide il rate Bi
indipendentemente in base a una politica
predeterminata
Deve essere Bi > b
… ma si può fare overbooking
Sincronizzazione H.323-RSVP
Transmitter
Le fasi di Reservation
vanno eseguite per
ogni canale
E’ possibile usare Fast
Connect
SETUP (con indirizzo H.245)
CALL PROC.
H.245 cap e Qos exchange
OpenLogicalChannel
OpenLogicalChannelAck
FlowControlCommand (maximum
bit rate = 0 bit/s) Optional
RSVP Path
RSVP Resv
RSVP Resv Confirm
FlowControlCommand (maximum
bit rate = no restriction) Optional
ALERTING
CONNECT
Receiver
Integrated Services: problemi
Richiedono di mantenere nei router uno stato
per ciascun flusso
Scarsa scalabilità
Segnalazione pesante
Forte impatto sull’architettura di rete
esistente
Buona soluzione per la rete di accesso
IntServ: problemi non risolti
I gestori possono lasciare passare la prenotazione RSVP in
modo trasparente (o meno)?
Come riservare risorse per tratte compresse in modo
diverso?
Come controllare il cammino?
Come fare routing alternativo?
RSVP
IntServ
IntServ
IntServ: problemi non risolti
L’alternativa è quella di utilizzare dei router d’accesso,
gateway IP-IP, o application server, che terminano le
connessioni, effettuano la prenotazione, rerouting,
conversione di formato
RSVP
RSVP è mantenuto all’interno
delle reti dei gestori
IntServ
segnalazione
Segnalazione per
Qos diversa da RSVP
IntServ
DIFFERENTIATED SERVICES
DiffServ
Differentiated Services
Perseguono una soluzione semplice, scalabile
e di basso costo
Si rinuncia al controllo stretto flusso per
flusso nel forwarding dei router
Si dimensiona la classe di servizio
collettivamente all’interno di un singolo
router
Le reservation possono ancora essere fatte
flusso per flusso attraverso RSVP
RSVP e Differentiated Services
Low Latency Queuing (LLQ)
Microflussi senza controllo
I microflussi non possono essere controllati
Il traffico che eccede sottrae QoS a tutti
A livello microflusso (es. per telefonia) occorre una
gestione esterna ai DiffServ, che controlli lo stato di
allocazione delle pipe DiffServ
Differentiated Services (RFC 2475)
Come
Le operazioni complesse e il controllo dei
microflussi sono compito esclusivamente dei
bordi della rete
I router di rete devono essere solo in grado di
applicare forwarding differenziati a poche
differenti classi di traffico
 Non richiedono modifiche significative, ed in
particolare non necessitano di mantenere uno stato
per flusso o gestire segnalazione
Differenziazione dei flussi
Viene usato il campo (DS) dell’header IP
corrisponde al TOS (Type Of Service) byte di IPv4
o al Traffic Class byte di IPv6
6 bit sono utilizzati per specificare il
Differentiated Service Code Point (DSCP), mentre
i rimanenti due bit non sono utilizzati
Il DSCP viene usato dai router per selezionare il
tipo di servizio (o Per-Hop-Behavior o PHB) da
applicare (Es. 0X00 standard per best effort
forwarding)
Controllo d’accesso
E’ basato su un contratto, Service Level
Specification, che specifica il servizio statico
offerto al traffico globale generato dall’utente
 Tipo di servizio e prestazioni
 ‘Scope’ del servizio (se il servizio e’ applicato a tutto il
traffico o solo alla porzione di traffico tra particolari
gateway di accesso e di uscita).
 Profilo di traffico concordato (Es: parametri del token
bucket)
 Disposizioni per il traffico che eccede il profilo di
traffico
Router diffserv di edge
DiffServ
Edge
Router
Classifier
Marker
Meter
Policer
I router di frontiera gestiscono aggregati di traffico e
verificano la coerenza con gli SLA di accesso
Router diffserv di core
DiffServ
Core
Router
Select PHB
Extract
DSCP
PHB
PHB
PHB
PHB
Local
conditions
Packet
treatment
I router di core gestiscono aggregati di traffico e
trattano i flussi secondo i PHB selezionati in
funzione delle condizioni locali
Possibili PHB (servizi)
Per Hop Behavior (PHB)
 Expedited Forwarding per applicazioni a basso ritardo
 Assured Forwarding service per applicazioni che
richiedono affidabilità di consegna
 Best Effort service, nessuna garanzia
Router
Traffico globale EF
Traffico globale
Assured and BE
Weighted Fair Queuing
Expedited Forwarding (RFC 2598)
Expedited Forwarding vuole emulare una
linea dedicata:
 Gli utenti richiedono una quantità di banda per la
comunicazione tra due punti
 Se il traffico non eccede quanto stabilito, i ritardi
e la percentuale di pacchetti persi devono essere
molto bassi
 Il traffico va condizionato e controllato. Quello in
eccesso non viene immesso in rete.
 Codepoint 101110
Assured Forwarding (RFC 2597)
Assured Forwarding fornisce differenti livelli
di garanzie di forwarding (banda e spazio
nelle code) (4-livelli)
Si propone di evitare situazioni di congestione
 di breve termine con l’accodamento nei buffer
 di lungo termine tramite un discarding preventivo
 e differenziato dei pacchetti
Si introducono così diversi livelli di probabilità
di discarding (almeno 3)
Assured Forwarding
Lo scarto dei pacchetti deve avvenire in modo
dolce
Una possibilità è usare RED (per ciascun
livello)
mandatory
discarding
discarding
probability
no
discarding
RED (Random Early Discarding)
Sched
Random Early Discarding
Scarto
Probabilità
di scartare (P)
Probabilità
di scartare (P)
max_P 1
1
P
0
0
min_th max_th queue_len Lunghezza
della coda
min_th max_th queue_len
avg_len
Lunghezza
della coda
Accodo
Scarto/Accodo
con probabilità
avg_len - min_th
P  max_ P
max_th - min_th
Esempio di Assured forwarding
Olimpic service: tre tipi di flusso, ciascuno con tre
probabilità di scarto
 Gold service: dimensionato con basso carico
 Silver service: dimensionato con medio carico
 Bronze service: dimensionato con medio-alto carico
Sched
Confronto IntServ e DiffServ
IntServ
DiffServ
Granularità della
differenziazione del servizio
Singoli flussi
Aggregati di flussi
Stato nei router (scheduling,
buffer management)
Per flusso
Per aggregati
Base per classificazione
traffico
Diversi campi dell’header
Campo DS
Tipologia di differenziazione
del servizio
Garanzie statistiche o
deterministiche
Garanzie assolute o relative
Admission control
Richiesto
Richiesto per
differenziazione assoluta
Protocollo di segnalazione
Richiesto (RSVP)
Non richiesto per schemi
relativi
Confronto IntServ e DiffServ
IntServ
DiffServ
Coordinamento della
differenziazione del servizio
End-to-end
Locale (per-hop)
Ambito della differenziazione
del servizio
Un cammino unicast o
multicast
Ovunque in una rete o in un
cammino specifico
Scalabilità
Limitata dal numero di flussi
Limitata dal numero di classi
di servizio
Contabilizzazione di rete
(accounting)
Basato su caratteristiche dei
flussi e requisiti di QoS
Basato sull’uso delle classi
Network Management
Simile a reti a commutazione
di circuito
Simile alle reti IP esistenti
attualmente
Dispiegamento interdominio
Accordi multilaterali
Accordi bilaterali