Sistemi e servizi di telecomunicazione

12.1.3 Resource allocation

Le risorse devono essere allocate in modo intelligente dato che i vari ussi in input vengono multiplexati in un singolo usso in output. Ci sono due diversi modi di allocazione:

• deterministica: le risorse sono suddivise staticamente tra i diversi ussi in ingresso (nessuna perdita di pacchetti)
• statistica: le risorse vengono suddivise dinamicamente tra i ussi in base a criteri statistici (possibile perdita di pacchetti)

Nel caso dell'allocazione deterministica, vediamo due metodi:

• Peak allocation: viene utilizzata quando il usso di traco in entrata non è stato regolato da nessun regolatore. Ad ogni usso viene assegnata una porzione della capacità del link di uscita, pari alla velocità massima p.
• Ipotizzando ussi di

input omogenei (ovvero tutti al peak rate ) il massimo numero di ussi che possono essere multiplexati senza perdita è CN = p pˆ Dual Leaky Bucket allocation: viene implementato ponendo un TokenBucket in input ad un Leaky Bucket, seguiti da un multiplatore con buerB Cdi dimensione massima , ottenendo una capacità in uscita . La parterelativa alla coppia TB e LB (sorgente di traco) è modellata da tre pa-r B p > rrametri: token rate, dimensione del buer dei token e peaks ts s srate. DLB permette di ridurre la durata di burst e consente un'eca-B Cce allocazione deterministica se i parametri e sono opportunamenterdimensionati. Il TB regola la velocità di uscita con una certa tolle-sBranza che dipende dalla dimensione , mentre LB regola il peak ratets≤p r . DLB impone un limite alla quantità massima di tempo in cuis s pi pacchetti possono essere spediti alla velocità massima che è dato dasBT = L = Nts . Se è il massimo numero

permette di multiplexare più ussi in inputDLB rispetto al Peak allocation.

12.2 Scheduling

Le tecniche di Scheduling consentono di condividere la larghezza di banda tra i pacchetti che arrivano nelle code in input. Uno scheduler determina in che modo la larghezza di banda deve essere partizionata, mediante diverse strategie.

12.2.1 Time Division Multiplexing

Nel Time Division Multiplexing viene assegnato un slot di tempo per ogni coda disponibile e, in questo slot, vengono inviati pacchetti di quella coda. Se una coda è vuota, allora non viene inviato nessun pacchetto, avendo così banda inutilizzata.

12.2.2 Round Robin (Fair Queuing)

Nel Round Robin il funzionamento è simile al Time Division Multiplexing, con la differenza che non ci sono slot vuoti. Infatti, se per una coda non ci sono pacchetti da inviare, si passa direttamente alla coda successiva senza che ci sia banda inutilizzata.

12.2.3 Weighted Fair Queuing

Nel Weighted Fair Queuing si indica, in anticipo, quanti

pacchetti inviare perkogni coda ad ogni round. Quindi, ad ogni round, si inviano al massimo pacchetti di ogni coda in base a quanto indicato (e in base a quanti pacchetti ci sono disponibili per ogni coda). Anche in questo caso, non c'è banda inutilizzata.

12.2.4 Service Priority

Nel Service Priority si assegna, in anticipo, la priorità per ogni coda. Quindi, si inviano sempre i pacchetti della coda con priorità maggiore e, se questa non ha pacchetti da inviare, si passa alla coda successiva, e così via. Anche in questo caso, non c'è banda inutilizzata. Bisogna, però, impostare bene queste priorità per evitare che ci siano code che trasmettono con molto ritardo, in casi in cui le code con priorità maggiore continuano ad avere pacchetti da inviare. Un altro problema di questo approccio è la lunghezza dei pacchetti da inviare, infatti 25se durante l'invio di un pacchetto di una coda con priorità bassa arriva

Un pacchetto in una coda con alta priorità, si deve fare in modo che quest'ultima non debba aspettare troppo tempo prima di inviare il pacchetto: una possibile soluzione al problema è di suddividere i pacchetti della coda a bassa priorità in più parti. Chi si occupa di questa frammentazione non può essere IP, infatti solo il destinatario può ricompattare i pacchetti suddivisi da IP e, inoltre, la suddivisione massiccia da parte di IP potrebbe causare enormi inefficienze. Il livello 2, quindi, si occupa di questa frammentazione (protocollo Point-to-Point PPP).

12.3 Call Admission Control

