3
Introduzione
Le reti che basano il loro funzionamento sullo stack protocollare TCP/IP, se da un lato sono in grado di garantire un inoltro affidabile e ordinato dei dati, non sono altrettanto capaci di assicurare altre garanzie come banda e ritardo, richiesti da specifiche applicazioni in tempo reale per funzionare in modo corretto. In questo senso ci riferisce all’architettura IP come ad un’architettura best-effort. Sotto tale condizionamento allo stato attuale una rete di questo tipo riesce a supportare quasi esclusivamente applicazioni dati asincrone (web service, e-mail,
messaging ecc.) che richiedo unicamente garanzie di inoltro affidabile.
La rete Internet di prossima generazione (Next Generation Internet), anche nell’ottica di una sempre maggiore integrazione tra reti per dati e reti multimediali, dovrà essere in grado di fornire in misura sempre maggiore servizi integrati che prevedano il trasferimento in tempo reale di contenuti multimediali, come ad esempio servizi di videoconferenza, chiamate vocali (VoIP), streaming, ecc. L’erogazione di servizi di questo tipo richiede alla rete di fornire garanzie di Qualità del Servizio: con il termine Quality of Service (QoS) si intende una serie di parametri di funzionamento temporali (banda, latenza, jitter), misurati end-to-end, che la rete dovrebbe essere in grado di garantire a ciascuna applicazione, al fine di consentire agli utenti una fruizione corretta dell’applicazione stessa. Inoltre tali garanzie devono rispondere a criteri di affidabilità, termine con il quale si intende invece la capacità complessiva della rete di garantire i parametri di funzionamento necessari all’applicazione per tutta la sua durata, a discapito di eventi che potrebbero invece comprometterne la continuazione (ad esempio guasti, resource-contention con altre applicazioni, ecc.).
Nella presente trattazione si è preso in considerazione un servizio di streaming multimediale
on-demand, nel quale l’utente al lato client richiede la trasmissione unicast (streaming unicast) da un server remoto di un file multimediale che viene riprodotto in tempo reale al client. In questo scenario la rete deve essere in grado di garantire una connessione con banda
garantita end-to-end tra client e il server che sta erogando il servizio.
In caso di fault di rete (per esempio perdita completa della connettività dovuta a guasti, perdita delle garanzie di QoS sulla connessione, ecc. ) la rete stessa può mettere in campo tecniche di ripristino, tipicamente basate sul rerouting della connessione attraverso path alternativi, che ristabiliscono la connessione garantita end-to-end tra client e il server che eroga il servizio.
4
Servizio di streaming unicast con approccio client/server
Tuttavia in certe situazioni la rete nen è capace di trovare una connessione con le garanzie richieste tra server ed client a causa della presenza di altre connessioni a banda garantita. Se si considera la possibilità che nel dominio di rete sia presente una molteplicità di server in grado di erogare lo streaming dello stesso contenuto multimediale, e in cui ciascun client è in grado di ricevere il servizio da tutti i server, è possibile realizzare un ulteriore meccanismo di ripristino basato sulla così detta migrazione del server, che prevede che il client possa continuare a ricevere lo streaming da un altro server, se quello che lo stava fornendo non è più in grado di farlo, per motivi che possono essere legati al server stesso, ma anche alla rete. Naturalmente si tratta di una tecnica di ripristino che si colloca ad un livello superiore dello
stack protocollare rispetto alla rete e in particolare è strettamente legato all’applicazione.
5
Pertanto traspare che l’integrazione di tecniche di ripristino a livello di rete ed a livello superiore può contribuire ad una maggiore affidabilità complessiva nel servizio, nel senso che ciascuna di esse può essere utile qualora l’altra non sia in grado di ripristinar e correttamente il servizio.
L’integrazione di schemi funzionali di ripristino a livelli diversi dello stack protocollare, presentano quantomeno problematiche di coordinazione, nel senso che in mancanza di meccanismi di coordinamento efficaci, si potrebbero venire a creare nel sistema fenomeni di concorrenza tra le tecniche di ripristino ai diversi livelli, che se non adeguatamente controllate, portano il sistema a ritardare il recupero di uno stato funzionale corretto, se non addirittura alla deriva verso uno stato complessivo inconsistente.
Tale problematica è stata affrontate nella presente trattazione, che propone l’implementazione e la valutazione sperimentale di due diversi schemi di coordinazione e integrazione di tecniche di ripristino a livello di rete e di migrazione del server a livello di applicazione. Nel Capitolo 1 si sono presentate preliminarmente le richieste di QoS richieste dal servizio preso in esame, stabilendo che il servizio di streaming on-demand richiede alla rete l’allocazione di u na connessione a banda garantita tra server e client; quindi si sono esaminate alcune delle architetture che sono state proposte o standardizzate per garantire tali requisiti su reti IP. In sono state passate in rassegna le architetture IntServ e DiffServ, per poi soffermarsi in particolar modo sull’architettura MPLS -DiffServ.
Nel capitolo 2 si sono evidenziati gli eventi (fault) che possono causare il non corretto funzionamento del servizio, e richiedere perciò l’intervento di uno dei due meccanismi di ripristino. In particolare ci si è soffermati su fault localizzati sulla rete, i quali possono compromettere la possibilità da parte della rete di fornire con continuità le garanzie richieste dal servizio. In relazione all’architettura MPLS si è esaminato il funzionamento delle tecniche di path recovery dinamico, nei casi di fault di rete individuati. Infine si è affrontate le problematiche da risolvere nell’implementazione della migrazione del server, per poi riflettere su quali debbano essere i criteri di coordinazione tra le due tecniche, stabilendo di fa intervenire la migrazione solo qualora la rete non sia in grado di ripristinare il fault.
Il capitolo 3 presenta l’implementazione e la valutazione sperimentale di uno schema di migrazione coordinato con il livello di rete, in cui il client ricorre alla migrazione del server, qualora i parametri di QoS (throughput) rilevati sullo streaming rilevino un fault che la rete non è in grado di ripristinare. Ciò richiede unicamente di dotare l’applicativo al lato client, di estensioni per il supporto della migrazione; le modifiche proposte sono state implementate
6
sull’applicativo open-source VideoLAN Client. Inoltre si è fatto ricorso ad una configurazione statica della rete per tutta la durata del servizio, allo scopo di proporre un’implementazione snella, che non richieda l’adozione di meccanismi centralizzati. In questo approccio la coordinazione tra le tecniche di ripristino è data dai differenti tempi con i quali i due livelli rilevano il fault (fault detection). L’implementazione è stata sottoposta ad una serie di esperienze su un testbed MPLS-DiffServ che hanno mirato a valutarne la funzionalità. Nel capitolo 4 si presenta uno sviluppo con approccio integrato alla rete, introducendo una funzionalità centralizzata (il resource broker), la quale, operando da interfaccia tra servizio/applicazione e il piano di controllo di rete, consente la configurazione dinamica della rete durante il servizio, e in particolare durante la procedura di migrazione. Tale funzionalità centralizzata opera una coordinazione ottimale tra i due livelli e ottimizza l’utilizzo della rete da parte del servizio. Anche in questo caso si è proceduta alla validazione sperimentale dell’implementazione, con particolare attenzione alla procedura di s egnalazione coinvolta nella procedura di migrazione, nonché alla valutazione della sua durata temporale.
