Reti multimediali
Reti di calcolatori e Internet:
Un approccio top-down
3a edizione
Jim Kurose, Keith Ross
Pearson Education Italia
Internet
Architettura, principali protocolli e
linee evolutive
Nicola Blefari Melazzi
Mc Graw -Hill
Multimedia - Qualità del servizio: di cosa si tratta?
Applicazioni multimediali:
contenuti audio e video
(“applicazioni continue”)
QoS
Le reti forniscono alle
applicazioni un livello di
prestazioni adeguato per un
corretto funzionamento
dell’applicazione.
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
Applicazioni multimediali di rete
Classi di applicazioni
multimediali:
1) Streaming audio e video
memorizzato.
2) Streaming audio e video in
diretta.
3) Audio e video interattivi in
tempo reale.
Jitter: termine con il
quale si indica la
variabilità dei ritardi
subita dai pacchetti dello
stesso flusso.
Caratteristiche
fondamentali
 Sensibili al ritardo:


Ritardo end-to-end
Jitter
 Ma tolleranti alla perdita:
perdite occasionali causano
solo marginali interferenze.
 In antitesi con i dati: lunghi
ritardi possono risultare
fastidiosi ma la completezza e
l’integrità dei dati trasferiti
risultano di fondamentale
importanza.
Streaming audio e video memorizzato
Streaming:
 Il contenuto multimediale è
memorizzato sul server.
 Viene trasmesso al client.
 Streaming: il client può iniziare la
riproduzione di una parte del file
prima di averlo interamente scaricato.
 La riproduzione del file multimediale procede in
sincronia con i tempi di registrazione originali.
Streaming audio e video memorizzato
1. video
registrato
2. video
inviato
rete
invio
3. Video ricevuti,
riprodotti dal cliente.
tempo
streaming: in questo momento,
il client può iniziare la riproduzione
di una parte del file audio/video
prima di averlo interamente scaricato.
Streaming audio e video memorizzato: interattività
 Funzionalità simili a quelle di un videoregistratore:
il cliente può mettere in pausa, mandare avanti o
indietro il video
 10 sec ritardo iniziale OK
 1-2 sec prima che il comando abbia effetto OK
 Spesso usato RTSP
Streaming audio e video in diretta
Esempi:
 Programmi radiofonici in Internet.
 Eventi sportivi in diretta.
Streaming
 Buffer di riproduzione (playout buffer).
 È tollerato un ritardo di una decina di secondi
prima che avvenga la riproduzione.
 È necessaria la continuità della riproduzione.
Interattività
 Non è possibile usare l’avanzamento rapido.
 Riavvolgimento e pausa sì!
Audio e video interattivi in tempo reale
 applicazioni: telefonia Internet,
video conferenze
 Requisiti del ritardo end-to-end:

audio: < 150 msec buono, < 400 msec accettabile
• Comprende i ritardi a livello di applicazione (pacchettizzazione) e il
ritardo di rete
• Ritardi superiori risultano frustranti, o impediscono addirittura la
conversazione
 Inizializzazione della sessione

Come fa il chiamante ad allertare indirizzo IP, numero di porta,
algoritmi di codifica?
Ostacoli alla multimedialità in Internet
TCP/UDP/IP: servizio best-effort
 Non offre garanzie sulla consegna, né sul ritardo
?
?
?
?
?
?
Ma non abbiamo detto che le applicazioni multimediali
richiedono QoS e adeguati livelli di performance?
?
?
?
?
Oggi le applicazioni multimediali in Internet
utilizzano tecniche a livello di applicazione
per mitigare (quanto possibile) i ritardi
e le eventuali perdite.
Evoluzione di Internet verso un miglior
supporto alle applicazioni multimediali
Filosofia di intergrazione dei
servizi:
Filosofia di differenziazione
dei servizi:
 Cambiamenti radicali, per
 Piccoli interventi, limitati ai
fornire alle applicazioni la
possibilità di prenotare
larghezza di banda.
 Software nuovi e più complessi
in host e router.
livelli di rete e di trasporto
 Suddivisione dei datagrammi in
due classi di servizio
Filosofia del “laissez-faire”
 Nessun cambiamento radicale.
 Più larghezza di banda quando
necessario.
 Reti per la distribuzione dei
contenuti
Qual è la vostra opinione?
Compressione audio
 Campioni di segnali analogici
a tasso costante:


telefono: 8.000 campioni al
secondo
CD musicali: 44.100
campioni al secondo
 Ogni campione è quantizzato

es., 28=256 valori possibili
di quantizzazione.
 Tutti i valori di
quantizzazione sono
rapprentati con lo stesso
numero di bit.

8 bit per 256 valori.
 Esempio: 8.000
campioni/sec, 256 valori di
quantizzazione --> 64.000
bps
 Questo segnale digitale può
essere riconvertito in un
segnale analogico per la
riproduzione:
 possibile perdita di
qualità.
Alcuni esempi:
 CD: 1.411 Mbps
 MP3: 96, 128, 160 kbps
 Telefonia Internet: 5,3 13 kbps
Compressione video
 Un video è una sequenza
d’immagini, solitamente
mostrate a un tasso
costante:

es. 24 immagini/sec
 Un’immagine digitale
consiste in una
sequenza di pixel.
 Ogni pixel è codificato
da una serie di bit.
 Due tipi di ridondanza:


Spaziale.
Temporale.
Esempi:
 MPEG 1 (CD-ROM) 1,5 Mbps
 MPEG2 (DVD) 3-6 Mbps
 MPEG4 (spesso usata in
Internet < 1 Mbps)
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
Streaming memorizzati
Tecniche di streaming a
livello di applicazione per
ottimizzare il servizio
best effort:
 buffering lato client
 utilizzo di UDP
Media Player
 Rimozione del jitter
 Decompressione
 Correzione degli errori
 Interfaccia in cui appaiono
pulsanti e cursori
interattivi.
Accesso ad audio e video
tramite server web
 Audio o video sono contenuti in un
unico file.
 Il file viene trasferito tramite un
messaggio HTTP:
 ricevuto per intero dal client
 il media player riproduce il file.
Accesso ad audio e video
tramite server web
 Il browser ottiene un metafile.
 Il browser lancia il media player e passa il metafile.
 Il media player contatta direttamente il server.
 Il server invia il file audio/video al media player.
 Uso di HTTP  TCP
Invio di contenuti multimediali
da server di streaming
 Questa architettura evita l’uso del protocollo HTTP tra
server e media player.
 Si può anche utilizzare UDP invece che TCP.
UDP o TCP?
UDP
 Il server invia a un tasso appropriato per il cliente
In genere: tasso di invio = tasso di codifica = tasso costante
 quindi, tasso di riempimento = tasso costante - perdita di
pacchetti
 Il media player ritarda la riproduzione di 2-5 secondi per
eliminare l’eventuale jitter indotto dalla rete.

TCP
 Il server immette, il più velocemente possibile, il video nella
socket TCP.
 Il tasso di riempimento fluttua nel tempo a causa del controllo
della congestione di TCP.
 Maggiore ritardo di riproduzione
 HTTP/TCP passano più facilmente attraverso i firewall
Protocollo di streaming in tempo reale: RTSP
HTTP
 Non prevede contenuti
multimediali.
 Non è previsto il comando
di avanzamento rapido ecc.
RTSP: RFC 2326
 Protocollo di streaming in
tempo reale.
 Usato per il controllo della
riproduzione: pausa, fermo
immagine, ricerca in avanti
e all’indietro, avanzamento
rapido ecc.
Cosa non può fare:
 Non definisce gli schemi di
compressione audio e video.
 Non prescrive il modo (UDP o
TCP) in cui i dati sono
trasportati.
 Non pone limiti a come il
media player memorizza i
file.
RTSP: protocollo fuori banda
FTP utilizza il concetto di
fuori banda:
 Un file viene trasferito su
una connessione TCP.
 Le informazioni di controllo
(cambio di directory,
cancellazione/rinomina di
file, ecc.) sono trasferite
su un’altra connessione TCP.
 I canali “in banda” e i canali
“fuori banda” utilizzano un
numero di porta diverso.
Anche i messaggi RTSP sono
inviati “fuori banda”:
 I messaggi di controllo
RTSP usano un numero di
porta diverso dal flusso
multimediale: fuori banda

Porta 554
 Il flusso dei contenuti
multimediali è considerato
“in banda”.
RTSP: esempio
Scenario:
 Il browser richiede a un server web un file.
 Il browser lancia il media player.
 Per consentire il controllo della riproduzione, media
player e server si scambiano informazioni impiegando
RTSP.
Metafile - esempio
<title>Twister</title>
<session>
<group language=en lipsync>
<switch>
<track type=audio
e="PCMU/8000/1"
src = "rtsp://audio.example.com/twister/audio.en/lofi">
<track type=audio
e="DVI4/16000/2" pt="90 DVI4/8000/1"
src="rtsp://audio.example.com/twister/audio.en/hifi">
</switch>
<track type="video/jpeg"
src="rtsp://video.example.com/twister/video">
</group>
</session>
Iterazioni tra client e server con RTSP
Esempio di una sessione RTSP
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0
Cseq=1; Transport: rtp/udp; compression; port=3056; mode=PLAY
S: RTSP/1.0 200 OK
Cseq=1 Session 4231
C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Cseq=2; Session: 4231
Range: npt=0S: RTSP/1.0 200 OK
Cseq=2 Session 4231
C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Cseq=3; Session: 4231
Range: npt=37
S: RTSP/1.0 200 OK
Cseq=3; Session 4231
C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0
Cseq=4; Session: 4231
S: RTSP/1.0 200 OK
Cseq=4; Session 4231
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
Applicazioni interattive in tempo reale
 Telefonia da PC a PC

Fornita da servizi di
messaggeria istantanea
 Telefonia da PC a telefono


Dialpad
Net2phone
 Videoconferenze con
webcam.
Vediamo ora il caso
di un’applicazione di
telefonia Internet.
Telefonia Internet
Introduciamo la telefonia Internet con un esempio:
 In una normale conversazione si alternano periodi di “parlato”
e di “silenzio”:

64 kbps durante il periodo di “parlato”.
 L’applicazione genera pacchetti solo nella fase di “parlato”.

Genera un flusso di 8.000 byte/s. Ogni 20 ms li riunisce in
blocchi da 160 byte.
 Ciascun blocco ha un’intestazione a livello di applicazione.
 Il blocco e l’intestazione sono incapsulati in un segmento
UDP.
 Quindi, durante la fase di emissione, ogni 20 ms viene inviato
un segmento UDP.
Telefonia Internet:
perdita dei pacchetti e ritardo
 Perdita a causa della rete: è possibile quando un
buffer è pieno e non può ricevere il datagramma IP
che, in questo caso, viene scartato e non arriverà
mai a destinazione.
 Perdita per ritardo: quando i datagrammi IP
arrivano con molto ritardo:


Diversi “tipi” di ritardo: di trasmissione, di elaborazione,
di accodamento nei router, di propagazione e di
elaborazione nei terminali lungo un collegamento.
Ritardo massimo tollerato: 400 ms.
 Ritardo tollerato: a seconda di come la voce è
codificata e trasmessa, e di come la perdita è
mascherata in ricezione, tassi di ritardo compresi
fra 1% e 10% possono essere tollerati.
Jitter di pacchetto
Ricezione
Ritardo
di rete
variabile
(jitter)
Ritardo di
riproduzione
riproduzione del video
a tasso costante
buffered
data
trasmissione
video con tasso
costante
tempo
Ritardo di riproduzione fisso
 Il ricevente tenta di riprodurre ciascun blocco esattamente
q millisecondi dopo che è stato generato.
 Se un blocco è contrassegnato da un tempo di
generazione t, il ricevente lo riproduce dopo un intervallo
t + q.
 Se il blocco non è arrivato in tempo utile, lo scarta e lo
considera perso.
 Qual è la migliore scelta per q ?
 q elevato: diminuisce la perdita dei pacchetti
 q basso: la qualità è migliore (ma se q è inferiore a 400
ms molti pacchetti mancherebbero il tempo programmato
per la riproduzione a causa del jitter)
Ritardo di riproduzione fisso
• Il trasmittente genera pacchetti a intervalli regolari,
supponiamo ogni 20 ms.
• Il primo pacchetto è ricevuto al tempo r.
• Il primo istante di riproduzione inizia al tempo p.
• Il secondo istante di riproduzione inizia al tempo p’.
packets
loss
packets
generated
packets
received
playout schedule
p' - r
playout schedule
p-r
time
r
p
p'
Ritardo di riproduzione adattativo
 Obiettivo: ritardo di riproduzione minimo con il vincolo che la
perdita sia al di sotto dei pochi punti percentuali.
 Approccio: regolare il ritardo di riproduzione:




Stimare il ritardo della rete e regolare il ritardo di riproduzione
con l’inizio di ciascun periodo di attività vocale.
Le pause dei trasmittenti vengono compresse o prolungate.
Il trasmittente genera pacchetti a intervalli regolari, ogni 20
ms.
ti = istante in cui il primo pacchetto è generato.
ri = istante in cui il pacchetto i è ricevuto.
pi = istante in cui il pacchetto i è riprodotto.
ri - ti = ritardo di rete end-to-end dell’i-esimo pacchetto.
di = stima del valore medio del ritardo alla ricezione dell’i-esimo
pacchetto.
Questa stima è ricavata dalle marcature temporali come segue:
d i  (1  u )d i 1  u( ri  ti )
dove u è una costante (es., u = 0,01).
Ritardo di riproduzione adattativo
Vi, = stima della deviazione media dal ritardo medio stimato:
vi  (1  u )vi 1  u | ri  ti  d i |
Le stime di di e vi sono calcolate per ogni pacchetto ricevuto, sebbene
possano essere utilizzate solo per determinare il punto di riproduzione
del primo pacchetto.
Se i è il primo pacchetto di un periodo di attività, il suo istante di
riproduzione è dato da:
pi  ti  d i  Kvi
dove K è una costante positiva.
Il punto di riproduzione per ogni pacchetto successivo è calcolato
come lo spostamento dal momento in cui è riprodotto il primo pacchetto.
Recupero dei pacchetti perduti
Correzione dell’errore in avanti
(FEC)
 Il ricevente deve attendere
di aver ricevuto l’intero
gruppo di pacchetti prima di
poter iniziarne la
riproduzione.
 Conseguenze:
 Aumento della banda
necessaria;
 ritardo di riproduzione.
Recupero dei pacchetti perduti
Interallacciamento
 Può migliorare la qualità con cui si
percepisce uno stream audio
 Non richiede l’aumento di
larghezza di banda dello stream
 Incrementa la latenza, limitando
così il suo utilizzo per applicazioni
interattive come la telefonia
 Buone prestazioni nello streaming
audio memorizzato
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
Protocolli per applicazioni
interattive in tempo reale
 RTP specifica la
struttura di un
pacchetto
standardizzata per i
campi dati audio/video.
 RFC 1889
 Il pacchetto RTP include:



Il tipo di carico utile
Il numero di sequenza
La marcatura temporale
 RTP opera sugli end-
system.
 I pacchetti RTP sono
incapsulati in un
segmento UDP.
 Interoperabilità: le
applicazioni che
incorporano RTP possono
interagire con altri
software di rete
multimediali, anche se
utilizzano prodotti
sviluppati da differenti
aziende.
RTP e QoS
 RTP non offre alcun meccanismo che assicuri la
consegna in tempo dei dati o fornisca altre
garanzie in termini di QoS
 L’incapsulamento RTP è visibile solo al sistema
terminale, non dai router intermedi.
RTP utilizza UDP
Le librerie RTP forniscono un’interfaccia a livello
di trasporto che estende UDP:
32 bit
Source port #
Destination port #
Lenght
Checksum (opt.)
V P X C
C
M
PType
Sequence number
Timestamp
Synchronization source (SSRC) identifier
Possible header extension
Payload
UDP
header
8B
RTP
header
12 B
Intestazione dei pacchetti RTP
0
V
2
P
3 4
X
8 9
CC
M
16
PT
24
Sequence Number
Timestamp
SSRC
CSRC_1
31
Intestazione dei pacchetti RTP

version (V) = (2 bit)
Indica la versione del protocollo RTP;

Padding (P) = (1 bit)
Indica che nella parte dati esistono dei byte di riempimento, che non fanno
parte dei dati;

Extension (X) = (1 bit)
Indica la presenza di un extension header; Dipende dal profilo o
dall’applicazione.

CSRC count (CC) = (1 bit)
Numero di campi CSRC presenti nell’intestazione;

Marker (M) = (1 bit)
Il suo uso dipende dal profilo della sessione in corso; Il profilo definisce i
codec utilizzati, mappati nel payload type (PT).
Intestazione dei pacchetti RTP
PT - Tipo di carico (7 bit).
Indica la codifica impiegata. Se il trasmittente decide di variare
la codifica durante una sessione, per aumentare la
qualità audio o per diminuire la frequenza trasmissiva del flusso RTP,
può informare il ricevente del cambiamento attraverso questo campo.
•Codice 0
PCM legge , 64 kbps
•Codice 3
GSM, 13 kbps
•Codice 7
LPC, 2,4 kbps
•Codice 26
JPEG
•Codice 31
H.261
•Codice 33
Video MPEG 2
Numero di sequenza (16 bit). Il numero di sequenza è incrementato
di un’unità per ogni pacchetto inviato, e può essere utilizzato dal
ricevente per rilevare le perdite e ricostruire la sequenza dei pacchetti.
All’inizio della sessione viene estratto in modo casuale:
minimizza la probabilità di avere pacchetti di connessioni “vecchie” ancora
in rete con lo stesso numero di sequenza.
Intestazione dei pacchetti RTP
 Marcatura temporale (32 bit). Riporta l’istante del campionamento del
primo byte nel pacchetto dati:
 Serve per eliminare il jitter dei pacchetti introdotto nella rete e per
fornire la riproduzione sincronizzata al receiver;
 Il primo timestamp inviato nello stream RTP viene estratto in modo
casuale;
 Nel caso dell’audio, l’orologio è incrementato di un’unità a ogni
campionamento (per esempio, ogni 125 ms per un campionamento a 8
KHz).
 Se l’applicazione audio genera blocchi costituiti da 160 campioni, allora la
marcatura temporale cresce di 160 per pacchetto RTP quando la
sorgente è attiva. La marcatura temporale è incrementata a tasso
costante anche se la sorgente è inattiva.
 Identificatore della sorgente di sincronizzazione, SSRC (32 bit).
 Identificativo della sorgente che ha creato il contenuto del
payload.
 E’ un numero scelto a caso dalla sorgente quando inizia un
nuovo stream.
 Contributing source (CSRC) = fino a 15 campi da 32 bit ciascuno
- Campi opzionali;
- Contengono gli SSRC delle vere sorgenti del flusso.
Intestazione dei pacchetti RTP
0
8
16
Defined by profile
24
31
Lenght
header extension
……..
 header extension
 Un meccanismo di estensione è previsto per le
implementazioni individuali per sperimentare nuove
funzioni payload-format indipendenti, che
richiedono informazioni aggiuntive da inserire
nell'header del pacchetto RTP;
 lenght : lunghezza dell’estensione dell’intestazione
espressa in word da 4 byte.
Protocollo di controllo di RTP (RTCP)
 RTP control protocol
 Le statistiche includono il
(RFC 1889).
 Funziona insieme a RTP.
 Ogni partecipante di una
sessione RTP trasmette
periodicamente pacchetti
di controllo RTCP a tutti gli
altri partecipanti.
 Ogni pacchetto RTCP
contiene i rapporti dei
trasmittenti e/o riceventi
numero dei pacchetti
spediti, di quelli persi e il
jitter.
 Queste informazioni
possono essere utilizzate
per controllare le
prestazioni
 Es., i trasmittenti
potrebbero utilizzarle
per modificare la loro
frequenza trasmissiva.

Che comunicano
statistiche utili
all’applicazione.
RTCP (continua)
- I pacchetti RTCP sono trasferiti tra i vari partecipanti a una sessione RTP
utilizzando IP multicast. Per ogni sessione RTP esiste un indirizzo multicast
utilizzato da tutti i pacchetti RTP e RTCP.
- I pacchetti RTP e RTCP sono distinguibili dai loro numeri di porta (quello
di RTCP è dato dal numero di porta RTP più uno).
- Per limitare il traffico, ogni partecipante riduce il suo traffico RTCP quando
il numero dei partecipanti aumenta.
Pacchetti RTCP
Il ricevente genera un rapporto
di ricezione:
 L’identificatore SSRC del
flusso RTP, la frazione di
pacchetti persi, l’ultimo
numero di sequenza ricevuto
e il jitter negli arrivi.
Il trasmittente invia pacchetti
di rapporto:
 L’identificatore SSRC del
flusso RTP, la marcatura
temporale e l’ora effettiva di
generazione dei pacchetti più
recenti, il numero dei
pacchetti inviati e il numero
dei byte inviati nel flusso.
Il trasmittente crea anche
pacchetti di descrizione
della sorgente:
 Indirizzo e-mail, nome del
trasmittente e
informazioni
sull’applicazione che ha
generato il flusso e il suo
identificatore SSRC.
 Questi pacchetti
forniscono una correlazione
fra SSRC e il nome
dell’utente/host.
Pacchetti RTCP
• SR (Sender Report):
- inviato da tutte le sorgenti attive a tutti i
partecipanti;
- trasporta statistiche di spedizione effettuate dai partecipanti che
trasmettono dati RTP;
- riassume la quantità di informazione appena inviata;
- contiene: a) Timestamp assoluto (NTP) all’istante di invio;
b) Timestamp relativo al flusso RTP in corso;
c) Quantità di dati inviati dall’inizio della sessione;
- Numero totale di pacchetti RTP inviati;
- Numero totale di byte inviati.
Pacchetti RTCP
 RR (Receiver Report):
-
inviato da tutte le sorgenti passive a tutti i partecipanti;
trasporta statistiche di ricezione di un partecipanti che riceve dati RTP;
informa i mittenti della qualità della ricezione;
è inviato ad ogni sorgente da cui si è ricevuto un SR;
contiene: a) Indicazione della sorgente ascoltata;
b) Timestamp dell’ultimo SR ricevuto;
c) Ritardo dalla ricezione dell’ultimo SR;
d) Numero di sequenza più alto ricevuto dalla sorgente;
e) Numero di pacchetti RTP della connessione persi;
f) Frazione di pacchetti RTP della connessione persi;
g) Stima del jitter dei pacchetti RTP della connessione.
Pacchetti RTCP
 SDES (Source Descriptor):
-
contiene elementi di descrizione dei partecipanti;
descrive la sorgente mediante identificativo unico;
è usato dalle sorgenti e dai ricevitori per “presentarsi”;
può contenere: a) CNAME: identificativo dell’utente ([email protected]);
b) NAME: nome della persona che usa l’applicazione;
c) EMAIL;
d) PHONE;
e) LOC: indicazione geografica dell’utente;
f) TOOL: applicazione che sta usando RTP;
g) NOTE.
 BYE:
- indica la disconnessione di un partecipante o termine della sessione
 APP: application-specific
- indica che un partecipante vuole lasciare la sessione
pacchetto RTCP
Encription
prefix
32 bit
SR o RR
Additional
RRs
SDES
(CNAME)
APP
BYE
Sincronizzazione dei flussi
 RTCP può essere utilizzato
per sincronizzare i flussi
delle sessioni RTP.
 Consideriamo
un’applicazione di
videoconferenza per la
quale ciascun trasmittente
genera due flussi RTP
indipendenti.
 Le marcature temporali in
questi pacchetti sono
legate agli orologi di
campionamento audio e
video.
 E non all’ora effettiva,
cioè al tempo reale.
 I rapporti RTCP del
trasmittente contengono:


La marcatura temporale
del più recente pacchetto
RTP.
L’ora effettiva di
creazione.
 I riceventi possono
utilizzare questa
corrispondenza per
sincronizzare la
riproduzione di audio e
video.
Scalabilità di RTCP
Problema !!!
 sessione RTP con un sender e un gran numero di receiver;
 ciascuno dei receiver genera pacchetti RTCP;
la velocità di trasmissione aggregata dei pacchetti può
superare di molto la velocità di invio dei pacchetti RTP del sender.
 la quantità di traffico RTP inviato nell’albero multicast non varia
all’aumentare del numero dei receiver;
 la quantità di traffico RTCP cresce linearmente con il numero dei receiver.
Risoluzione:
 RTCP modifica la velocità a cui i partecipanti inviano i pacchetti alla
sessione.
Scalabilità di RTCP
 RTCP cerca di limitare il
 Il tasso ridotto è equamente
traffico al 5% della
ripartito tra i riceventi:
larghezza di banda della
 Dati R riceventi, ciascuno di
sessione.
essi può trasmettere a una
Esempio:
frequenza di 75/R kbps.
 Se il trasmittente sta
 La frequenza del mittente sarà
inviando un video a 2 Mbps,
di 25 kbps.
il 5% corrisponde a 100
 I partecipanti determinano il
Kbps.
periodo di trasmissione del
 Il protocollo ripartisce
pacchetto RTCP calcolandone
quindi equamente il 75% del
dinamicamente la dimensione
tasso ridotto tra i riceventi
media e dividendola per il
e assegna il restante 25%
tasso di trasmissione
al trasmittente.
assegnato.
Scalabilità di RTCP
 Un partecipante (sender o receiver) determina il periodo di
trasmissione del pacchetto RTCP calcolando dinamicamente la
dimensione media del pacchetto RTCP e dividendola per la
velocità che gli è stata allocata.
Ts =
numero sender
(dim. media pacchetto RTCP)
0.25 x 0.05 x larghezza banda
sessione
Tr =
numero receiver
0.75 x 0.05 x larghezza banda
sessione
(dim. media pacchetto RTCP)
SIP
 SIP: Session Initiation Protocol
 Definito in ambito IETF
SIP, visione a lungo termine
 Tutte le telefonate e le video conferenze passano
attraverso Internet.
 Le persone sono identificate dal loro nome o
dall’indirizzo e-mail, piuttosto che dal loro numero
di telefono.
Servizi offerti da SIP
 Impostazione della
chiamata



Fornisce i meccanismi che
consentono al chiamante di
connettersi al ricevente.
Fornisce i meccanismi che
consentono ai partecipanti di
accordarsi sulle codifiche
dei media.
Fornisce i meccanismi che
permettono di terminare le
chiamate.
 Determinazione
dell’attuale indirizzo IP
del ricevente.
 Gestione della chiamata,
fornisce procedure che
permettono di:




aggiungere nuovi flussi di
media.
cambiare la codifica durante
la chiamata
invitare nuovi partecipanti
trasferire o mettere in
attesa.
Chiamata verso un indirizzo IP noto
Bob
Alice
167.180.112.24
INVITE bob
@193.64.2
10.89
c=IN IP4 16
7.180.112.2
4
m=audio 38
060 RTP/A
VP 0
193.64.210.89
port 5060
port 5060
Bob's
terminal rings
200 OK
.210.89
c=IN IP4 193.64
RTP/AVP 3
3
m=audio 4875
ACK
port 5060
 Law audio
time
• Bob invia un messaggio di
risposta che comprende, oltre
alla stringa 200 OK, anche le
indicazioni del suo indirizzo IP e
le preferenze di codifica (GSM).
• i messaggi SIP possono essere
inviati sia con TCP sia con UDP.
Qui sono inviati con RTP/UDP
port 38060
GSM
• Alice invia un messaggio
INVITE a Bob che comprende le
indicazioni del suo numero di
porta, del suo indirizzo IP. Vuole
ricevere l’audio codificato nel
formato AVP 0 (PCM codificato
con legge ).
port 48753
time
• Di default, il numero di porta di
SIP è 5060.
Esempio di un messaggio SIP
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 167.180.112.24
From: sip:[email protected]
To: sip:[email protected]
Call-ID: [email protected]
Content-Type: application/sdp
Content-Length: 885
c=IN IP4 167.180.112.24
m=audio 38060 RTP/AVP 0
• Qui non si usa
l’indirizzo IP di Bob, ma
il suo indirizzo SIP
sip:[email protected]
• Alice invia e riceve
messaggi SIP usando
il numero di porta di
default 5060.
Note:
 Assomiglia ai messaggi HTTP.
 sdp = session description protocol – RFC 2327
 Call-ID è unico per ogni chiamata.
Traduzione dei nomi
e localizzazione degli utenti
 Il chiamante ha solo il
nome o l’indirizzo email del destinatario.
 Ha bisogno di
conoscere l’indirizzo
IP dell’attuale host del
destinatario:



L’utente si sposta
Protocollo DHCP
L’utente ha differenti
dispositivi IP (PC,
PDA,…)
 I risultati si basano su:



momento della giornata (al
lavoro, a casa)
chiamante (non si desidera
che il capo ci rintracci a casa)
status del ricevente (le
chiamate vengono dirottate
su una segreteria telefonica
se il destinatario sta già
parlando con qualcuno)
Servizi forniti dai server SIP:
 Server di registrazione SIP.
 Server proxy SIP.
Server di registrazione SIP
 Un utente (Bob) è associato a un server di registrazione SIP al
quale l’applicazione, quando viene lanciata, invia un messaggio di
registrazione. Il server di registrazione di Bob memorizza il suo
attuale indirizzo IP.
Messaggio di registrazione:
REGISTER sip:domain.com SIP/2.0
Via: SIP/2.0/UDP 193.64.210.89
From: sip:[email protected]
To: sip:[email protected]
Expires: 3600
Messagi di refresh ogni 3600 secondi
Esempio
Procedura seguita da
[email protected] per
avviare una sessione vocale
IP con [email protected]
SIP registrar
upenn.edu
SIP
registrar
eurecom.fr
2
SIP proxy
umass.edu
3
4
(1) Jim invia un messaggio
INVITE al proxy SIP
1
5
7
di umass. (2) Questo fa una
8
6
ricerca e quindi rilancia il
Messaggio al server di
9
registrazione. (3) dato che
SIP client
197.87.54.21
SIP
client
[email protected] non è
217.123.56.89
presente nel server di upenn,
quest’ultimo invia una risposta di ri-direzione.
(4) Il proxy umass trasmette un INVITE al server di registrazione SIP di
eurecom (5) che conosce l’indirizzo e rilancia l’INVITE al terminale 197.87.54.21,
su cui gira il client SIP di Keith. (6-8) viene inviata una risposta SIP verso il client
SIP (9) I media vengono scambiati direttamente tra i due client.
Nota: il messaggio di riscontro SIP non è mostrato.
Confronto con H.323
 H.323 è un altro protocollo
di trasmissione in tempo
reale, interattivo.
 H.323 è una famiglia
completa di protocolli
integrati verticalmente per
le conferenze multimediali:
segnalazione, registrazione,
controllo di ammissione,
trasporto e codec.
 SIP è un componente
monolitico. Lavora con RTP,
ma non lo richiede. Può
essere combinato con altri
protocolli e servizi.
 H.323 è di origine ITU
(telefonia).
 SIP è di origine IETF e
adotta molti concetti del
Web, di DNS e della posta
elettronica in Internet.
 SIP adotta il principio
KISS: keep it simple
stupid, fallo in modo
semplice, stupido.
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
Reti per la distribuzione dei contenuti
(CDN)
Distribuzione di contenuti:
 Distribuzione in tempo reale di
flussi di file di notevoli dimensioni
(es., video) da un singolo server di
origine.
 Soluzione: replicare il contenuto a
centinaia di server attraverso
Internet:
 Il contenuto viene prima
caricato nel server CDN.
 La CDN replica i contenuti nei
server CDN
 La CDN fornisce un
meccanismo per cui il
contenuto richiesto da un
client viene fornito dal server
CDN che può farglielo
pervenire nel modo migliore.
Server di origine
in Nord America
Nodo di distribuzione CDN
Server CDN
in Sud America
Server CDN
in Europa
Server CDN
in Asia
Reti per la distribuzione dei contenuti
(CDN)
Distribuzione di contenuti:
 I fornitori di servizi come
CNN distribuiscono i
contenuti attraverso una CDN
(es., Akamai).
 Ogni volta che un fornitore
modifica un oggetto,
provvederà a inoltrare la
versione aggiornata al nodo
CDN, il quale lo replica
immediatamente e lo
distribuisce ai server CDN.
Server di origine
in Nord America
Nodo di distribuzione CDN
Server CDN
in Europa
CDN - Esempio
1
Richiesta HTTP per
www.foo.com/sports/sports.html
Server di origine
2
3
Richiesta DNS per www.cdn.com
Server DNS di
competenza della CDN
Richiesta HTTP per
www.cdn.com/www.foo.com/sports/ruth.gif
Server CDN
più vicino
Server di origine
(www.foo.com)
 Provvede a diffondere l’oggetto
base HTML
 sostituisce:
http://www.foo.com/sports.ruth.gif
con
http://www.cdn.com/www.foo.com/sports/ruth.gif
Server CDN (cdn.com)
 Distribuisce file gif.
 Utilizza il server DNS
server per instradare le
richieste di ridirezione
Ancora su CDN
Richieste di instradamento
 CDN crea una “mappa” che indica le distanze tra gli
ISP foglia e i nodi CDN
 Quando arriva una richiesta al server DNS :


Il server determina l’ISP dal quale è arrivata la richiesta
Usa tabelle d’instradamento per determinare il miglior
server CDN.
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
Migliorare la qualità di servizio
nelle reti IP
Fin qui: si è cercato di ottenere il meglio dal servizio best-effort.
In futuro: una nuova generazione di Internet con garanzie di QoS.
 RSVP: protocollo di segnalazione che consente alle applicazioni di
prenotare le risorse.
 Differenziazione dei servizi: architetture per fornire differenti
garanzie.
 Servizi integrati: architetture per servizi integrati.
Princìpi per fornire garanzie di QoS
 Esempio: applicazione audio a 1 Mbps, collegamento a 1,5 Mbps
con applicazione FTP.


Una raffica (burst) di pacchetti dalla sorgente FTP può
congestionare il router, causando la perdita di alcuni pacchetti.
Vogliamo dare priorità ai pacchetti audio rispetto a quelli FTP.
Principio 1
La marcatura dei pacchetti consente ai router di
distinguerli in base alla loro classe di traffico.
Principi per fornire garanzie di QoS (segue)
 Cosa succede se un pacchetto audio viene inviato a un un tasso
più alto rispetto a quanto dichiarato?

controllo: costringere la sorgente ad attenersi all’allocazione di
banda prevista
 Marcatura e controllo:

Simile ad ATM UNI (User Network Interface)
Principio 2
È auspicabile che ciascun flusso sia isolato, in modo che l’uno non
subisca gli effetti negativi derivati dal comportamento non conforme
degli altri.
Principi per fornire garanzie di QoS (segue)
 Allocare banda fissa (non-sharable) al flusso: uso
inefficiente della banda se il flusso non rispetta la
sua allocazione
Principio 3
È auspicabile che l’utilizzo delle risorse sia quanto più
efficiente possibile anche in presenza di isolamento dei flussi.
Principi per fornire garanzie di QoS (segue)
 Assioma: è impossibile supportare richieste di
traffico superiore alla capacità del collegamento
Principio 4
È necessario un processo di ammissione alla chiamata durante il quale vengono
confrontati i requisiti di servizio dei flussi con le risorse disponibili in quel dato
momento. Sa la richiesta può essere soddisfatta il flusso potrà accedere alla
rete, altrimenti il suo ingresso sarà negato.
Sommario dei principi di QoS
Esamineremo ora i vari modi in cui sono implementati….
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
Meccanismi di scheduling e sorveglianza
 scheduling: procedura con cui i pacchetti sono selezionati nelle
code prima di essere inoltrati.
 Procedura FIFO (first in first out): i pacchetti vengono inviati in
ordine di arrivo. Quindi vengono trasmessi nello stesso ordine
che hanno nella coda.

Politica di esclusione: se un buffer non ha più spazio per ricevere un
ulteriore pacchetto, come determina quale deve scartare?
• Tail drop: elimina il pacchetto ultimo arrivato
• Priorità: elimina o rimuove in base alla priorità
• Random: elimina o rimuove a caso
Modalità di scheduling
Accodamento con priorità: i pacchetti vengono trasmessi in base
alla priorità e non in ordine di arrivo.
 più classi, con differenti priorità


Le classi dipendono da una marcatura riportata nell’intestazione
del pacchetto, es. IP sorgente o di destinazione, numero di porta,
ecc.
Esempio concreto?
Modalità di scheduling
Accodamento round robin:
 Diverse classi
 Le classi non hanno una rigida priorità di servizio. Infatti è
prevista una sorta di avvicendamento “circolare” tra le
diverse classi.
Modalità di scheduling
Accodamento equo ponderato (weighted fair queuing-WFQ):
 Astrazione della strategia round robin
 Offre un servizio di tipo ciclico e le classi possono ricevere
un servizio differenziato.
Criteri nelle procedure di monitoraggio
Obiettivo: porre limitazioni al traffico in modo che questo non
ecceda i parametri dichiarati
Tre importanti criteri:
 Tasso medio: è limitato il numero di pacchetti in un determinato
intervallo di tempo (a lungo termine).

Aspetto cruciale: un flusso con una frequenza trasmissiva media
vincolata a 100 pacchetti al sec subisce maggiori restrizioni rispetto
a una sorgente il cui limite è di 6000 pacchetti al minuto, anche se
entrambi presentano un’identica media!
 Tasso di picco: es., è imposto al flusso un tasso medio di 6000
pacchetti al minuto con il vincolo di non superare i 1500 pacchetti
al secondo.
 Dimensione della raffica (burst): vincola il numero di pacchetti
che possono essere trasmessi consecutivamente al tasso di picco.
Criteri nelle procedure di monitoraggio
Leaky bucket (secchio bucato): meccanismo per monitorare
il rispetto dei limiti imposto a un flusso di pacchetti.
BTS
rs
 Recipiente in grado di contenere fino a b gettoni (token).
 Generati alla frequenza di r gettoni al secondo e quindi immessi
nel contenitore.
 Il numero massimo di pacchetti che possono essere trasmessi
nell’intervallo di tempo t è uguale a rt + b.
Criteri nelle procedure di monitoraggio
LB
BTS
LB
Ps
rs
BTS
rs
Ps
Dual Leaky-Bucket
b
c
BTS
rs
Ps  c
BTS  b
Ps  rs
Ps
b
BTS
rs
Ps
c
Multiplexing
DLB1
B
C
DLB2
...
Es. Fair-Share
b
DLBk
C B

c b
c
Capacità Equivalente e Banda Equivalente
b
Ps  c
BTS  b
Ps  rs
BTS
Fair-Share
PS BTS
c0 
Dmax ( PS  rS )  BTS
B
Dmax 
C
C B
nmax  
c0 b0
oppure
b0
C B

c b
b0  Dmax c0
C B

c b
b
 Dmax
c
Max delay
rs
c0
Ps
c
b
 Dmax
c
c0 
PS BTS
Dmax ( PS  rS )  BTS
b0  Dmax c0
B C
nmax  min  , 
 b0 c0 
B
tipicamente
 Dmax
C
Criteri nelle procedure di monitoraggio
arriving
token rate, r
traffic
bucket size, b
per-flow
rate, R
WFQ
D = b/R
max
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
Servizi integrati IETF
 Architettura per fornire garanzie in termini di QOS nelle reti IP
 Prenotazione delle risorse
 Ammissione/negazione delle richieste di impostazione di una nuova
chiamata
 Per garantire opportune prestazioni di rete è necessario creare e
mantenere degli stati in ciascun nodo
 La gestione è più semplice ed affidabile se ogni stato ha significato
locale ed è di tipo soft
 Le informazioni contenute in uno stato sono relative a un flusso di
informazione. Un flusso è una sequenza di datagrammi IP trasmessi da
una data sorgente, ricevuto da un dato ricevitore ed appartenenti alla
medesima applicazione
Integrated Services Architecture (ISA) = estensione della classica
architettura Internet (RFC 1633), per supportare funzionalità di QoS
Intserv: architettura per servizi integrati
 Prenotazione delle risorse



Segnalazione per l’impostazione della
chiamata (RSVP).
Caratterizzazione del traffico e
specifica della QoS.
Ammissione della chiamata singola.
richiesta/
risposta
Meccanismi
attuativi di QoS
(es., WFQ)

Advanced IP Architecture
Real Time Applications
RSVP
RTP/RTCP
Elastic
Applications
UDP
IPv4/IPv6
Underlying Data Link Technologies
TCP
Intserv: architettura per servizi integrati
Service Class:
Specifica il tipo di servizio ricevuto dal flusso
L’architettura IS fornisce tre Service Classes:
- best effort delivery
- guaranteed service
- controlled load service
Intserv: architettura per servizi integrati
Guaranteed Service è definita per applicazioni real-time
Guaranteed Service QoS implica:
- Larghezza di banda garantita
- Ritardo massimo end-to-end prefissato (matematicamente)
- Assenza di perdite
Il traffico entrante nel dominio è monitorato (policed):
Il traffico non conforme è trattato in modalità best-effort
Intserv: architettura per servizi integrati
Controlled Load è definito per traffico real-time, ma con
requisiti sul ritardo meno stringenti
Controlled Load fornisce prestazioni simili a quelle ottenibili
mediante il servizio best-effort con rete scarica
Il traffico entrante nel dominio è monitorato (policed):
Il traffico non conforme è trattato in modalità best-effort
Reservation Setup Protocol: RSVP
RSVP è un protocollo di segnalazione che coinvolge
trasmsttitore, ricevitore e router del percorso di rete
RSVP usa stati soft:
• Gli stati path e reservation immagazzinati nei router
scadono dopo in certo intervallo di tempo, quindi se
devono essere mantenuto occorre confermarli (refresh)
periodicamente; il refresh è realizzato dagli host
Procedure RSVP :Unicast Reservation
1st step: invio del messaggio PATH downstream
PATH
RSVP Enabled
Host (SND)
RSVP Router
RSVP Router
RSVP Enabled
Host (RCV)
Quando un router RSVP riceve il messaggio di PATH:
• crea o aggiorna il relativo a stato PATH associato alla sessione,
contenente: Phop (Previous hop), Sender_Tspec and Adspec
• Tspec: Ps, rs, max burst size, min policed unit, max packt size
• Adspec: Optional (e.g. Min Path Latency, Min Bdw, break bit, Hops, min
MTU)
• Re-inizializza il timer associato allo stato PATH (refresh)
• Aggiorna i campi Phop and Adspec ed inoltra il mesaggio PATH al
router successivo (eventualmente un router RSVP)
RSVP Procedures:Unicast Reservation
2nd step: messaggio RESV inviato indietro (upstream)
RESV
RSVP Enabled
Host (SND)
RSVP Router
RSVP Router
RSVP Enabled
Host (RCV)
Quando un router RSVP riceve il messaggio RESV:
• Legge i campi FlowSpec e Admission Control; se la richiesta è
accettabile è creato uno stato RESV e i campi Packet Classifier e
Packet Scheduler sono aggiornati
• Re-inizializza il timer associato allo stato RESV (refresh)
• Inoltra il messaggio RESV al nodo a monte (previous) nel percorso,
indicato dal campo Phop
Problemi di Scalabilità di RSVP
Esempio:
La codifica ADPCM genera flussi vocali di 32 kb/s. Senza
considerare altri overhead, una singola interfaccia OC-12 (622
Mb/s) nel backbone dovrebbe gestire 20000 flussi, ossia:
• il packet scheduler deve poter gestire 20000 code
• 20000 stati devono essere confermati periodicamente
Le applicazioni punto-punto narrowband (come la telefonia IP)
implicherebbero un elevato overhead di elaborazione nei router
una notevole quantità di traffico di segnalazione per i refresh.
Problemi di Scalabilità di RSVP
Soluzioni:
• Aggregazione dei flussi
• Limitare l’uso di RSVP limited alle reti IP di accesso
• Approccio
backbone
Differentiated
Services
(DiffServ)
nel
IETF - servizi differenziati (DiffServ)
Alcune problematiche associate a Intserv:
 Scalabilità
 Modelli di servizio flessibili
Approcci DiffServ (DS):
 Colloca alcune semplici funzionalità nel nucleo della
rete e implementa le operazioni di controllo (più
complesse) alla periferia.
DiffServ: Idee di base
The real question is to choose which packets shall be dropped. The
first definition of differential service is something like "not mine.”
-- Christian Huitema
 DiffServ fornisce la possibilità di specificare
la priorità relativa fra i pacchetti
 Alcuni dati sono piu’ “importanti” di altri
 Servizi migliori a pagamento
Obiettivi DS
 Possibilità di realizzare tariffazione
differenziata per servizi differenziati
 Introduzione di tecniche leggere e scalabili per
differenziare i servizi di rete nel backbone
 Assenza
di stati e/o segnalazione per
flusso
 Evoluzione encrementale
 Realizzazione
di un nucleo semplice
iniziale, da espandere in futuro se
necessario
Architettura Diffserv
Router periferico:
r marking
scheduling
 Amministrazione del traffico
per flusso.
 I pacchetti sono
contrassegnati dal profilo di
ingresso e dal profilo d’uscita.
Router principale:
 Amministrazione del traffico
per classe.
 È basato sulla marcatura del
pacchetto.
 Preferenza accordata ai
pacchetti in ingresso
 Inoltro assicurato.
b
..
.
Classificazione e condizionamento del
traffico
Meter
Classifier
Marker
Shaper/
Dropper
Campo ToS nell’intestazione IP
 Historical TOS
field (‘81)
Precedence
011
111 - Network Control
110 - Internetwork Control010
001
101 - CRITIC/ECP
000
100 - Flash Override
-
Flash
Immediate
Priority
Routine
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 |
|
|
|
|
|
|
|
+-----+-----+-----+-----+-----+-----+-----+-----+
<RFC-791>
Classificazione e condizionamento
del traffico Diffserv
 I pacchetti sono contrassegnati in base al tipo di
servizio (TOS) in IPv4, e in classe di traffico in
IPv6.
 6 bit sono usati per il DSCP (Differentiated
Service Code Point) e determinano il
comportamento per-hop (PHB )
 2 bit sono al momento inutilizzati.
Comportamento per-hop (PHB)
 PHB (per-hop behaviour) fornisce diverse
prestazioni a differenti classi di traffico. Le
differenze nelle prestazioni devono essere
osservabili e misurabili.
 PHB definisce diverse prestazioni per le classi, ma
non impone alcuna particolare procedura per
raggiungerle.
Per Domain Behavior (PHB)
DS interior node
DS boundary
DS boundary node
Un dominio DS domain è un insieme contiguo di nodi DS
operanti sotto la stessa politica di provisioning e PHB
implementati nei nodi  Per Domain Behavior (PDB)
 Il campo DS deve essere usato come indice a una tabella
 I campi DS sono mappati nei PHB disponibili in ogni nodo
 Un PHB è implementato mediante meccanismi interni al nodo
 I servizi sono esplicitati da PHB e PDB
 Si puo’ immaginare come la sovrapposizione di Internet
coesistenti e sovrapposte, ciascuna operante in modalità “best
effort”. Dati i diversi livelli di priorità, si puo’ parlare, quindi,
di servizi “better-than-best-effort”.
 ... ma senza GARANZIE!
Controllo di ammissione dinamico
Admission
Control
Server
Host
R
R
ED
RSVP based
access
networks
ED
DS-R
ED
DS-R
R
ED
R
ED
Diff-serv
cloud
ED
R
R
ED: Edge Device
DS-R Diff-Serv Router
R: RSVP capable router
User flows
SACP protocol
RSVP relationship
Proposte di Livelli di Servizio
 Assured Service (1 bit)
 Premium Service (1 bit)
 Two-bit Differentiated Services (RFC …)
Assured Service -
Dave Clark (MIT)
 Allocazione statistica delle risorse
 Risorse allocate sulla base del comportamento atteso degli
utenti
 Il traffico conforme (In profile) ha “bassa
probabilità” di perdita.
 I pacchetti non conformi (Out of profile) sono
trattati in modalità best-effort.
Definisce un servizio “better than best-effort”
Assured Service
Drop if congested
Uncongested
Congested
Assured Service
Premium Service -
Van Jacobson (LBL)
 Allocazione delle risorse conservativa
 In accordo al picco dei profili di traffico
 Sagomatura ai bordi per eliminare i picchi di traffico
 I pacchetti non conformi (Out of profile) sono
scartati.
Definisce una “virtual leased line”: banda di picco
prefissata e disponibile se necassaria.
Premium Service
Drop always
Fixed Bandwidth
Two-bit Differentiated Services
 Combina i servizi Assured e Premium
 I servizi Assured e Premium sono realizzati mediante
meccanismi simili
 Premium service, indicato dal P-bit
 Assured service, indicato dal A-bit
 Si possono considerare elementi di base per creare
diversi servizi
Funzionalità del Two-Bit Border Router
Premium Service
Token
Bucket
Wait
for
token
Packet Input
Set
P-bit
Packet Output
Data Queue
Assured Service
Packet Input
Token
Bucket
No token
Test if
token
Token
Set
A-bit
Packet Output
Data Queue
Funzionalità del Two-bit Internal Router
High Priority Queue
Packets In
P-bit
set?
Yes
No
Packets Out
Low Priority Queue
If A-bit set,
a_cnt++
If A-bit set,
a_cnt- -
RIO In/Out
Queue Management
Regione DiffServ
DS domain “A”
DS domain “B”
User
<-SLA->
<-SLA->
 Una regione DS è un insieme di uno o più domini DS contigui.
 I domini DS in una regione DS possono avere diversi PHB e
campi DS -> PHB mappings
 SLA (Service Level Agreement):
 Un contratto di servizio fra un utente e un service
provider che specifica il servizio di inoltro (forwarding
service) che l’utente dovrà ricevere.
 L’utente può essere una organizzazione (source domain) o
un altro dominio DS (upstream domain)
Regione DiffServ
 Gli SLA possono essere sia statici sia dinamci
 Possono essere rinegoziati periodicamente (giorni… settimane …)
 Possono specificare un servizio tempo variante (time of day)
 Gli SLA dinaminci possono variare frequentemente, ad esempio al
variare del traffico offerto o modifiche nelle strategie di
tariffazione dei provider
 Gli SLA dinaminci possono variare senza l’intervento umano.
Richiedono quindi degli agenti e dei protocolli in grado di agire
autonomamente (e.g. “Bandwidth Broker”)
 Si suggerisce che gli SLA facciano riferimento solo agli aggregati
di traffico, e non ai flussi individuali.
Commento …
… l’approccio basato sulla forza bruta, ossia sul
sovradimensionamento delle risorse di rete ha ancora
consensi…
Reti multimediali
 Applicazioni multimediali di rete
 Streaming memorizzati
 Utilizzo ottimale del servizio best-effort: la telefonia Internet
 Protocolli per applicazioni interattive in tempo reale:





RTP, RTCP, SIP
Reti per la distribuzione di contenuti multimediali
Oltre il best-effort
Scheduling e sorveglianza
Servizi intergrati e servizi differenziati
MPLS
“Label Substitution” cos’è?
Ci sono molto modi per andare da A a B:
•BROADCAST: andare ovunque e fermarsi quando si è
arrivati a B, senza chiedere informazioni.
•HOP BY HOP ROUTING: chiedere continuamente cosa
si trova più vicino a B, andarci e ripetere la cosa fin
quando si arriva a B.
“Per andare a B? Dovresti raggiungere X, che si trova sulla strada”.
•SOURCE ROUTING: chiedere una lista (da portarsi
dietro) di posti da raggiungere per arrivare a B.
“Per andare a B? Vai avanti per 5 isolati, girare a sinistra, procedere per
altri 6 isolati, girare a destra al semaforo…”
Label Substitution
Si supponga di avere un aiutante che ci precede verso B
usando una delle prime due tecniche precedenti. Per ogni
strada riserva una corsia. Ad ogni incrocio lascia
un’indicazione chiara sulla direzione da prendere e sulla
corsia riservata.
LANE#1 TURN RIGHT USE LANE#2
LANE#1
LANE#2
Idea di base
MPLS è un modello ibrido adottato da IETF che
incorpora le caratteristiche migliori delle trasmissioni a
circuito e a pacchetto (o cella).
IP Router
Control:
MPLS
Control:
IP Router
Software
IP Router
Software
Forwarding:
Forwarding:
Longest-match
Lookup
Label Swapping
ATM Switch
Control:
ATM Forum
Software
Forwarding:
Label Swapping
Idea di base (Cont.)
 I pacchetti sono commutati (switched), non instradati (routed), sulla
