|
PREMESSA
- Nel preparare
un contributo all'interno di questo quinto Quaderno del Charter Italiano
dell'Internet Society desideravo considerare uno degli aspetti fondamentali
della maturazione dell'architettura di Internet che potesse stimolare nel
lettore una riflessione sulla contrapposizione tra approcci evoluzionistici
ed a "tabula rasa" (o "clean slate") recentemente proposti
come prospettive portanti antitetiche nello sviluppo di un'internetwork
di prossima generazione.
- Ho scelto a
questo proposito il tema del supporto della Qualità del Servizio
in reti a commutazione di pacchetto fondate sullo stack TCP/IP. L'intento
non è tanto quello di entrare in aspetti tecnici di dettaglio quanto
di porre all'attenzione di chi legge il classico esempio di "patchwork/bugs
fixing" che in generale caratterizza gli sviluppi di questa importantissima
infrastruttura.
- Processi "evoluzionistici"
dello stesso tipo potrebbero essere messi in evidenza anche per moltissime
altre tematiche chiave nel funzionamento della rete: supporto alla mobilità,
multicasting, sicurezza, affidabilità e, con sempre maggiore interesse,
aspetti relativi alla riduzione dei consumi energetici in rete (green networking).
- Credo che l'analisi
condotta su uno di questi specifici argomenti possa quanto meno suscitare
un po' di curiosità relativamente ad approcci drasticamente alternativi
incentrati sulla totale ridefinizione delle funzionalità fondamentali
della rete validabili, come ai tempi di Arpanet, mediante la realizzazione
di nuovi trial sperimentali (possibilmente realizzati su vasta scala) che
consentano il confronto tra soluzioni "tabula rasa" alternative.
- Per i super
appassionati all'immutabilità dello stack TCP/IP preciso subito
che nessuna di queste proposte "clean-slate" desidera "togliere
di mezzo" l'Internet attuale per sostituirla con qualcosa d'altro
quanto piuttosto di riuscire ad affiancare, stimolati da un processo di
ingegnerizzazione basato su una solida base metodologica soluzioni alternative
che potrebbero risultare più adatte all'evoluzioni di particolari
classi di servizi ubiqui, pervasivi, multimediali, interattivi dei quali
ancora non abbiamo perfettamente definito lo sviluppo.
1.
CARATTERISTICHE FONDAMENTALI DELL'INTERNET ATTUALE E PROPOSTE "CLEAN
SLATE" NEL PASSATO
2.
PARADIGMI PORTANTI DI UNA ARCHITETTURA DI RETE A COMMUTAZIONE DI PACCHETTO
"ALLA INTERNET"
- Per poter descrivere
in che modo le lezioni del passato abbiano influenzato lo sviluppo delle
soluzioni di trasporto di IP con Qualità del Servizio è necessario
soffermarsi su alcune delle "filosofie di base" su cui si sono
fondate le successive evoluzioni della rete. IP (l'Internet Protocol) è
un modo particolare [6] di istanziare l'idea della comunicazione
a commutazione di pacchetto in modalità datagram molto adatta alla
comunicazione tra sorgenti VBR (variable bit rate) che non richiedano particolari
requisiti prestazionali nel trasporto da nodo e nodo della rete.
- Esso rappresenta
il collante universale con cui poteva essere realizzato un'internetwork
globale: la definizione di un'unità informativa "incapsulabile"
(imbustabile) in qualunque campo "body" [7] delle "trame
di lunghezza variabile" trasferite dalle diverse specifiche tecnologie
di rete (es. trame Ethernet piuttosto che quelle di una rete satellitare,
Wi-Max o in tecnologia optical burst switching).
- Questa nuova
unità informativa, denominata datagramma, doveva essere gestibile
dal componente per l'internetworking che opera a livello "rete"
denominato "Router".
- Come dice la
parola le funzioni più sofisticate di questo componente non sono
solo relative al "forwarding" ovvero alla sua capacità
di spostare informazione da una certa porta di ingresso ad una determinata
porta di uscita ma al "routing" ovvero alla scelta del percorso
"più adeguato" per raggiungere una certa sottorete di
Internet (a cui ovviamente apparterrà il destinatario del datagramma
inviato).
- Il router è
il vero elemento collante. Il datagramma IP ne consente l'azione di "integratore"
rendendo visibile da una molteplicità di tecnologie di rete eterogenee
(ciascuna spesso caratterizzata da propri "modi di trasporto"
dell'informazione) un'unica rete "logica", "astratta"
che nasce dall'interoperabilità offerta da questi apparati di Internetworking.
- Le filosofie
fondamentali sono sostanzialmente tre:
- a) mantenere
la complessità possibilmente sulla periferia della rete (meglio
se negli end-system ovvero nei computer di qualunque tipo usati come dispositivi
terminali della rete)
- b) risolvere
l'annoso problema del controllo della congestione, che rappresenta sempre
il rovescio della medaglia del meraviglioso [8] mondo della multiplazione
statistica (su cui si basa la commutazione di pacchetto), end-to-end (in
particolare grazie a funzionalità a livello 4 implementate nel TCP)
- c) dividere
il complicato problema del routing in più sottoproblemi (routing
ottimo [9] intradominio, routing subottimo [10] interdominio)
- Il modo di trasporto
Datagram è connection-less cioè non orientato alla connessione
(non è cioè necessario far precedere una fase di allestimento
di una connessione ad ogni sessione di traffico che attraverserà
la rete nè l'abbattimento della connessione stessa al termine della
sessione [11]).
- Ogni unità
informativa è completamente a se stante rispetto alle altre e questo
talvolta permette che, in corrispondenza di una certa sessione di traffico
end-to-end, alcuni datagrammi seguano un certo percorso in rete mentre
altri, pur appartenenti alla stessa sessione seguono percorsi alternativi
[12].
- Il miglior pregio
di Internet (o più correttamente del modo di trasporto in modalità
datagram connectionless impiegato in Internet) è anche il suo peggior
difetto.
- Esso consente
l'interoperabilità tra reti realizzate in tecnologie eterogenee
ma non si cura in alcun modo delle garanzie prestazionali che ciascuna
tecnologia di rete potrebbe offrire nè tanto meno di sfruttarle
al fine di ottenere prestazioni garantite da estremo ad estremo della rete.
3.
LA PROPOSTA INTERNET INTEGRATED SERVICES
- Nella definizione
del formato del datagramma IP si può osservare come ben 8 bit dell'intestazioni
siano stati riservati al Type of Service. In perfetta sintonia con il modo
connection-less si era pensato che pacchetto per pacchetto si sarebbe potuto
affrontare il problema di un forwarding differenziato di ogni singolo datagramma
(opportunamente marcato nel suo campo ToS).
- Ma, come vedremo
tra breve, non si trattava di definire solo una nuova funzionalità
del router che consentisse questa diversificazione nel trasporto dell'informazione
quanto la definizione di una nuova [13] vera e propria architettura
della rete.
- Per architettura,
è bene precisarlo da subito, non si intenderà esclusivamente
l'insieme delle funzioni relative ad un trasporto differenziato dell'informazione
dell'utente (privilegiando flussi caratterizzati da certe garanzie prestazionali
rispetto agli altri) quanto piuttosto la definizione oltre a queste funzionalità
fondamentali delle componenti relative al piano di controllo della rete
(segnalazione) ed alla sua gestione (management).
- È una
lezione imparata dagli sviluppi della rete ISDN (Integrated Services Digital
Networks) e non a caso che questa prima proposta per l'Internet dei servizi
interattivi multimediali integrati è stata denominata Internet Integrated
Services.
- Il nome di questa
architettura (sinteticamente citata come IntServ) non deve però
far pensare ad una "replica a pacchetto" delle soluzioni proposte
a livello ITU-T.
- È interessante
comprendere quali dovessero essere gli aspetti fondamentali su cui fondare
la proposta di una Internet capace di offrire una qualità di servizio
differenziata da estremo ad estremo della rete. Certamente nei singoli
nodi/dispositivi dell'internetworking (router IntServ) sarebbero stati
necessarie delle funzionalità di scheduling (discipline di servizio
in sistemi a coda multipla) in grado di privilegiare certe classi di traffico
rispetto ad altre.
- Quando si pensa
a servizi di trasporto differenziati immediatamente si pensa ad uno scheduler
a priorità. In realtà questa ipotesi è spesso non
adatta ad essere impiegata in apparati reali perché "manda
in stallo" le classi a priorità più bassa nel caso siano
sempre presenti flussi di traffico a maggiore priorità.
- Lo scheduler
è certamente uno dei mattoni fondamentali nella realizzazione di
un router in grado di offrire un "forwarding" differenziato per
le diverse classi di traffico.
- Da router banalmente
first-in-first-out "alla Internet tradizionale" nell'architettura
Intserv si è cominciato ad ipotizzare l'idea di apparati che per
ogni singola porta di uscita potessero prevedere più sistemi a coda
serviti opportunamente da scheduler di pacchetto in grado di privilegiare
certi flussi di traffico rispetto ad altri.
- Ma cosa si voleva
ottenere? Certamente un numero di classi di servizio facilmente adattabili
ad una molteplicità di contesti applicativi ma anche facilmente
comprensibili. Sono state così definite la classe priva di garanzie
prestazionali (che ottiene le risorse che "restano disponibili")
e la classe di servizio "time-bounded" capace di offrire una
sorta di emulazione di circuito end-to-end dove oltre alla bit rate era
possibile garantire un ritardo massimo di attraversamento della rete. La
prima categoria venne denominata "guaranteed services" la seconda
"best effort" [14] .
- Venne introdotta
però un'altra categoria denominata "controlled load" interpretabile
come segue. Essa corrispondeva alla classe di traffico "better than
best effort" che avrebbe potuto, qualora non sopraffatta dalla classe
guaranteed services, offrire una tipologia di servizio corrispondente ad
una rete "best effort" scarica (capace cioè di sentirsi
"non congestionata" dalla classe best effort).
- Si evidenzia
in questa proposizione un aspetto fondamentale nel funzionamento della
rete e nella proposta di nuove funzionalità in grado di differenziare
il traffico in reti IP. Le soluzioni di forwarding differenziato entrano
in gioco quando le risorse vengono congestionate. In una rete scarica end-to-end
non c'è alcun bisogno di preoccuparci di servire in modo differenziato
le diverse classi di traffico.
- Tutte le classi
riescono (almeno a livello di throughput) ad ottenere il servizio di cui
hanno bisogno (e talvolta anche la packet loss rate, il ritardo end-to-end
ed altre rilevanti metriche prestazionali risultano soddisfacente per una
vasta classe di servizi).
- Nel definire
la prima architettura Intserv gli ingegneri di Internet si preoccuparono
dell'esistenza di tale classe (la classe che corrisponde all'Internet scarica)
perché sanno bene che la visibilità di una Internet scarica
avrebbe potuto soddisfare un sacco di applicazioni (quelle non proprio
completamente "elastiche" ma real-time "tolleranti e adattative").
- L'aspetto però
certamente più significativo dell'architettura Intserv era relativo
al fatto che l'offerta di un servizio differenziato avveniva per singolo
flusso [15] d'utente grazie ad un'azione di segnalazione che, direttamente
dall'applicazione avrebbe dovuto richiedere una qualità del servizio
adeguata a tale flusso.
- L'approccio
è stato certamente originale. Non si voleva in alcun modo riproporre
l'idea di una "connessione", come nella modalità a circuito
virtuale, quanto piuttosto una soluzione "soft state" che sulla
segnalazione dell'applicazione impiegata dall'utente finale producesse
l'allestimento di code multiple all'interno dei nodi, dimensionando opportunamente
i parametri di servizio (propri degli scheduler) atti ad offrire la qualità
del servizio desiderata.
- Internet scopre
la segnalazione: essa matura non solo nel piano dati (azioni di forwarding
differenziate) ma anche nel piano di controllo (fino ad allora limitato
all'azione di "advertising" dei protocolli di routing ed a qualche
error reporting protocol come ICMP).
- Il nuovo protocollo
adottato per la segnalazione in reti Intserv fu RSVP (Resource Reservation
Protocol). È interessante osservare però che sia l'azione
dello scheduler che del protocollo di segnalazione che avrebbe dovuto indicare
nodo per nodo la parametrizzazione del servizio per quel flusso al fine
di ottenere certe prestazioni end-to-end passava necessariamente attraverso
l'esigenza di "caratterizzare il flusso", "quantificare
le prestazioni attese" e "parametrizzare" le diverse funzionalità
della rete al fine di ottenere quelle prestazioni.
- Come si può
facilmente immaginare, confrontando questa proposta con la rete "real-time"
per antonomasia (quella tradizionale di tipo telefonico) risultava certamente
molto più facile accogliere una telefonata in più su una
rete a commutazione di circuito dove per ogni connessione si alloca sempre
la stessa aliquota di risorse (ad esempio un circuito bidirezionale a 64
Kbit/s) rispetto a dover allocare le risorse ad un flusso VBR (variable
bit rate), possibilmente caratterizzabile nel modo più parsimonioso
possibile [16].
- Ecco evidenziato
un altro aspetto fondamentale: l'esigenza di una nuova ingegneria del traffico
(intesa nel senso più nobile del termine) da svilupparsi per poter
stabilire a priori se accettando la nuova sessione di traffico non solo
quest'ultima possa ottenere le prestazioni attese ma anche che le altre
sessioni di traffico in corso non debbano venir disturbate.
- L'impostazione,
ancorché di tipo soft-state, apriva in questa prima fase di un processo
evolutivo tutta una serie di aspetti che non avevano molto a che fare con
il tradizionale modo di vedere la rete (neutrale, totalmente condivisa,
ecc).
- Senza entrare
in alcun dettaglio su queste diatribe (certamente molto importanti ed affrontate
con grande serietà anche in ambito ISOC) si vuole osservare che
in questo caso per la prima volta abbiamo una rete che può rifiutare
una sessione di traffico; una rete per la quale sarà necessario
definire degli opportuni SLA (Service Level Agreement) con l'utente finale.
Una rete molto più matura sia sul piano di controllo che sul piano
dati (e conseguentemente che avrebbe dovuto maturare moltissimo sul piano
del Network Management).
- È però
significativo l'approccio: si tengo fissi i caposaldi (gli elementi portanti)
che caratterizzano le fondamenta dell'architettura mentre nuove funzionalità
aggiuntive (patch) vengono aggiunte al fine di trasformarne la natura in
modo talvolta piuttosto rocambolesco.
- Per completare,
in modo molto sintetico, questa prima fase dell'evoluzione di IP che ha
portato alla proposta Intserv, è necessario considerare oltre agli
scheduler ed a nuovi meccanismi di segnalazione due fondamentali componenti
dell'architettura:
- a. il policer
(poliziotto del traffico) che in modo molto semplice deve poter essere
in grado di verificare la conformità del traffico (singolo flusso)
alla parametrizzazione dichiarata dall'utente
- b. il Call Admission
Control che deve poter essere in grado di accettare o rifiutare una connessione
conformemente allo stato della rete, alle prestazioni attese, alla caratterizzazione
del traffico
- Viene introdotta
la nuova segnalazione RSVP ma nei pacchetti di segnalazione devono transitare
in modalità soft-state (e quindi con pacchetti che periodicamente
vengono inviati dal nodo sorgente al destinatario) i parametri che caratterizzano
il traffico e le prestazioni attese (in particolare per la classe Guaranteed
Services).
- Il termine Ingegneria
del traffico esiste ormai da quasi 100 anni e le teorie matematiche impiegate
dagli studi di Erlang sulla rete telefonica alle generalizzazione di Kleinrock
(primo ricercatore ad occuparsi dei nuovi approcci matematici necessari
al dimensionamento ed alla valutazione delle prestazioni di una rete a
commutazione di pacchetto come Arpanet di cui la sua UCLA fu il primo nodo)
non sono state assolutamente adatte ad affrontare il problema della previsione
"a priori" del funzionamento della rete.
- Non solo non
si dovevano considerare le valutazioni "a regime" di certe grandezze
ma neppure sarebbe stato di grande interesse valutare i loro valori medi
di tali quantità (alcune sessioni avrebbero potuto avere una durata
molto limitata non consentendo di giustificare in ogni caso la condizione
di "equilibrio statistico" del sistema e, più che i valori
medi, quello che interessava erano i valori massimi di grandezza quali
il ritardo di attraversamento della rete ed il jitter o variazione del
ritardo).
- La matematica
che ha rappresentato il fondamento metodologico degli ultimi 100 anni della
rete telefonica non era adatta all'ingegneria del traffico da impiegarsi
nella rete a commutazione di pacchetto. Sono stati proposti metodi alternativi
al tipico approccio "probabilistico" (basati cioè su una
modellistica stocastica del processo di arrivo del traffico e delle lunghezze
dei singoli pacchetti) passando a metodi di tipo "deterministico"
dove cioè si andavano ad ottenere delle valutazioni di worst-case
che avrebbero potuto in qualche modo dare un idea sui limiti superiori
(massimi) di certe grandezze.
- Dai sofisticatissimi
modelli di traffico impiegati anche in ambito ATM (alcuni addirittura di
tipo "frattale-stocastico") si è passati ad approcci deterministici
orientati alla ricerca di curve "estremanti" tipicamente ricondotte
a caratterizzazioni corrispondenti rette "massimanti" che si
mantenevano cioè al di sopra dell'aliquota di traffico prodotto
dalla singola sorgente.
- Poichè
una retta può essere perfettamente identificata da due parametri
(l'intercetta con l'asse delle ordinate e la sua pendenza) così
il traffico è stato caratterizzato, in questi approcci di tipo deterministico,
da quella che si chiamò parametrizzazione LBAP (Linear Bounded Arrival
Process).
- Modellizzazione
perfetta per essere controllata da policer piuttosto semplici realizzati
con algoritmi che vennero denominati Token Bucket.
- Ce l'avevamo
fatta! La rete Internet (a patto che ovviamente a livello sottostante le
tecnologie reali di trasporto dell'informazione fossero state all'altezza
di offrire adeguate garanzie prestazionali) poteva finalmente trasformarsi
in un Internetwork in grado di offrire le prestazioni attese anche dai
più critici servizi multimediali interattivi, quelli real-time intolleranti.
- E invece Intserv
fu un flop colossale! Non passò più di un paio d'anni che
tutta la comunità tecnico scientifica internazionale cominciò
a gridare alla mancanza di scalabilità.
- La nuova architettura
di rete secondo gli esperti non avrebbe retto alla crescita vertiginosa
del numero di flussi che avrebbero attraversato ciascun nodo. Non si sarebbe
stati in grado di gestire nè il forwarding né il processing
di scheduling necessario per sistemi a code multiple dove, come già
detto, tutto doveva essere gestito per singolo flusso.
- Ma quanti sarebbero
stati i flussi davvero da gestire con code multiple all'interno dei nodi?
Quanti i flussi caratterizzati da prestazioni differenziate 100, 1000?
Nessuno lo riuscì a scoprire perché Intserv è stato
abbandonato molto prima che esperienze "in the large" potessero
essere condotte.
- Questo non ha
però escluso che moltissimi laboratori di ricerca, soprattutto in
ambito universitario, si dedicassero alla prototipizzazione di router Intserv
o addirittura (come nel caso dei nostri laboratori) alla realizzazione
di router Intserv over ATM !
- È interessante
osservare come, a quel tempo, i costruttori di router iniziassero ad introdurre
gradualmente nei propri apparati tutti i mattoncini elementari corrispondenti
alle nuove funzionalità previste dall'architettura Intserv, senza
invece preoccuparsi di rendere ciascun apparato perfettamente integrato
all'architettura proposta ed alle nuove funzionalità di management
richieste.
- Al contrario
in ambito ricerca, e proprio in analogia alle prime pionieristiche fasi
di sviluppo di Arpanet in cui un computer general purpose gradualmente
si trasformo' in quello che sarebbe diventato l'antenato di un router,
anche in questa fase si cominciò ad assistere a sviluppi di Software
Router [17] realizzati con esplicito riferimento alla proposta Intserv
e non genericamente in grado di offrire alcune delle funzionalità
fondamentali che sarebbero state utili anche per questa particolare proposta.
- Ma la lezione
più importante della crisi di Intserv non fu solo la mancanza della
scalabilità delle funzionalità richieste all'interno del
nodo (e forse anche della segnalazione per flusso) quanto l'idea che ogni
singola applicazione avrebbe dovuto dichiarare mediante una segnalazione
RSVP sia le caratteristiche del traffico trasmesso sia le prestazioni attese
(almeno nel caso guaranteed services).
- Questo era un
aspetto fondamentale del requisito end-to-end offerto dall'architettura
Intserv requisito per certi versi analogo all'insuccesso di ATM sul desktop
o "a livello nativo".
- I dispositivi
multimediali e tutti i computer del mondo avrebbero forse potuto inviare
cellette ATM ma certamente i programmatori di applicazioni avrebbero detestato
di dover conoscere i dettagli relativi alle modalità di segnalazione
che avrebbero permesso alla rete di allocare le risorse giuste per quel
tipo di traffico generato dall'applicazione.
- Mille volte
meglio il buon vecchio TCP che produce un traffico che non ha nessuna natura
stocastica intrinseca. Mille volte meglio la sorgente "adattativa"
che si strozza da sola se la rete si congestiona e "spinge sul gas"
se la rete torna ad avere risorse disponibili.
- Il programmatore
non si preoccupa di nulla. La rete fa del suo meglio. La rete resta Best
Effort e, qualora scarica, riesce a trasferire qualunque tipo di traffico
anche quello di tipo multimediale interattivo.
4.
LA PROPOSTA INTERNET DIFFERENTIATED SERVICES
- Verso la fine
degli anni '90 venne introdotta una architettura di supporto della qualità
del servizio in Internet per molti aspetti molto più grezza della
proposta Intserv denominata Diffserv (Internet Differentiated Services).
- Senza entrare
anche qui in alcun dettaglio, pur mantenendo i mattoncini elementari nel
supporto della qualità del servizio già visti per Intserv
(scheduler, code multiple, policer, ma anche Active Queue Management e
shaper di cui non si è parlato) l'idea fondamentale è stata
quella di offrire servizi di trasporto differenziati edge-to-edge.
- Non doveva minimamente
essere più l'utente finale a doversi occupare di dichiarare per
singolo flusso le prestazioni desiderate o le caratteristiche del traffico
ma sarebbero stati i nodi della rete ad aggregare più flussi in
un unico torrente di pacchetti che sarebbe stato gestito in modo differenziato
rispetto ad altri aggregati.
- Quanto omogenea
potesse essere questa aggregazione è sempre rimasto un problema
aperto. Certo però che al primo edge router capace di gestire un
forwarding differenziato i flussi sarebbero stati classificati e marcati
(naturalmente proprio sul campo ToS) al fine di farli appartenere ad un
numero modesto di aggregati di traffico gestiti in modo diverso uno rispetto
all'altro.
- Da un numero
molto elevato di classi distinte si scese rapidamente ad una dozzina o
poco più di alternative possibili. Il numero di classi (denominate
PHB o Per Hop Behaviour) non richiese di utilizzare tutti i bit del campo
ToS ma soltanto i primi 6.
- La classe di
default (Best Effort) corrisponde alla configurazione di tutti i 6 bit
a zero. La classe cui corrispondeva l'azione di forwarding (PHB) più
privilegiato venne denominata Expedited Forwarding (configurazione 101110).
- Essa corrispondeva
alla classe non solo a banda garantita ma anche caratterizzata da low loss,
low delay e jitter. Vennero inoltre definite 4 gruppi di classi (più
correttamente PHB) denominate Assured Forwarding (AF) [18] .
- Ogni gruppo
era diviso in sottoclassi ciascuna delle quali caratterizzata da una diversa
drop precedence (es. AF23 è la sottoclasse del gruppo AF2 caratterizzata
dalla più elevata probabilità di scarto).
- Le quattro classi
richiedevano ciascuna una singola coda all'interno delle quali la drop
precedence veniva selezionata con opportuni algoritmi di Active Queue Management
(AQM) producendo così nel complesso 12 diversi possibili trattamenti
differenti del traffico.
- Spesso al fine
di evidenziare che questo modello di supporto di servizi differenziati
in Internet non corrisponde ad un'architettura in grado di offrire una
Qualità del Servizio end-to-end per singolo flusso invece che a
IP-QoS ci si riferisce a IP-CoS (Class of Service) [19] .
- Come già
detto la proposta Internet Differentiated Services risulta più grezza
rispetto alla soluzione architetturale di tipo Internet Integrated Services
e l'elemento chiave che ne consente la scalabilità è rappresentato
dal fatto di poter servire in modo differenziato non ciascuna singola sessione
di traffico (flusso) ma un aggregato di flussi anche eventualmente eterogenei
tra loro.
- Ogni operatore
grazie a queste funzionalità, configurando opportunamente i propri
router poteva fare in modo che nell'attraversare un certo numero di nodi
i diversi aggregati di traffico (EF, AFxy, Best Effort) ricevessero un
trattamento di forwarding (PHB) differenziato es. riservando un'aliquota
garantita dalle banda al traffico EF e consentendo di ripartirsi in modo
fair (conformemente alle diverse priorità) le restanti risorse per
le classi AFxy (con drop precedence stabilità dall'indice y).
- Naturalmente
la classe Best Effort avrebbe potuto utilizzare solo le risorse non impiegate
dalle classi AF ed EF a privilegi maggiori. Molti operatori impiegano l'approccio
Internet Differentiated Services per riuscire a gestire in modo differenziato
il trasporto delle informazione sulle proprie infrastrutture di rete (in
particolare quelle multimediali interattive rispetto alle altre). La soluzione
Diffserv si è quindi diffusa in modo statico.
- Per ciascuna
porta d'uscita tipicamente si allocavano le aliquote di banda associate
ai diversi aggregati di traffico (EF, AF). Si osservi inoltre come l'instradamento
sulla rete continuava ad essere deciso da tecniche di instradamento tradizionali
che non tenevano minimamente in conto lo stato di occupazione delle risorse
sui diversi link della rete.
- Come più
volte osservato il forwarding è un problema completamente autonomo
rispetto al routing e come tale, anche in questo caso avrebbe potuto essere
affrontato introducendo tecniche di tipo CBR (Constrained Based Routing)
o QoS-Routing che invece non si diffusero minimamente sugli apparati commerciali.
- La lezione imparata
sul piano di controllo nell'ambito della proposta Internet Integrated Service
viene completamente dimenticata o quando meno subordinata ad una sorta
di "rinegoziazione degli aggregati" che poteva avvenire agendo
con un protocollo che potrebbe apparire come una via di mezzo tra un protocollo
di segnalazione ed un protocollo di gestione della rete (COPS - Common
Open Policy Service).
- Mentre quindi
a livello di trial basati su Software Router si sono moltiplicate, soprattutto
a livello universitario, le iniziative rivolte alla realizzazione di un
router Diffeserv che potesse operare anche in modo dinamico su base segnalazione
(ma non segnalazione d'utente!!) anche in un contesto multidominio (utilizzando
tipicamente per ogni rete controllori delle risorse centralizzati denominati
Bandwidth Broker) a livello di apparati commerciali non si è mai
diffusa la modalità di impiego di Class of Service Differenziate
allocabili in modo dinamico.
- Mentre quindi
stavano prendendo sempre più piede le tecniche di segnalazione end-to-end
di tipo VoIP (h.323, SIP, ecc) o per il controllo di flussi video (si pensi
anche solo alla necessità di segnalare a remoto Fast Forward, Stop,
Reply in casi di video streaming) non esistevano tecniche standard per
accoppiare questo tipo di segnalazione alle parametrizzazioni degli scheduler
che avrebbero consentito di modificare le allocazioni delle risorse all'interno
dei nodi ed in rete.
- È mancata
soprattutto una vera e propria ingegnerizzazione del traffico della rete
anche perché come già detto l'azione del routing continuava
ad essere completamente autonoma rispetto a queste nuove possibilità
offerte a livello di forwarding del nodo.
5.
LE PROPOSTE DIFFSERV OVER MPLS E DIFFSERV-AWARE MPLS TRAFFIC ENGINEERING
- È forse
per questo che l'Internet Differentiated Services si sposò immediatamente
con una nuova architettura di forwarding denominata MPLS capace di fornire
un routing esplicito di flussi di traffico denominati LSP (essi non sono
altro che circuiti virtuali e, si noti bene, MPLS è una tecnica
orientata alla connessione!).
- Nacque così
una terza evoluzione di una architettura IP con Qualità del Servizio
denominato Diffserv over MPLS al quale fece seguito un ulteriore quarta
evoluzione denominata Diffserv Aware MPLS traffic Engineering caratterizzato
dall'introduzione del nuovo concetto delle "Traffic Engineering Classes"
caratterizzate da certi "class types".
- Senza entrare
in alcun dettaglio su queste ultime due proposte è molto importante
però sottolineare come ancora una volta nel processo evolutivo che
ha portato a definire architetture ancora più complesse (questa
volta capaci di impiegare una segnalazione di tipo RSVP-TE ed un routing
OSPF-TE corrispondenti ad estensioni Traffic Engineering - TE del protocollo
RSVP e del protocollo OSPF) non si sia sviluppato un approccio di ottimizzazione
delle risorse all'altezza delle flessibilità delle funzioni introdotte.
- Con l'estensione
Traffic Engineering si riassume sostanzialmente la capacità dell'architettura
di far fare al traffico il percorso che si desidera o di riconfigurare
rapidamente i percorsi del traffico sulla rete in caso di guasto (fast-restoration,
protection).
- Nell'architetture
più evoluta DS-TE (Diffserv Aware MPLS Traffic Engineering) il routing
con Qualità del Servizio si sposa con una rete in grado di offrire
servizi differenziati e funzionalità di traffic engineering. Purtroppo
però l'ingegneria del traffico delle reti a commutazione di circuito
che ha guidato per circa 100 anni l'ottimizzazione delle risorse (allocate
in modo dinamico) della rete telefonica non ha corrispondenze nel mondo
della commutazione di pacchetto basate sulla multiplazione statistica.
- La cosa si complica
se pensiamo che gli aspetti relativi al supporto della qualità del
servizio in una rete in grado di offrire Virtual Private Network e Traffic
Engineering dovranno essere sempre più integrati con gli aspetti
di affidabilità e sicurezza della rete unitamente, come già
detto agli aspetti di consumo energetico.
- Ecco perché
certamente alcuni ricercatori di tutto avrebbero voluto scrollarsi dalle
spalle la pesante eredità dovuta dalle "filosofie portanti"
che hanno caratterizzato gli sviluppi della rete ridefinendo "from
scratch", da zero, un'architettura capace di offrire queste caratteristiche
funzionali a fronte di un'elevata ingegnerizzazione del sistema complessivo.
6.
PIATTAFORME DI RETE PER LA SPERIMENTAZIONE DI SOLUZIONI "FUTURE INTERNET"
- Chi scrive è
certamente tra coloro che sostiene che troppo poco è stato fatto
fino ad oggi per consentire di abilitare a fianco della tradizionale architettura
TCP/IP sperimentazioni a livello nazionale ed internazionale che consentano
indipendentemente da qualunque scelta tecnologica pregressa di virtualizzare
tipologie di rete alternative.
- In particolare
ritengo che tale percorso non possa essere condotto senza tornare ad occuparci
delle funzionalità in hardware che dovranno caratterizzare la realizzazione
di apparati ad elevate prestazioni.
- Tale hardware
nel futuro dovrà essere non solo riprogrammabile ma anche riconfigurabile
al più basso livello logico di progettazione elettronica e questo
avverrà "a software" impiegando prevalentemente componenti
quali Network Processor e FPGA.
- Mentre quindi
certamente a livello applicativo stiamo assistendo al diffondersi di "overlay"
alternativi in grado di consentire anche su vasta scala la sperimentazione
di proposte funzionali in tutti quei casi dove le prestazioni della rete
non sono rilevanti a livello di trasporto dell'informazione spesso ci si
accontenta di poter offrire emulazioni di circuito su reti IP (pseudowire
emulation).
- Si resta cioè
completamente vincolati alle prestazioni di basso livello ottenibili da
una rete a commutazione di pacchetto di tipo IP/MPLS mentre si dovrebbe
poter virtualizzare il funzionamento concorrente di più stack architetturali
a livello di nodo di rete e non di macchina virtuale a livello software.
- L'hardware deve
poter essere "affettato" in "slices" che consentano
di sperimentare nuove tipologie di apparato che possono eventualmente condividere
sullo stesso link fisico tipologie di pacchetto completamente alternative.
CONCLUSIONI
- Si è
accennato all'evoluzione di proposte architetturali che consentono di trasformare
l'Internet attuale in una infrastruttura in grado di offrire servizi differenziati
integrati in alcuni casi con le funzionalità di traffic engineering
e virtual private networks gestite mediante MPLS.
- L'analisi di
casi di questo tipo evidenzia come gradualmente vengano introdotte nuove
funzionalità aggiuntive da svilupparsi rispettivamente dentro i
nodi della rete, alla periferia della rete e talvolta quali supervisori
di ogni singolo dominio amministrativo di rete nuove funzionalità
che in qualche modo rappresentano un "aggiustamento" delle funzionalità
dell'Internet tradizionale al fine di superare alcuni limiti strutturali
dell'architettura TCP/IP.
- C'è chi
sostiene che questa architettura in realtà non esista e che il modello
evolutivo rappresenti di per se una delle caratteristiche più significative
della rete. Resta il fatto che numerose iniziative governative a supporto
degli sviluppi della rete del futuro (es. Progetto GENI negli Stati Uniti
e progetto FIRE in Europa) iniziano a mettere in evidenza il fatto che
proprio i nuclei storici portanti delle funzionalità della rete
(es. IP, o protocolli quali TCP e UDP) da sempre considerati l'elemento
centrale, il collante universale della rete, divengano oggi gli elementi
di progressiva sclerotizzazione (si usa il termine ossification) della
rete.
- È per
questo motivo che proprio come ai tempi delle prime esperienze di Arpanet,
Alohanet, Ethernet diverse field trial si stanno sviluppando sia a livello
di overlay applicativo (molto spesso in modalità peer-to-peer) sia
(molto più raramente) con l'obiettivo di realizzare infrastrutture
di rete in grado di accogliere proposte funzionali drasticamente alternative
all'Internet attuale (approcci clean-slate).
- La riflessione
sull'IP-QoS non evidenzia solo il patchwork condotto per "sistemare
l'architettura" della rete quanto l'esigenza di funzionalità
che siano basate su solide basi metodologiche e su un'ingegneria della
rete che come in tutti gli altri campi dell'ingegneria sia rivolta alla
scoperta di soluzioni ottimizzate, adattative, autonomiche (come spesso
di usa dire) ma fondate su un approccio robusto, ragionato e quantitativo
di progetto della rete stessa.
|
