Laboratorio telematico offerte tesi

Architettura di Conferenza Multimediale Internet

Domanda di finanziamento ricerca di Ateneo Anno: 2001 - prot. C26A011248

Responsabile della ricerca FALASCHI Alessandro

Inquadramento della ricerca proposta

Sebbene nata per la sola trasmissone dati, la rete Internet si puo' prestare altrettanto bene a servizi di comunicazione real-time, grazie agli sviluppi delle tecniche di codifica del segnale, di trasmissione, e di garanzia della qualita' di servizio.

Grande interesse deriva dalla prospettiva di una singola rete ubiqua, in grado di offrire non solo servizi di telefonia, ma anche video, strumenti collaborativi condivisi e, mediante il multicast, conferenze tra piu' parti e sessioni multimediali, di dimensioni che vanno da piccoli gruppi ad "audience" televisive.

Al di la' delle implicazioni socio-politiche di una tale liberizzazione, e di quali servizi eventualmente emergeranno, e' interesse strategico essere presenti sulla scena della sperimentazione internazionale delle tecnologie alla base di tale scenario evolutivo.

L'architettura di conferenza che sta evolvendo in internet e' ben piu' generale di quelle esistenti, ad esempio basate sulla rete telefonica, ISDN, o di video telefonia, essendo estensibile a gruppi molto estesi, e permettendo l'introduzione di nuovi media ed applicazioni non appena disponibili. Mentre le tecnologie esistenti prevedono trasmissioni replicate per ognuno dei destinatari, l'adozione di protocolli Multicast individua un approccio piu' efficiente alla trasmissione, ottimizzando l'uso delle risorse fisiche.

Il multicast e' attuato riservando ad esso una classe dello spazio degli indirizzi IP, non corrispondenti a macchine specifiche, ma su cui i ricevitori si pongono in ascolto, verso cui le sorgenti inviano i pacchetti, che i router "cospirano" a consegnare. I pacchetti viaggiano dunque in copia unica nella rete, finche' non si duplicano, qualora due diversi destinatari facciano capo a due diverse sottoreti. Da qualche anno e' iniziata una transizione nel protocollo di routing del multicast, che durante tutto lo sviluppo della cosiddetta MBONE si basava su di un paradigma di inondamento e recisione (il DVMRP). Il nuovo paradigma corrente (PIM-SM) costruisce invece esplicitamente un albero di distribuzione per i singoli gruppi, risparmiando ai router non interessati di elaborare il protocollo di controllo. Un tema di ricerca e' quello della allocazione degli indirizzi multicast, ed una soluzione promettente e' quella che fa capo alla definizione del BGMP (Border Gateway Multicast Protocol), che sfrutta una allocazione di indirizzi su base geografica per facilitare i compiti di instradamento.

Il problema della garanzia della qualita' di servizio, intesa come massimo ritardo dei pacchetti, prevede sia una soluzione (RSVP) basata sulla prenotazione delle risorse, sia una soluzione (DIFFSERV) fondata sul controllo di ammissione, da svolgere ai bordi della rete, e che consente l'adozione di accordi tra provider per assicurare la qualita' di trasmissioni che attraversano piu' reti. La sperimentazione di tali tecniche sulla rete scientifica di Ateneo e' uno dei prerequisiti fondamentali alla erogazione di servizi avanzati di teledidattica, particolarmente rilevante nel caso di poli distaccati come quelli di Latina e Civitavecchia.

Entrambi i metodi di prenotazione e di controllo ammissione, necessitano di meccanismi di reazione negativa per limitare il traffico a maggiore priorita'. Nel primo caso, il meccanismo puo' essere costituito da una tariffazione da imporre sul traffico, resa problematica dalla necessita' di coinvolgere tutti i nodi di transito. Il secondo caso permette invece di ricorrere a profili di utenza contrattati solo ai bordi della rete. Entrambe le soluzioni sono tuttora oggetto di studio.

Dal punto di vista del trasporto, i contenuti audio, video e di stato condiviso, viaggiano su connessioni logicamente separate; inoltre, uno stesso contenuto puo' essere trasmesso in diversi formati, eventualmente incrementali, per soddisfare le differenti capacita' elaborative e di connettivita' dei ricevitori interessati, che possono cosi' decidere quali flussi intendono ricevere. Per i flussi audio-video (real-time), il protocollo RTP compensa la variabilita' del tempo di consegna dei pacchetti, inserendo un ritardo fisso in ricezione. Il protocollo di controllo RTCP integra poi le informazioni temporali presenti nell'RTP con riferimenti assoluti, permettendo la sincronizzazione mutua dei diversi contenuti. Infine, le funzioni di rapporto della qualita' di ricezione dell'RTCP, permettono la stima grossolana del numero di destinatari di una emissione multicast, nonche' la modifica adattiva della velocita' di trasmissione in presenza di congestione di rete.

