– pubblicazione – abbonamenti – responsabilit`a – fatturazione • supporto:
– alla rete tussle
– ai nuovi modelli di business
Infine, al pi`u alto livello `e localizzato il layer applicazione: le applicazioni saranno usate efficientemente dai servizi, dalle informazioni e dai fornitori di media e contenuti per l’architettura datacentrica ed offrir`a nuove esperienze media per gli utenti.
2.6
Architettura datacentrica autonoma
Dopo aver introdotto i componenti content, che possono essere generati e ricostruiti al volo e semanticamente arricchiti da mondi virtuali 3D al fine di creare una coinvolgente esperienza multimediale, ne espandiamo ulteriormente il concetto.
Un oggetto content (o semplicemente oggetto) `e un contenitore che pu`o essere costituito da mezzi di comunicazione, da norme, da comportamenti, da relazioni e da caratteristiche o da qualsivoglia combinazione di queste: [1]
• un media pu`o essere una qualsiasi cosa che un essere umano pu`o percepire e praticare con i suoi sensi
• le norme possono fare riferimento al modo in cui un oggetto viene trattato o manipolato da altri oggetti o dall’ambiente
• l’oggetto conosce il proprio scopo nell’esperienza multimediale integrata e quindi la sua priorit`a per il trasferimento
– potrebbero essere incluse anche le opzioni per la manipolazione da parte dell’utente finale al momento della presentazione
• il comportamento pu`o fare riferimento al modo in cui l’oggetto incide su altri oggetti o ambienti
• le relazioni tra due oggetti possono fare riferimento al tempo, allo spazio o problemi di sincronizzazione
• le caratteristiche descrivono il significato dell’oggetto e permettono di recuperare oggetti correlati
Gli oggetti possono essere organizzati gerarchicamente, come gli strumenti che costitui- scono una band, e possono innescare la generazione di nuovi oggetti.
Un oggetto pu`o essere diviso in oggetti nuovi o pi`u oggetti possono essere combinati e concentrati per creare nuovi oggetti e gestire i servizi: tutte queste operazioni possono accadere durante il viaggio attraverso la rete.
Un oggetto pu`o essere clonato, il clone mantiene le caratteristiche dell’oggetto principale ma sa che `e un clone: questo pu`o essere associato a problemi come l’incasso e la gestione dei DRM.
Gli oggetti autonomi viaggeranno attraverso la rete, si divideranno e si combineranno per creare nuovi servizi ed oggetti del mondo virtuale: attualmente `e molto difficile immaginare come sar`a un’architettura di rete che supporti oggetti.
Ecco un tentativo di mappare le caratteristiche di un approccio stratificato nel nuovo concetto layer-less di un oggetto, in cui uno o pi`u strati vengono mappati da una o pi`u caratteristiche dell’oggetto.
2.6. ARCHITETTURA DATACENTRICA AUTONOMA 33 Pi`u nello specifico, il trasferimento `e l’integrazione dell’oggetto ai fini della creazione di un orchestrata esperienza che chiaramente richiede un’intelligenza tale da combinare applicazioni e contenuti informativi.
L’intelligenza potrebbe essere inserita nell’oggetto stesso, recuperare informazioni nella rete fornendo istruzioni per il routing e per la trasformazione o l’intelligenza potrebbe essere ospitata nei nodi della rete che cercano di soddisfare le richieste degli oggetti come sono descritti nelle norme, comportamenti e relazioni.
Infine le caratteristiche descrivono in modo significativo l’oggetto da prendere, soprat- tutto l’input del layer “information / adaptation”.
Va notato che sia l’architettura datacentrica logica che autonoma forniscono una pro- spettiva olistica della visione di un internet datacentrico del futuro.
Oltre a servire le applicazioni esigenti del futuro in tempo reale, offrono anche la possi- bilit`a di ridurre in modo significativo le barriere e le limitazioni degli approcci esistenti nella gestione della rete.
Capitolo 3
DIFFERENTI APPROCCI
3.1
NDN ed il suo protocollo CCN
NDN (Named Data Networking) `e un’architettura completamente nuova in cui i principi di design sono derivati dai successi dell’internet di oggi che riflettono la conoscenza dei punti di forza e di debolezza dell’attuale architettura.
Vengono applicati sei principi guida per disegnare l’architettura NDN: i primi tre deri- vano dai successi dell’attuale internet, mentre gli altri tre da dall’esperienza fatta negli anni.
Figura 3.1: architettura internet e clessidra NDN [5] 35
L’architettura a clessidra `e proprio ci`o che fa diventare il design originale di internet elegante e potente in quanto `e tutto centrato attorno un livello di rete universale che implementa le funzionalit`a minime necessarie ad un’interconnettivit`a globale.
Questa “vita sottile” `e stata una chiave che ha attivato una crescita di internet cos`ı esplosiva in quanto ha permesso ai layer inferiori e superiori di portare innovazione ed il principio end-to-end permette lo sviluppo di applicazioni robuste per contrastare guasti di rete.
La separazione di routing e forwarding `e risultata necessaria nello sviluppo di internet in quanto permette al forward di funzionare finch´e il sistema di routing continua ad evolvere nel tempo. [5]
La sicurezza deve essere costruita nell’architettura: la sicurezza nell’attuale architettura di internet `e in ripensamento in quanto non accoglie la domanda di un ambiente sempre pi`u ostile; per questo NDN fornisce una sicurezza di base direttamente nella “vita sottile”. Il traffico di rete si deve auto-regolare perch´e una consegna equilibrata del flusso di dati `
e essenziale per avere operazioni di rete stabili e, dato che IP esegue la consegna dei dati in un loop aperto, i protocolli di trasporto sono stati migliorati per fornire un traffico unicast bilanciato: per questo NDN disegna il bilanciamento di flusso nella “vita sottile”. L’architettura dovrebbe facilitare le scelte degli utenti e la competizione ove possibile e, anche se non `e stata un fattore rilevante nel disegno originale di internet, gli sviluppatori ci dicono oggi che l’architettura non `e neutrale: ecco perch´e NDN fa uno sforzo per rafforzare gli utenti finali ed attivare la competizione.
Analogamente all’attuale architettura IP, la “vita sottile” `e il centro dell’architettura NDN, la “vita sottile” del NDN utilizza data name anzich´e indirizzi IP di consegna per offrire un nuovo set di funzionalit`a di base: questo, che sembra un semplice cambiamento, conduce a significative differenze tra IP e NDN nelle loro operazioni di consegna dati.
3.1. NDN ED IL SUO PROTOCOLLO CCN 37
Figura 3.3: nodo NDN [5]
La comunicazione in NDN `e guidata dal ricevente, infatti per ricevere il dato l’utente invia un pacchetto interest, il quale trasporta un nome che identifica il dato desidera- to: il protocollo di trasporto costruito su NDN viene chiamato CCN (Content-Centric Networking).
CCN non ha nozione di host nel suo pi`u basso livello, un pacchetto “indirizzo” indica il contenuto e non la posizione: il protocollo CCN consegna in modo efficiente il contenuto indicato anzich´e connettere un host ad altri host.
Tutti i pacchetti dati possono essere messi in cache in qualunque router CCN: ci`o, combi- nato con un intrinseco supporto alla consegna multicast o broadcast, porta ad un utilizzo molto efficiente della rete nel momento in cui molte persone sono interessate al medesimo contenuto.
Il servizio include multipli inoltri per consegne end-to-end, controllo di flusso, conse- gne multicast trasparenti ed automatiche utilizzando registrazioni in buffer disponibili nella rete, inoltri a pi`u percorsi esenti da cicli, verifica dell’integrit`a del contenuto con noncuranza del percorso di consegna ed una moltitudine di applicazioni arbitrarie.
Le applicazioni eseguono il protocollo CCN sopra a qualche servizio di comunicazione ad un layer pi`u basso capace di trasmettere pacchetti, non ci sono restrizioni nella natura del servizio: pu`o essere un trasporto fisico o un’altro protocollo di rete o trasporto. Ad esempio, le applicazioni tipicamente eseguiranno il protocollo CCN sopra ad UDP per trarre vantaggio della connettivit`a IP esistente: dato che il contenuto ´e indicato indipendetemente dalla posizione, potrebbe anche essere conservato indefinitamente nella rete fornendo efficacemente un servizio di filesystem distribuito.
Il protocollo CCN `e generico e supporta un ampio spettro di applicazioni di rete: potreb- be essere naturale pensare ad applicazioni con contenuto memorizzato come distribuzioni di file video o documenti.
Ma il modello CCN supporta anche comunicazioni in tempo reale, protocolli di ricerca ed `e abbastanza generico da trasportare conversazioni tra host come connessioni TCP (Transmission Control Protocol).
Il protocollo supporta un gran numero di applicazioni lasciando la scelta delle conven- zioni sui nomi alle applicazioni, le complete specifiche sull’uso del protocollo CCN per una particolare applicazione richiederanno specifiche addizionali sulle regole dei nomi, formato dati e semantica dei messaggi.
Queste specifiche sui protocolli applicazione sopra al protocollo CCN (unite probabil- mente alle specifiche API) sono chiamate profili.
Il protocollo CCN `e disegnato per comunicazioni end-to-end tra applicazioni e perci`o `e inteso per essere integrato nell’elaborazione dell’applicazione anzich´e essere implementato in un layer separato.