base di etichiette (label)
 Le label sono inserite nell’intestazione del pacchetto
 Operazioni di base:
 L’ Ingress LER (Label Edge Router) inserisce (push) una label
davanti all’header IP
 L’ LSR (Label Switch Router) sostituisce la label (swapping)
 L’ Egress LER rimuove (pop) la label
 La chiave di funzionamento è la costruzione della forwarding table
 Protocolli di routing Link state
• Scambio di informazioni fra i nodi sulla topologia della rete
• Es. OSPF-TE
 Protocolli di segnalazione e di distribuzione delle label
• Set up LSPs (Label Switched Path)
• LDP, RSVP-TE, CR-LDP
Una label può essere nota con un
nome diverso ...
• ATM – la label è nota come VPI/VCI, ed è presente nella
calla.
• TDM – la label è nota come timeslot its implied.
• WDM – la label è nota come lunghezza d’onda
Terminologia MPLS
 LDP: Label Distribution Protocol
 LSP: Label Switched Path
 FEC: Forwarding Equivalence Class
 LSR: Label Switching Router
 LER: Label Edge Router (Useful term not in
standards)
 CR: Constraint Routing
Funzionamento MPLS
1a. Protocolli di routing (es. OSPF-TE, IS-IS-TE)
scambio di informazione sulla raggiungibilità delle reti
1b. Label Distribution Protocol (LDP)
Realizza il mappaggio delle label fino alla destinazione
4. L’LER rimuove
le label dai
pacchetti uscenti
e li inoltra
IP
IP
2. L’ Ingress LER riceve i
pacchetti e li etichetta
3. L’LSR inoltra i
pacchetti e
sostituisce le label
Caratterisctiche essenziali
 Label swapping:

La commutazione è più veloce del routing
 Separazione dei piani di utente e di controllo
 Gerarchia di reti realizzabile mediante label stacking

Migliora la scalabilità
 Realizzabilità di instradamento vincolato
Traffic Engineering
 Fast reroute

 Facile realizzabilità di virtual private networks (VPNs)
 Possibilità di introdurre classi di servizio

Opportunità di mappare il campo DiffServ sulle
label MPLS
ROUTING AI BORDI, SWITCHING NEL
CORE
Impossibile v isualizzare l'immagine.
La memoria del computer potrebbe
essere insufficiente per aprire
l'immagine oppure l'immagine
potrebbe essere danneggiata.
Riav v iare il computer e aprire di
nuov o il file. Se v iene v isualizzata di
nuov o la x rossa, potrebbe essere
necessario eliminare l'immagine e
inserirla di nuov o.
IP
IP
IP Forwarding
#L1
Impossibile v isualizzare l'immagine.
La memoria del computer potrebbe
essere insufficiente per aprire
l'immagine oppure l'immagine
potrebbe essere danneggiata.
Riav v iare il computer e aprire di
nuov o il file. Se v iene v isualizzata di
nuov o la x rossa, potrebbe essere
necessario eliminare l'immagine e
inserirla di nuov o.
IP
#L2
LABEL SWITCHING
IP
#L3
IP
IP Forwarding
Forwarding Equivalence Class
LSR
LER
LSP
LSR
Impossibile v isualizzare l'immagine.
La memoria del computer potrebbe
essere insufficiente per aprire
l'immagine oppure l'immagine
potrebbe essere danneggiata.
Riav v iare il computer e aprire di
nuov o il file. Se v iene v isualizzata di
nuov o la x rossa, potrebbe essere
necessario eliminare l'immagine e
inserirla di nuov o.
LER
Impossibile v isualizzare l'immagine.
La memoria del computer potrebbe
essere insufficiente per aprire
l'immagine oppure l'immagine
potrebbe essere danneggiata.
Riav v iare il computer e aprire di
nuov o il file. Se v iene v isualizzata di
nuov o la x rossa, potrebbe essere
necessario eliminare l'immagine e
inserirla di nuov o.
IP1
IP1
IP1
#L1
IP1
#L2
IP1
#L3
IP2
#L1
IP2
#L2
IP2
#L3
IP2
IP2
I pacchetti sono destinati a doverso prefissi di rete, ma
possono essere mappati su un percorso comune.
• FEC = “Un sottinsieme di pacchetti trattati nello stesso modo dal router”
• Il concetto di FECs introduce flessibilità e scalabilità
• Nel routing convenzionale, ad ogni salto un pacchetto è assegnato a una
FEC (es. L3 look-up); in MPLS questo è fatto una sola volta all’ingresso
della rete
MPLS FA USO DI IP STANDARD
D est
4 7 .1
4 7 .2
4 7 .3
D est
4 7 .1
4 7 .2
4 7 .3
O ut
1
2
3
O ut
1
2
3
1 47.1
3
1
D est
4 7 .1
4 7 .2
4 7 .3
2
3
O ut
1
2
3
2
1
47.2
47.3 3
2
• Destination based forwarding tables as built by OSPF, IS-IS, RIP, etc.
L’ IP FORWARDING E’ USATO COME CONTROLLO HOPBY-HOP
D est
4 7 .1
4 7 .2
4 7 .3
D est
4 7 .1
4 7 .2
4 7 .3
O ut
1
2
3
1 47.1
1
D est
4 7 .1
4 7 .2
4 7 .3
O ut
1
2
3
IP 47.1.1.1
2
IP 47.1.1.1
3
O ut
1
2
3
2
IP 47.1.1.1
1
47.2
47.3 3
2
IP 47.1.1.1
MPLS Label Distribution
Intf Label Dest Intf Label
In In
Out Out
3
0.50 47.1 1
0.40
Intf
In
3
Label Dest Intf
In
Out
0.40 47.1 1
1
Request: 47.1
3
Intf Dest Intf Label
In
Out Out
3
47.1 1
0.50
3
2
1
1
47.3 3
47.1
Mapping: 0.40
2
47.2
2
Label Switched Path (LSP)
Intf Label Dest Intf Label
In In
Out Out
3
0.50 47.1 1
0.40
Intf Dest Intf Label
In
Out Out
3
47.1 1
0.50
2
2
47.2
2
IP 47.1.1.1
3
1
47.3 3
Label Dest Intf
In
Out
0.40 47.1 1
IP 47.1.1.1
1 47.1
3
1
Intf
In
3
EXPLICITLY ROUTED-LSP
Intf Label Dest Intf Label
In In
Out Out
3
0.50 47.1 1
0.40
I n tf
In
3
3
D est
4 7 .1 . 1
4 7 .1
In t f
O ut
2
1
Label
O ut
1 .3 3
0 .5 0
3
1
47.3 3
2
2
47.2
2
IP 47.1.1.1
Label Dest Intf
In
Out
0.40 47.1 1
IP 47.1.1.1
1 47.1
3
1
Intf
In
3
Vantaggi dell’ER LSP
•Flessibilità di routing per l’operatore (policybased, QoS-based), eventualmente diverso dallo
shortest path
•Possibilità di realizzare traffic engineering