Dal punto di vista del controllo, occorrono meccanismi per rendere nota l'esistenza della conferenza, sia mediante delle directory, in cui un protocollo di annuncio (SAP) invia una descrizione (SDP) dei contenuti e dei formati, sia mediante un invito esplicito, come realizzato dal protocollo SIP o dalla raccomandazione H.323. Quest'ultimo caso ha pero' una applicabilita' ridotta al caso di conferenze strettamente controllate, mentre per il controllo di gruppi piu' estesi e liberali, viene proposto l'SCCP. Due ulteriori temi di ricerca connessi all'argomento sono: lo sviluppo del multicast affidabile, necessario per la propagazione dello stato condiviso relativo ad es. alle funzioni di editing cooperativo, ed il supporto delle funzioni di invito al caso di utenti mobili.

Per ultimo, sono citate le problematice di sicurezza ed identificazione, che consentono sia l'erogazione dei contenuti in forma crittografata, sia la distribuzione della chiave di decodifica a destinatari di cui e' certa l'identita'. Inoltre, le stesse tecniche sono adottate anche per proteggere trasmissioni multicast "in chiaro" dall'eventuale presenza di trasmissioni interferenti, incidenti sullo stesso canale multicast, e che possono essere rigettate dai destinatari, sulla base di meccanismi di firma digitale presenti nei pacchetti.

Sintesi del programma di ricerca e descrizione dei compiti dei singoli partecipanti

L'attivita' di ricerca intende affrontare molti dei temi esposti nella sezione relativa all'inquadramento, e dotare al contempo l'ateneo di tecnologie all'avanguardia per ciò che riguarda la possibità di dispiegare al meglio sulla rete le proprie competenze scientifiche.

Un prerequisito indispensabile allo svolgimento della ricerca, e' quello di realizzare un istradamento per il multicast all'interno dell'ateneo. Infatti al momento attuale gli indirizzi multicast non oltrepassano i router di frontiera, e non sono presenti elementi di tunneling verso router multicast esterni. Inoltre la rete GARR stessa, di cui l'ateneo fa parte, e' attualmente scollegata dal multicast internazionale, e supporta solo una circolazione muticast ristretta al territorio nazionale.

Il multicast internazionale e' invece presente presso il Cineca di Bologna, e per iniettarlo in una rete remota e' sufficiente configurare un tunnel PIM [rfc2362] tra questa ed il Cineca. Fortunatamente, il PIM e' attualmente implementato dal kernel di Linux, cosicche' e' sufficiente un comune computer ben equipaggiato per ricevere la programmazione erogata in multicast da tutta la comunita' scientifica mondiale. Per la configurazione e la manutenzione dell'instradamento, ci si intende avvalere della collaborazione di Marco Di Bonifacio, responsabile per la Facolta' di Ingegneria della sottorete di Via Eudossiana.

Per partecipare alle trasmissioni Multicast, e prendervi parte attiva, sono disponibili appositivi applicativi (VIC RAT SDR WB) sviluppati negli anni recenti presso il Dipartimento di Computer Science dell'University College di Londra, liberamente disponibili in rete sotto forma di codice aperto, che ben si presta pertanto alla sperimentazione di nuove soluzioni protocollari e di codifica, nonche' di nuove applicazioni.

Per erogare contenuti, occorre riservare un indirizzo (o canale) multicast, e dunque confrontarsi con le attivita' di ricerca legate appunto alle strategie di assegnazione dei canali, che seguono filosofie simili a quelle realizzate dai protocolli DHCP, con in piu' la possibilita' di suddividere ulteriormente lo spazio di indirizzamento sulla base della estensione geografica su cui la trasmissione verra' distribuita.

Soddisfatte tutte queste premesse, si e' finalmente in grado di svolgere la sperimentazione di maggiore interesse per l'ateneo, relativa alla presenza virtuale dei suoi docenti presso le sedi distaccate come ad esempio quella del polo di latina. A questo scopo e' necessario inoltrare il traffico multicast anche presso la sede del polo, utilizzando di nuovo un computer Linux come router PIM.

Il trasporto del traffico puo' avvenire in due diversi modi: il primo consiste nell'usare l'attuale connettivita' di rete, in modo da sperimentare immediatamente la tecnologia. Qualora pero' si passi ad un reale uso a fini di teledidattica, occorrera' garantirsi una idonea qualita' del servizio, e ricorre quindi a connettivita' indipendente (ISDN, ADSL o altro) tra i due siti, ed alla relativa configurazione di rete. Di nuovo, sara' fondamentale il contributo di Marco di Bonifacio.

Ora che l'architettura di riferimento e' completa, si puo' passare alla parte piu' interessante dal punto di vista della ricerca applicata. Come tutta l'evoluzione di Internet, e' solamente realizzando in prima persona i protocolli in via di sviluppo che si puo' prendere parte attiva alla sperimentazione e condurre una attivita' di ricerca densa di risultati scientifici. Per le attivita' elencate nel seguito, ci si intende avvalere di studenti collaboratori, tesisti e rapporti di collaborazione di ricerca.

Layering e sincronizzazione dei media

Una trasmissione multicast puo' prevedere diversi canali contemporanei, sui quali viaggiano rappresentazioni complementari della stessa trasmissione. In funzione della banda a disposizione, i destinatari possono scegliere di riceverne solo alcuni, oppure tutti, integrandone in modo sincronizzato i contenuti. E' questo un terreno di ricerca assai fertile, su cui condurre sperimentazione attiva.

Stima di share

L'attivita' di teledidattica puo' oltrepassare i confini delle sedi universitarie, e rivolgersi ad un pubblico ben piu' vasto, utilizzando gli appositi strumenti di annuncio sessione. Un campo di ricerca attivo e' la stima del numero approssimato di ascoltatori, realizzata per mezzo dei rapporti di qualita' prodotti dall'RTCP [rfc1889].

Protocolli di directory e di invito

I diversi soggetti interessati ad una emissione multicast, possono essere informati mediante un annuncio pubblicato su di una directory, come e' il caso per il SAP [rfc2974] associato all'SDP, oppure possono essere invitati esplicitamente a partecipare alla conferenza, come e' il caso di SIP [rfc2543] e dell'H323 dell'ITU-T. L'uso di una directory richiede di svolgere una attivita' promozionale preventiva, confidando che questa riesca a raggiungere gli interessati, ed e' indicata nel caso di un elevato numero di partecipanti. In caso contrario, e' invece preferibile ricorre a protocolli di invito, per i quali occorre disporre della lista dei soggetti da invitare.

Protocollo di Invito Sessione

Il SIP permette di creare, modificare e terminare sessioni multimediali con uno o piu' partecipanti, e consente la mobilita' di utente. Si basa sulla presenza in rete di diversi server SIP, che possono essere rintracciati mediante una estensione del tipo di RR (resource records) contenuti nei DNS. In tal modo per ogni utente internet, individuato dall'indirizzo email, e' definito il server SIP relativo. Qualora l'utente intenda poter essere invitato, registra la propria posizione effettiva presso il proprio server SIP, cosicche' un soggetto che intenda invitarlo puo' raggiungerlo, in base alle indicazione fornite dal server SIP. Questo gestisce quindi la procedura di instaurazione della chiamata, e puo' operare sia come proxy (ossia da intermediario), sia redirigendo l'invito direttamente all'utente. Un utente si puo' registrare sullo stesso server SIP a partire da piu' indirizzi, che posso essere invitati in parallelo dallo stesso server se operante come proxy.

Protocollo di descrizione Sessione

L'SDP [rfc2327] permette di descrivere le sessioni multimediali a fini di annuncio, di invito, ed altri scopi da definire. Essendo di utilita' molto generale, non fornisce supporto alla negoziazione dei contenuti, delle modalita di partecipazione e delle codifiche adottate, ne' assume ipotesi a riguardo del meccanismo di trasporto dei propri messaggi, che possono essere distribuiti via SAP, SIP, RTSP, e-mail e HTTP.

Qualita' del servizio

Viene attualmente realizzata mediante diverse tecniche, come ad esempio RSVP [rfc2210] e Multilink PPP Interleaving, che posso essere debitamente confrontate in termini di prestazioni e campi di applicazione. Il kernel di linux realizza inoltre diversi schemi di code con priorita', e di sagomatura del traffico, grazie ai quali sara' possibile sperimentare le tecniche tipiche delle politiche di servizio differenziato, oggetto di ricerca attiva a livello mondiale. In [sdp-qos] si discute come i requisiti di QoS possano definire delle precondizioni all'adesione delle sessioni descritte da SDP, richiedendo ai partecipanti di riservare le risorse di rete prima di continuare. La prenotazione rimane estranea ai protocolli di invito, ed e' attuata con i mezzi disponibili dall'utente, rendendo l'approccio aperto alle evoluzioni delle modalita' di garanzia della QoS. Questo da' luogo ad un meccanismo di instaurazione della chiamata a piu' fasi, assicurandosi che le risorse siano disponibili "prima che il telefono suoni".

Interlavoro tra H323 e SIP

Di questi due protocolli di invito, il primo e' gia' relativamente diffuso, mentre il secondo, associato all'SDP, ha caratteristiche di semplicita' e scalabilita' che lo rendono piu' promettente per l'uso generale. Entrambi fanno uso dell'RTP per trasferire i contenuti multimediali, e la compatibilita' tra i due si riduce semplicemente a tradurre i protocolli di segnalazione (Q.931, H.245 e RAS per l'H.323) e di descrizione di sessione (SDP per il SIP). Le funzionalita' di interlavoro tra i due protocolli di invito sono tuttora oggetto di dibattito, e giungeranno alla definizione di un oggetto "bilingue", presente in entrambe le "nuvole" di terminali-utenti che supportano i due diversi protocolli.

Controllo conferenza

L'attuale architettura di conferenza internet [confarch] prevede funzioni di controllo solo per conferenze "scarsamente accoppiate", del tipo "folla che si accalca attorno ad una attrazione". I meccanismi previsti dall'H.323 per imporre un controllo più rigoroso sui diritti e capacita' dei singoli partecipanti, sono limitati a conferenze a cui partecipano non piu' di qualche migliaio di soggetti, e sono quindi scarsamente scalabili alla dimensione di villaggio globale. Per questo motivo, si stanno attualmente definendo le specifiche dei servizi offerti da un futuro protocollo di controllo "semplice" di conferenza SCCP [sccp-01], che forniscono le funzioni di gestione dell'insieme dei membri, dell'insieme delle sessioni media e applicative che costituiscono la conferenza, e di controllo d'ambiente, che consiste nel definire un "conduttore" e/o nello stabilire regole di controllo di accesso per le risorse distribuite. Sono infatti definibili uno o piu' ambienti, per i quali accordare il controllo ad un unico partecipante od a piu' di essi, inibire a qualcuno l'accesso, rilasciare il controllo, cederelo, richiederlo o conoscerne il detentore. Inoltre, puo' essere necessario consentire a tutti i partecipanti la possibilita' di negoziare le risorse, in modo da garantire a tutti la ricezione dei contenuti; nel caso di sessioni invitate od annunciate, invece, chi e' sprovvisto delle risorse descritte dall'SDP non puo' far nulla per partecipare alla conferenza.

Editing cooperativo

Oltre alla trasmissione multimediale, il conferencing internet prevede anche l'adozione di strumenti di editing condiviso, che sopperiscono alle tradizionali lavagne delle riunioni fisiche. Mentre il contenuto multimediale e' trasportato in modo inaffidabile dall'RTP (i dati errati o mancanti vengono semplicemnete ignorati), la necessita' di mantenere uno stato condiviso tra i partecipanti pone l'interessante problema di realizzare un trasporto affidabile in ambito multicast.

Riferimenti

[rfc2362] - Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification, June 1998
[rfc1889] - RTP: A Transport Protocol for Real-Time Applications, January 1996
[rfc2974] - Session Announcement Protocol, October 2000
[rfc2543] - SIP: Session Initiation Protocol, March 1999
[rfc2327] - SDP: Session Description Protocol, April 1998
[rfc2210] - The Use of RSVP with IETF Integrated Services, September 1997
[sdp-qos] - draft-manyfolks-sip-resource-01.txt, June, 2000
[confarch]- draft-ietf-mmusic-confarch-03.txt, July 2000
[sccp-01] - draft-ietf-mmusic-sccp-01.txt, February 2001


alef@infocom.uniroma1.it; Fri May 11 17:14:27 2001