Si tratta di un insieme di azioni intraprese da una rete durante la creazione o la rinegoziazione di una connessione, con l'obiettivo di determinare se la richiesta di connessione può essere accettata. Viene garantito che, per ogni collegamento, viene assegnato: una parte della larghezza di banda e una porzione di buffer nell'interfaccia di output del nodo.

Il soggetto che esegue la procedura CAC deve conoscere: la quantità di risorse necessarie per soddisfare adeguatamente la richiesta e la quantità di risorse attualmente utilizzate da ciascun collegamento/nodo (quindi, controlla se esiste un percorso con le specifiche desiderate e, se esiste, prenota queste risorse). Esistono tre modi per svolgere la procedura di CAC:

1. Modalità centralizzata: il CAC viene eseguito su un server centrale che riceve tutte le richieste e conosce tutte le informazioni necessarie per prendere le decisioni appropriate. Ha come vantaggi che la gestione delle segnalazioni risulta semplice e può essere determinato un percorso ottimale, ma ha come svantaggi che non è ben tollerato da IP e può causare problemi di scalabilità e adattabilità. Questa modalità può essere usata solo in piccoli sistemi di rete.
2. Modalità distribuita: ogni nodo è consapevole delle proprie risorse di rete occupate.

E contribuisce al CAC. Ha come vantaggio che è un sistema robusto e affidabile, ma ha come svantaggio che è un sistema complesso dove è necessario un complicato sistema di segnalazioni.

Modalità ibrida: il CAC viene eseguito dai router all'estremità della rete (Edge router) ed essi ottengono periodicamente informazioni sullo stato delle risorse di rete (informazioni derivanti anche dai Core router). Ha come vantaggio che il sistema risulta meno complesso (meno nodi coinvolti), ma ha come svantaggio che richiede, anch'esso, un complicato sistema di segnalazioni.

12.4 Integrated Services (IntServ)

IntServ è il primo modello di servizio progettato per fornire QoS nelle reti IP, utilizzando il protocollo RSVP per la prenotazione dinamica delle risorse del ussodi ciascun utente. La QoS è definita in termini assoluti mediante il meccanismo di Call Admission Control. IntServ offre due classi di servizio:

- Guaranteed Service: emula un servizio di

circuito con ritardi garantiti26€ Controlled Load Service: emula la modalità Best Effort ma in una rete non congestionata

Per IntServ i router devono subire delle modifiche sostanziali nella propria architettura.

RSVP viene utilizzato per scambiare, per una determinata richiesta di prenotazione e sul percorso prescelto, informazioni relative alla QoS e alle risorse da assegnare. Ogni router valuta autonomamente se la richiesta può essere accettata e, in caso affermativo, memorizzano le richieste accettate, in modo tale che la QoS possa essere garantita una volta che i flussi di traffico arrivano ad esso.

RSVP utilizza vari tipi di messaggi, ma i più importanti sono:

• messaggio PATH: serve per impostare il percorso su cui deve essere effettuata la prenotazione delle risorse. La sorgente invia un messaggio di PATH alla destinazione periodicamente, con lo scopo di rilevare possibili modifiche all'instradamento (in tal caso, la prenotazione delle risorse deve essere ripetuta sul

nuovo percorso). Ogni router che riceve un messaggio di PATH memorizza un path state (che farà riferimento ad uno specifico messaggio di PATH), che include: l'indirizzo dell'interfaccia precedente, parametri delle caratteristiche di usso e le interfacce di input e output locali. Un messaggio di PATH è formato da due oggetti:

TSPEC: consente di informare i router sulle caratteristiche del usso e contiene una descrizione del traco generato dalla sorgente (ad esempio, i parametri del Token Bucket), non può essere modicato dai router

ADSPEC (opzionale): raccoglie informazioni preliminari sulla QoS che può essere garantita sul percorso e viene esaminato e, eventualmente, modicato ad ogni hop. Vengono quindi sintetizzate le informazioni sulla QoS ottenibile sul percorso (come, ad esempio, la presenza di router non RSVP compilant)

messaggio RESV: la destinazione genera un messaggio di RESV verso la sorgente per effettuare richieste di prenotazione delle risorse.

Questo messaggio segue lo stesso percorso che ha seguito il messaggio di PATH (tramite l'instradamento source-based), le informazioni necessarie per poter seguire lo stesso percorso sono contenute nel messaggio di PATH. Sulla base dei campi TSPEC e ADSPEC, il destinatario determina quale richiesta di prenotazione delle risorse deve essere effettuata. Un messaggio di RESV è formato da un oggetto chiamato FLOWSPEC (che specifica la prenotazione di risorsa da effettuare), il quale è formato da due oggetti: